You are viewing a plain text version of this content. The canonical link for it is here.

Posted to jetspeed-dev@portals.apache.org by ji...@apache.org on 2004/05/26 06:36:01 UTC

[jira] Created: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
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: Tue, 25 May 2004 9:35 PM
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.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by ji...@apache.org.

Message:

   The following issue has been closed.

   Resolver: David Le Strat
       Date: Wed, 2 Jun 2004 6:00 AM

The ClassHelper patch was applied on OJB by Thomas Dudziak.
I am therefore closing this issue.
---------------------------------------------------------------------
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: Closed
   Priority: Major
 Resolution: FIXED

    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: Wed, 2 Jun 2004 6:00 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.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by ji...@apache.org.

The following comment has been added to this issue:

     Author: David Sean Taylor
    Created: Thu, 27 May 2004 1:14 PM
       Body:
Another solution to consider:
loading User info and preferences when the user logs in
...

I've been reviewing Tomcat's code, and I don't see any pluggable Class loader implementation. I found:

WebappClassLoader
StandardClassLoader
ClassLoaderFactory

For the StandardClassLoader, they Bootstrap creates a hard-coded loader:

            unpacked[0] = new File(getCatalinaHome(),
                                   "common" + File.separator + "classes");
            packed2[0] = new File(getCatalinaHome(),
                                  "common" + File.separator + "endorsed");
            packed2[1] = new File(getCatalinaHome(),
                                  "common" + File.separator + "lib");

I haven't got thru the WebappClassLoader yet, which is really the class loader we need to modify...

Just leaves me wishing Tomcat had pluggable components.

Im also concerned that this approach requires us to manipulate the class loaders for each app server.



---------------------------------------------------------------------
View this comment:
  http://issues.apache.org/jira/browse/JS2-56?page=comments#action_35754

---------------------------------------------------------------------
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: Thu, 27 May 2004 1:14 PM
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.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

Re: [jira] Commented: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by Scott T Weaver <sc...@binary-designs.net>.

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              *
*         <we...@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

Re: [jira] Commented: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by Ate Douma <at...@douma.nu>.

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

Re: [jira] Commented: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by David Le Strat <dl...@yahoo.com>.

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?

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

[jira] Commented: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by ji...@apache.org.

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.

If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira

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

[jira] Commented: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by ji...@apache.org.

The following comment has been added to this issue:

     Author: Scott T Weaver
    Created: Wed, 26 May 2004 6:19 AM
       Body:
We may want to consider using classworlds to manipulate the class loaders.  I played with it when I was working in my other branch and it seemd to take some (not all) of the pain out of class loader manipulation.

The site is usually classworlds.codehuas.org, but it isn't up at the moment.
---------------------------------------------------------------------
View this comment:
  http://issues.apache.org/jira/browse/JS2-56?page=comments#action_35726

---------------------------------------------------------------------
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: Wed, 26 May 2004 6:19 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.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by ji...@apache.org.

The following comment has been added to this issue:

Author: Scott T Weaver
Created: Fri, 28 May 2004 8:26 AM
Body:
Instead of commons, I would prefer creating an om sub-project instead of cluttering commons with implentation classes. Waddya think?
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-56?page=comments#action_35770

---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JS2-56

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 8:26 AM
Environment: Tomcat 4 and 5

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);

I think we have several directions we can take for a solution
One experiment I tried with Tomcat 4.1.30, was:

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.

If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira

[jira] Commented: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by ji...@apache.org.

The following comment has been added to this issue:

     Author: Ate Douma
    Created: Thu, 27 May 2004 8:11 AM
       Body:
I've done some more research and experimenting.

First remark: There is no such thing as a cross-context classloader within Tomcat.
For detailed information about Tomcat (5) classloaders see:
  http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html

The bad news second: Merging the J2 web-app ContextClassLoader with the ContextClassLoader of a portlet web app ourselves will not work with Tomcat. 

I created a MergedClassLoader doing just that which even works.
The problem though, is that when a RequestDispatcher forwards or includes to another resource (servlet, jsp etc.) Tomcat again sets its own ContextClassLoader. This we cannot intercept (and thus not solve) without hacking the Tomcat core.
Even classworlds won't be able to help us out here.

