felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Pauls <karlpa...@gmail.com>
Subject Re: Error with multiple instances of Felix running as separate EAR deployments in WebLogic
Date Mon, 09 Jan 2012 18:50:09 GMT
After thinking some more about this I'm not so sure anymore I
understand what is going on correctly. It looks like the url is
generated by us -- hence, it should be working unless it is
toString()'ed _and_ recreated outside the framework.

Can you maybe share a little bit more about your set-up (ie., how do
you embed felix and how are bundles - esp. blueprint -  installed and
used - esp. in combination with spring - etc.)?

regards,

Karl

On Mon, Jan 9, 2012 at 5:44 PM, Karl Pauls <karlpauls@gmail.com> wrote:
> On Mon, Jan 9, 2012 at 5:38 PM, Richard S. Hall <heavy@ungoverned.org> wrote:
>>
>>
>> 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.
>
> Yeah, we should use the framework ID. Please open a bug for this.
>
> regards,
>
> Karl
>
>> 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
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls



-- 
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls

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


Mime
View raw message