Re: How to add bundles with transitive dependencies to a running Sling instance?

[Felix Meschberger]

Oops wrong search. Use: 
http://search.maven.org/#search%7Cga%7C1%7Corg.apache.felix.webconsole.plugins.obr

Regards
Felix

Am 13.09.2014 um 06:49 schrieb Felix Meschberger 
mailto:fmesc...@adobe.com>>:

Hi Sandro

IIRC we separated the OSGi Bundle Repository support out into a separate Web 
Console plugin bundle. You just would want to install that bundle and you 
should get that page back.

E.g. 
http://search.maven.org/#search%7Cga%7C1%7Cpackageadmin

Regards
Felix

Am 13.09.2014 um 00:23 schrieb Sandro Boehme 
mailto:sandro.boe...@gmx.de>>:

Hello,

in earlier versions of Sling I could use the OSGi repository admin page of the 
web console to start a bundle and get all its transitive dependencies resolved 
by Felix.
As this page is not available in the web console anymore, is there an 
other/better way of loading and starting 3rd party bundles in a running Sling 
instance?
Or is this page still to be integrated? If yes, I would be happy if I could 
help out. It would just be good to have some pointers as a starter to make it 
easier to get into this issue.

Best,

Sandro

Re: How to add bundles with transitive dependencies to a running Sling instance?

[Felix Meschberger]

Hi Sandro

IIRC we separated the OSGi Bundle Repository support out into a separate Web 
Console plugin bundle. You just would want to install that bundle and you 
should get that page back.

E.g. 
http://search.maven.org/#search%7Cga%7C1%7Cpackageadmin

Regards
Felix

Am 13.09.2014 um 00:23 schrieb Sandro Boehme 
mailto:sandro.boe...@gmx.de>>:

Hello,

in earlier versions of Sling I could use the OSGi repository admin page of the 
web console to start a bundle and get all its transitive dependencies resolved 
by Felix.
As this page is not available in the web console anymore, is there an 
other/better way of loading and starting 3rd party bundles in a running Sling 
instance?
Or is this page still to be integrated? If yes, I would be happy if I could 
help out. It would just be good to have some pointers as a starter to make it 
easier to get into this issue.

Best,

Sandro

Re: Differences between type responses for node and resource

[Alexander Klimetschek]

On 12.09.2014, at 10:55, Jason E Bailey  wrote:

> I have a hard time understanding how there would be added complexity by
> incorporating the nodeType hierarchy into a determination as to whether
> a specific resource "is" of a specific type. Multiple hierarchies are
> fairly common in programming languages, like the instanceof I mentioned
> that does both the class hierarchy and the interface hierarchy.

Yes, but it gets complicated when you look at the servlet resolution: which 
super type hierarchy has a higher precedence? The current weighting is already 
pretty complex.

And I think enforcing more use of resource types and less node types here is a 
good thing :)

>  I also
> don't see much confusion occurring from implementing this. If I am
> attempting to validate a whether something is inherited from nt:base I
> clearly have a need in mind that would be separate from desire to know
> if it's a sling component that inherits from "foundation/list"

BTW, you can handle the case yourself:

Node node = resource.adaptTo(Node.class);
if (node != null) {
if (node.isNodeType(nt)) {
// ...
}
}

Cheers,
Alex

How to add bundles with transitive dependencies to a running Sling instance?

[Sandro Boehme]

Hello,

in earlier versions of Sling I could use the OSGi repository admin page 
of the web console to start a bundle and get all its transitive 
dependencies resolved by Felix.
As this page is not available in the web console anymore, is there an 
other/better way of loading and starting 3rd party bundles in a running 
Sling instance?
Or is this page still to be integrated? If yes, I would be happy if I 
could help out. It would just be good to have some pointers as a starter 
to make it easier to get into this issue.


Best,

Sandro

Re: Differences between type responses for node and resource

[Jason E Bailey]

Hi Felix,

