Skip to main content

JXTA + OSGi

27 replies [Last post]
kultcrowd
Offline
Joined: 2007-09-05
Points: 0

Hello,

I have successfully written a JXTA application for sharing information between peers. It runs perfectly.
However, I am trying to port this application to OSGi framework (equinox). I wrote a simple bundle containing my application, but when I start it, I am not able to find any peer in the network, neither EDGE or RDV peers.
Running under OSGi framework, my application throws some warning when saving the configuration:

WARNING: Failed loading Security Providers into System Class Loader. Will try local class loader (which may not work)
java.lang.ClassNotFoundException: org.bouncycastle.jce.provider.BouncyCastleProvider
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at net.jxta.impl.membership.pse.PSEUtils.(PSEUtils.java:137)
at net.jxta.impl.membership.pse.PSEUtils.(PSEUtils.java:122)
at net.jxta.platform.NetworkConfigurator.createPSEAdv(NetworkConfigurator.java:1641)
at net.jxta.platform.NetworkConfigurator.getPlatformConfig(NetworkConfigurator.java:1814)
at net.jxta.platform.NetworkConfigurator.save(NetworkConfigurator.java:1566)

It seems a problem with PSE certificates, but I don't see any problem because my application is not using PSE authentication...

Do you know any known problem of using JXTA over OSGi? Does any JXTA bundle for OSGi exist already?

Thanks in advance

Kult

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
keesp
Offline
Joined: 2007-05-22
Points: 0

Hi Wayne,

I have just released a beta package of JXTA that you might find interesting. see https://jxta-eclipse.dev.java.net/.
I have used your PSEUtils to split jxta, mortbay jetty and bouncycastle up in three separate plugins. The bouncycastle plugin has its own activator, which tries to load the bouncycastle provider when the following launch argument -Dorg.bouncycastle.provider=true is added in the launch configuration.
JXTA now just checks for this provider and switches to the lightweight API if the bouncycastle provider was not found.

This beta version [i]also[/i] uses the newest org.mortbay.jetty (5 and further). It seems to work fine here, but keep in mind that some things might pop up. This version should work in the default situation -still waiting for feedback from the Ganymede bug-, but still needs quite a bit of further testing to mature.

Regards

Kees

Message was edited by: keesp

wwilliams
Offline
Joined: 2008-07-13
Points: 0

That sounds great. I'll look into your latest efforts on the JXTA-Eclipse project. Concerning your bug where the class files disappear in the Explorer I have run into this myself using Ganymede. For me it happened when I tried creating a plug-in from existing archives and then selected the option to unpack the jar files. Mysteriously after a short while the unpacked class files disappear in Explorer. I have been able to get around this by not selecting to unpack and leave as jar libs to form the plugin. The jars seem to stick around :).

-Wayne

keesp
Offline
Joined: 2007-05-22
Points: 0

That's the bug, all right!
I also see it happening when importing a project. There's no problem as long as you don't fix the warnings, but this prevents me from trying Matt's solution.
Ah well...
I'll be working on JXTA-eclipse tomorrow as well, so if you see strange things I'll try to correct them a.s.a.p. Maybe it's good to report them in the forums I added there...this thread seems to get a bit contaminated with 'happy experimenting' news, and I don't know if thats a problem...

CU

Kees

wwilliams
Offline
Joined: 2008-07-13
Points: 0

I am attaching a modified version of PSEUtils that interfaces to BC Lightweight API. This version uses a switch between Provider or BC Lightweight depending on if Provider can be loaded into System class loader. From the little testing that I have done it appears to work correctly generating and signing both self-signed CA and client certs using the Lightweight API. Please review the new code, test and let me know of any defects or flaws you encounter. I realize Mike Bondolo desires getting rid of the Provider code altogether so if you need me to post a newer version that interfaces to the Lightweight only then let me know. It would only take a couple of minutes.

I just signed and emailed a SCA to Sun. I assume from reading your post Mike that is all I need to do to authorize you or anybody else for that matter to do whatever you like with the code. If not then please let me know. I figured I would just post the source here and Kees you can do as you wish with it integrating it into your JXTA-equinox project.

Please let me know of any concerns/questions you may have.

Thanks,

-Wayne

keesp
Offline
Joined: 2007-05-22
Points: 0

Ok..great!

I'll start working on my version and do some testing with it. I'll let you know what I find.
I've also tried the solution from Matt Flaherty, but some strange things happened when trying this in Ganymede (I think it's a bug, I've made a report), so it's going slow. Did you make any progress?

Kees

wwilliams
Offline
Joined: 2008-07-13
Points: 0

Hi Kees,

I have had absolutely no luck in trying to get the BC provider loaded into system class loader doing everything Matt told you to do in his email. It seems as though there may be some other things that he failed to tell us to really get this to work inside Ganymede or like you said there are some bugs present which is prohibiting this approach to work.

I was able to create a System fragment with the BC 1.4 lib and fragment-host as system.bundle with extension=ext. I then had my JXTA plugin require the system.bundle while removing the BC 1.4 lib from the JXTA plugin since it was now part of the system bundle. This seemed to all work fine as I was not getting any compilation errors due to unresolved dependencies. I made sure to set the osgi parent farnework classloader to ext as Matt said in my launch VM arguments before launching my app. I first ran into Class Not defined errors with the BC classes being used by PSEUtils which tells me the system.bundle is not loading or looking for classes defined in system fragments. I went back and added the BC 1.4 lib to my JXTA plugin solving those errors and still wanting to see if the System class loader could load BC provider from the system.bundle. I ran into the same issue before with the System class loader throwing a ClassNotFoundException telling me this system fragment approach doesn't quite work.

Have you made any further progress with this approach on your end?

-Wayne

keesp
Offline
Joined: 2007-05-22
Points: 0

Hi Wayne,

