You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Marcel Offermans <ma...@luminis.nl> on 2012/01/09 18:22:53 UTC
Re: Error with multiple instances of Felix running as separate EAR deployments in WebLogic
On Jan 9, 2012, at 17:44 PM, Karl Pauls wrote:
>> 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.
You're referring to 4.2.8 that defines a Framework UUID I guess?
As far as I understand from the implementation (Util.randomUUID()) the framework gets a "new" unique ID every time it starts. We might want to consider holding on to it (in our bundle cache) to at least keep it as "constant" as we can.
Why?
I can see some value in a URL not changing, and if we include it in the bundle: URLs we generate, we might want to do our best to ensure they are valid for longer than the current framework run.
Greetings, Marcel
Re: Error with multiple instances of Felix running as separate EAR deployments in WebLogic
Posted by Marcel Offermans <ma...@luminis.nl>.
On Jan 9, 2012, at 19:47 PM, Karl Pauls wrote:
> On Mon, Jan 9, 2012 at 6:22 PM, Marcel Offermans
> <ma...@luminis.nl> wrote:
>> On Jan 9, 2012, at 17:44 PM, Karl Pauls wrote:
>>
>>>> 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.
>>
>> You're referring to 4.2.8 that defines a Framework UUID I guess?
>>
>> As far as I understand from the implementation (Util.randomUUID()) the framework gets a "new" unique ID every time it starts. We might want to consider holding on to it (in our bundle cache) to at least keep it as "constant" as we can.
>>
>> Why?
>>
>> I can see some value in a URL not changing, and if we include it in the bundle: URLs we generate, we might want to do our best to ensure they are valid for longer than the current framework run.
>
> I agree that there is some value to it but at the same time, we
> already have that problem as we need to encode the revision number in
> the url which might be invalid/changed after a refresh/restart...
>
> Making assumptions about the bundle: urls is a problem not matter what :-).
Good point, so unless we somehow manage to "fix" other issues with this URL, one should not rely on them to stick around for longer than the life cycle of the framework itself.
Greetings, Marcel
Re: Error with multiple instances of Felix running as separate EAR deployments in WebLogic
Posted by Marcel Offermans <ma...@luminis.nl>.
On Jan 9, 2012, at 19:47 PM, Karl Pauls wrote:
> On Mon, Jan 9, 2012 at 6:22 PM, Marcel Offermans
> <ma...@luminis.nl> wrote:
>> On Jan 9, 2012, at 17:44 PM, Karl Pauls wrote:
>>
>>>> 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.
>>
>> You're referring to 4.2.8 that defines a Framework UUID I guess?
>>
>> As far as I understand from the implementation (Util.randomUUID()) the framework gets a "new" unique ID every time it starts. We might want to consider holding on to it (in our bundle cache) to at least keep it as "constant" as we can.
>>
>> Why?
>>
>> I can see some value in a URL not changing, and if we include it in the bundle: URLs we generate, we might want to do our best to ensure they are valid for longer than the current framework run.
>
> I agree that there is some value to it but at the same time, we
> already have that problem as we need to encode the revision number in
> the url which might be invalid/changed after a refresh/restart...
>
> Making assumptions about the bundle: urls is a problem not matter what :-).
Good point, so unless we somehow manage to "fix" other issues with this URL, one should not rely on them to stick around for longer than the life cycle of the framework itself.
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Error with multiple instances of Felix running as separate EAR
deployments in WebLogic
Posted by Karl Pauls <ka...@gmail.com>.
On Mon, Jan 9, 2012 at 6:22 PM, Marcel Offermans
<ma...@luminis.nl> wrote:
> On Jan 9, 2012, at 17:44 PM, Karl Pauls wrote:
>
>>> 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.
>
> You're referring to 4.2.8 that defines a Framework UUID I guess?
>
> As far as I understand from the implementation (Util.randomUUID()) the framework gets a "new" unique ID every time it starts. We might want to consider holding on to it (in our bundle cache) to at least keep it as "constant" as we can.
>
> Why?
>
> I can see some value in a URL not changing, and if we include it in the bundle: URLs we generate, we might want to do our best to ensure they are valid for longer than the current framework run.
I agree that there is some value to it but at the same time, we
already have that problem as we need to encode the revision number in
the url which might be invalid/changed after a refresh/restart...
Making assumptions about the bundle: urls is a problem not matter what :-).
regards,
Karl
> Greetings, Marcel
>
--
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls
Re: Error with multiple instances of Felix running as separate EAR
deployments in WebLogic
Posted by Karl Pauls <ka...@gmail.com>.
On Mon, Jan 9, 2012 at 6:22 PM, Marcel Offermans
<ma...@luminis.nl> wrote:
> On Jan 9, 2012, at 17:44 PM, Karl Pauls wrote:
>
>>> 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.
>
> You're referring to 4.2.8 that defines a Framework UUID I guess?
>
> As far as I understand from the implementation (Util.randomUUID()) the framework gets a "new" unique ID every time it starts. We might want to consider holding on to it (in our bundle cache) to at least keep it as "constant" as we can.
>
> Why?
>
> I can see some value in a URL not changing, and if we include it in the bundle: URLs we generate, we might want to do our best to ensure they are valid for longer than the current framework run.
I agree that there is some value to it but at the same time, we
already have that problem as we need to encode the revision number in
the url which might be invalid/changed after a refresh/restart...
Making assumptions about the bundle: urls is a problem not matter what :-).
regards,
Karl
> Greetings, Marcel
>
--
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