Could you refresh me on the technical issue that you are trying to
work around? I looked in the archives and it didn't jump out at me.
I tried googling the original thread I posted about this a while
back, but honestly, I can't seem to find it.
So, here goes. Some Receiver implementations (DB, JMS in particular)
require specific implementation drivers to work. These Receivers do
not work in _any_ distribution without having, say, the JTDS JDBC
driver to connect to ones local SQL Server db using DBReceiver, or,
say, the ActiveMQ jars available so as to use the JMSReceiver
connected through an ActiveMQ JMS bus. Obviously we can't
practically or legally bundle all known relevant driver JARs with
Chainsaw.
So, putting aside the Webstart distribution for a second, even a
normal downloaded 'double-clickable' jar distribution simply will not
work with DBReceiver and JMSReceiver. Period.
One could get around this by forcing the user to place these driver/
implementation jars aside the Chainsaw distribution jars and fudge
either the Manifest 'Main-class' parameters or any starting script to
force inclusion of these JARs in the runtime Chainsaw classpath.
That's a bit lame IMHO.
Instead, Chainsaw is configured to use a custom Classloader
(PluginClassLoader). Any jars found in ~/.chainsaw/plugins are
loaded by this Classloader. The TCCL is set at startup.
This does come with a caveat though. The JMSReceiver and DBReceiver
etc cannot be loaded by the parent/standard classloader. This is
because if the parent classloader loads the JMSReceiver class and
during init it tries to find the implementation class (say, JDBC
driver) it can't 'see' the class available in the child classloader.
Therefore, for the PluginClassloader to work, the jar containing the
JMSReceiver and DBReceiver need to sit along side their
implementation jars inside the plugins directory. This allows both
the Receiver class and it's helper driver class to be loaded by the
same class loader.
This is why I would like to have a customized Receiver distribution.
One that allows a second artifact for the user to download and place
in the plugins folder if they need DBReceiver or JMSReceiver
functionality.
It still seems to me that Webstart doesn't align well with the ASF
release infrastructure. I don't see a way for us to leverage the
ASF web of trust of GPG signatures to verify a signed jar and the
current Webstart version of Chainsaw isn't served through the
mirrorred distribution server and not archived. I also could not
find a release vote in the archives. I'm fairly uncomfortable with
what we have out there and would like to have a formal release.
The Webstart distribution is signed. The user is prompted to accept
a certificate with my name and email address visible (see previous
reply on a different thread). This is IMHO no different from a PGP
signed distribution. The user simply sees 'Bob Bar <[EMAIL PROTECTED]>'
or whoever as the signer. The Webstart distribution becomes the
'latest stable, easily accessible release'. The other distributions
can form the archive if needed.
There is nothing preventing a single individual or organization
repackaging a Chainsaw release for use with Webstart, but it seems
problematic as an official release mechanism. Could we have a tool/
script in the tarball/zip release that allows an individual or
organization to sign the jars with their signature to support
private webstart deployments? So we would send up with a tarball
and zip that would:
The current Maven pom allows easy code signing by anyone, just setup
an active profile with 4 properties that are required for code
signing. (keystore, keystore password, key alias, and key password).
a) Could be run double clicking on the chainsaw jar (where
supported) or by "java -jar apache-chainsaw-2.0.jar").
b) Could be run on Mac OS/X platforms by clicking on Chainsaw.app
c) Could be jarsigned by running some script and then copied to a
web server for deployment.
I think we should do all these AND:
D) Webstart distribution
I really think the Webstart distribution is important. I agree it
needs to abide by the release voting mechanism, and we've been a bit
independent here updating that. I'm happy to go through a formal
release process, but I'm VERY passionate about retaining the Webstart
distribution. I'd be very keen if all 3 of us active devs are setup
to sign the Webstart distribution. It doesn't need to be me.
Hoping this information helps.
cheers,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
