[
https://issues.jboss.org/browse/AS7-2695?page=com.atlassian.jira.plugin.s...
]
David Lloyd commented on AS7-2695:
----------------------------------
{quote}
What if you have multiple modules using the same native
component? Since the .os/.dll can be loaded only once per VM
instance second invocation will always fail because JNI methods
have already been bound to a different class loader.
Next what if multiple native components have the same dependency.
Static linkage of dependencies means that dependency fix would
cause fixing all components using it.
Anyhow, setting LD_LIBRARY_PATH to a whatever location you have
installed jboss-native/native before starting AS works equally well,
so I see no reason why would this be something mandatory.
Well, since everybody seems to be 'module' oriented
why not creating a separate module for all native components
a. Native component can be loaded only once per VM
b. In that case they could be shared among different modules
c. It would solve module redeployment cause they would
be loaded by parent class loader.
d. User could safely deploy his native component into
that module and be sure it'll be loaded by a correct
classloader
{quote}
What are you talking about? Modules can't be redeployed. Modules are loaded once per
VM, that's it. Anyway, there are no parent class loaders in AS 7. None of this makes
any sense... I think you must have some wrong assumption.
Package APR native libraries correctly
--------------------------------------
Key: AS7-2695
URL:
https://issues.jboss.org/browse/AS7-2695
Project: Application Server 7
Issue Type: Task
Components: Web
Reporter: David Lloyd
Assignee: Remy Maucherat
Fix For: 7.1.0.Final
Attachments: jbossweb-native.jar.jar
The APR libraries for native jbossweb should be packaged in the "lib" directory
of the module under the platform specific name, e.g.
* {{lib/linux-i686/libxxxx.so}}
* {{lib/linux-x86_64/libxxxx.so}}
* {{lib/solaris-sparc/libxxxx.so}}
* {{lib/solaris-sparcv9/libxxxx.so}}
* {{lib/solaris-i686/libxxxx.so}}
* {{lib/solaris-x68_64/libxxxx.so}}
* {{lib/macosx-i686/libxxxx.sl}}
* {{lib/macosx-x86_64/libxxxx.sl}}
For the case where you need to vary the library based on the Solaris version, you have
two options:
* (best solution) rework the library to use weak symbols and/or libc probes and/or system
call error detection, to detect features which are present and absent and adjust at
runtime
* Introduce more than one library in each of the solaris-xxx directories with the version
suffix, e.g. libnative-2.8.so or similar and check for solaris at load time, and if
solaris, choose the library with the version encoded in the name
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira