Different classpath for Servlet vs. JSP in the same containi

[sash]

First up, kudos to JBoss's authors and maintainers. JBoss is superb.

I'm using:

- NT4
- J2SDK-1.3.0
- JBoss-2.2.2_Tomcat-3.2.2

I'm just starting to experiment with JBoss and have discovered something a little odd.

- When I want a Servlet to use an EJB (e.g. the Interest example), it can simply import and use it. This means (i) the home and remote classes are in my own classpath at compile time and (ii) they are in the relevant JBoss classloader's classpath once the .ear is deployed.

- When I want a JSP inside the same .war file inside the same .ear file to use the same EJB, it can't. Instead the stacktrace below appears. This suggests that, while the deployed environment for the contents of the .war file includes the EJBs declared in the .ear's application.xml (or thereabouts), the environment used for invoking the Java compiler to compile the .JSP files from the same .war file does not include those EJBs in its classpath. I have found that copying the EJB's .jar file into the .war's lib/ directory causes things to work again, but this duplication seems wasteful and (potentially) bug-inducing.

Is there a better way? Is this a JBoss bug? Is this simply a consequence of the J2EE spec?

Thanks.

--

Error: 500
Location: /Test.jsp
Internal Servlet Error:

org.apache.jasper.JasperException: Unable to compile class for JSPE:\bin\jboss.org\JBoss-2.2.2_Tomcat-3.2.2\tomcat\work\localhost_8080\_0002fTest_0002ejspTest_jsp_1.java:13: Class org.jboss.docs.interest.Interest not found in import.
import org.jboss.docs.interest.Interest;
^
1 error

at org.apache.jasper.compiler.Compiler.compile(Compiler.java:282)
at org.apache.jasper.servlet.JspServlet.doLoadJSP(JspServlet.java:612)
at org.apache.jasper.servlet.JasperLoader12.loadJSP(JasperLoader12.java:146)
at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:542)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary(JspServlet.java:258)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:268)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:429)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:500)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405)
at org.apache.tomcat.core.Handler.service(Handler.java:287)
at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797)
at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:213)
at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501)
at java.lang.Thread.run(Unknown Source)

[mattmead]

Question:

How do I configure an MDB to talk to remote queue.

Answer:

You need to configure a remote provider (this is similar to local one in jms-ds.xml)
Note:
1) The name changes with "Whatever" to avoid conflicts with default
2) The ProviderUrl used for jndi
3) Use external Queue/Topic ConnectionFactory

 <mbean code="org.jboss.jms.jndi.JMSProviderLoader" name="jboss.mq:service=JMSProviderLoader,name=RemoteMQProvider,server=Whatever">
 <attribute name="ProviderName">WhateverJMSProvider</attribute>
 <attribute name="ProviderUrl">jnp://whatever:1099</attribute>
 <attribute name="ProviderAdapterClass">
 org.jboss.jms.jndi.JBossMQProvider
 </attribute>
 <attribute name="QueueFactoryRef">UIL2XAConnectionFactory</attribute>
 <attribute name="TopicFactoryRef">UIL2XAConnectionFactory</attribute>
 </mbean>

Then provide your own invoker binding that uses this provider to deliver
messages to the mdb this is either in jboss.xml or standardjboss.xml:

 <invoker-proxy-binding>
 <name>whatever-message-driven-bean</name>
 <invoker-mbean>whatever</invoker-mbean>
 <proxy-factory>org.jboss.ejb.plugins.jms.JMSContainerInvoker</proxy-factory>
 <proxy-factory-config>
 <JMSProviderAdapterJNDI>WhateverJMSProvider</JMSProviderAdapterJNDI>
 <ServerSessionPoolFactoryJNDI>StdJMSPool</ServerSessionPoolFactoryJNDI>
 <MaximumSize>15</MaximumSize>
 <MaxMessages>1</MaxMessages>
 <MDBConfig>
 <ReconnectIntervalSec>10</ReconnectIntervalSec>
 <DLQConfig>
 <DestinationQueue>queue/DLQ</DestinationQueue>
 <MaxTimesRedelivered>10</MaxTimesRedelivered>
 <TimeToLive>0</TimeToLive>
 </DLQConfig>
 </MDBConfig>
 </proxy-factory-config>
 </invoker-proxy-binding>

Finally use the invoker proxy binder for your mdb in jboss.xml:

 <enterprise-beans>
 <message-driven>
 <ejb-name>MyMessageBean</ejb-name>
 <configuration-name>My Message Driven Bean</configuration-name>
 <destination-jndi-name>queue/myQueue</destination-jndi-name>
 <invoker-bindings>
 <invoker>
 <invoker-proxy-binding-name>whatever-message-driven-bean</invoker-proxy-binding-name>
 </invoker>
 </invoker-bindings>
 </message-driven>

Regards,
Adrian

[surdules]

I've noticed the exact same behavior. This seems like a relatively easy bug to fix, and it would make a great deal of difference in terms of usability.

[emoogee]

Have you got a solution for this problem yet?

[ldevrie]

I am not sure if this is the answer to your problem, but have you tried providing a MANIFEST.MF that contained your needed classpath(s)? Just a thought that worked for me.

[ceolter]

Hi Guys,

I'm having the exact same problem. Can someone please explain what classpath is being used for jsp compilations? I tried using the class-path in the manifest.mf but this doesn't work for me. Putting the jar as a resource inside the war works, so does expanding the classes into the classes directory within the war, however this goes against the modularisation idiom and also opens oppertuinities for classes to be loaded twice from different class loaders (i think) and thus class cast problems come about.

[jeffhalleux]

Could someone post a directory structure / with manifest file that actually works with JSP ?
Obviously there are classpath problems with JBoss2.4.3.

Alternatively, may I suggest that the example application (speed test) be written using JSP, so we can all learn from it.

[kuding2000]

My solution is:

jar all needed classes including EJBs in one jar and deply it to JBOSS_DIST/lib/ext, then you don't need to put EJB classes into your WAR.

the disadvantage is if I changed some JSP and rebuild WAR and then deploy it. I have to restart JBoss or else it will report class not found exception.

[jeffhalleux]

Hmmm... looks a little "extreme" to me.
Anyone else with a more acceptable solution ?

[danch1]

This is a common problem with Jasper (the JSP implementation that's in more and more web containers). When it compiles, it doesn't get the extended classpath that it should have being in a war in an ear. You get the ClassNotFound on compile of the JSP only.
Two things you can try:
1. Use Catalina (Tomcat 4)
2. Precompile your JSPs - this should allow you to override the classpath at that time.