Exploring Soashable

[Jim Carroll]

Hello,

I'm trying to set up OpenFire and Soashable together, and am
completely new to maven.

I've followed the steps on getting-started, and I had to skip unit
tests on both xmpp4j and soashable. Each failed with a single Null
pointer error.

So after watching tons of maven download messages, I have a working
soashable on my machine, but I have no idea what to do next.

How can I configure soashable to use my local OpenFire? Is it using
originator:5222 by default?

OpenFire embeds Jetty, and soashable has its own jetty instance... but
I eventually want to build my site using TurboGears. Can I use what's
in soashable-web/src/main/javascript and resources and serve them up
with any other web server?

I've gotten some hints from various web posts that there are some
scaling issues with the current approach... Should I be concerned?
How can I help?

I've got OpenFire's bridge installed, but not configured. I want to
set it up to bridge to at least AIM initially... are there any
configuration details that soashable needs?

Thanks! I can see a lot of hard work has gone into Soashable!
-Jim

[Harlan Iverson]

Hello Jim, thanks for writing the list. Responses are inline

On Thu, May 8, 2008 at 10:29 AM, Jim Carroll <mrm...@gmail.com> wrote:

Hello,

I'm trying to set up OpenFire and Soashable together, and am
completely new to maven.

I've followed the steps on getting-started, and I had to skip unit
tests on both xmpp4j and soashable.  Each failed with a single Null
pointer error.

Can you include the failure traces? I believe 'mvn -e -X test' will give the details.
 

So after watching tons of maven download messages, I have a working
soashable on my machine, but I have no idea what to do next.

Were there any rough spots aside from the test failures, or details you think would have been helpful to include? I definitely want to make it as easy as possible for people not familiar with Maven.
 

How can I configure soashable to use my local OpenFire?  Is it using
originator:5222 by default?

I think it's configured to soashable.com:5222 in Soashable.js. Not ideal, but it is what it is ;]. I created an issue for it:

http://code.google.com/p/soashable/issues/detail?id=60
 

OpenFire embeds Jetty, and soashable has its own jetty instance... but
I eventually want to build my site using TurboGears.  Can I use what's
in soashable-web/src/main/javascript and resources and serve them up
with any other web server?

In its current state I think it can be run off any web server, but there is some stuff that won't work like the TokBox API (A/V Chat) because it is powered by a Servlet. The lowest recommendation for upgradability I can make is any Servlet container, including Jetty.

Something else that could happen is there could be a "light" version that does not contain any of the extra Servlet based features.
 

I've gotten some hints from various web posts that there are some
scaling issues with the current approach... Should I be concerned?
How can I help?

The current approach is really limited by the fact that it ties up threads if you're connecting straight to the Servlet port, and Threads + Apache processes if you're connecting through mod_jk.

I recommend the non-mod_jk approach simply because static content is such a small part of this app that the added complexity and overhead isn't worth the small potential performance gain; Jetty is also very fast.

One thing that I have been investigating for a while is the use of Jive Software's Connection Manager servlet . I've been posting my findings in the issue http://code.google.com/p/soashable/issues/detail?id=48 . This uses Jetty Continuations which claims ability to hold a mammoth amount of long-running connections using very few resources.

If you have time to spare, I'd love if you could continue on the line of exploration I've started in this issue.

 

I've got OpenFire's bridge installed, but not configured.  I want to
set it up to bridge to at least AIM initially...  are there any
configuration details that soashable needs?

There's nothing special, but I believe like the hard-coding of soashable.com, aim.soashable.com is hard coded into Soashable.js and maybe a few other places as well. The same issue applies where I'd like to strip all of that out into a properties file.

[Jim Carroll]

> > I've followed the steps on getting-started, and I had to skip unit
> > tests on both xmpp4j and soashable.  Each failed with a single Null
> > pointer error.
>
> Can you include the failure traces? I believe 'mvn -e -X test' will give the
> details.

for xmpp4j I ran the -e -X test, and I see the problem:

Fri May 09 00:58:53 PDT 2008: StandaloneTest: launching c:/program
files/Mozilla Firefox/firefox.exe
java.io.IOException: java.io.IOException: c:/program files/Mozilla
Firefox/firefox.exe: not found

I'm on Ubuntu Hardy Heron, so the hard-coded firefox path is failing.

Doing the same for soashable: (and got the same results)

Fri May 09 01:00:43 PDT 2008: StandaloneTest: launching c:/program
files/Mozilla Firefox/firefox.exe
java.io.IOException: java.io.IOException: c:/program files/Mozilla
Firefox/firefox.exe: not found
at java.lang.UNIXProcess.<init>(UNIXProcess.java:148)

