Re: [equinox-dev] Class loader, class space, protection domai, package private things and fragments

2014-07-22 Thread Gunnar Wagenknecht

Hi Tom!

On 2014-07-18 19:09:02 +, Thomas Watson said:

Are your troubles when you run the fragment in the Equinox/OSGi 
environment or is it when using Mockito/CGLIB outside of an OSGi 
environment?  If it is the later then are you running into issues with 
signing?  Or perhaps you could clarify the issue you are running into 
because I just realized that it is not clear to me ;-)
I fixed the problems with signing upstream in cglib. :) Hopefully it 
ends up in Mockito one day.


But the other problem I have with Mockito is that it can't mock package 
private methods in an OSGi environment. It works outside of OSGi. Thus, 
when a class is defined in a bundle and has package private methods, 
those methods can be accessed in the test fragment. However, mocking 
those fails in OSGi. Oh and to make the problem even more complex, it 
does not fail when run as JUnit Plug-in Test from within Eclipse but 
when run as Tycho Surefire test from within a Maven Tycho build. But as 
soon as I make the methods protected it works.


-Gunnar


--
Gunnar Wagenknecht
gun...@wagenknecht.org


___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev


Re: [equinox-dev] Class loader, class space, protection domai, package private things and fragments

2014-07-22 Thread Neil Bartlett
This is probably because package-private accessibility in the JVM is based on 
the concept of “runtime packages”.

A runtime package is a package loaded by a particular classloader. If some 
classes have the same package name but are loaded by a different classloader 
then they are NOT part of the same runtime package, so do not have access to 
the package-private members and would throw IllegalAccessError.

Very few people seem to know about this area of the Java specification! It 
means that the javac compiler actually has no idea whether some code has access 
to a private-package member, since it doesn’t know how you will arrange your 
classloaders at runtime. Of course in OSGi we have multiple classloaders. 
Mockito would probably fail in the same way outside of OSGi if you loaded it in 
a different classloader from the classes it is trying to mock…

Neil


On 22 July 2014 at 22:52:00, Gunnar Wagenknecht (gun...@wagenknecht.org) wrote:

Hi Tom!  

On 2014-07-18 19:09:02 +, Thomas Watson said:  

 Are your troubles when you run the fragment in the Equinox/OSGi  
 environment or is it when using Mockito/CGLIB outside of an OSGi  
 environment?  If it is the later then are you running into issues with  
 signing?  Or perhaps you could clarify the issue you are running into  
 because I just realized that it is not clear to me ;-)  
I fixed the problems with signing upstream in cglib. :) Hopefully it  
ends up in Mockito one day.  

But the other problem I have with Mockito is that it can't mock package  
private methods in an OSGi environment. It works outside of OSGi. Thus,  
when a class is defined in a bundle and has package private methods,  
those methods can be accessed in the test fragment. However, mocking  
those fails in OSGi. Oh and to make the problem even more complex, it  
does not fail when run as JUnit Plug-in Test from within Eclipse but  
when run as Tycho Surefire test from within a Maven Tycho build. But as  
soon as I make the methods protected it works.  

-Gunnar  


--  
Gunnar Wagenknecht  
gun...@wagenknecht.org  


___  
equinox-dev mailing list  
equinox-dev@eclipse.org  
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit  
https://dev.eclipse.org/mailman/listinfo/equinox-dev  
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev