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 Thomas Dudziak <to...@first.gmd.de> on 2004/06/01 21:19:14 UTC
Re: [OJB] [J2] [OJB-PATCH] ClassHelper Patch.
On Mon, 31 May 2004, David Le Strat wrote:
> Hello there,
>
> I am cross posting this message to both Jetspeed-Dev
> and OJB-Dev lists as this patch impacts both projects.
>
> The following J2 issues describe in more detail the
> reason for this patch.
>
> http://nagoya.apache.org/jira/browse/JS2-48
> http://nagoya.apache.org/jira/browse/JS2-56
>
> The Jetspeed 2 development team ran in an issue with
> OJB in the context of web application using
> cross-context functionality (which we have to
> implement to be able to comply with JSR168).
>
> OJB in its current form cannot be used by web
> applications using cross-context functionality. The
> problem is caused by the way OJB dynamically creates
> new class instances: Class.forName("className",
> currentThread.getContextClassLoader()).
>
> 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").
>
> The enclosed patch extends the
> org.apache.ojb.broker.util.ClassHelper to allow
> external application to specify the class loader that
> should be used by OJB. This allows us in the example
> above to tell OJB to use the web app B (Jetspeed)
> classloader in specific circumstances.
>
> Please post to both list to discuss any issues you may
> have with that patch.
Is integrated in CVS. I also replaced the remaining hardwired usages of
the context classloader so that OJB should now use this class loder for
all its tasks including resource loading (except for logging which I'm
currently working on).
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [OJB] [J2] [OJB-PATCH] ClassHelper Patch.
Posted by David Le Strat <dl...@yahoo.com>.
Super! Thanks for the quick turn around.
Regards,
David.
--- Thomas Dudziak <to...@first.gmd.de> wrote:
> On Mon, 31 May 2004, David Le Strat wrote:
>
> > Hello there,
> >
> > I am cross posting this message to both
> Jetspeed-Dev
> > and OJB-Dev lists as this patch impacts both
> projects.
> >
> > The following J2 issues describe in more detail
> the
> > reason for this patch.
> >
> > http://nagoya.apache.org/jira/browse/JS2-48
> > http://nagoya.apache.org/jira/browse/JS2-56
> >
> > The Jetspeed 2 development team ran in an issue
> with
> > OJB in the context of web application using
> > cross-context functionality (which we have to
> > implement to be able to comply with JSR168).
> >
> > OJB in its current form cannot be used by web
> > applications using cross-context functionality.
> The
> > problem is caused by the way OJB dynamically
> creates
> > new class instances: Class.forName("className",
> > currentThread.getContextClassLoader()).
> >
> > 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").
> >
> > The enclosed patch extends the
> > org.apache.ojb.broker.util.ClassHelper to allow
> > external application to specify the class loader
> that
> > should be used by OJB. This allows us in the
> example
> > above to tell OJB to use the web app B (Jetspeed)
> > classloader in specific circumstances.
> >
> > Please post to both list to discuss any issues you
> may
> > have with that patch.
>
> Is integrated in CVS. I also replaced the remaining
> hardwired usages of
> the context classloader so that OJB should now use
> this class loder for
> all its tasks including resource loading (except for
> logging which I'm
> currently working on).
>
> Tom
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail:
> ojb-dev-help@db.apache.org
>
__________________________________
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
Re: [OJB] [J2] [OJB-PATCH] ClassHelper Patch.
Posted by David Le Strat <dl...@yahoo.com>.
Super! Thanks for the quick turn around.
Regards,
David.
--- Thomas Dudziak <to...@first.gmd.de> wrote:
> On Mon, 31 May 2004, David Le Strat wrote:
>
> > Hello there,
> >
> > I am cross posting this message to both
> Jetspeed-Dev
> > and OJB-Dev lists as this patch impacts both
> projects.
> >
> > The following J2 issues describe in more detail
> the
> > reason for this patch.
> >
> > http://nagoya.apache.org/jira/browse/JS2-48
> > http://nagoya.apache.org/jira/browse/JS2-56
> >
> > The Jetspeed 2 development team ran in an issue
> with
> > OJB in the context of web application using
> > cross-context functionality (which we have to
> > implement to be able to comply with JSR168).
> >
> > OJB in its current form cannot be used by web
> > applications using cross-context functionality.
> The
> > problem is caused by the way OJB dynamically
> creates
> > new class instances: Class.forName("className",
> > currentThread.getContextClassLoader()).
> >
> > 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").
> >
> > The enclosed patch extends the
> > org.apache.ojb.broker.util.ClassHelper to allow
> > external application to specify the class loader
> that
> > should be used by OJB. This allows us in the
> example
> > above to tell OJB to use the web app B (Jetspeed)
> > classloader in specific circumstances.
> >
> > Please post to both list to discuss any issues you
> may
> > have with that patch.
>
> Is integrated in CVS. I also replaced the remaining
> hardwired usages of
> the context classloader so that OJB should now use
> this class loder for
> all its tasks including resource loading (except for
> logging which I'm
> currently working on).
>
> Tom
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail:
> ojb-dev-help@db.apache.org
>
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org