> > So after watching tons of maven download messages, I have a working
> > soashable on my machine, but I have no idea what to do next.
>
> Were there any rough spots aside from the test failures, or details you
> think would have been helpful to include? I definitely want to make it as
> easy as possible for people not familiar with Maven.

I wouldn't mind if there was a paragraph or two that helped me
understand why
maven at all? Javascript is supposed to not need a build. Now that I
went through
the process, I see that Maven downloads lots of dependancies and puts
it into
my ~/.m2/repository/ path . It seems most of them have to do with the
server
setup that you have to demonstrate soashable.

As someone who may end up having to get comfortable with the whole
process
it seems very 'black box' or magical. The good news is that it works
though!

So now, if I modify soashable.js, am I going to have to use maven to
'rebuild'
anything? I couldn't say for certain, because I don't understand what
the build
really does.

> I think it's configured to soashable.com:5222 in Soashable.js. Not ideal,
> but it is what it is ;].

Cool, I try pointing that to my server.

> In its current state I think it can be run off any web server, but there is
> some stuff that won't work like the TokBox API (A/V Chat) because it is
> powered by a Servlet. The lowest recommendation for upgradability I can make
> is any Servlet container, including Jetty.

Ok. I don't anticipate wanting A/V chat for a long time, and part of
me wants
to see if I can port the servlet to Python... eventually.

> The current approach is really limited by the fact that it ties up threads
> if you're connecting straight to the Servlet port, and Threads + Apache
> processes if you're connecting through mod_jk.

I've run into that before... I remember something about 80 being the
magic
max number of sockets (or open files of any type) in the past.

> I recommend the non-mod_jk approach simply because static content is such a
> small part of this app that the added complexity and overhead isn't worth
> the small potential performance gain; Jetty is also very fast.

Jetty does rock. I used it to create something like Google maps
once...

> One thing that I have been investigating for a while is the use of Jive
> Software's Connection Manager servlet . I've been posting my findings in the

> issuehttp://code.google.com/p/soashable/issues/detail?id=48. This uses

> Jetty Continuations which claims ability to hold a mammoth amount of
> long-running connections using very few resources.

I've heard that a project called Comet is supposed to address this
too.

> If you have time to spare, I'd love if you could continue on the line of
> exploration I've started in this issue.

Will do.

> > I've got OpenFire's bridge installed, but not configured.  I want to
> > set it up to bridge to at least AIM initially...  are there any
> > configuration details that soashable needs?
>
> There's nothing special, but I believe like the hard-coding of soashable.com,
> aim.soashable.com is hard coded into Soashable.js and maybe a few other
> places as well. The same issue applies where I'd like to strip all of that
> out into a properties file.

Would I point that to openfire's 5222 port? What is the openfire
equivalent of aim.soashable.com?

Thanks again!

[Jim Carroll]

After editing any 'soashable.com' in Soashable.js, and pointing it to
my linux
machine... I ran the mvn commands from getting started again just to
be
sure.

(When I ran mvn jetty compile jetty:run-war I get the error:

firemyweb:~/tmp/soashable/soashable-web # mvn jetty compile jetty:run-
war
[INFO] Scanning for projects...
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Invalid task 'jetty': you must specify a valid lifecycle phase,
or a goal in the format plugin:goal or
pluginGroupId:pluginArtifactId:pluginVersion:goal)

So I ran all the other related mvn commands that show up in that part
of getting started...

I tried to log in or create a user using the Soashable web interface,
I see the soashable console error:

INFO: FileResourceLoader : adding path '.'
[2] sending response [9701]: <body xmlns="http://jabber.org/protocol/
httpbind" condition="remote-connection-failed" type="terminate"/>
May 9, 2008 2:04:20 AM org.apache.velocity.runtime.log.JdkLogChute log
INFO: FileResourceLoader : adding path '.'
[2] sending response [725]: <body xmlns="http://jabber.org/protocol/
httpbind" condition="remote-connection-failed" type="terminate"/>

I can connect to the openfire instance with the Spark IM client... so
I'm pretty sure it's a configuration
issue with soashable.

I appreciate your time!

[Jim Carroll]

My next question is going to be:

How do I tell soashable to bind to port 80 instead of 8080? (I am
running as root.)
I can't find any references to port 8080 in any of:

./pom.xml
./nbactions.xml
./src/site/site.xml
./src/main/webapp/META-INF/context.xml
./src/main/webapp/views/default/registration-1.xml
./src/main/webapp/WEB-INF/web.xml
./src/assembler/soashable-web.xml
./src/assembler/src.xml
./target/work/webapp/META-INF/context.xml
./target/work/webapp/META-INF/maven/com.soashable/soashable-web/
pom.xml
./target/work/webapp/views/default/registration-1.xml
./target/work/webapp/WEB-INF/web.xml
./target/war/work/webapp-cache.xml
./target/soashable-web-1.0-SNAPSHOT/META-INF/context.xml
./target/soashable-web-1.0-SNAPSHOT/views/default/registration-1.xml
./target/soashable-web-1.0-SNAPSHOT/WEB-INF/web.xml

But I did find a ping reference to soashable.com:8180 for
a deployable pingURL. What would I change that to for Openfire?

Thanks

[Harlan Iverson]

Hey,

I've amassed all replies to your messages in one email:

I wouldn't mind if there was a paragraph or two that helped me
understand why
maven at all?  Javascript is supposed to not need a build.  

The reason I started using a build system is to make packaging, documentation generation, automated testing and dependency management a core part of the process. Another guy and I built the Maven Javascript Tools plugin (he did most of the work) while I was building Soashable and Xmpp4Js because we both had the desire to automate these things; this description explains it in a little more depth:

http://mojo.codehaus.org/javascript-maven-tools/

So now, if I modify soashable.js, am I going to have to use maven to
'rebuild'
anything?  I couldn't say for certain, because I don't understand what
the build
really does.

Yea, modifying JS will require a rebuild because it takes all the individual source files and splices them into one, which is ultimately pulled in by the web page. The mvn compile jetty:run-war will be needed.

> One thing that I have been investigating for a while is the use of Jive
> Software's Connection Manager servlet . I've been posting my findings in the
> issuehttp://code.google.com/p/soashable/issues/detail?id=48. This uses

> Jetty Continuations which claims ability to hold a mammoth amount of
> long-running connections using very few resources.

I've heard that a project called Comet is supposed to address this
too.

Right, this BOSH technology is basically the same as COMET. One thing that I would like to do is push for a Bayeux connection manager xep/standard. I know I've spent a lot of time fighting with perfecting my BOSH implementation. Here are more thoughts on that thread from my blog:

http://blog.devspan.com/2007/11/bayeux-jabber-and-xep-0124.html

> If you have time to spare, I'd love if you could continue on the line of
> exploration I've started in this issue.

Will do.

Excellent, I can't wait :)

> There's nothing special, but I believe like the hard-coding of soashable.com,
> aim.soashable.com is hard coded into Soashable.js and maybe a few other
> places as well. The same issue applies where I'd like to strip all of that
> out into a properties file.

Would I point that to openfire's 5222 port?  What is the openfire
equivalent of aim.soashable.com?

Yea, basically the want that BOSH works is you tell the servlet where to 'route' connections to, and that would be a normal XMPP port that you would point a jabber client to. By default, Openfire will have it 'aim.yourdomain.dom'; you can customize this in Openfire Gatway plugin settings.

I tried to log in or create a user using the Soashable web interface,
I see the soashable console error:

INFO: FileResourceLoader : adding path '.'
[2] sending response [9701]: <body xmlns="http://jabber.org/protocol/
httpbind" condition="remote-connection

-failed" type="terminate"/>
May 9, 2008 2:04:20 AM org.apache.velocity.runtime.log.JdkLogChute log
INFO: FileResourceLoader : adding path '.'
[2] sending response [725]: <body xmlns="http://jabber.org/protocol/
httpbind" condition="remote-connection-failed" type="terminate"/>

I can connect to the openfire instance with the Spark IM client... so
I'm pretty sure it's a configuration
issue with soashable.

Yea, it would seem like it's ione of two things.

Either it is still pointing to soashable.com. I had to close the ports to the public because spimmers started abusing it (uhg! I'll open it again as soon as I have time to implement safeguards); have you tried rebuilding it?

If that still isn't the issue, Ubuntu's JVM is very strict by default and I had to turn off their security manager:

http://preview.tinyurl.com/5gu9gs

This thread explains the issue. It's related to another Java webapp, but the same procedure fixed my issue.

My next question is going to be:

How do I tell soashable to bind to port 80 instead of 8080?  (I am
running as root.)
I can't find any references to port 8080 in any of:

 

I haven't done this directly. I set up a firewall rule that forwards port 80 to port 8180 (Tomcat) internally. I've seen reference to people doing it though; if you find a way, would you care to share?

But I did find a ping reference to soashable.com:8180 for
a deployable pingURL.  What would I change that to for Openfire?

I think you're actually seeing the Tomcat manager URL that the Maven Cargo plugin uses (oh, this is another perk of using Maven, is super-simple deployment). There's no equivalent for Openfire proper.


I hope this helps.

Cheers.