|I was getting nasty errors when trying to make |optimised calls from the web to the ejb container. | |It seems that while JBoss is aware that both client |and server objects exist within the same vm, it was |upset that the call was being serialised, instead of |just simply made natively, and wanted to tell me about |it. | |So I investigated.... | |Along the path that an invocation must make from web |to ejb container a test (Class.isAssignableFrom()) is |made to establish whether the call can be made between |two ClassLoaders without serialisation.
I am going to remove this test but it doesn't fix the problem. |Jetty has 2 modes in which it can run the ClassLoader |used for WebApps. | |1. Java 2 compliant - all requests for classes are |delegated first to it's parent. | |Using this strategy you may get bitten if your webapp |uses e.g. different versions of the same |infrastructure than it's container - since the |container's copies will be used in preference. |Problems also occur with abstract APIs (e.g. JAXP), |loaded by the container, looking for implementations |which the webapp contains, but the container does not |ship with. Right this is afaik the only way to make integration work, unless there is physical sharing for CL. I could be wrong. The problem you describe is not a limitation of the model but really a BUG in the application code, really you should always start by looking for classes from the CL context. The way to do this is to always set the parent of the cl you build from the context. You are done. |2. Non-compliant - only requests for system classes |are passed upwards. Don't do this, you essentially shoot all possible integration by always using the Jetty CL. If you have classes that are duplicated then you are shot for sure. |This strategy resolves the problems listed against (1) |but causes the isAssignableFrom() test mentioned above |to fail. What appears to happen is that JBoss passes of course |ClassLoader A to the EJB container which loads class X |then on to Jetty which creates it's WebApp |ClassLoader, B, as a child of A, then asks B to load |class X. B does not delegate to A, but loads class A |for a second time. because you don't delegate. Again it is a bug in the client app if you don't set the parent. Also why in the world would you do away with delegation in integration? The "bug" you describe above, is it the only reason? if so then that is a bit strange. |Scott, If you could explain a little about the |architecture of ClassLoaders in JBoss3, Greg and I may |be in a better position to figure out how to get this |going. It is simple rh cls will enable you to get visibility on all apps packaged classes. If Jetty uses the contextCL and we always call jetty from JBoss then you leverage this. The fact that you won't get a ClassCast is a by-product of integration not of the scope. Then the scope buys you something more powerful. In this first case you still need to package all the classes with the application. The scope CL enables you to do away with this. We will have scope at the app level and scope at the system level. I will code that. If jetty uses the RH cl directly, as it should when we actually integrate the codebases then the problem is natively taken care of, you will see the classes directly. It will make for superior packaging (lack of) where right now you have a nightmare of "where did I put my classes". |Greg, I guess we are looking at pluggable |ContextLoader strategies - stand-alone, jboss etc... Again setting the parent to all your cls from context and not dissabling delegation is the simplest thing to try, you will use RH cl implicitely by delegation. It works standalone and jboss integration and you still use your own little cl stuff. INtegrated Jetty will need to use the RH cl. |WebSphere seems to have a highly configurable |ClassLoader system, and I think it is unlikely that |there is a one-size-fits-all solution here. bullshit, webshemere still doesn't support hot-deploy which tends to indicate a primitive usage of classloaders. I could be wrong there, I don't know webshemere. marcf |Sorry to complicate your mornings guys, | | |Jules | | |__________________________________________________ |Do You Yahoo!? |Everything you'll ever need on one web page from News and Sport to |Email and Music Charts |http://uk.my.yahoo.com | |_______________________________________________ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