I appreciate the feedback and at this point I feel confident that I
understand the resource hierarchy structure and how it's implemented. I
think there is a missing use case that isn't being considered here. I
took some time this morning to do a review of the project that I'm
currently on and in the last 2 years of development with between 5-8
developers the only time that we have used resource.isResourceType was
to validate the primary node type and the only time we've done
node.isNodeType was when the  node type could have been hidden by the
sling:resourceType.

As for my personal project which started this conversation, this has
caused quite a bit of pain since I need to categorize by Type in quite a
few places. I think I'm good with a solution however;

session.getWorkspace().getNodeTypeManager().getNodeType("primaryNode").isNodeType("desired")

should handle the majority of my use cases.

-- 
Jason

On Thu, Sep 11, 2014, at 03:55 PM, Felix Meschberger wrote:
> Hi Jason,
> 
> That’s true and mentioned, albeit a bit short on words if you will at
> [1]:
> 
> Returns true if the resource type or any of the resource's super type(s)
> equals the given resource type.
> 
> So basically, Sling deals with Resource objects which have a Resource
> Type which form a hierarchy much like the Java class hierarchy. The
> implicit root resource type is called „sling/servlet/default“ (not the
> best of all names, I agree, but this is historical :-) ). The
> Resource.isResourceType(String) and ResourceUtil.isA(Resource, String)
> methods basically mimick the Java instanceof operator.
> 
> And yes, this might better described on [2] (should show up shortly)
> 
> Hope this helps.
> 
> Regards
> Felix
> 
> [1]
> http://sling.apache.org/apidocs/sling6/org/apache/sling/api/resource/Resource.html#isResourceType(java.lang.String)
> [2] http://sling.apache.org/documentation/the-sling-engine/resources.html
> 
> Am 11.09.2014 um 15:54 schrieb Jason E Bailey
> mailto:jason.bai...@24601.org>>:
> 
> I understand the difference between the Sling Resource Type and the JCR
> Node type. However the resource.isResourceType is not specifically
> dealing with one or the other. If I had a resource of a node with a
> primaryNodeType of nt:file then doing resource.isResourceType("nt:file")
> would return true.
> 
> I had to dig through the code to see what was going on.
> 
> The basic idea is that calling resource.getResourceType() will return
> the sling:resourceType and if that's not there then it will return the
> jcr:primaryType. When calling "isResourceType" it will compare against
> the resource.getResourceType() and if that's not a match will march of
> the chain of getSuperResourceType looking for a match, and that matches
> only against the sling:resourceType.
> 
> I can sorta see where that's useful from a script resolution point of
> view. I find it odd overall as it's missing out on a section of
> inheritance. It's like having a java instanceof operator ignoring
> interfaces.
> 
> --
>  Jason
> 
> On Wed, Sep 10, 2014, at 01:13 PM, Paul McMahon wrote:
> There isn't necessarily a mapping between Sling Resource Type and the JCR
> Node type. The sling resource type is determined based on the value or
> the sling:resourceType property on the node, where as the JCR Node type
> is determined based on jcr:primaryType value. In most cases nodes of
> sling:resourceType will always be the same jcr:primaryType, but technical
> that isn't a requirement. In  reality there are most jcr:primaryTypes map
> to many different sling:resourceType (or no sling resource type).
> 
> 
> Paul McMahon
> Acquity Group, Part of Accenture Interactive
> 
> 
> On Wednesday, September 10, 2014 9:56 AM, Jason E Bailey
> mailto:jason.bai...@24601.org>> wrote:
> 
> 
> 
> Lets say I have a node of type sling:Folder.
> 
> 
> 
> Calling
> 
> node.isNodeType("nt:folder")
> 
> will return true, since sling:Folder extends nt:folder
> 
> 
> 
> However
> 
> resource.isResourceType("nt:folder")
> 
> will return false. I'm assuming since it's attempting to
> resolve up the resource heirarchy(?)
> 
> 
> 
> My question, is there a Foo utility to determine if a given
> resource is of a particular type via the node definition?
> 
> 
> 
> TIA.
> 
> --
> Jason E Bailey
> 

