Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » BIRT » BIRT/OSGi Classloading screwing up SSL in WebSphere?!
BIRT/OSGi Classloading screwing up SSL in WebSphere?! [message #628662] Thu, 23 September 2010 15:15 Go to next message
Robert Aust is currently offline Robert AustFriend
Messages: 17
Registered: July 2009
Junior Member
Hi,

I've been working on this problems since a couple of days..
The scenario is this:

BIRT 2.5.2 integrated in a WebApp i.e. a InitServerlt starting up the
Engine [referencing the runtime somewhere in the filesystem].
So BIRT [all necessary classes/libraries] is included with the WEB-APP
in the ear-File.

This is then deployed to WebSphere 6.1
First I head PARENT_LAST - but after I fixed some classpath-issues
concerning XML und logging etc. PARENT_FIRST [standard] worked also,
meaning BIRT starts up produces a test-report.

BUT - in my application I also use a background-thread for some long-ops
and in this operations HTTPS-access to a WebService fails with
"MalformedURLException" in "java.net.URL", since it abviously cannot
find the SSL-Implementation [of WebSphere] anymore and thererfor cannot
handle "https"..

I've tried several variations of Thread.setContextClassloader in the
code, where the background-Thread is started, but no success.
The same problem appears with the scheduler quartz, although I use a
config-property to use the TheadContextClassloader.

Does anyboy has an idea, what happens to the [Context-] Clasloaders when
BIRT ist started inside a WebSphere WebApp?
And how I possibly could get SSL to work?

The SSL-implementation is com.ibm.websphere.ssl.protocol.SSLSocketFactory
and the CodeSource is a OSGi-Plugin of WebSphere itself :

ProtectionDomain
(file:/opt/WebSphere/AppServer-6.1/plugins/com.ibm.ws.securi ty.crypto_6.1.0.jar
<no signer certificates>)
null
<no principals>
org.eclipse.osgi.framework.internal.core.BundleCombinedPermi ssions @70007000
(
)

Is there a way to use this plugin/library also in the BIRT-OSGi, so that
it will be availibe to the application AFTER BIRT ist started?

Thanks a lot!
Robert
Re: BIRT/OSGi Classloading screwing up SSL in WebSphere?! [message #628695 is a reply to message #628662] Thu, 23 September 2010 17:14 Go to previous messageGo to next message
Jason Weathersby is currently offline Jason WeathersbyFriend
Messages: 9167
Registered: July 2009
Senior Member

Can you open a bugzilla entry for this?

Jason

On 9/23/2010 11:15 AM, Robert Aust wrote:
>
> Hi,
>
> I've been working on this problems since a couple of days..
> The scenario is this:
>
> BIRT 2.5.2 integrated in a WebApp i.e. a InitServerlt starting up the
> Engine [referencing the runtime somewhere in the filesystem].
> So BIRT [all necessary classes/libraries] is included with the WEB-APP
> in the ear-File.
>
> This is then deployed to WebSphere 6.1
> First I head PARENT_LAST - but after I fixed some classpath-issues
> concerning XML und logging etc. PARENT_FIRST [standard] worked also,
> meaning BIRT starts up produces a test-report.
>
> BUT - in my application I also use a background-thread for some long-ops
> and in this operations HTTPS-access to a WebService fails with
> "MalformedURLException" in "java.net.URL", since it abviously cannot
> find the SSL-Implementation [of WebSphere] anymore and thererfor cannot
> handle "https"..
>
> I've tried several variations of Thread.setContextClassloader in the
> code, where the background-Thread is started, but no success.
> The same problem appears with the scheduler quartz, although I use a
> config-property to use the TheadContextClassloader.
>
> Does anyboy has an idea, what happens to the [Context-] Clasloaders when
> BIRT ist started inside a WebSphere WebApp?
> And how I possibly could get SSL to work?
>
> The SSL-implementation is com.ibm.websphere.ssl.protocol.SSLSocketFactory
> and the CodeSource is a OSGi-Plugin of WebSphere itself :
>
> ProtectionDomain
> (file:/opt/WebSphere/AppServer-6.1/plugins/com.ibm.ws.securi ty.crypto_6.1.0.jar
> <no signer certificates>)
> null
> <no principals>
> org.eclipse.osgi.framework.internal.core.BundleCombinedPermi ssions @70007000
> (
> )
>
> Is there a way to use this plugin/library also in the BIRT-OSGi, so that
> it will be availibe to the application AFTER BIRT ist started?
>
> Thanks a lot!
> Robert
>
>
Re: BIRT/OSGi Classloading screwing up SSL in WebSphere?! [message #628782 is a reply to message #628695] Fri, 24 September 2010 07:01 Go to previous messageGo to next message
Robert Aust is currently offline Robert AustFriend
Messages: 17
Registered: July 2009
Junior Member
Hi Jason,

Done : https://bugs.eclipse.org/bugs/show_bug.cgi?id=326118

In the entry, I have also added a link to an IBM APAR, that describes
the same problem inside some tivoli-product using BIRT and also gives
a workaround. I will try that.

Best regards,
Robert-


Am 23.09.2010 19:15, schrieb Jason Weathersby:
> Can you open a bugzilla entry for this?
>
> Jason
>
> On 9/23/2010 11:15 AM, Robert Aust wrote:
>>
>> Hi,
>>
>> I've been working on this problems since a couple of days..
>> The scenario is this:
>>
>> BIRT 2.5.2 integrated in a WebApp i.e. a InitServerlt starting up the
>> Engine [referencing the runtime somewhere in the filesystem].
>> So BIRT [all necessary classes/libraries] is included with the WEB-APP
>> in the ear-File.
>>
>> This is then deployed to WebSphere 6.1
>> First I head PARENT_LAST - but after I fixed some classpath-issues
>> concerning XML und logging etc. PARENT_FIRST [standard] worked also,
>> meaning BIRT starts up produces a test-report.
>>
>> BUT - in my application I also use a background-thread for some long-ops
>> and in this operations HTTPS-access to a WebService fails with
>> "MalformedURLException" in "java.net.URL", since it abviously cannot
>> find the SSL-Implementation [of WebSphere] anymore and thererfor cannot
>> handle "https"..
>>
>> I've tried several variations of Thread.setContextClassloader in the
>> code, where the background-Thread is started, but no success.
>> The same problem appears with the scheduler quartz, although I use a
>> config-property to use the TheadContextClassloader.
>>
>> Does anyboy has an idea, what happens to the [Context-] Clasloaders when
>> BIRT ist started inside a WebSphere WebApp?
>> And how I possibly could get SSL to work?
>>
>> The SSL-implementation is com.ibm.websphere.ssl.protocol.SSLSocketFactory
>> and the CodeSource is a OSGi-Plugin of WebSphere itself :
>>
>> ProtectionDomain
>> (file:/opt/WebSphere/AppServer-6.1/plugins/com.ibm.ws.securi ty.crypto_6.1.0.jar
>>
>> <no signer certificates>)
>> null
>> <no principals>
>> org.eclipse.osgi.framework.internal.core.BundleCombinedPermi ssions @70007000
>>
>> (
>> )
>>
>> Is there a way to use this plugin/library also in the BIRT-OSGi, so that
>> it will be availibe to the application AFTER BIRT ist started?
>>
>> Thanks a lot!
>> Robert
>>
>>
>
Re: BIRT/OSGi Classloading screwing up SSL in WebSphere?! [message #628900 is a reply to message #628782] Fri, 24 September 2010 16:34 Go to previous message
Jason Weathersby is currently offline Jason WeathersbyFriend
Messages: 9167
Registered: July 2009
Senior Member

Robert,

Thanks. Please post an update when you have one.

Jason

On 9/24/2010 3:01 AM, Robert Aust wrote:
> Hi Jason,
>
> Done : https://bugs.eclipse.org/bugs/show_bug.cgi?id=326118
>
> In the entry, I have also added a link to an IBM APAR, that describes
> the same problem inside some tivoli-product using BIRT and also gives
> a workaround. I will try that.
>
> Best regards,
> Robert-
>
>
> Am 23.09.2010 19:15, schrieb Jason Weathersby:
>> Can you open a bugzilla entry for this?
>>
>> Jason
>>
>> On 9/23/2010 11:15 AM, Robert Aust wrote:
>>>
>>> Hi,
>>>
>>> I've been working on this problems since a couple of days..
>>> The scenario is this:
>>>
>>> BIRT 2.5.2 integrated in a WebApp i.e. a InitServerlt starting up the
>>> Engine [referencing the runtime somewhere in the filesystem].
>>> So BIRT [all necessary classes/libraries] is included with the WEB-APP
>>> in the ear-File.
>>>
>>> This is then deployed to WebSphere 6.1
>>> First I head PARENT_LAST - but after I fixed some classpath-issues
>>> concerning XML und logging etc. PARENT_FIRST [standard] worked also,
>>> meaning BIRT starts up produces a test-report.
>>>
>>> BUT - in my application I also use a background-thread for some long-ops
>>> and in this operations HTTPS-access to a WebService fails with
>>> "MalformedURLException" in "java.net.URL", since it abviously cannot
>>> find the SSL-Implementation [of WebSphere] anymore and thererfor cannot
>>> handle "https"..
>>>
>>> I've tried several variations of Thread.setContextClassloader in the
>>> code, where the background-Thread is started, but no success.
>>> The same problem appears with the scheduler quartz, although I use a
>>> config-property to use the TheadContextClassloader.
>>>
>>> Does anyboy has an idea, what happens to the [Context-] Clasloaders when
>>> BIRT ist started inside a WebSphere WebApp?
>>> And how I possibly could get SSL to work?
>>>
>>> The SSL-implementation is
>>> com.ibm.websphere.ssl.protocol.SSLSocketFactory
>>> and the CodeSource is a OSGi-Plugin of WebSphere itself :
>>>
>>> ProtectionDomain
>>> (file:/opt/WebSphere/AppServer-6.1/plugins/com.ibm.ws.securi ty.crypto_6.1.0.jar
>>>
>>>
>>> <no signer certificates>)
>>> null
>>> <no principals>
>>> org.eclipse.osgi.framework.internal.core.BundleCombinedPermi ssions @70007000
>>>
>>>
>>> (
>>> )
>>>
>>> Is there a way to use this plugin/library also in the BIRT-OSGi, so that
>>> it will be availibe to the application AFTER BIRT ist started?
>>>
>>> Thanks a lot!
>>> Robert
>>>
>>>
>>
>
Previous Topic:Securtity in BIRT
Next Topic:Birt Quesries
Goto Forum:
  


Current Time: Thu Apr 25 15:05:41 GMT 2024

Powered by FUDForum. Page generated in 0.02783 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top