[jira] Updated: (SLING-651) Extending the SlingPostServlet with SlingPostOperations
[ https://issues.apache.org/jira/browse/SLING-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Norman updated SLING-651: -- Attachment: FixedSlingPostServlet.diff Updated the patch to fix the problems with the bundle startup order. > Extending the SlingPostServlet with SlingPostOperations > --- > > Key: SLING-651 > URL: https://issues.apache.org/jira/browse/SLING-651 > Project: Sling > Issue Type: Bug > Components: Servlets Post >Affects Versions: Servlets Post 2.0.2 >Reporter: Bertil Chapuis >Priority: Minor > Attachments: FixedSlingPostServlet.diff, samples.diff, samples.diff, > SlingPostServlet.diff > > > As described in the documentation > (http://incubator.apache.org/sling/site/manipulating-content-the-slingpostservlet.html), > it should be possible to extend the SlingPostServlet with > SlingPostOperations. However, in the SlingPostServlet, no methods allow to > bind new operations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling Parent POM
Works for me. > mvn --version Maven version: 2.0.9 Java version: 1.5.0_16 OS name: "mac os x" version: "10.5.6" arch: "i386" Family: "unix" Jim John Langley wrote: Works on linux (ubuntu feisty), jdk 1.6.0_05. I did a clean checkout and full build. -- Langley On Tue, 2009-02-24 at 03:58 -0500, Juan José Vázquez Delgado wrote: As of Rev. 7471333, the Apache SNAPSHOT repository is now declared in the parent pom. My test builds seem to work. It would be great if others could also test (and review the pom), so that we can then release the parent pom. Works for me (Windows Vista SP1 JDK 1.5.0_14-b03) BR, Juanjo.
Re: Sling Parent POM
Works on linux (ubuntu feisty), jdk 1.6.0_05. I did a clean checkout and full build. -- Langley On Tue, 2009-02-24 at 03:58 -0500, Juan José Vázquez Delgado wrote: > > As of Rev. 7471333, the Apache SNAPSHOT repository is now declared in > > the parent pom. My test builds seem to work. It would be great if others > > could also test (and review the pom), so that we can then release the > > parent pom. > > Works for me (Windows Vista SP1 JDK 1.5.0_14-b03) > > BR, > > Juanjo.
Re: StarResource.adaptTo(Node.class)
Hi, 2009/2/24 Felix Meschberger : > ...SLING-344 [1] added the StarResource [2] to support requests to > explicitly unknown resources like /* or /*.html. One feature of this > class is, that it adapts to a "FakeNode" Yes, the use case for that is when building a simple CRUD application. Requesting the StarResource and adapting that to a Node provides you with empty values for all the node's properties, so if using the sling.wizard() from sling.js you have no code to write for the Create action - it is handled just like the Update action, but works on the "magic" star resource. The only difference between Create and Update in this case, is that for Create you retrieve the * resource (which initializes all your fields to empty values), whereas for Update you retrieve the actual resource that was created before. See my "blog in 46 lines" example at http://dev.day.com/microsling/content/blogs/main/sling-46-lines-blog.html for an actual mini-app that uses this feature. > ...having a > synthetic resource not backed by a JCR item return a non-null result for > adaptTo(Node.class) is kind of strange. > > For this reason, I suggest remove the Node adapter functionality of the > StarResource, such that > > StarResource.adaptTo(Node.class) == null... Although I see the idea, that would break the above use case. I'm open to suggestions for providing that functionality in another way, but don't have much time to look at it myself at the moment. -Bertrand
[jira] Closed: (SLING-872) Use header entry format to define path mappings
[ https://issues.apache.org/jira/browse/SLING-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-872. -- Resolution: Fixed Assignee: Carsten Ziegeler Fixed in revision 747467 by parsing the header value with the OSGi manifest parser and handling the path directive. If no directive is found, the old behaviour is used. > Use header entry format to define path mappings > --- > > Key: SLING-872 > URL: https://issues.apache.org/jira/browse/SLING-872 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: Extensions Bundleresource 2.0.2 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Extensions Bundleresource 2.1.0 > > > It would be nice to define mappings for the bundle resource provider through > the usual header syntax, like: > > /META-INF/resources/apps/myscripts;path:=/apps/myscripts > > This allows to store the resources "somewhere" in the bundle and create the > correct mapping by specifying the path directive. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: glassfishv3-prelude & sling incubator-4
Hi John, John Langley schrieb: > Thanks Felix, I haven't tried it yet, but that sounds great! > I hope to experiment with it later in the week. Thanks again! You are welcome. Regards Felix > > -- Langley > > On Sun, 2009-02-22 at 13:38 -0500, Felix Meschberger wrote: > >> Hi John, >> >> Yet another reply ;-) >> >> In Rev. 746794 I have added a LauncherClassLoader which helps using >> Sling inside Glassfish (at least in my simple setup here). >> >> Regards >> Felix >> >> John Langley schrieb: >>> Just FYI... >>> >>> I tried loading the launchpad webapp into glassfishv3-prelude this >>> afternoon and it threw exception stack included below. >>> My guess is that this is related to there being different versions of >>> the org.apache.felix.framework.Felix because glassfishv3-prelude also >>> uses felix. Perhaps there's a work around by specifying a different >>> import version in a sling manifest? >>> >>> I haven't tried to dig around, but osgi ~should~ allow us to have >>> multiple versions, but being a relative newbie I realize this may be on >>> the hairy edge of 'system bundle' space, which could be a limitation >>> that's hard to work around. >>> >>> At any rate, I thought I'd let people know. >>> >>> -- Langley >>> >>> >>> >>> >>> >>> Feb 20, 2009 4:27:56 PM org.apache.catalina.core.ApplicationContext log >>> SEVERE: >>> WebModule[/org.apache.sling.launchpad.webapp-4-incubator-SNAPSHOT]sling: >>> Failed to start Sling in >>> sling/_org.apache.sling.launchpad.webapp-4-incubator-SNAPSHOT >>> java.lang.NoSuchMethodError: >>> org.apache.felix.framework.Felix.(Ljava/util/Map;)V >>> at >>> org.apache.sling.launchpad.base.impl.SlingFelix.(SlingFelix.java:39) >>> at >>> org.apache.sling.launchpad.base.impl.Sling.(Sling.java:234) >>> at >>> org.apache.sling.launchpad.base.webapp.SlingBridge.(SlingBridge.java:42) >>> at >>> org.apache.sling.launchpad.base.webapp.SlingServletDelegate.init(SlingServletDelegate.java:202) >>> at javax.servlet.GenericServlet.init(GenericServlet.java:270) >>> at >>> org.apache.sling.launchpad.webapp.SlingServlet.startSling(SlingServlet.java:317) >>> at >>> org.apache.sling.launchpad.webapp.SlingServlet.startSling(SlingServlet.java:254) >>> at >>> org.apache.sling.launchpad.webapp.SlingServlet.init(SlingServlet.java:90) >>> at javax.servlet.GenericServlet.init(GenericServlet.java:270) >>> at >>> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1198) >>> at >>> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1038) >>> at >>> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4953) >>> at >>> org.apache.catalina.core.StandardContext.start(StandardContext.java:5350) >>> at com.sun.enterprise.web.WebModule.start(WebModule.java:456) >>> at >>> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:922) >>> at >>> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:906) >>> at >>> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:696) >>> at >>> com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2205) >>> at >>> com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1890) >>> at >>> com.sun.enterprise.web.WebApplication.start(WebApplication.java:85) >>> at >>> com.sun.enterprise.v3.server.ApplicationLifecycle.start(ApplicationLifecycle.java:560) >>> at >>> com.sun.enterprise.v3.server.ApplicationLifecycle.start(ApplicationLifecycle.java:547) >>> at >>> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:189) >>> at >>> com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:260) >>> at >>> com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:97) >>> at >>> com.sun.enterprise.v3.server.ApplicationLoaderInjector.postConstruct(ApplicationLoaderInjector.java:61) >>> at >>> com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:150) >>> at com.sun.hk2.component.ConstructorWomb >>> $1.run(ConstructorWomb.java:90) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at >>> com.sun.hk2.component.ConstructorWomb.initialize(ConstructorWomb.java:87) >>> at >>> com.sun.hk2.component.AbstractWombImpl.get(AbstractWombImpl.java:75) >>> at >>> com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:58) >>> at >>> com.sun.hk2.component.LazyInhabitant.get(LazyInhabitant.java:107) >>> at >>> com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:60) >>> at >>> com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:203) >>> at com.sun.enterprise.v3.server.AppServerS
Re: glassfishv3-prelude & sling incubator-4
Thanks Felix, I haven't tried it yet, but that sounds great! I hope to experiment with it later in the week. Thanks again! -- Langley On Sun, 2009-02-22 at 13:38 -0500, Felix Meschberger wrote: > Hi John, > > Yet another reply ;-) > > In Rev. 746794 I have added a LauncherClassLoader which helps using > Sling inside Glassfish (at least in my simple setup here). > > Regards > Felix > > John Langley schrieb: > > Just FYI... > > > > I tried loading the launchpad webapp into glassfishv3-prelude this > > afternoon and it threw exception stack included below. > > My guess is that this is related to there being different versions of > > the org.apache.felix.framework.Felix because glassfishv3-prelude also > > uses felix. Perhaps there's a work around by specifying a different > > import version in a sling manifest? > > > > I haven't tried to dig around, but osgi ~should~ allow us to have > > multiple versions, but being a relative newbie I realize this may be on > > the hairy edge of 'system bundle' space, which could be a limitation > > that's hard to work around. > > > > At any rate, I thought I'd let people know. > > > > -- Langley > > > > > > > > > > > > Feb 20, 2009 4:27:56 PM org.apache.catalina.core.ApplicationContext log > > SEVERE: > > WebModule[/org.apache.sling.launchpad.webapp-4-incubator-SNAPSHOT]sling: > > Failed to start Sling in > > sling/_org.apache.sling.launchpad.webapp-4-incubator-SNAPSHOT > > java.lang.NoSuchMethodError: > > org.apache.felix.framework.Felix.(Ljava/util/Map;)V > > at > > org.apache.sling.launchpad.base.impl.SlingFelix.(SlingFelix.java:39) > > at > > org.apache.sling.launchpad.base.impl.Sling.(Sling.java:234) > > at > > org.apache.sling.launchpad.base.webapp.SlingBridge.(SlingBridge.java:42) > > at > > org.apache.sling.launchpad.base.webapp.SlingServletDelegate.init(SlingServletDelegate.java:202) > > at javax.servlet.GenericServlet.init(GenericServlet.java:270) > > at > > org.apache.sling.launchpad.webapp.SlingServlet.startSling(SlingServlet.java:317) > > at > > org.apache.sling.launchpad.webapp.SlingServlet.startSling(SlingServlet.java:254) > > at > > org.apache.sling.launchpad.webapp.SlingServlet.init(SlingServlet.java:90) > > at javax.servlet.GenericServlet.init(GenericServlet.java:270) > > at > > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1198) > > at > > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1038) > > at > > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4953) > > at > > org.apache.catalina.core.StandardContext.start(StandardContext.java:5350) > > at com.sun.enterprise.web.WebModule.start(WebModule.java:456) > > at > > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:922) > > at > > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:906) > > at > > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:696) > > at > > com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2205) > > at > > com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1890) > > at > > com.sun.enterprise.web.WebApplication.start(WebApplication.java:85) > > at > > com.sun.enterprise.v3.server.ApplicationLifecycle.start(ApplicationLifecycle.java:560) > > at > > com.sun.enterprise.v3.server.ApplicationLifecycle.start(ApplicationLifecycle.java:547) > > at > > com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:189) > > at > > com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:260) > > at > > com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:97) > > at > > com.sun.enterprise.v3.server.ApplicationLoaderInjector.postConstruct(ApplicationLoaderInjector.java:61) > > at > > com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:150) > > at com.sun.hk2.component.ConstructorWomb > > $1.run(ConstructorWomb.java:90) > > at java.security.AccessController.doPrivileged(Native Method) > > at > > com.sun.hk2.component.ConstructorWomb.initialize(ConstructorWomb.java:87) > > at > > com.sun.hk2.component.AbstractWombImpl.get(AbstractWombImpl.java:75) > > at > > com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:58) > > at > > com.sun.hk2.component.LazyInhabitant.get(LazyInhabitant.java:107) > > at > > com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:60) > > at > > com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:203) > > at com.sun.enterprise.v3.server.AppServerStartup > > $1.run(AppServerStartup.java:116) > > > >
[jira] Commented: (SLING-857) Support XSL transformations when importing XML for initial-content
[ https://issues.apache.org/jira/browse/SLING-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676298#action_12676298 ] Torgeir Veimo commented on SLING-857: - It would be handy to be able to specify a custom entity resolver as well. Any chance to get that incorporated? > Support XSL transformations when importing XML for initial-content > -- > > Key: SLING-857 > URL: https://issues.apache.org/jira/browse/SLING-857 > Project: Sling > Issue Type: New Feature > Components: JCR Contentloader >Reporter: Vidar S. Ramdal >Assignee: Felix Meschberger >Priority: Minor > Fix For: JCR Contentloader 2.0.4 > > Attachments: SLING-857.diff > > > As described at http://markmail.org/thread/qxi6qw77vgymrdim > Implementing support for XSL transformations while loading initial-content > XML, by looking for the xml-stylesheet processing instruction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-857) Support XSL transformations when importing XML for initial-content
[ https://issues.apache.org/jira/browse/SLING-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vidar S. Ramdal updated SLING-857: -- Attachment: SLING-857.diff The first patch contained a bug, which would skip some attributes in processing instructions. Please apply this patch instead. > Support XSL transformations when importing XML for initial-content > -- > > Key: SLING-857 > URL: https://issues.apache.org/jira/browse/SLING-857 > Project: Sling > Issue Type: New Feature > Components: JCR Contentloader >Reporter: Vidar S. Ramdal >Assignee: Felix Meschberger >Priority: Minor > Fix For: JCR Contentloader 2.0.4 > > Attachments: SLING-857.diff > > > As described at http://markmail.org/thread/qxi6qw77vgymrdim > Implementing support for XSL transformations while loading initial-content > XML, by looking for the xml-stylesheet processing instruction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-857) Support XSL transformations when importing XML for initial-content
[ https://issues.apache.org/jira/browse/SLING-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vidar S. Ramdal updated SLING-857: -- Attachment: (was: SLING-857.diff) > Support XSL transformations when importing XML for initial-content > -- > > Key: SLING-857 > URL: https://issues.apache.org/jira/browse/SLING-857 > Project: Sling > Issue Type: New Feature > Components: JCR Contentloader >Reporter: Vidar S. Ramdal >Assignee: Felix Meschberger >Priority: Minor > Fix For: JCR Contentloader 2.0.4 > > Attachments: SLING-857.diff > > > As described at http://markmail.org/thread/qxi6qw77vgymrdim > Implementing support for XSL transformations while loading initial-content > XML, by looking for the xml-stylesheet processing instruction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: StarResource.adaptTo(Node.class)
On Tue, Feb 24, 2009 at 2:38 PM, Felix Meschberger wrote: > Bertrand Delacretaz schrieb: >> ...Although I agree with the intention, I think the "edit the magic star >> to create content" use case is a valid one, and we need to provide an >> alternative before breaking it > ...In fact, looking at the sling.js script, the wizard() method calls > getContent() inderectly, which places a JSON request, which is handled > by the default GET servlet for JSON. Since this servlet is completely > prepared to not get a Node, it makes no difference Great - if that works I have no problem with your suggestion. I'm back from a business trip + holiday and swamped with stuff, so won't have time to check that right now. -Bertrand
Re: StarResource.adaptTo(Node.class)
Hi, Bertrand Delacretaz schrieb: > (ignore second copy if this comes doubled...offline Gmail + 2 > computers + Gmail was down) Only got one.. > > Hi, > > 2009/2/24 Felix Meschberger : >> ...SLING-344 [1] added the StarResource [2] to support requests to >> explicitly unknown resources like /* or /*.html. One feature of this >> class is, that it adapts to a "FakeNode" > > Yes, the use case for that is when building a simple CRUD application. > > Requesting the StarResource and adapting that to a Node provides you > with empty values for all the node's properties, so if using the > sling.wizard() from sling.js you have no code to write for the Create > action. > > The only difference between Create and Update in this case, is that > for Create you retrieve the * resource, whereas for Update you > retrieve the actual resource that was created before. > > See my "blog in 46 lines" example at > http://dev.day.com/microsling/content/blogs/main/sling-46-lines-blog.html > for an actual mini-app that uses this feature. > >> ...having a >> synthetic resource not backed by a JCR item return a non-null result for >> adaptTo(Node.class) is kind of strange. >> >> For this reason, I suggest remove the Node adapter functionality of the >> StarResource, such that >> >>StarResource.adaptTo(Node.class) == null... > > That would break the above use case. > > Although I agree with the intention, I think the "edit the magic star > to create content" use case is a valid one, and we need to provide an > alternative before breaking it. The point is, that a resource is not required to adapt to a Node. For example resources loaded from the file system or from bundles are not backed by nodes and will always return null on adaptTo(Node.class). Hence every application must be prepared to get null in this case and therefore the sling.wizard() must also be prepared to not get anything. In fact, looking at the sling.js script, the wizard() method calls getContent() inderectly, which places a JSON request, which is handled by the default GET servlet for JSON. Since this servlet is completely prepared to not get a Node, it makes no difference. Regards Felix
[jira] Created: (SLING-872) Use header entry format to define path mappings
Use header entry format to define path mappings --- Key: SLING-872 URL: https://issues.apache.org/jira/browse/SLING-872 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Extensions Bundleresource 2.0.2 Reporter: Carsten Ziegeler Fix For: Extensions Bundleresource 2.1.0 It would be nice to define mappings for the bundle resource provider through the usual header syntax, like: /META-INF/resources/apps/myscripts;path:=/apps/myscripts This allows to store the resources "somewhere" in the bundle and create the correct mapping by specifying the path directive. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: StarResource.adaptTo(Node.class)
(ignore second copy if this comes doubled...offline Gmail + 2 computers + Gmail was down) Hi, 2009/2/24 Felix Meschberger : > ...SLING-344 [1] added the StarResource [2] to support requests to > explicitly unknown resources like /* or /*.html. One feature of this > class is, that it adapts to a "FakeNode" Yes, the use case for that is when building a simple CRUD application. Requesting the StarResource and adapting that to a Node provides you with empty values for all the node's properties, so if using the sling.wizard() from sling.js you have no code to write for the Create action. The only difference between Create and Update in this case, is that for Create you retrieve the * resource, whereas for Update you retrieve the actual resource that was created before. See my "blog in 46 lines" example at http://dev.day.com/microsling/content/blogs/main/sling-46-lines-blog.html for an actual mini-app that uses this feature. > ...having a > synthetic resource not backed by a JCR item return a non-null result for > adaptTo(Node.class) is kind of strange. > > For this reason, I suggest remove the Node adapter functionality of the > StarResource, such that > > StarResource.adaptTo(Node.class) == null... That would break the above use case. Although I agree with the intention, I think the "edit the magic star to create content" use case is a valid one, and we need to provide an alternative before breaking it. -Bertrand
Re: StarResource.adaptTo(Node.class)
Sounds reasonable. +1 Juanjo
[jira] Resolved: (SLING-871) Add new method to AccessControlUtil to determine if an AccessControlEntry contains granted privileges or denied privileges
[ https://issues.apache.org/jira/browse/SLING-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Jose Vazquez Delgado resolved SLING-871. - Resolution: Fixed Assignee: Juan Jose Vazquez Delgado Patch applied in revision 747309. Thanks to Eric Norman for the contribution. > Add new method to AccessControlUtil to determine if an AccessControlEntry > contains granted privileges or denied privileges > -- > > Key: SLING-871 > URL: https://issues.apache.org/jira/browse/SLING-871 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Eric Norman >Assignee: Juan Jose Vazquez Delgado >Priority: Minor > Attachments: AccessControlUtil_isAllow.diff > > > The AccessControlUtil.addEntry(..) methods enable creating an > AccessControlEntry for denied privileges, but there is no easy way to lookup > that information at a later time. > My proposal is to add a new 'isAllow' method to the AccessControlUtil class > to enable looking up the 'isAllow' flag for an AccessControlEntry. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: StarResource.adaptTo(Node.class)
Felix Meschberger wrote: > Hi all, > > SLING-344 [1] added the StarResource [2] to support requests to > explicitly unknown resources like /* or /*.html. One feature of this > class is, that it adapts to a "FakeNode". > > Given that in the meantime we are firm on the resource tree, which > resolves resource, which need not be backed by JCR items, having a > synthetic resource not backed by a JCR item return a non-null result for > adaptTo(Node.class) is kind of strange. > > For this reason, I suggest remove the Node adapter functionality of the > StarResource, such that > > StarResource.adaptTo(Node.class) == null > Urgs, that's really strange; yes we should change it: +1 Carsten -- Carsten Ziegeler cziege...@apache.org
StarResource.adaptTo(Node.class)
Hi all, SLING-344 [1] added the StarResource [2] to support requests to explicitly unknown resources like /* or /*.html. One feature of this class is, that it adapts to a "FakeNode". Given that in the meantime we are firm on the resource tree, which resolves resource, which need not be backed by JCR items, having a synthetic resource not backed by a JCR item return a non-null result for adaptTo(Node.class) is kind of strange. For this reason, I suggest remove the Node adapter functionality of the StarResource, such that StarResource.adaptTo(Node.class) == null WDYT ? Regards Felix PS: The StarResource also uses the FakeNode to apply the PathBaseResourceType resolution. This would still be kept. [1] https://issues.apache.org/jira/browse/SLING-344 [2] http://svn.apache.org/repos/asf/incubator/sling/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/starresource/StarResource.java
Re: Sling Parent POM
> As of Rev. 7471333, the Apache SNAPSHOT repository is now declared in > the parent pom. My test builds seem to work. It would be great if others > could also test (and review the pom), so that we can then release the > parent pom. Works for me (Windows Vista SP1 JDK 1.5.0_14-b03) BR, Juanjo.