Re: Differences between type responses for node and resource

[Jason E Bailey]

Alexander,

I have a hard time understanding how there would be added complexity by
incorporating the nodeType hierarchy into a determination as to whether
a specific resource "is" of a specific type. Multiple hierarchies are
fairly common in programming languages, like the instanceof I mentioned
that does both the class hierarchy and the interface hierarchy.  I also
don't see much confusion occurring from implementing this. If I am
attempting to validate a whether something is inherited from nt:base I
clearly have a need in mind that would be separate from desire to know
if it's a sling component that inherits from "foundation/list"

I would like to use resources as much as possible :) The flexibility
however ends when I need to validate an associated nodeType,

-- 
Jason

On Thu, Sep 11, 2014, at 03:09 PM, Alexander Klimetschek wrote:
> Sling resource types have their own super type hierarchy. Using jcr node
> types if no sling:resourceType is specified was added as a fallback for
> cases where it is impractical to set a sling:resourceType. But it does
> not take into account the node type hierarchy, I think because it would
> simply be too complex, since you then have to look at two hierarchies.
> 
> I would use sling resource types as much as possible over node types,
> since they are a lot more flexible.
> 
> HTH,
> Alex
> 
> On 11.09.2014, at 14:54, Jason E Bailey  wrote:
> 
> > I understand the difference between the Sling Resource Type and the JCR
> > Node type. However the resource.isResourceType is not specifically
> > dealing with one or the other. If I had a resource of a node with a
> > primaryNodeType of nt:file then doing resource.isResourceType("nt:file")
> > would return true. 
> > 
> > I had to dig through the code to see what was going on. 
> > 
> > The basic idea is that calling resource.getResourceType() will return
> > the sling:resourceType and if that's not there then it will return the
> > jcr:primaryType. When calling "isResourceType" it will compare against
> > the resource.getResourceType() and if that's not a match will march of
> > the chain of getSuperResourceType looking for a match, and that matches
> > only against the sling:resourceType.
> > 
> > I can sorta see where that's useful from a script resolution point of
> > view. I find it odd overall as it's missing out on a section of
> > inheritance. It's like having a java instanceof operator ignoring
> > interfaces. 
> > 
> > -- 
> >  Jason
> > 
> > On Wed, Sep 10, 2014, at 01:13 PM, Paul McMahon wrote:
> >> There isn't necessarily a mapping between Sling Resource Type and the JCR
> >> Node type. The sling resource type is determined based on the value or
> >> the sling:resourceType property on the node, where as the JCR Node type
> >> is determined based on jcr:primaryType value. In most cases nodes of
> >> sling:resourceType will always be the same jcr:primaryType, but technical
> >> that isn't a requirement. In  reality there are most jcr:primaryTypes map
> >> to many different sling:resourceType (or no sling resource type). 
> >> 
> >> 
> >> Paul McMahon
> >> Acquity Group, Part of Accenture Interactive
> >> 
> >> 
> >> On Wednesday, September 10, 2014 9:56 AM, Jason E Bailey
> >>  wrote:
> >> 
> >> 
> >> 
> >> Lets say I have a node of type sling:Folder.
> >> 
> >> 
> >> 
> >> Calling
> >> 
> >> node.isNodeType("nt:folder")
> >> 
> >> will return true, since sling:Folder extends nt:folder
> >> 
> >> 
> >> 
> >> However
> >> 
> >> resource.isResourceType("nt:folder")
> >> 
> >> will return false. I'm assuming since it's attempting to
> >> resolve up the resource heirarchy(?)
> >> 
> >> 
> >> 
> >> My question, is there a Foo utility to determine if a given
> >> resource is of a particular type via the node definition?
> >> 
> >> 
> >> 
> >> TIA.
> >> 
> >> --
> >> Jason E Bailey
>