Our problems really are caused by the way classes are loaded dynamically and the (formally correct) ContextClassLoader Tomcat provides for each web app.

When a web app A (e.. portlet app) wants to dynamically instantiate a new class which is local to web app B (e.g. Jetspeed), it needs the classloader of web app B to do so. 
This can easily be done by using the classloader from an already instantiated class from web app B: Class.forName("className",instanceFromWebAppB.getClassLoader());
What clearly won't work is: instanceFromWebAppA.getClass().forName("className").

Our current problems are caused by the way OJB dynamically creates new class instances: Class.forName("className", currentThread.getContextClassLoader()). 
The only way we can get this to work is temporarily setting the correct ContextClassLoader in every method where OJB is accessed like this:
  ClassLoader cl = Thread.currentThread().getContextClassLoader();
  try
  {
    Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());
    // OJB dynamic class instantiating method call
  }
  finally
  {
    Thread.currentThread().setContextClassLoader(cl);
  }

This alone already is a lot of work. but worse, its not enough!
What if the above code returns a lazy/proxied Collection or Iterator. Only when their elements are accessed the instantiation will take place resulting again in a ClassNotFoundException. 
There is no protection against these type of constructs (other then never lazy loading or a proxy)!

Another, more successful, solution would be to patch OJB to use Class.forName("className") instead. Note: the OJB jar *must* be in the J2 web-app lib after that. Hacking external libraries isn't my favorite solution though.

The simplest solution in theory is of course moving the OJB jar, and all classes it needs to load, to the tomcat/shared/lib folder. In practice, this requires moving all the J2 classes and all the jars (but one) to the tomcat/shared folder because almost everything is interrelated to each other (at runtime that is).

I've tested this out. 
The only problem I encountered was getting a connection to the Oracle database because commons-dbcp couldn't find the Oracle driver classes (which are in my case also in tomcat/shared/lib). Very strange. After moving only the commons-dbcp jar back into the Jetspeed web-app lib folder everything worked perfectly. No more ClassNotFoundExceptions at all.

Personally I don't like this solution. All of J2 is shared that way. There really isn't a need for a commons jar anymore because of this. But, we can improve this by only moving all objects which can be dynamically instantiated by OJB to the tomcat/shared folder, including the OJB jar. 

One thing which remains important, even after we have fixed all this, is being very careful with providing access to objects which might be instantiated dynamically using the currentThread contextClassLoader. 
Its not very likely only OJB is doing that... 
---------------------------------------------------------------------
View this comment:
  http://issues.apache.org/jira/browse/JS2-56?page=comments#action_35747

---------------------------------------------------------------------
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: Thu, 27 May 2004 8:11 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.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by ji...@apache.org.

The following comment has been added to this issue:

Author: Ate Douma
Created: Wed, 26 May 2004 8:12 AM
Body:
I've been looking into this as well.

The Tomcat classloader is doing what it is supposed to do: prevent access to the context of other web-apps.

The current state of J2 only works because so many of its classes are already loaded when a portlet is accessed that you don't notice it the current thread has already loaded most from J2 its context.

The problem we have with OJB is that it loads classes dynamically on request. And then only the webapp contextclassloader provided by Tomcat is available to load the new classes. If these are cross web-app it won't work. Period.

So, I suggest trying to infuse the J2 web-app context classpath into the JetspeedContainerServlet as David has already tried.
The suggestion of Scott to look into classworlds for doing this (although the site is indeed offline so I only have looked at cached pages so far) probably will allow us to solve this.

---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-56?page=comments#action_35727

---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JS2-56

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: Wed, 26 May 2004 8:12 AM
Environment: Tomcat 4 and 5

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);

I think we have several directions we can take for a solution
One experiment I tried with Tomcat 4.1.30, was:

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.

If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira

[jira] Commented: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by ji...@apache.org.

The following comment has been added to this issue:

Author: Ate Douma
Created: Fri, 28 May 2004 1:07 PM
Body:
David Sean Taylor wrote:
>So we would now have 3 sub-projects out of commons:
>1. jetspeed-om (om interfaces and implementations)
>2. jetspeed-core-pa (JS2-37)
>3. jetspeed-commons (basically just o.a.j.util)
+1

