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. > > > > --- [EMAIL PROTECTED] 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- ****************************************** * Scott T. Weaver * * <[EMAIL PROTECTED]> * * <http://www.einnovation.com> * * -------------------------------------- * * Apache Jetspeed Enterprise Portal * * Apache Pluto Portlet Container * * * * OpenEditPro, Website Content Mangement * * <http://www.openeditpro.com> * ****************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
