> Ultimately every component deployed onto Jetty will be
> self-contained, i.e. not expect to find any filesystem
> outside it's own deployment. Jetty also will act in
> the same way.
Ok.
> At the moment, we are in a state of flux. You have
> fixed Jetty's two main dependencies on external files
> (it's config and webdefault files) by copying them
> into a jboss config directory.
I think that Hiram did that, but ok.
> The problem is that Jetty's static config file, is
> referencing a number of things as filesystem objects,
> which it expects to find somewhere in a tree.
>
> 1. drop this legacy stuff entirely, until it is
> properly packaged.
What does this entail?
> 2. merge the Jetty and JBoss distribution trees, so
> that Jetty will find it's tree on every cluster, since
> it is now part of the core JBoss installation tree.
I don't understand how this helps the configuration problem. It just
changes to maintenece from updating jars to updating source & build system
integrations.
> 3. some combination of the above.
>
> In fact, we are already looking at 3, since we have
> moved components of the Jetty tree into the JBoss
> tree.
What do you mean moved components here?
> I guess I should just strip verything else out of the
> config file and possiby even look at doing the
> remaining configuration via JBoss' standard config
> mechanism - I'll get onto it.
>
> For the moment simply set JettyHome to point to a
> valid Jetty-3.1.RC9 tree (in jetty-service.xml) and
> everything should start up fine. (It has to be RC9
> because of the repackaging).
>
> however all is not well. There are some runtime
> issues.
What does it need from the jetty dist? Lets put that in
plugins/jetty/src/...
> 1. JSPs do not work.
>
> In order to find the Jasper JSP Servlet, Jetty needs
> access to the org.apache.jasper.jar with which it
> ships. I got this working on the train this morning by
> copying the jar into thirdparty/mortbay/jetty/lib
> (whilst you are in there, the jaxp jar does not seem
> to be needed).
Done.
> 2. JSPs will still not work !
>
> Although Jetty will start up OK, when you request a
> JSP it's compilation fails, because Jetty cannot
> locate the classes held in javac.jar. I tried putting
> this in jetty/lib, although this is really the wrong
> place for it since it should be a shared resource. The
> compile started, but javac could not see the Jasper or
> javax.servlet.jar classes, although Jetty was able to
> find them at startup.
Any clues as to why this is broken?
> I don't know enough about how JBoss' ClassLoader
> system works to guess at what is happening, but this
> same Jetty release works perfectly in JBoss-2.4, so
> something very different is happening in RH.
Perhaps the jetty-service.xml needs to be explict about the <classpath> it
needs?
> 3. Aside from JSPs not working, a SOAP service that
> deploys fine on 2.4 is failing to load a class stored
> in war/WEB-INF/lib/activation.jar, because it has
> already been loaded. I was looking at this until I was
> drawn away by the repackaging issues.
Why would it fail to load? Shouldn't the webapp use its own cl which uses
the mbean cl as it's parent (so classes in lib/* will take precidence)?
> If you can tell me anything about how ClassLoaders are
> structured within RH, this would be most useful in
> trying to figure out what is going on with Jasper and
> SOAP. Or perhaps I should address this one to Marc?
This is a Marc question... I have not had time to dive into the wonderland
of rabbit-hole details (yet).
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