>Im wondering if we even need #3 ....perhaps they can be moved into #2
Don't forget the util OJB classes which should belong in #3.

>Ate, regarding your patch, didn't you receive your Apache account yet?
:( No. Still nothing...

>If so, no need to send patches, unless you just want us to test it out.
If possible please to test it out. Its working for me but we should be sure about this.

>I prefer that we resolve the issues above before applying Ate's solution to JS2-56 (this issue)
+1

Also, David Le Strat commented on the list about cross posting my comments (also for Tomcat JAASRealm) to OBJ and Tomcat lists to initiate a discussion.
I answered that I would prefer having a more direct discussion with one or more of the lead developers of both products.
I'd like to know what you think of that (please answer on the list). If we should enter a discussion with them maybe we should wait on that as well.
I'm -1 on waiting though.

---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-56?page=comments#action_35786

---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JS2-56

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 1:07 PM
Environment: Tomcat 4 and 5

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);

I think we have several directions we can take for a solution
One experiment I tried with Tomcat 4.1.30, was:

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.

If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira

[jira] Updated: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by ji...@apache.org.

The following issue has been updated:

Updater: Ate Douma (mailto:ate@douma.nu)
Date: Fri, 28 May 2004 5:34 AM
Comment:
One big (676k) multi-file patch implementing the solution I described above
Changes:
Attachment changed to JS2-56-patch.txt
---------------------------------------------------------------------
For a full history of the issue, see:

http://issues.apache.org/jira/browse/JS2-56?page=history

---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JS2-56

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:34 AM
Environment: Tomcat 4 and 5

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);

I think we have several directions we can take for a solution
One experiment I tried with Tomcat 4.1.30, was:

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.

If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira

[jira] Commented: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by ji...@apache.org.

The following comment has been added to this issue:

Author: Scott T Weaver
Created: Fri, 28 May 2004 2:44 PM
Body:
> Furthermore, hearing people "talk" about how easy it might be doesn't
> convince me, no offence.

Well, they are people I work with that are very compotent developers, so I generally trust their opinions. I will, however, research this for myslef.

> The first three I don't really worry about, but the others?
> I know J2 currently can't (easily) be deployed on those right now but
> if it would block this in the future I certainly will vote -1 on this.

On the contrary, I think it would make deploying to ANY container much easier than now.

1. We no longer have to put anything in shared/lib because we control the servlet container (Jetty)

2. Another benefit is that J2 no longer needs to be x-context because, as stated above, we are control the servlet container.

Just some food for thought. I feel this would make our life easier in the long run as we would only have to worry about dealing with app server's idiosyncraies relative to a portlet application's web app.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-56?page=comments#action_35790

---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JS2-56

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 2:44 PM
Environment: Tomcat 4 and 5

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);

I think we have several directions we can take for a solution
One experiment I tried with Tomcat 4.1.30, was:

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.

If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira

[jira] Commented: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by ji...@apache.org.

The following comment has been added to this issue:

Author: Ate Douma
Created: Thu, 27 May 2004 1:52 PM
Body:
David Sean Taylor wrote:
> Another solution to consider:
> loading User info and preferences when the user logs in

I don't think that will be enough.
Consider an external portlet in which I want to display/report certain User info of several users. We can't just preload all the data in memory to solve this...
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-56?page=comments#action_35755

---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JS2-56

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: Thu, 27 May 2004 1:52 PM
Environment: Tomcat 4 and 5

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);

I think we have several directions we can take for a solution
One experiment I tried with Tomcat 4.1.30, was:

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.

If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira

[jira] Resolved: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by ji...@apache.org.

Message:

   The following issue has been resolved as FIXED.

   Resolver: David Sean Taylor
       Date: Tue, 1 Jun 2004 8:55 AM

Resolved by patching OJB 1.0 rc6.
The patch allows for configuring the OJB class loader.
OJB dynamically loads OM classes (via the OJB repository descriptor).
When these classes are loaded in another servlet (PA) context, the context/thread class loader is for the PA, not Jetspeed.
This patch allows the Jetspeed engine to dynamically swap the class loader used by OJB when locating classes defined in the OJB descriptor.

