felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Error with multiple instances of Felix running as separate EAR deployments in WebLogic
Date Mon, 09 Jan 2012 16:38:07 GMT

On 1/9/12 10:08 , Steele, Richard wrote:
> On Mon, Jan 9, 2012 at 8:46 AM, Karl Pauls<karlpauls@gmail.com>  wrote:
> Sorry for the late reply - still in vacation mode :-).
> No need to apologize!
>> Your problem is a tricky one namely,
>> spring (or blueprint) is creating bundle: urls manually (or
>> toString()ing bundle urls and then creating them again).
> This is a problem in itself as bundle: urls are not spec'ed (ie., they
>> are guessing). They get the format right but the problem is that we
>> need to know the framework the bundle is in and this information is
>> lost (the bundle: url doesn't say which framework it targets).
> Is this an invalid assumption that Eclipse Gemini Blueprint is making
> then?  Should a defect be reported to them?

It depends, it they are taking one of our bundle: URLs and simply 
toString()'ing it, then we can possibly make this work by adding a 
framework ID to our bundle: URL. If they are constructing one from 
scratch, then we'd likely still have the issue.

>> We do handle multiple framework instances as we have a simple
>> heuristic in place: if there is only one running/registered framework
>> inside the vm then use that one (i.e., it works in this case). If
>> there are more, fail.
>> You are running in the second case :-(
> Yes.

To be clear, our solution works if you have multiple framework instances 
as long as you aren't either (1) constructing bundle: URLs by hand or 
(2) toString()'ing bundle: URLs.

It would seem you are getting into the failure case because one of these 
two is happening.

> For other protocols the same problem exists only if the handler is a
>> URLHandlers Service (and not provided by the environment) and can be
>> made a little less problematic by setting
>> felix.service.urlhandlers=false. Unfortunately, for you, spring needs
>> the data and insists on using a bundle: url -- hence, you can't set
>> the property to false.
> So in general with well-behaved bundles setting felix.service.urlhandlers
> to false ought to work?
>> I was at one point proposing to encode a known framework id into the
>> bundle: url in order to resolve this issue but it didn't make it spec
>> and as a consequence, even if I'd add one, spring wouldn't know about
>> it.

As of R4.3, we do have a framework ID spec, so we could do this, but it 
would still only solve case (2) above. As long as that is your case, 
then it would work.

Could you open up a bug for us to consider adding a framework ID on 
bundle: URLs? Thanks.

-> richard

>> I'm not sure how to tackle your problem. Why do you need two
>> frameworks in the first place? Can't you run both apps inside the same
>> framework? Otherwise, maybe not using spring helps (not sure about
>> blueprint).
> The "why" is because our system administrators say so.  :-( This could
> perhaps be renegotiated given our current troubles, especially since there
> doesn't appear to be an easy answer to this.
> (I hate to even ask on this forum, but does anyone know if other OSGi
> implementations have the same issue?)
> We're using Spring because as far as I know that's what Gemini Blueprint
> requires.  We're using Blueprint because many of our developers are already
> very familiar with Spring and DI in general.
> regards,
>> Karl
> Thanks,
> Rich

To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

View raw message