You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Ian Boston <ie...@tfd.co.uk> on 2010/03/28 10:20:38 UTC

Non listed bundle dependencies.

Hi 
What us the procedure for handling unlisted bundle dependencies ?

eg, servlets/get has a dependency on resources since it has a redirect.cnd with a super type defined in jcr/resource

If servlets get loads it node types before jsr/resource the there is an exception, eg
Caused by: org.apache.jackrabbit.core.nodetype.InvalidNodeTypeDefException: [{http://sling.apache.org/jcr/sling/1.0}Redirect] invalid supertype: {http://sling.apache.org/jcr/sling/1.0}Resource

This only happens on certain OS's since the load sequence is file system order dependent with disconnected bundles in the same start level. (eg its OK on OSX which lists directors in natural order, but not ok on ext3 which lists in date order iirc)

and a second question.

Is it possible to change, invert or randomize the start order in Felix so that I don't have to test startup on all the OS's I can run a VM for ?


Ian

(perhaps redirect.cnd should be in jcr/resources ? )

Re: Non listed bundle dependencies.

Posted by Justin Edelson <ju...@gmail.com>.
On Mar 30, 2010, at 5:02 PM, Ian Boston <ie...@tfd.co.uk> wrote:

>
> On 30 Mar 2010, at 07:15, Felix Meschberger wrote:
>
>> So, how about moving the node type definition to the jcr.resource
>> bundle ?
>
> +1,
> Its the only cnd file outside jcr.resource in the core code.
> and sling:target is referenced in jcr.resource anyway.
>
> btw, I'd also like to avoid Require-Bundle if possible, partly
> because it may prevent replacement bundles providing the same
> functionality, if there was a "Require-Capability" in OSGi it might
> be more appropriate.
>
> Ian

Re: Non listed bundle dependencies.

Posted by Justin Edelson <ju...@gmail.com>.
On Mar 30, 2010, at 5:02 PM, Ian Boston <ie...@tfd.co.uk> wrote:

>
> On 30 Mar 2010, at 07:15, Felix Meschberger wrote:
>
>> So, how about moving the node type definition to the jcr.resource
>> bundle ?
>
> +1,
> Its the only cnd file outside jcr.resource in the core code.
> and sling:target is referenced in jcr.resource anyway.
>
If this is the case, then the cnd files should absolutely be in the
jcr.resource bundle.

> btw, I'd also like to avoid Require-Bundle if possible, partly
> because it may prevent replacement bundles providing the same
> functionality, if there was a "Require-Capability" in OSGi it might
> be more appropriate.
>
I understand the arguments against Require-Bundle, but I'm not aware
of a way to describe a dependency between bundle resources which the
bundle resolver will take into account (i.e. Something like Require/
Provide-Capability). The only other option which comes to mind is to
export and import fake packages, but that seems like it would cause
problems at some point.

So while moving the CND around is a good solution for this particular
issue, I personally am still looking for a good way to describe
dependencies between bundle resources, most significantly nodetypes,
initial content, and bundle-provided resources. In all of these cases,
I'm less concerned with start order as I am with presence.

Justin

> Ian

Re: Non listed bundle dependencies.

Posted by Ian Boston <ie...@tfd.co.uk>.
On 30 Mar 2010, at 07:15, Felix Meschberger wrote:

> So, how about moving the node type definition to the jcr.resource bundle ?

+1,
Its the only cnd file outside jcr.resource in the core code.
and sling:target is referenced in jcr.resource anyway.

btw, I'd also like to avoid Require-Bundle if possible, partly because it may prevent replacement bundles providing the same functionality, if there was a "Require-Capability" in OSGi it might be more appropriate.

Ian

Re: Non listed bundle dependencies.

Posted by Felix Meschberger <fm...@gmail.com>.
Hi,

On 29.03.2010 23:55, Justin Edelson wrote:
> This does remind me that I keep meaning to ask if anyone knows/remembers why
> the bundles are in the start levels they are and whether or not this is
> necessary.... e.g. why is commons.log in start level 1 (and not 0)?
> 
> In this particular case, it seems like we should move jcr.resource into
> start level 15, with the other jcr bundles.
> 
> OR...
> 
> we should get rid of start levels at all and just stick everything in 0.
> 
> In either case, I think we should use Require-Bundle to express the
> dependency between servlets.get and jcr.resource. I usually don't love the
> use of Require-Bundle but in this case, we need to document the dependency
> somewhere (even though we recover from the error)

Require-Bundle is like a red rag to me ;-)

It would create all sorts of problems (strong bundle dependency is just
one among them) to fix a minor issue which is a bit exagerated due to
the stacktrace occurring in the log file (as I said, node type
management is currently sub-optimal and error handling close to impossible).

Also, there is (technically) no relationship between servlets.get and
jcr.resource. There is a dependency of the node type in servlets.get on
the node types provided by jcr.resource. That's all. And nothing
dramatic - in the end of the day (today), servlets.get is not
operational at all if jcr.resource is not available.

Maybe it is just plain wrong to have node type definitions in the
servlets.get bundle in the first place. Maybe its better to move the
node types to the jcr.resource bundle, because it is basically the
jcr.resource bundle, which creates the redirect resource instance while
the servlets.get bundle just supports such resources for redirection.

So, how about moving the node type definition to the jcr.resource bundle ?

Regards
Felix

> 
> Justin
> 
> 
> On Sun, Mar 28, 2010 at 4:20 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> 
>> Hi
>> What us the procedure for handling unlisted bundle dependencies ?
>>
>> eg, servlets/get has a dependency on resources since it has a redirect.cnd
>> with a super type defined in jcr/resource
>>
>> If servlets get loads it node types before jsr/resource the there is an
>> exception, eg
>> Caused by: org.apache.jackrabbit.core.nodetype.InvalidNodeTypeDefException:
>> [{http://sling.apache.org/jcr/sling/1.0}Redirect<http://sling.apache.org/jcr/sling/1.0%7DRedirect>]
>> invalid supertype: {http://sling.apache.org/jcr/sling/1.0}Resource<http://sling.apache.org/jcr/sling/1.0%7DResource>
>>
>> This only happens on certain OS's since the load sequence is file system
>> order dependent with disconnected bundles in the same start level. (eg its
>> OK on OSX which lists directors in natural order, but not ok on ext3 which
>> lists in date order iirc)
>>
>> and a second question.
>>
>> Is it possible to change, invert or randomize the start order in Felix so
>> that I don't have to test startup on all the OS's I can run a VM for ?
>>
>>
>> Ian
>>
>> (perhaps redirect.cnd should be in jcr/resources ? )
> 

Re: Non listed bundle dependencies.

Posted by Justin Edelson <ju...@gmail.com>.
This does remind me that I keep meaning to ask if anyone knows/remembers why
the bundles are in the start levels they are and whether or not this is
necessary.... e.g. why is commons.log in start level 1 (and not 0)?

In this particular case, it seems like we should move jcr.resource into
start level 15, with the other jcr bundles.

OR...

we should get rid of start levels at all and just stick everything in 0.

In either case, I think we should use Require-Bundle to express the
dependency between servlets.get and jcr.resource. I usually don't love the
use of Require-Bundle but in this case, we need to document the dependency
somewhere (even though we recover from the error)

Justin


On Sun, Mar 28, 2010 at 4:20 AM, Ian Boston <ie...@tfd.co.uk> wrote:

> Hi
> What us the procedure for handling unlisted bundle dependencies ?
>
> eg, servlets/get has a dependency on resources since it has a redirect.cnd
> with a super type defined in jcr/resource
>
> If servlets get loads it node types before jsr/resource the there is an
> exception, eg
> Caused by: org.apache.jackrabbit.core.nodetype.InvalidNodeTypeDefException:
> [{http://sling.apache.org/jcr/sling/1.0}Redirect<http://sling.apache.org/jcr/sling/1.0%7DRedirect>]
> invalid supertype: {http://sling.apache.org/jcr/sling/1.0}Resource<http://sling.apache.org/jcr/sling/1.0%7DResource>
>
> This only happens on certain OS's since the load sequence is file system
> order dependent with disconnected bundles in the same start level. (eg its
> OK on OSX which lists directors in natural order, but not ok on ext3 which
> lists in date order iirc)
>
> and a second question.
>
> Is it possible to change, invert or randomize the start order in Felix so
> that I don't have to test startup on all the OS's I can run a VM for ?
>
>
> Ian
>
> (perhaps redirect.cnd should be in jcr/resources ? )

Re: Non listed bundle dependencies.

Posted by Felix Meschberger <fm...@gmail.com>.
Hi,

On 29.03.2010 14:31, Carsten Ziegeler wrote:
> Ian Boston  wrote
>> Hi 
>> What us the procedure for handling unlisted bundle dependencies ?
>>
>> eg, servlets/get has a dependency on resources since it has a redirect.cnd with a super type defined in jcr/resource
>>
>> If servlets get loads it node types before jsr/resource the there is an exception, eg
>> Caused by: org.apache.jackrabbit.core.nodetype.InvalidNodeTypeDefException: [{http://sling.apache.org/jcr/sling/1.0}Redirect] invalid supertype: {http://sling.apache.org/jcr/sling/1.0}Resource
>>
>> This only happens on certain OS's since the load sequence is file system order dependent with disconnected bundles in the same start level. (eg its OK on OSX which lists directors in natural order, but not ok on ext3 which lists in date order iirc)
>>
>> and a second question.
>>
>> Is it possible to change, invert or randomize the start order in Felix so that I don't have to test startup on all the OS's I can run a VM for ?
>>
>>
> I don't know the answer to your question, but usually node type
> registration is retried if it fails as soon as another bundle is
> installed. So while the above error statement is logged, the node type
> should be registered correctly at a later stage.
> This is implemented this way to avoid adding new levels of dependencies
> between bundles :)

Correct, and in fact there is a bug releated to improve node type
registration, because currently we use a very simple API which has very
weak operation feedback (it just throws a RepositoryException and a
program must parse the message to try to find out about the problem...).

Now that we use Jackrabbit 2 with JCR 2 we could implement our own CND
file parsing and register the node types with low-level JCR2 node type
management calls and better log problems.

The issue is https://issues.apache.org/jira/browse/SLING-7 (one of our
oldest issues still open ....)

Regards
Felix

Re: Non listed bundle dependencies.

Posted by Carsten Ziegeler <cz...@apache.org>.
Ian Boston  wrote
> Hi 
> What us the procedure for handling unlisted bundle dependencies ?
> 
> eg, servlets/get has a dependency on resources since it has a redirect.cnd with a super type defined in jcr/resource
> 
> If servlets get loads it node types before jsr/resource the there is an exception, eg
> Caused by: org.apache.jackrabbit.core.nodetype.InvalidNodeTypeDefException: [{http://sling.apache.org/jcr/sling/1.0}Redirect] invalid supertype: {http://sling.apache.org/jcr/sling/1.0}Resource
> 
> This only happens on certain OS's since the load sequence is file system order dependent with disconnected bundles in the same start level. (eg its OK on OSX which lists directors in natural order, but not ok on ext3 which lists in date order iirc)
> 
> and a second question.
> 
> Is it possible to change, invert or randomize the start order in Felix so that I don't have to test startup on all the OS's I can run a VM for ?
> 
> 
I don't know the answer to your question, but usually node type
registration is retried if it fails as soon as another bundle is
installed. So while the above error statement is logged, the node type
should be registered correctly at a later stage.
This is implemented this way to avoid adding new levels of dependencies
between bundles :)

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org