[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [birt-dev] Birt Runtime integration : with JWS ? : Security issue
|
Marc
This is an interesting usage scenario. BIRT uses Eclipse' OSGi
implementation (equinox) to load its plugins (components), which does
have the issue you raise that it is using a different class loader from
the application that embeds BIRT engine.
Do you know if JWS offer any suggestion/solution for java apps that has
its own class loader? We will also do some research on JWS's security
model.
Thanks
Wenfeng
-----Original Message-----
From: birt-dev-bounces@xxxxxxxxxxx [mailto:birt-dev-bounces@xxxxxxxxxxx]
On Behalf Of birt@xxxxxxxxxxx
Sent: Thursday, March 15, 2007 1:28 PM
To: birt-dev@xxxxxxxxxxx
Subject: [birt-dev] Birt Runtime integration : with JWS ? : Security
issue
Hi all,
I have a question concerning BIRT runtime integration.
I work on a software project in a JBoss env. for a major software
company, and have integrated BIRT on the client side, as it meets all
our needs, well almost... :
Our Swing client (GUI), is distributed via Java Web Start, and the idea
was to install (unzip) the BIRT runtime on the client, from a install
package, and accessing it from the JWS (java web start) client.
When I set the BIRT runtime location from the app. distributed via Java
WebStart and run it, I get a java Security exception, which in fact, is
quite logical. JWS Security rules, implies, that every .jar archive has
to be signed AND loaded in the same classloader...Also, if I give the
most permissive configuration in the .jnlp file, I can write and read
anyware on the client PC. But, execution is not aloud..So, when I try to
launch the BIRT runtime, I get a security exception.
I tried signing the BIRT runtime jars, but of course, as they are not
loaded from the same classloader, I get the same Java Security
exception.
The only way, I found, to overcome this problem, is to modify the java
security policy, in order to give full access to the JWS client gui.
This solution works fine, but I find it dirty, and not buisness-wize : I
will have to ask my customers to modify there current JRE java security
policy file, which might not please them...
The main issue, is that the BIRT runtime and api does not offer the
possibility of embedding the runtime in my application. This is for me,
a big issue, as more and more software companies use JWS to distribute
their clients..So if BIRT wants to survive in J2EE envs. we have to find
a solution without modifying the policy file.
Has anybody come accross this issue or has ideas ?
Big thanks,
Marc Rochat (Switzerland)
P.S. In the mailing list, there was a question concerning the fact of
"embedding" the BIRT runtime "IN" the developped application without
pointing on a folder (i.E. birt-runtime.1.2.2/ReportEngine)..no answer
_______________________________________________
birt-dev mailing list
birt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/birt-dev