User development, A new message was posted in the thread "Native library mapping at jboss-cl level":
http://community.jboss.org/message/521793#521793 Author : Thomas Diesler Profile : http://community.jboss.org/people/[email protected] Message: -------------------------------------------------------------- I cleaned up the the way how the OSGiClassLoaderPolicy gets the associated NativeLibraryProviders. 1) NativeLibraryProviders are now added in the ctor of the OSGiClassLoaderPolicy like all the other properties that get initialized from the Module. Here I must say I don't fully understand what a http://jbmuc.dyndns.org:8280/hudson/job/jbossmc-javadoc/ws/jbossmc-javadoc/target/apidocs/org/jboss/classloading/spi/dependency/Module.htmlis and how it fits together with all the other pieces that are associated with it. This http://java.dzone.com/articles/jboss-microcontainer-classloading is the only source of information I have. 2) I removed all getter access of NativeLibraryProviders from ClassLoaderPolicy. To an existing ClassLoaderPolicy you can only add new libraries. 3) I removed NativeLibraryMetaData from the base layer. You are right, only the OSGi layer uses it. This also removes the need for XML parsing. > It might be a good idea to add a "security option" for this feature.. > e.g. something like only signed jars can deploy native code this way. > i.e. have a new security permission for this feature (with the option on the > deployer to enable/disable the check). > https://jira.jboss.org/jira/browse/JBOSGI-280 -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521793#521793
_______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
