But, so what? If they’re part of the platform, they’re supposed to be there in all Jini clients and services.
Greg. On Apr 26, 2014, at 8:28 PM, Peter <j...@zeus.net.au> wrote: > Dennis is right, these classes have snuck into jsk-platform.jar, they're not > in there in Jini2.1 > > Because these classes aren't preferred, they'll be resolved in the > application loader, simply because they're present, annotated or not. > > ----- Original message ----- >> Hi Dennis: >> >> I’m not sure I follow you - why would they not be annotated? >> jsk-platform goes in the application’s class loader, so either it’s >> annotated with a CodebaseAccessClassLoader or with the java.rmi.codebase >> property. >> >> Are you sure you’re not thinking of jsk-policy.jar? That normally goes >> “one level above” the application’s class path (since it has to control >> the security), so wouldn’t get a codebase annotation. But that jar only >> contains the policy provider. >> >> Cheers, >> >> Greg Trasuk >> >> On Apr 26, 2014, at 5:21 PM, Dennis Reedy <dennis.re...@gmail.com> wrote: >> >>> >>> On Apr 26, 2014, at 254PM, tras...@stratuscom.com wrote: >>> >>>> What is the rationale for inclusion/ exclusion ? >>> >>> Classes that are loaded by the system classloader never get annotated >>> with a codebase. These classses were in jsk-platform.jar. The class in >>> question are the net.jini.lookup classes, they are service attributes: >>> >>> net/jini/lookup/entry/Address.class >>> net/jini/lookup/entry/AddressBean.class >>> net/jini/lookup/entry/Comment.class >>> net/jini/lookup/entry/CommentBean.class >>> net/jini/lookup/entry/EntryBean.class >>> >>> These need to be in jdk-dl.jar (which they were, but they would never >>> have a codebase since they were loaded by the system classloader). >>> Peter asked me to help him modularizing qa_refactor, this was >>> something I spotted. >>> >>> Dennis >> >
