[
https://issues.apache.org/jira/browse/POLYGENE-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16022420#comment-16022420
]
Niclas Hedhman commented on POLYGENE-249:
-----------------------------------------
Additional experiments shows that the actual challenge is to get the
AbstractPolygeneTest to work properly, since it defines Composite types which
will end up being loaded by the System class loader (sometimes called
application classloader).
That would mean that we are probably on the brink of introducing
PolygeneTestRunner instead of abstract superclass, and then inject into the
testcase instead. Perhaps consider the testcase as a Composite? The Runner
would then simply ask for an ApplicationAssembly (Class argument in
annotation?) and then add the testcase as a service... This would only work if
JUnit is not too particular about the testcase to be a class, i.e. allow an
interface before engaging the Runner. This is an interesting issue in its own
right... Opening a new ticket.
> private and package protected types are not accessible when they should be.
> ---------------------------------------------------------------------------
>
> Key: POLYGENE-249
> URL: https://issues.apache.org/jira/browse/POLYGENE-249
> Project: Polygene
> Issue Type: Bug
> Reporter: Niclas Hedhman
> Fix For: 3.1.0
>
>
> The FragmentClassLoader creates new subclasses (_Stub) in the same package as
> its superclass. Yet, the classloading of a
> {code:java}
> package org.apache.polygene.abc;
> class Abc
> implements SomeType
> {}
> {code}
> will insist that the Abc.class is public or protected and that the
> SomeType.class is public. Otherwise an IllegalAccessException is thrown.
> {code}
> java.lang.IllegalAccessError: class org.apache.polygene.abc.Abc_Stub cannot
> access its superclass org.apache.polygene.abc.Abc
> {code}
> and
> {code}
> java.lang.IllegalAccessError: tried to access class
> org.apache.polygene.abc.SomeType from class org.apache.polygene.abc.Abc_Stub
> {code}
> This is probably because the FragmentClassLoader is doing something wrong
> regarding packages. Maybe it is not enough to give the right name to the
> class, but also have to put in some type of package reference.
> The work-around is more 'public' and 'protected' fragment types, but that is
> not ideal.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
