You are viewing a plain text version of this content. The canonical link for it is here.
Posted to graffito-dev@incubator.apache.org by Felix Meschberger <Fe...@day.com> on 2006/09/06 08:16:01 UTC

JCR-Mapper: ClassLoading issues

Hi,

I am new to the JCR-Mapper, so please forgive any stupidity :-)

I am working on a projects which involves mapping nodes to objects.
The environment of this project is an OSGi Framework which makes
extensive use of classloaders and visibility separation.

Consider now, that I have different classes and their descriptors
defined in different bundles. It would now be very unpractical to
export all classes from the defining bundles (which would work in the
worst case) and even almost impossible to import those classes into
the bundle, which has the JCR-Mapper classes.

Currently classes are loaded through Class.forName(String) which just
takes the class loader of the object placing the call. This call is
placed from various places though probably, there is some kind of
central place in the RefelctionUtils class.

To solve this issue, class loading must probably be completely
centralized (all users use ReflectionUtils.forName(String)) and
ReflectionUtils should be somehow configurable to set the classloader
to use.

What do you think of this ?

Regards
Felix

Re: JCR-Mapper: ClassLoading issues

Posted by Alexandru Popescu <th...@gmail.com>.
On 9/6/06, Felix Meschberger <Fe...@day.com> wrote:
> Hi,
>
> I am new to the JCR-Mapper, so please forgive any stupidity :-)
>
> I am working on a projects which involves mapping nodes to objects.
> The environment of this project is an OSGi Framework which makes
> extensive use of classloaders and visibility separation.
>
> Consider now, that I have different classes and their descriptors
> defined in different bundles. It would now be very unpractical to
> export all classes from the defining bundles (which would work in the
> worst case) and even almost impossible to import those classes into
> the bundle, which has the JCR-Mapper classes.
>
> Currently classes are loaded through Class.forName(String) which just
> takes the class loader of the object placing the call. This call is
> placed from various places though probably, there is some kind of
> central place in the RefelctionUtils class.
>
> To solve this issue, class loading must probably be completely
> centralized (all users use ReflectionUtils.forName(String)) and
> ReflectionUtils should be somehow configurable to set the classloader
> to use.
>

This was exactly the reason why I have decided to have this central
place to deal with reflection/CL/etc. I was quite sure that sooner or
later somebody will need better mechanisms and this might be a good
start. I know it is not perfect, but I am sure we can evolve it.

./alex
--
.w( the_mindstorm )p.

> What do you think of this ?
>
> Regards
> Felix
>

Re: JCR-Mapper: ClassLoading issues

Posted by Felix Meschberger <Fe...@day.com>.
Hi Christophe,

No problem, I will patch all Class.forName(String) uses to use
ReflectionUtils and I add setter/getter to RelfectionUtil to implant a
custom class loader used by the ReflectionUtils.forName() method.

While I tend to think, that classloader configuration of a static
utility method this is not the best solution possible, I have no
better one at hand right now.

Will do the patches and create an issue.

Regards
Felix

On 9/6/06, Christophe Lombart <ch...@gmail.com> wrote:
> On 9/6/06, Felix Meschberger <Fe...@day.com> wrote:
> > Hi,
> >
> > I am new to the JCR-Mapper, so please forgive any stupidity :-)
> >
>
> You are welcome
>
> > I am working on a projects which involves mapping nodes to objects.
> > The environment of this project is an OSGi Framework which makes
> > extensive use of classloaders and visibility separation.
> >
> > Consider now, that I have different classes and their descriptors
> > defined in different bundles. It would now be very unpractical to
> > export all classes from the defining bundles (which would work in the
> > worst case) and even almost impossible to import those classes into
> > the bundle, which has the JCR-Mapper classes.
> >
> > Currently classes are loaded through Class.forName(String) which just
> > takes the class loader of the object placing the call. This call is
> > placed from various places though probably, there is some kind of
> > central place in the RefelctionUtils class.
> >
> > To solve this issue, class loading must probably be completely
> > centralized (all users use ReflectionUtils.forName(String)) and
> > ReflectionUtils should be somehow configurable to set the classloader
> > to use.
> >
> > What do you think of this ?
> >
>
> I understand your problem and your solution. Can you contribute
> something  :-) ?
> I have no time to work on this.  Thanks !
>
>
> --
> Best regards,
>
> Christophe
>

Re: JCR-Mapper: ClassLoading issues

Posted by Christophe Lombart <ch...@gmail.com>.
On 9/6/06, Felix Meschberger <Fe...@day.com> wrote:
> Hi,
>
> I am new to the JCR-Mapper, so please forgive any stupidity :-)
>

You are welcome

> I am working on a projects which involves mapping nodes to objects.
> The environment of this project is an OSGi Framework which makes
> extensive use of classloaders and visibility separation.
>
> Consider now, that I have different classes and their descriptors
> defined in different bundles. It would now be very unpractical to
> export all classes from the defining bundles (which would work in the
> worst case) and even almost impossible to import those classes into
> the bundle, which has the JCR-Mapper classes.
>
> Currently classes are loaded through Class.forName(String) which just
> takes the class loader of the object placing the call. This call is
> placed from various places though probably, there is some kind of
> central place in the RefelctionUtils class.
>
> To solve this issue, class loading must probably be completely
> centralized (all users use ReflectionUtils.forName(String)) and
> ReflectionUtils should be somehow configurable to set the classloader
> to use.
>
> What do you think of this ?
>

I understand your problem and your solution. Can you contribute
something  :-) ?
I have no time to work on this.  Thanks !


-- 
Best regards,

Christophe