Hi, Well, after some travails, I figured I'd post back...
Yes, had to play class loader games as below... Thanks for the tip. Also, due to use of embedded wsdl libraries et al (for which I am thoroughly opposed), vice using the spring converted bundles (on my TODO list), I had to add varying items from rt.jar to the bootdelegation property entry (for which I am also thoroughly opposed); As for SCR/DS... Turns out the generated wsdl code, which leaves MUCH to be desired, does not throw an exception, for which I was trapping... No... Instead, the generated wsdl code throws "Throwable" for which I was not trapping (at the time)... Thus, the "Throwable" was being caught/trapped by SCR/DS... Unfortunately, SCR/DS is not displaying the Throwable message... that would have been a big help... D-OSGi -- I am a big fan of this and I hope that all the splinter groups can consolidate the architecture... to that end, I have a pluggable transport (for IBM' System S) I would like to incorporate one day; I'm a bit leery of "stub" generation, however; I'm wondering if there's a way that the transport can be plugged in to the equation without the need to get involved in all the "stub" generation, but I suspect that is a year or more away from reality; Regards, Craig Phillips, Praxis Engineering From: Stefan Seifert Sent: Tue 3/9/2010 2:55 PM To: [email protected] Subject: RE: Axis2 / WSDL on OSGi (sorry, last message was sent to early) this is an issue with 3rdparty libraries loading classes via Thread.currentThread().getContextClassLoader() this is illegal/problematic in OSGI context. it happens with other complex libraries like apache CXF as well. a workaround is to wrap all calls to this libraries in blocks like: ClassLoader oldLoader = Thread.currentThread().getContextClassLoader(); Thread.currentThread().setContextClassLoader(getClassLoader()); try { // execute your code } finally { Thread.currentThread().setContextClassLoader(oldLoader); } this is somewhat ugly but worked well in our scenarios. stefan >-----Original Message----- >From: Craig Phillips [mailto:[email protected]] >Sent: Tuesday, March 09, 2010 5:02 PM >To: [email protected] >Subject: Axis2 / WSDL on OSGi > >Hi, > >Figured I'd retitle the thread.... Just posting back... > >So, I modified the Axis 2 wsdl generated code and threw in printf()'s ('er, >System.out's) and trapped the Throwables throughout... > >Turns out, the actual error/exception/throwable is a class-not-found on >javax.xml.naming... > >Now, javax.xml.naming (as well as a ton of other stuff) is in the bundle, >embedded, with bundle class path et al... also, the class loader was passed >to context class loader... I did mention this is inherited code, didn't I ? > >Anyway, yeah, I can go down the diagnostic path of bundle class path and >context class loaders and what have you trying to figure out why >javax.xml.naming can't be found... And, there's boot delegation as well... > >I figure there are some axis2 folk out there who could chime in and happen to >know the recommended / suggested quick answer... > >Much appreciated, Craig Phillips > > >-----Original Message----- >From: Craig Phillips [mailto:[email protected]] >Sent: Tue 3/9/2010 9:44 AM >To: [email protected] >Subject: RE: The activate method has thrown an exception > >Hi, > >re: DOSGI... Well, I'm not going that far (yet / at this time)... It looks >really interesting, but that's off topic for me right now... > >I did some preliminary surfing and found this: > >----------------------------------------------------------------------------- >------------------------------- >Well, i solved it just putting the following lines above my webservice >method caller...: > >[WebPermission(SecurityAction.Assert, Unrestricted = true)] >[EnvironmentPermission(SecurityAction.Assert, Unrestricted = true)] > >And i trusted my assembly in the client machine using a Strong name key >generated by the sn.exe. In the .net framework configuration i created >a new codegroup called "MyComponent", using the membership condiction >type as Strong Name and the Permission Set equal Full trust. >----------------------------------------------------------------------------- >- > >Unfortunately, I don't know what that all means, at least in terms of OSGi; >And, it appears 1.6 and I'd like something that doesn't require 1.6 based >language constructs... > >??? My gut feeling tells me I either have a config.properties setting or I >modify the jvm parameters on java startup ??? > >I appreciate all the feedback/help... If I manage to figure it out, I'll post >back... much appreciated, Craig > > > >From: Justin Edelson >Sent: Tue 3/9/2010 9:33 AM >To: [email protected] >Subject: Re: The activate method has thrown an exception > > >Hi. > >On 3/9/10 9:30 AM, Craig Phillips wrote: >> Hi, >> >> Well, I sort of need to get at what the actual exception is... I moved the >wsdl service instantiation code from the activator to a separate method, >which is invoked from within a client's bind method... Unfortunately, all >that did was move the problem... I got a similar behavior from SCR there: >"the client bind method has thrown an exception"... >> >> My gut is there's some sort of config.properties / possibly security >setting in order to instantiate a wsdl service from within an OSGi / SCR- >based container... >There's DOSGI. CXF has an implementation: >http://cxf.apache.org/distributed-osgi.html > >> >> Interestingly, I wrapped the wsdl instantiation within a try-catch, but >apparently the exception is caught by SCR first, and so the execution stack >is hi jacked - thus, my catch{} block is never executed; >Hmm. This would indicate that you're either catching the wrong exception >type or in the wrong place in your code. >> >> If there are any wsdl experts out there? Appreciate the >feedback/reply, Craig > >HTH, > >Justin > >> >> >> >> From: Felix Meschberger >> Sent: Tue 3/9/2010 8:52 AM >> To: [email protected] >> Subject: Re: The activate method has thrown an exception >> >> >> Hi Craig, >> >> The problem seems to be, that in the activate() method an exception is >> thrown, which is not handled inside the activate() method. >> >> As a consequence SCR catches the problem and logs said message. As a >> further consequence the component is not considered activated and thus >> the deactivate method will never be called. >> >> Hope this helps. >> >> Regards >> Felix >> >> On 09.03.2010 14:41, Craig Phillips wrote: >>> Hi, >>> >>> Felix 201 / SCR1.4.0... I'm attempting to connect to a wsdl service from >within the activate() method (don't ask / inherited code, although I'm open >to suggestions).. >>> >>> I am getting this message to log4j: "The activate method has thrown an >exception"... >>> >>> I did find one post a la google-surf back to felix and it suggests a >security related issue... There is apparently a fix, from what I can tell, >but it seemed that was for felix2.1.0 (no officially released)... >>> >>> Can someone shed some light / provide advisement? >>> >>> Thanks, Craig Phillips >>> >> > >