The patched jar is now a part of the j2 build.
DLS is liaisoning with the OJB team on integrating the patch into the final release of OJB 1.0
Thus I will resolve this issue, but not close it until that happens.

---------------------------------------------------------------------
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: Resolved
   Priority: Major
 Resolution: FIXED

    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: Tue, 1 Jun 2004 8:55 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.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by ji...@apache.org.

The following comment has been added to this issue:

Author: Scott T Weaver
Created: Fri, 28 May 2004 1:21 PM
Body:
David Taylor an I have discussed the possiblity of using embedded Jetty with in Jetsped to process web/portlet apps.

We would still be deploying Jetspeed to multiple containers but the job of dealing servlets/jsp that are part of portlet apps would always be done through Jetty.

I suggest this because I have heard quite a few people talk about how modualr Jetty is and how easy it is to embed.

Comments???
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-56?page=comments#action_35787

---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JS2-56

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 1:21 PM
Environment: Tomcat 4 and 5

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);

I think we have several directions we can take for a solution
One experiment I tried with Tomcat 4.1.30, was:

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.

If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira

[jira] Commented: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by ji...@apache.org.

The following comment has been added to this issue:

Author: Ate Douma
Created: Fri, 28 May 2004 8:32 AM
Body:
Scott wrote:
> Instead of commons, I would prefer creating an om sub-project instead of cluttering commons with implentation classes. Waddya think?
+1

I thought of doing that already, but really I considered the patch I attached as something to evaluate first.
An om sub-project should also contain the om classes already now in commons. I just wanted to define the leased possible changes needed to fix the current issue first.
But, I'm all for doing it all at once.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-56?page=comments#action_35771

---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JS2-56

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 8:32 AM
Environment: Tomcat 4 and 5

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);

I think we have several directions we can take for a solution
One experiment I tried with Tomcat 4.1.30, was:

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.

If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira

[jira] Commented: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by ji...@apache.org.

The following comment has been added to this issue:

Author: Ate Douma
Created: Fri, 28 May 2004 1:57 PM
Body:
I'm not against embedding Jetty per se.
But, I don't want this to delay resolving the current issue.

Furthermore, hearing people "talk" about how easy it might be doesn't convince me, no offence.

Before Jetty would be embedded I would like to "see" some proof it won't close the door for J2 to be used on application servers like:
- JBoss
- JOnAS
- Geronimo
- WebLogic
- WebSphere
- OC4J
The first three I don't really worry about, but the others?
I know J2 currently can't (easily) be deployed on those right now but if it would block this in the future I certainly will vote -1 on this.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-56?page=comments#action_35789

---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JS2-56

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 1:57 PM
Environment: Tomcat 4 and 5

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);

I think we have several directions we can take for a solution
One experiment I tried with Tomcat 4.1.30, was:

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.

If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira

[jira] Commented: (JS2-56) Objects Fail to Create with Tomcat Classloaders and cross context

Posted by ji...@apache.org.

The following comment has been added to this issue:

Author: David Sean Taylor
Created: Fri, 28 May 2004 10:45 AM
Body:
" Instead of commons, I would prefer creating an om sub-project instead of cluttering commons with implentation classes. Waddya think"

I think we need to clearly define what new jars we are proposing.
Currently, we the commons jar.
It has OM interfaces and implementations.
It also has a dual purpose of providing portal/portlet-application communications.
I proposed pulling out the p/pa comm code into a new project:

http://issues.apache.org/jira/browse/JS2-37

Finally, there is the util directory o.a.j.util under commons

So we would now have 3 sub-projects out of commons:

1. jetspeed-om (om interfaces and implementations)
2. jetspeed-core-pa (JS2-37)
3. jetspeed-commons (basically just o.a.j.util)

Im wondering if we even need #3 ....perhaps they can be moved into #2

Ate, regarding your patch, didn't you receive your Apache account yet?
If so, no need to send patches, unless you just want us to test it out.

I prefer that we resolve the issues above before applying Ate's solution to JS2-56 (this issue)

---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-56?page=comments#action_35774

---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JS2-56

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 10:45 AM
Environment: Tomcat 4 and 5

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);

I think we have several directions we can take for a solution
One experiment I tried with Tomcat 4.1.30, was:

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.

If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira