You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Jennifer A Thompson (JIRA)" <de...@tuscany.apache.org> on 2011/09/15 23:59:09 UTC
[jira] [Updated] (TUSCANY-3947) Compliance testcase POJO_10009
testing for too strict of a condition
[ https://issues.apache.org/jira/browse/TUSCANY-3947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jennifer A Thompson updated TUSCANY-3947:
-----------------------------------------
Description:
In compliance testcase POJO_10009 service1ClassLoaderCheckImpl.operation1() is checking if the TCCL retrieved is exactly the same as service1ClassLoaderCheckImpl's classloader. However, it seems as long as the implementation class is loadable from the TCCL the testcase is still compliant with the specifiation.
The suggested update is to change:
public String operation1(String input) {
ClassLoader tccl = Thread.currentThread().getContextClassLoader();
ClassLoader loader = this.getClass().getClassLoader();
String result = " thread context classloader is correct";
if( loader != tccl ) result = " thread context classloader not correct";
return serviceName + " operation1 invoked" + result;
}
to:
public String operation1(String input) {
ClassLoader tccl = Thread.currentThread().getContextClassLoader();
ClassLoader loader = this.getClass().getClassLoader();
ClassLoader loader2 = Class.forName("org.oasisopen.sca.test.service1ClassLoaderCheckImpl", false, tccl);
String result = " thread context classloader is correct";
if (loader != loader2) result = " thread context classloader not correct";
return serviceName + " operation1 invoked" + result;
}
was:
In compliance testcase POJO_10009 service1ClassLoaderCheckImpl.operation1() is checking if the TCCL retrieved is exactly the same as service1ClassLoaderCheckImpl's classloader. However, it seems as long as the implementation class is loadable from the TCCL the testcase is still compliant with the specifiation.
The suggested update is to change:
public String operation1(String input) {
ClassLoader tccl = Thread.currentThread().getContextClassLoader();
ClassLoader loader = this.getClass().getClassLoader();
String result = " thread context classloader is correct";
if( loader != tccl ) result = " thread context classloader not correct";
return serviceName + " operation1 invoked" + result;
}
to:
public String operation1(String input) {
ClassLoader tccl = Thread.currentThread().getContextClassLoader();
ClassLoader loader = this.getClass().getClassLoader();
ClassLoader loader2 = Class.forName("org.oasisopen.sca.test.service1ClassLoaderCheckImpl", false, tccl);
String result = " thread context classloader is correct";
if (loader != loader2) result = " thread context classloader not correct";
return serviceName + " operation1 invoked" + result;
}
This testcase would then allow the runtime the flexibility to compose a classloader that can delegate to the contribution classloader and to other classloaders (e.g. library loaders).
> Compliance testcase POJO_10009 testing for too strict of a condition
> ---------------------------------------------------------------------
>
> Key: TUSCANY-3947
> URL: https://issues.apache.org/jira/browse/TUSCANY-3947
> Project: Tuscany
> Issue Type: Improvement
> Components: OASIS Compliance - TUSCANY
> Affects Versions: Java-SCA-2.x
> Reporter: Jennifer A Thompson
> Fix For: Java-SCA-2.x
>
>
> In compliance testcase POJO_10009 service1ClassLoaderCheckImpl.operation1() is checking if the TCCL retrieved is exactly the same as service1ClassLoaderCheckImpl's classloader. However, it seems as long as the implementation class is loadable from the TCCL the testcase is still compliant with the specifiation.
> The suggested update is to change:
> public String operation1(String input) {
> ClassLoader tccl = Thread.currentThread().getContextClassLoader();
> ClassLoader loader = this.getClass().getClassLoader();
> String result = " thread context classloader is correct";
> if( loader != tccl ) result = " thread context classloader not correct";
> return serviceName + " operation1 invoked" + result;
> }
> to:
> public String operation1(String input) {
> ClassLoader tccl = Thread.currentThread().getContextClassLoader();
> ClassLoader loader = this.getClass().getClassLoader();
> ClassLoader loader2 = Class.forName("org.oasisopen.sca.test.service1ClassLoaderCheckImpl", false, tccl);
> String result = " thread context classloader is correct";
> if (loader != loader2) result = " thread context classloader not correct";
> return serviceName + " operation1 invoked" + result;
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Updated] (TUSCANY-3947) Compliance testcase POJO_10009
testing for too strict of a condition
Posted by Greg Dritschler <gr...@gmail.com>.
We have cases where the runtime needs classes to be accessible via the TCCL,
which are not needed by the application itself. We have seen this when
providing EJB support (JITed stubs and ties). We have seen this with
security support.
Another example is with OSGi. The runtime may need access to all sorts of
classes via the TCCL. The application bundle would not have imports for
these classes, so making the application's bundle loader the TCCL would not
work at all.
I completely agree that the application classes need to be accessible via
the TCCL, and that's what the revised test checks.
Greg
On Fri, Sep 16, 2011 at 6:35 AM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:
> On 15/09/2011 22:59, Jennifer A Thompson (JIRA) wrote:
>
>>
>> [ https://issues.apache.org/**jira/browse/TUSCANY-3947?page=**
>> com.atlassian.jira.plugin.**system.issuetabpanels:all-**tabpanel<https://issues.apache.org/jira/browse/TUSCANY-3947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel>]
>>
>> Jennifer A Thompson updated TUSCANY-3947:
>> ------------------------------**-----------
>>
>> Description:
>> In compliance testcase POJO_10009 service1ClassLoaderCheckImpl.**operation1()
>> is checking if the TCCL retrieved is exactly the same as
>> service1ClassLoaderCheckImpl's classloader. However, it seems as long as the
>> implementation class is loadable from the TCCL the testcase is still
>> compliant with the specifiation.
>>
>>
>> The suggested update is to change:
>>
>> public String operation1(String input) {
>> ClassLoader tccl = Thread.currentThread().**getContextClassLoader();
>> ClassLoader loader = this.getClass().**getClassLoader();
>> String result = " thread context classloader is correct";
>> if( loader != tccl ) result = " thread context classloader not correct";
>> return serviceName + " operation1 invoked" + result;
>> }
>>
>> to:
>>
>> public String operation1(String input) {
>> ClassLoader tccl = Thread.currentThread().**getContextClassLoader();
>> ClassLoader loader = this.getClass().**getClassLoader();
>> ClassLoader loader2 = Class.forName("org.oasisopen.**sca.test.**service1ClassLoaderCheckImpl",
>> false, tccl);
>> String result = " thread context classloader is correct";
>> if (loader != loader2) result = " thread context classloader not correct";
>> return serviceName + " operation1 invoked" + result;
>> }
>>
>>
>> was:
>> In compliance testcase POJO_10009 service1ClassLoaderCheckImpl.**operation1()
>> is checking if the TCCL retrieved is exactly the same as
>> service1ClassLoaderCheckImpl's classloader. However, it seems as long as the
>> implementation class is loadable from the TCCL the testcase is still
>> compliant with the specifiation.
>>
>>
>> The suggested update is to change:
>>
>> public String operation1(String input) {
>> ClassLoader tccl = Thread.currentThread().**getContextClassLoader();
>> ClassLoader loader = this.getClass().**getClassLoader();
>> String result = " thread context classloader is correct";
>> if( loader != tccl ) result = " thread context classloader not correct";
>> return serviceName + " operation1 invoked" + result;
>> }
>>
>> to:
>>
>> public String operation1(String input) {
>> ClassLoader tccl = Thread.currentThread().**getContextClassLoader();
>> ClassLoader loader = this.getClass().**getClassLoader();
>> ClassLoader loader2 = Class.forName("org.oasisopen.**sca.test.**service1ClassLoaderCheckImpl",
>> false, tccl);
>> String result = " thread context classloader is correct";
>> if (loader != loader2) result = " thread context classloader not correct";
>> return serviceName + " operation1 invoked" + result;
>> }
>>
>> This testcase would then allow the runtime the flexibility to compose a
>> classloader that can delegate to the contribution classloader and to other
>> classloaders (e.g. library loaders).
>>
>>
>> Compliance testcase POJO_10009 testing for too strict of a condition
>>> ------------------------------**------------------------------**
>>> ---------
>>>
>>> Key: TUSCANY-3947
>>> URL: https://issues.apache.org/**
>>> jira/browse/TUSCANY-3947<https://issues.apache.org/jira/browse/TUSCANY-3947>
>>> Project: Tuscany
>>> Issue Type: Improvement
>>> Components: OASIS Compliance - TUSCANY
>>> Affects Versions: Java-SCA-2.x
>>> Reporter: Jennifer A Thompson
>>> Fix For: Java-SCA-2.x
>>>
>>>
>>> In compliance testcase POJO_10009 service1ClassLoaderCheckImpl.**operation1()
>>> is checking if the TCCL retrieved is exactly the same as
>>> service1ClassLoaderCheckImpl's classloader. However, it seems as long as the
>>> implementation class is loadable from the TCCL the testcase is still
>>> compliant with the specifiation.
>>> The suggested update is to change:
>>> public String operation1(String input) {
>>> ClassLoader tccl = Thread.currentThread().**getContextClassLoader();
>>> ClassLoader loader = this.getClass().**getClassLoader();
>>> String result = " thread context classloader is correct";
>>> if( loader != tccl ) result = " thread context classloader not correct";
>>> return serviceName + " operation1 invoked" + result;
>>> }
>>> to:
>>> public String operation1(String input) {
>>> ClassLoader tccl = Thread.currentThread().**getContextClassLoader();
>>> ClassLoader loader = this.getClass().**getClassLoader();
>>> ClassLoader loader2 = Class.forName("org.oasisopen.**sca.test.**service1ClassLoaderCheckImpl",
>>> false, tccl);
>>> String result = " thread context classloader is correct";
>>> if (loader != loader2) result = " thread context classloader not
>>> correct";
>>> return serviceName + " operation1 invoked" + result;
>>> }
>>>
>>
>> --
>> This message is automatically generated by JIRA.
>> For more information on JIRA, see: http://www.atlassian.com/**
>> software/jira <http://www.atlassian.com/software/jira>
>>
>>
>>
>> Folks,
>
> The specification says this:
>
> "The SCA runtime MUST set the thread context class loader of a component
> implementation class to the class loader of its containing contribution.
> [JCI100009]"
>
> and this:
>
> "The SCA runtime MUST ensure that the Java classes used by a contribution
> are all loaded by a class loader that is unique for each contribution in the
> Domain. [JCI100010] "
>
> I don't see how this can be interpreted as allowing the TCCL to be anything
> other than the classloder that is used to load the classes in the
> contribution. And I think that the testcase POJO_10009 is spot-on in
> testing exactly this requirement. I note that the specification folks
> debated these requirements for some time and the requirements above are the
> result.
>
> Now, you may wish to argue that the specification is being too strict -
> that's fine, but it is a different debate. I'd be interested to hear some
> points in favour of allowing the TCCL classloader to be a different beast
> from the classloader which loads the classes in the contribution.
>
>
> Yours, Mike.
>
>
>
>
Re: [jira] [Updated] (TUSCANY-3947) Compliance testcase POJO_10009
testing for too strict of a condition
Posted by Mike Edwards <mi...@gmail.com>.
On 15/09/2011 22:59, Jennifer A Thompson (JIRA) wrote:
>
> [ https://issues.apache.org/jira/browse/TUSCANY-3947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Jennifer A Thompson updated TUSCANY-3947:
> -----------------------------------------
>
> Description:
> In compliance testcase POJO_10009 service1ClassLoaderCheckImpl.operation1() is checking if the TCCL retrieved is exactly the same as service1ClassLoaderCheckImpl's classloader. However, it seems as long as the implementation class is loadable from the TCCL the testcase is still compliant with the specifiation.
>
>
> The suggested update is to change:
>
> public String operation1(String input) {
> ClassLoader tccl = Thread.currentThread().getContextClassLoader();
> ClassLoader loader = this.getClass().getClassLoader();
> String result = " thread context classloader is correct";
> if( loader != tccl ) result = " thread context classloader not correct";
> return serviceName + " operation1 invoked" + result;
> }
>
> to:
>
> public String operation1(String input) {
> ClassLoader tccl = Thread.currentThread().getContextClassLoader();
> ClassLoader loader = this.getClass().getClassLoader();
> ClassLoader loader2 = Class.forName("org.oasisopen.sca.test.service1ClassLoaderCheckImpl", false, tccl);
> String result = " thread context classloader is correct";
> if (loader != loader2) result = " thread context classloader not correct";
> return serviceName + " operation1 invoked" + result;
> }
>
>
> was:
> In compliance testcase POJO_10009 service1ClassLoaderCheckImpl.operation1() is checking if the TCCL retrieved is exactly the same as service1ClassLoaderCheckImpl's classloader. However, it seems as long as the implementation class is loadable from the TCCL the testcase is still compliant with the specifiation.
>
>
> The suggested update is to change:
>
> public String operation1(String input) {
> ClassLoader tccl = Thread.currentThread().getContextClassLoader();
> ClassLoader loader = this.getClass().getClassLoader();
> String result = " thread context classloader is correct";
> if( loader != tccl ) result = " thread context classloader not correct";
> return serviceName + " operation1 invoked" + result;
> }
>
> to:
>
> public String operation1(String input) {
> ClassLoader tccl = Thread.currentThread().getContextClassLoader();
> ClassLoader loader = this.getClass().getClassLoader();
> ClassLoader loader2 = Class.forName("org.oasisopen.sca.test.service1ClassLoaderCheckImpl", false, tccl);
> String result = " thread context classloader is correct";
> if (loader != loader2) result = " thread context classloader not correct";
> return serviceName + " operation1 invoked" + result;
> }
>
> This testcase would then allow the runtime the flexibility to compose a classloader that can delegate to the contribution classloader and to other classloaders (e.g. library loaders).
>
>
>> Compliance testcase POJO_10009 testing for too strict of a condition
>> ---------------------------------------------------------------------
>>
>> Key: TUSCANY-3947
>> URL: https://issues.apache.org/jira/browse/TUSCANY-3947
>> Project: Tuscany
>> Issue Type: Improvement
>> Components: OASIS Compliance - TUSCANY
>> Affects Versions: Java-SCA-2.x
>> Reporter: Jennifer A Thompson
>> Fix For: Java-SCA-2.x
>>
>>
>> In compliance testcase POJO_10009 service1ClassLoaderCheckImpl.operation1() is checking if the TCCL retrieved is exactly the same as service1ClassLoaderCheckImpl's classloader. However, it seems as long as the implementation class is loadable from the TCCL the testcase is still compliant with the specifiation.
>> The suggested update is to change:
>> public String operation1(String input) {
>> ClassLoader tccl = Thread.currentThread().getContextClassLoader();
>> ClassLoader loader = this.getClass().getClassLoader();
>> String result = " thread context classloader is correct";
>> if( loader != tccl ) result = " thread context classloader not correct";
>> return serviceName + " operation1 invoked" + result;
>> }
>> to:
>> public String operation1(String input) {
>> ClassLoader tccl = Thread.currentThread().getContextClassLoader();
>> ClassLoader loader = this.getClass().getClassLoader();
>> ClassLoader loader2 = Class.forName("org.oasisopen.sca.test.service1ClassLoaderCheckImpl", false, tccl);
>> String result = " thread context classloader is correct";
>> if (loader != loader2) result = " thread context classloader not correct";
>> return serviceName + " operation1 invoked" + result;
>> }
>
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>
Folks,
The specification says this:
"The SCA runtime MUST set the thread context class loader of a component implementation class to the
class loader of its containing contribution. [JCI100009]"
and this:
"The SCA runtime MUST ensure that the Java classes used by a contribution are all loaded by a class
loader that is unique for each contribution in the Domain. [JCI100010] "
I don't see how this can be interpreted as allowing the TCCL to be anything other than the
classloder that is used to load the classes in the contribution. And I think that the testcase
POJO_10009 is spot-on in testing exactly this requirement. I note that the specification folks
debated these requirements for some time and the requirements above are the result.
Now, you may wish to argue that the specification is being too strict - that's fine, but it is a
different debate. I'd be interested to hear some points in favour of allowing the TCCL classloader
to be a different beast from the classloader which loads the classes in the contribution.
Yours, Mike.