Nope, I've drawn a blank too, but with me it's at an earlier stage.
I want to update the net.jxta plugin to contain just jxta.jar (and maybe jxtashell.jar), with dependencies to plugins for bcprov***.jar (or the lightweight API) and the Jetty server. However when I prepared Ganymede I got a weird bug that deleted the class files in the package explorer (see https://jxta-eclipse.dev.java.net/servlets/ProjectForumMessageView?forum... ). Because I have not been able to get the Matt solution working in Eclipse 3.3x, I need to wait to see how the bug is going to be resolved, which I hope I will get more info on on monday.

Meanwhile I'll start with Bondolo's preferred solution using your modifications and see if I can get that running in Eclipse 3.3x. I'm probably going to make two bouncycastle plugins (provider and lightweight), and maybe make the jxta plugin switchable depending on the plugin that is provided.
This way I can just wait to see how the JXTA team is going to implement your work and be able to adjust the plugins accordingly in the future.
I'll go on with this on monday and tuesday (my programming days..). I'll keep you posted!

I'm pretty sure that Matt gave the correct info on how this should work, but because this required a change in (I think) org.eclipse.osgi it is possible that it is not perfect yet. The only thing that I could think of (but it is probably not right) is that a plugin needs to be included -think of a security plugin or so. I've been experimenting with that a bit myself but without success, so I think that the newest org.eclipse.osgi should be sufficient.

I'll keep you posted!

Cheers

Kees

Message was edited by: keesp

bondolo
Offline
Joined: 2003-06-11
Points: 0

Given the problems with the BC Provider I'd be in favour of just replacing it entirely with the lightweight API based implementation.

As far as contributing the source goes; there are two choices. You can complete a contributor agreement (http://www.sun.com/software/opensource/contributor_agreement.jsp) and optionally become a jxse committer. Alternately you can publish your patch in a message here or on the jxta dev mailing list and explicitly license it in the message with an MIT license.(see http://www.virtualbox.org/wiki/Contributor_information) for further details on this approach.

The persistent classloader problems with the BC provider have been enough of an annoyance that I'm quite eager to see them gone. I think this is an excellent contribution to making JXSE easier to use in a number of important deployment environments.

Mike

keesp
Offline
Joined: 2007-05-22
Points: 0

Hi Bondolo,

I have no problems being a tester for this solution you suggest. I'll make a plugin based on Wayne's solution (but then bypassing the bouncycastle provider alltogether) and do some tests with it next week and the week after. I'll inform you about the results.

Out of interest, you say that bouncycastle has been a bit of a pain. Is it just this specific problem or have there been more issues with the provider package? I can imagine that you would like direct calls to the lightweight API in order to use JXTA with JAVA mobile technology (I believe they don't provide JCA by default) and maybe there are some issues with non-windows platforms?

Kees

keesp
Offline
Joined: 2007-05-22
Points: 0

Hi Wayne,

I've just received an email from Matt Flaherty of the Equinox /JCA JAAS initiative and he told me that their work is progressing steadily (lucky). He gave me a solution that you might like, for it would make your own 'quick' solution a bit more conform equinox standards. I've copy and pasted his answer below. Hope this may help you.

Kees

>Sorry, haven't been great at keeping up with the website. Next release we're going to >be relying more on the wiki.

>In the meantime, several of our components have graduated into the mainline of >Eclipse. For a demo of the 3.4 features, see here: http://live.eclipse.org/node/565

>Is your JXTA provider packaged into a bundle, or available in the extension classloader >(lib/ext) of the JRE? We added a feature to equinox for adding code to the extension >classloader, see this bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=202282

>Basically, you create an osgi extension bundle which augments the extension >classloader using a directive

> Fragment-Host: system.bundle; extension:="ext"

>in the MANIFEST.MF. You will also need to set

> osgi.frameworkParentClassloader=ext

> in your launch arguments.

> Let me know if this helps. We do have some other provider-related code that did not > graduate in 3.4, perhaps it can be of help to you.

>-matt

wrote on 07/23/2008 07:47:00 AM:

> [image removed]
>
> JAAS/JCA in Eclipse
>
> cees_pieters
>
> to:
>
> Matthew Flaherty
>
> 07/23/2008 08:00 AM
>
> Hi Matt,
>
> I have just been looking into your incubator project -which seems
> alarmingly quiet since last year (?)- and was wondering if you could
> help me with a similar issue I've been running into on one of my ownprojects.
> I have been trying to maintain a JXTA plugin for Equinox (see
> https://jxta-eclipse.dev.java.net/) and as JXTA uses a security
> provider for encryption amd authentication purposes, I'm facing the
> problem that the plugin adds a provider (which eventually is used by
> the system class loader), which then does not have access to the
> classes in the plugin. With the risk of being overly redundant (I'm
> sure you know all of this, but maybe I don't...security is still
> quite new for me) the problem as I understand it is as follows:
>
> 1: JCA requires the implementation of security providers in order to
> secure encryption etc in a safe environment.
> 2: The security providers are mandatorily performed by the system
> class loader, thus the system classloader needs to have access to
> the implemented providers
> 3: The component-based nature of Equinox causes a conflict with
> bullet (2) as the provided code in the plugin is aimed to work in a
> different virtual machine. Therefore the system class loader has no
> knowledge of any provider that is implemented in the plugin.
> 4: I've looked into a number of possible solutions, but everyone of
> them seems to be a nasty workaround, rather than a correct approach
> to this problem.
>
> As far as my knowledge on JCA goes, this should be a fundamental
> problem of integrating equinox with JCA, and so I would think that
> you would face this problem also with your incubator project. My
> question therefore is twofold:
>
> 1: Have you managed to provide a mechanism that would allow me to
> add a provider (including supplementary classses) that would be
> treated correctly in your framework?
> 2; If not, do you know how tackle this problem?
>
> If your framework would provide a solution to this problem, then my
> project will become a very good test environment for your framework,
> as a lot of JXTA users are desperately waiting for a solution to
> this problem in order to integrate JXTA in equinox. I would be more
> than happy to provide feedback on the implementation issues and do some tests.
>
> Kind regards,
>
> Kees Pieters

wwilliams
Offline
Joined: 2008-07-13
Points: 0

Hi Kees,

Thanks, this is excellent news! I just wished I had it a couple of weeks ago but it was a good thing you followed up with Matt Flaherty on this. I did not even realize Ganymede introduced such a feature where you could augment the ext classloader with your own bundle/plugin. I'm now just starting to learn all about Ganymede's new features and it seems like they have made a lot of headway in regards to security and being able to use JAAS within Equinox in this latest release.

I would say that in light of this that our issues using the Bouncy Castle provider within a JXTA Eclipse plugin should go away permanently. I'm going to test this out on my project getting rid of the idea of directly pushing the BC jar in the JRE ext. I don't see much added value in continuing with the BC Lightweight API solution but I would be more than happy to give you a modified PSEUtils with the BC Lightweight code if you wanted it.

I did have a few questions for you. I think I read somewhere where you were thinking of maybe splitting up BC from the JXTA Eclipse plugin into it's own separate plugin. This would at least enable other plugins to make use of BC without having to embed it like the JXTA Eclipse plugin. Being that the BC needs to be added to the ext classloader using Fragment-Host: system.bundle; extension:="ext" it might make even more sense to have it as a separate plugin. Although I do realize that one of your goals was to make a slimmed down JXTA Eclipse plugin with no dependencies making it a truly self-contained component. So I just wanted to know your thoughts now after learning about this new feature in Ganymede?

Regards,

-Wayne

keesp
Offline
Joined: 2007-05-22
Points: 0

Hi Wayne,

Yeah..it seems that we might get a quick and easy solution for the bouncycastle problem. As far as I can ee it was the only remaining problem for succesful JXTA integration, and I think it would be rather cool if it can be done with the default 2.5.0 version. As I mentioned earlier, I do think that using providers is the best way to go for this.
Anyhow..it's clear that we're tapping in to rather recent developments wih Eclipse, so it's not that bad after all. Anyway, I think JXTA-Equinox is getting more attention in the past months so maybe we're just starting this at a very fortunate time.

I have begun implementing this, but I still need to update some plugins from Ganymede. If I've done this, then I'll make a bouncycastle plugin with a documentation on how to work with this. If you do the same, then maybe we can share our experiences so that it should be prety easy for others to benefit from the effort!

I would ideally want to make a JXTA, bouncycastle and mortbay jetty plugin (I've been doing most of the work on the latter, but haven't fixed all the problems yet), so that we really get a nice decoupling of functionality. I don't think that it should be too much of a problem with the Ganymede release, for basically bouncycastle can be implemented as a standalone plugin without a problem if the provider issue is resolved. At least, I have never had any problems with other issues (remember that I used a workaround for about a year or so to solve this problem) using a separate plugin I created from the bcprov-jdk14.jar.

Maybe Bondolo kan assess this, but I can imagine that the lightweight issue is still interesting as an alternative route in the try-catch section where the bouncycastle provider is loaded. I got the impression that PSEUtils tries to load bouncycastle from the provider as a test, and tries an alternative if this fails. I can imagine that directly loading the lightweight components would be a good alternative route, but I'm not quite sure how urgent this alternative route is. If it is interesting, I would suggest to implement this alternative path, for instance by setting a flag that can be checked at the MessageDigest instances, and keep the rest of PSE as it is.

Kees

Message was edited by: keesp

Message was edited by: keesp

Message was edited by: keesp

wwilliams
Offline
Joined: 2008-07-13
Points: 0

Hi Kees,

I'm finished with the mods to PSEUtils so that it now interfaces to the BC Lightweight API to generate and sign certs. Like you mentioned in your previous email it only uses BC Lightweight if the BouncyCastleProvider fails to load into System Classloader else the PSEUtils just works as the same before using Provider instead. Let me know if you are still interested in possibly integrating this with your existing JXTA-Equinox project. I would gladly give over to you the new modified PSEUtils source. I guess I could always attach the source with a message reply in this forum but I don't know if the JXTA team would take issue up with that???

Sure I will test out the new Ganymede feature that can contribute plugins to the extension class loader with my project and give you back the results and my experience with it. It should be pretty trivial for me since I have already ported my project onto Ganymede anyways. Unfortunately I did not have the chance to relook into that yesterday after our discussion. Also I think splitting up the different libs into separate plugins is a good idea so I'm on board with that.

Please keep me updated on your status and I'll do the same.

Thanks.

-Wayne

keesp
Offline
Joined: 2007-05-22
Points: 0

Hi Wayne,

Great work! I did some testing on the Matt solution today, but you really need Ganymede to make it work (I had hoped that selecting a newest equinox release as target would be sufficient). This meant that I had some updating to do in my development environment.

I would imagine that the ideal solution would be if your modification is taken up in the regular JXTA code. I would think that the solution would be an improvement over the current alternative (I got the feeling that this was a 'you're on your own' kind of solution) when an exception is thrown, but this is not for us to decide of course. Maybe Bondolo can give his opinion?

I will follow the Ganymede solution myself and start preparing a bouncycastle plugin in the coming days. Keep me posted on your progress. I have just opened a forum in my own project environment (try https://jxta-eclipse.dev.java.net/servlets/ForumMessageList?forumID=3199) and see if you can send the files there. Maybe it is good to continue this thread there as well (if all works...still learning to be a project owner...)

Thanks

Kees

bondolo
Offline
Joined: 2003-06-11
Points: 0

JXSE currently requires BC for PKCS#1 certificate generation and for PKCS#10 certificate signing request. Unfortunately neither of these functions is provided by the public JSSE implementation. For all other algorithms the JSSE versions should be sufficient (I don't believe we are selecting the BC versions specifically.

If you search for the places where BC classes are imported that will point you in the direction of the non-JCE usages.

Mike

wwilliams
Offline
Joined: 2008-07-13
Points: 0

Thanks for your response Mike.

I revisited PSEUtils and found that the BC usage is restricted to both of the genCert methods as well as genCertSubjectCName and genCertIssuerCName although I don't believe any mods would have to occur in the latter two methods (Please correct me if I'm wrong). The big ones obviously are the genCert methods which are responsible for the generation and signing of certificates. This is where you would need to divert and interface to the BC Lightweight API to generate and sign the cert versus using Provider as these methods do now. With the help of Rene Mayrhofer who implemented a X509CertificateGenerator class that uses the BC Lightweight API to generate and sign a cert I am modifying PSEUtils to use BC Lightweight in the generation of the cert if and only if BouncyCastleProvider could not be loaded into the System classloader. I'm using a useProvider boolean that gets assigned to true after a successful attempt to load BouncyCastleProvider by the system loader. Otherwise the useProvider will stay false if the ClassNotFoundException is thrown.

I use this boolean indicator in the genCert methods to do the diversion to the BC Lightweight API if necessary. Interfacing to the Lightweight API adds a lot more code than using the Provider and so I have implemented separate private methods in that class to perform a RSA key generation and certificate generation. So far I have been able to successfully integrate RSA key pair generation and the ability to generate a cert using BC Lightweight API. I'm now working on the signing of the cert which is the last step. I will be sure to keep you and keesp updated on my progress.

Thanks.

-Wayne

keesp
Offline
Joined: 2007-05-22
Points: 0

Hi Wayne,

Back from the holidays, I have fully submerged myself into this problem and can get past the quick and dirty answers I gave the previous weeks ;)
As far as I can tell right now, I've moved back from Bondolo's proposition, not because it will not work, but rather because the bouncycastle problem is rather exemplary for a whole range of problems that concern integration of equinox and JCA.
Aas far as I understand it, equinox should at some point manage to provide a mechanism that would allow a plugin to implement security providers -and the classes it uses- that can be used without any problem.
Therefore, my own stance on this issue right now is that the current JXTA/Bouncycastle approach is correct and that equinox should provide the functionality needed to tackle this.
I've seen one incubator project that seems to be working on this, and I've contacted them for more info (the activity on this project appears to be rather low, see: http://www.eclipse.org/equinox/incubator/security/) and hopefully this may provide an alternative solution. However, there's a good possibility that this approach is going to take a long time, so probably you may end up having something much faster.

If this is the case, it could maybe be an idea to make a release in my equinox-jxta project environment (https://jxta-eclipse.dev.java.net/) and transfer this project as a subproject of jxta.

Kind regards

Kees

Message was edited by: keesp

bondolo
Offline
Joined: 2003-06-11
Points: 0

> Hi Bondolo,
>
> I've taken up up your challenge and have been looking
> into porting JXTA to the bouncycastle lightweight
> API. However, I am wondering if your suggestion to
> make direct calls against the API is the right way to
> go. The idea to use a provider is rather neat; the
> only problem is that PSEUtils forces JXTA to use the
> system classloader, while sometimes you might need to
> load a class from another one. Isn't it a better
> option to modify PSEUtils in such a way that you can
> provide a class loader upon initialisation?

No, the problem is due to BouncyCastle and JSSE being in different class loaders. The JCE algorithm selector allows a security algorithm only to load other algorithms from it's own class loader and parent class loaders. When BouncyCastle is not loaded into the system class loader then JSSE can't load algorithms from BouncyCastle. This mostly applies to the algorithms for the certificate extensions and for the PKCS#5/PKCS#8 PBE.

JCE does not allow algorithms to be loaded from other class loaders to prevent attack by rogue providers designed to subvert the security by substituting insecure implementations.

I believe there are any solutions to this problem using solely providers. If we can't load BouncyCastle into the system class loader we're dead in the water. The lightweight API doesn't use the JCE provider framework so it doesn't have this problem. (It's also entirely self contained, it doesn't call any outside security code).

PSEUtils needs to replace all use of JSSE/JCE with the BouncyCastle Lightweight API to fix this problem.

keesp
Offline
Joined: 2007-05-22
Points: 0

I had run into this myself by now. I've been looking into ways of providing a classloader through the constructor of PSEUtils, or add a singleton that offers the classloader, so that the bundle classloader could be used, but I haven't made much progress on this (holidays...).
Hope to continue in two weeks time...

Kees

keesp
Offline
Joined: 2007-05-22
Points: 0

Hi Bondolo,

I've taken up up your challenge and have been looking into porting JXTA to the bouncycastle lightweight API. However, I am wondering if your suggestion to make direct calls against the API is the right way to go. The idea to use a provider is rather neat; the only problem is that PSEUtils forces JXTA to use the system classloader, while sometimes you might need to load a class from another one. Isn't it a better option to modify PSEUtils in such a way that you can provide a class loader upon initialisation? That would mean changing the singleton construction a bit. I did some tests and that seemed to work okay, but I can imagine that I need to proceed carefully as PSEUtils seems to be used in various locations in JXTA.

Keesp

wwilliams
Offline
Joined: 2008-07-13
Points: 0

Hi Keesp,

Any word or updates on this from Bondolo? I'm very anxious to get a working version of this as my Eclipse/OSGi/JXTA project requires it. Please let me know if I can be of any help!

Thanks!

jgoebel
Offline
Joined: 2008-07-17
Points: 0

The Apache ServiceMix project is using Felix to create an OSGi kernel for their ESB. They ran into the same issue when trying to integrate JAAS. Documentation is a little sparse, but you could look at this page: http://servicemix.apache.org/SMX4KNL/45-security-framework.html and the source code for the "ProxyLoginModule."

Also you may find this blog entry useful: http://gnodet.blogspot.com/2008/05/jaas-in-osgi.html

Hope this helps. Having the JXTA core as an OSGi bundle would be very useful!

Jay

wwilliams
Offline
Joined: 2008-07-13
Points: 0

Hi Jay,

Thanks for the links and info. The Apache ServiceMix sounds like an interesting project. I decided to take up Bondolo's challenge and started to replace in PSEUtils the JCE Provider calls with direct calls into the Bounty Castle Lightweight API. When I found out that it was going to be a simple API replace since the Lightweight API requires more effort on the developer to work with than the JCE Provider I found myself spending a lot of time trying to learning how to use the Lightweight API (especially the algorithm engine implementations PKCS#5/PKCS#8 PBE) and Java security in general. I'm very much a novice when it comes to working with the Java Security and Cryptography architecture. It wasn't my idea to be spending a lot of time on this as I have so many other things I need to focus on so I resorted to a very quick and easy solution. I just dropped the Bouncy Castle lib in my Java 5 JRE's ext directory enabling the Bouncy Castle Provider to be loaded in the System Classloader during the init of PSEUtils. Seemed like a logical place being that Sun JCE Provider and PKCS libs are there as well but definitely not an elegant solution by far and away. Still I have my JXTA Eclipse plugin playing rather nicely with my other plugins and PSEUtils has not given me any more issues.

Excuse for my ignorance on Java security but I thought when I was reading up on it that Sun's JCE Provider provides engine implementations for PKCS#5/PKCS#8 PBE. So the obvious question is what is the real need for Bouncy Castle besides the fact that may be it provides a far superior implementation of those algorithms? I don't know ... I was just curious if someone knew.

-Wayne

keesp
Offline
Joined: 2007-05-22
Points: 0

Hi Wayne,

Sounds interesting what you did, I'll look into it myself also tomorrow or the day after.
Bondolo will probably give the real answer to your question, but I'm pretty sure it's mainly historical, Bouncycastle has been in JXTA at a quite early stage, before the encryption package of JAVA matured. There were also some judicial issues that some algorithms were not allowed to be used outside the States because they were considered confidential or so. Bouncycastle I believe was a means to bypass this.

The problem with JXTA from the start has been that it used quite a lot of third party code that either became more bloated over time (e.g. Apache's log4J) or changed considerably (Mortbay Jetty), which made maintenance quite problematic and probably caused more headaches for the JXTA team than that it brought relief. The 2.5.0 version seems to be a good fix to these problems, but Equinox pushes the issues of component-based packages a bit further...

Kees

keesp
Offline
Joined: 2007-05-22
Points: 0

From what I understand looking into PSEUtils, is that JXTA basically only uses one encryption algorithm, which probably could also be replaced by a JAVA5 and further implementation. Considering the fact that the bouncycastle problem only occurs when creating the platformconfig file, I think that this might even be a simpler solution, but I'm not quite sure if this might have some unforseen consequences. It would mean that backwards JXTA compatibility with previous JAVA versions is breached.

I agree with you that the replacement that Bondolo suggests is not easy. I'm also not sure if the conversion really solves the problem as the decision to use the system classloader is done for good security reasons.
Your solution is problematic in the sense that it is breaches the fundamental ideas of component-based programming equinox style. You might run into problems when wanting to distribute your product and have to set the class path to include bouncycastle with every distribution..it's possible, but classpath issues introduce their own can of worms...
So as long as you're doing this for a standalone situation its a possible workaround

Kees

bondolo
Offline
Joined: 2003-06-11
Points: 0

The warning you are seeing is due to the class loader security infrastructure that OSGI uses for bundles. JXTA is trying to install a security provider, BouncyCastle, and is not being allowed to do so. Unfortunately the design of JCE requires that security providers be loaded into the system class loader in order to be fully trusted. Running within OSGI (or in an Applet, Servlet or within Java Web Start) JXTA might not be able to do all of the required security operations. Since you say that your application is not explicitly using PSE and you are not seeing any unrecoverable "SEVERE" failure messages on the console I suspect that the problems you are encountering are unrelated to the Security providers warning message.

Good Developer Opportunity : Replace JXTA's use of the Bouncy Castle JCE provider with direct calls into the Bouncy Castle lightweight API in order to permanently eliminate this problem.

keesp
Offline
Joined: 2007-05-22
Points: 0

There's a workaround for this problem: just copy and paste a default platformconfig file in .jxta and change the contents using configuration manager.

Not neat, but it does work....

Kees