portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott T Weaver <scotts-jetspeed-l...@binary-designs.net>
Subject Re: [jira] Commented: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context
Date Fri, 28 May 2004 15:06:50 GMT
I know Matthew Baird from OJB fairly well. He is also evaluating using
J2 for his company's portal product.

On Fri, 2004-05-28 at 09:58, Ate Douma wrote:
> 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,
> 
> Ate
> 
> > 
> > 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
> >>o.a.j.components.portletentity.PortletEntityImpl,
> >>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
> >>this.
> >>
> >>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
> >>compliance).
> >>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
> >>anymore. 
> >>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
> >>
> >>Description:
> >>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
> >>solution
> >>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
> >>this.
> >>
> >>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
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> > 
> > ---------------------------------------------------------------------
> > 
> >>JIRA INFORMATION:
> >>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
-- 
******************************************
*           Scott T. Weaver              *
*         <weaver@apache.org>            *
*     <http://www.einnovation.com>       *   
* -------------------------------------- *
*   Apache Jetspeed Enterprise Portal    *
*     Apache Pluto Portlet Container     *
*                                        *
* OpenEditPro, Website Content Mangement *
*     <http://www.openeditpro.com>       *
******************************************


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


Mime
View raw message