portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [jira] Commented: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context
Date Fri, 28 May 2004 13:58:04 GMT
David Le Strat wrote:

> Ate,
> I think we should cross post your comments on the OJB
> and Jetspeed development lists and initiate a
> discussion around this. 
> I also think we should do the same regarding the
> Tomcat JAASRealm issue.
> What do you think?
I have no objections, only not much hope they would wanna fix this themselves (any time soon).
The comments in their current form are also too J2 specific to have much effect. I think they
must be rewritten as 
proper questions targeted at each list.
I can do that but actually don't feel like it right now (I'm swapped with other issues myself
which got delayed already 
too much because of all this).

I think what might be more effective is a direct discussion with some of their lead developers.
Maybe I've overlooked some solutions they might see.
A few weeks back David Taylor invited Brian McCallister to discuss our problems with OJB.
Inviting him back to discuss the current issue might be an idea?
Also, if someone knows Remy Maucherat from Tomcat maybe he could be invited to discuss our
problems with the JAASRealm.
I don't have the contacts yet ;-) to do so but maybe David Sean Taylor, you or someone else?



> Regards,
> David.
> --- jira@apache.org wrote:
>>The following comment has been added to this issue:
>>     Author: Ate Douma
>>    Created: Fri, 28 May 2004 5:26 AM
>>       Body:
>>I think I have found solution which I think might be
>>the easiest way to go.
>>There is one big consequence that I don't like but
>>it applies to any other valid solution we have come
>>up with so far (except patching the Tomcat
>>ClassLoaders or OJB itself which I personally don't
>>see as acceptable options). I will come back to this
>>consequence below.
>>What I did was moving all the classes which OJB
>>might instantiate dynamically (using the
>>currentThread contextClassLoader) into commons.
>>This involves *all* the om classes, a few ojb util
>>classes like the FieldConversion implementations,
>>and the OJB jar itself.
>>I also needed to refactor the
>>StoreablePortletDefinitionDelegate which was
>>dependent on PersistencyStore. I solved that by
>>creating a new interface
>>(PortletDefinitionStoreDelegate) which defines
>>handling the store functionality and a
>>implementation class of which a
>>StoreablePortletDefinitionDelegate gets supplied in
>>its constructor.
>>Furthermore, I moved registry
>>which really is an om class, to a new commons
>>package o.a.j.om.common.entity.impl. I guess this
>>one was overlooked in abstracting the om classes.
>>Thats all.
>>All the current classloader issues are solved by
>>Because I moved all these om packages to commons we
>>will lose the cvs history on all these files though.
>>Thats bad, but the price of still using cvs.
>>There is one more big consequence though which
>>should be considered before this is applied (I will
>>attach a patch file after this comment).
>>Moving the ojb jar to tomcat shared/lib means that
>>external portlet apps which also want to use ojb
>>really are forced to use the version supplied by J2.
>>In theory, a web-app can supply its own version of
>>ojb in its WEB-INF/lib folder and it *will* override
>>the version in shared/lib (servlet api spec
>>But, because J2 also uses OJB, om objects loaded
>>through J2 will have a different classloader as the
>>ones loaded through a portlet app.
>>Thus, this locks portlet developers who want to use
>>OJB (but, who would, honestly?) into the version
>>supplied by J2 (and are not even allowed to put the
>>same version in their WEB-INF/lib folder).
>>Currently, I don't see how this can be prevented
>>though. If we don't want to put OJB into shared/lib
>>we will have to hack the Tomcat classloaders, or
>>hack OJB itself for not using the ContextClassLoader
>>I think the OJB team made a wrong decision how to
>>implement the dynamic classloading. In its current
>>form OJB cannot be used by any web application using
>>cross-context functionality without the same
>>consequence. Maybe they can be convinced to change
>>this but I don't see that happen overnight and we
>>need a solution now...
>>If we are going for this solution then we can go
>>full speed ahead again. 
>>But we must be very careful not (re)introducing
>>these kind of problems. Maybe not only OJB causes
>>these kind of problems.
>>The rules to prevent this are simple:
>>1) Put all classes which might get dynamically
>>created through the ContextClassLoader by a external
>>web app into shared/lib.
>>2) If one of those classes need an object reference
>>only available to J2 itself, Dependency Injection is
>>required based on interfaces in shared/lib (like I
>>did with StoreablePortletDefinitionDelegate).
> ---------------------------------------------------------------------
>>View this comment:
> http://issues.apache.org/jira/browse/JS2-56?page=comments#action_35764
> ---------------------------------------------------------------------
>>View the issue:
>>  http://issues.apache.org/jira/browse/JS2-56
>>Here is an overview of the issue:
> ---------------------------------------------------------------------
>>        Key: JS2-56
>>    Summary: Objects Fail to Create with Tomcat
>>Classloaders and cross context
>>       Type: Task
>>     Status: Open
>>   Priority: Major
>>    Project: Jetspeed 2
>> Components: 
>>             Components Core
>>   Fix Fors:
>>             2.0-dev/cvs
>>   Versions:
>>             2.0-a1
>>   Assignee: David Sean Taylor
>>   Reporter: David Sean Taylor
>>    Created: Tue, 25 May 2004 9:35 PM
>>    Updated: Fri, 28 May 2004 5:26 AM
>>Environment: Tomcat 4 and 5
>>J2 uses a cross-context class loader to share
>>objects created in the jetspeed context with other
>>portlet application contexts. This works fine when
>>objects have already been instantiated in the
>>jetspeed context. 
>>J2 infuses a common servlet into every portlet
>>application that is deployed into a Tomcat
>>application server via the J2 portal's PAM (Portlet
>>Application Manager). The code that runs in this
>>servlet is placed in Tomcat's shared/lib directory
>>so that both Jetspeed common servlet and the
>>Jetspeed portal can share objects. 
>>The problems I am seeing with this approach are
>>rooting in the creation of new objects. For example,
>>if a portlet application, such as the HW_App, has a
>>portlet UserInfo, that requires creation of
>>preference objects. Preference objects by OJB.
>>Looking at the code used by the ojb object broker
> http://cvs.apache.org/viewcvs.cgi/db-ojb/src/java/org/apache/ojb/broker/util/ConstructorHelper.java
>>you see object creation taking place as:
>>  result = constructor.newInstance(NO_ARGS);
>>And this code fails, class not found exception. It
>>fails to find the object to be created, such as a
>>NodeImpl, which is deployed in the Prefs jar,
>>normally stored under jetspeed's WEB-INF/lib
>>directory. This tells me that the classloader being
>>used by the code above is not the same as the
>>cross-context classloader in Tomcat...or...the
>>Tomcat cross-context class loader is not designed to
>>handle this kind of object construction.
>>I think we have several directions we can take for a
>>One experiment I tried with Tomcat 4.1.30, was:
>>1. move every jar out of WEB-INF/lib into shared/lib
>>2. delete all classes under WEB-INF/classes
>>3. copy jetspeed-2.0-a1.jar into shared/lib
>>4. move the JDBC driver into Tomcat's system
>>directory or into the classpath
>>This seemed to work, although for some reason I
>>could not login to the LoginPortlet tonight. Not
>>sure if its related. The solution is simple here:
>>move everything down into shared/lib. 
>>A second solution would be to replace Tomcat's
>>cross-context class loader with our own.
>>Although I have not found a 'pluggable' way to do
>>A third solution would be to modify the classloader
>>in the Jetspeed common servlet.
>>I have started some testing in this area without any
>>success (yet):
> http://cvs.apache.org/viewcvs.cgi/jakarta-jetspeed-2/commons/src/java/org/apache/jetspeed/container/JetspeedContainerServlet.java
>>see the infuseClasspath method
> ---------------------------------------------------------------------
>>This message is automatically generated by JIRA.
> === message truncated ===
> __________________________________
> Do you Yahoo!?
> Friends.  Fun.  Try the all-new Yahoo! Messenger.
> http://messenger.yahoo.com/ 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message