[jira] Updated: (SLING-653) adding a validator plugin for .json files that could be found

2008-09-10 Thread Thierry Yge (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thierry Yge updated SLING-653:
--

Attachment: (was: BundleValidateJSONFilesMojo.java)

> adding a validator plugin for .json files that could be found
> -
>
> Key: SLING-653
> URL: https://issues.apache.org/jira/browse/SLING-653
> Project: Sling
>  Issue Type: New Feature
>  Components: Maven Plugins
>Affects Versions: Maven Sling Plugin 2.0.2
>Reporter: Thierry Yge
>Priority: Minor
> Attachments: BundleValidateJSONFilesMojo.java
>
>
> It could be nice to have the sling maven plugin that build the bundle to 
> validate the .json files that are found, thus it avoid to find the error 
> during the
> deployment of the bundle
> simple error message that would tell in which file and where the problem 
> occur would help.
> It could use the json library like "JSONObject.fromObject()" to parse the 
> .json files and catch the JSONException when it find an error.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (SLING-653) adding a validator plugin for .json files that could be found

2008-09-10 Thread Thierry Yge (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thierry Yge updated SLING-653:
--

Attachment: BundleValidateJSONFilesMojo.java

> adding a validator plugin for .json files that could be found
> -
>
> Key: SLING-653
> URL: https://issues.apache.org/jira/browse/SLING-653
> Project: Sling
>  Issue Type: New Feature
>  Components: Maven Plugins
>Affects Versions: Maven Sling Plugin 2.0.2
>Reporter: Thierry Yge
>Priority: Minor
> Attachments: BundleValidateJSONFilesMojo.java
>
>
> It could be nice to have the sling maven plugin that build the bundle to 
> validate the .json files that are found, thus it avoid to find the error 
> during the
> deployment of the bundle
> simple error message that would tell in which file and where the problem 
> occur would help.
> It could use the json library like "JSONObject.fromObject()" to parse the 
> .json files and catch the JSONException when it find an error.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (SLING-653) adding a validator plugin for .json files that could be found

2008-09-10 Thread Thierry Yge (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thierry Yge updated SLING-653:
--

Attachment: (was: JSONValidator.java)

> adding a validator plugin for .json files that could be found
> -
>
> Key: SLING-653
> URL: https://issues.apache.org/jira/browse/SLING-653
> Project: Sling
>  Issue Type: New Feature
>  Components: Maven Plugins
>Affects Versions: Maven Sling Plugin 2.0.2
>Reporter: Thierry Yge
>Priority: Minor
> Attachments: BundleValidateJSONFilesMojo.java
>
>
> It could be nice to have the sling maven plugin that build the bundle to 
> validate the .json files that are found, thus it avoid to find the error 
> during the
> deployment of the bundle
> simple error message that would tell in which file and where the problem 
> occur would help.
> It could use the json library like "JSONObject.fromObject()" to parse the 
> .json files and catch the JSONException when it find an error.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (SLING-653) adding a validator plugin for .json files that could be found

2008-09-10 Thread Thierry Yge (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629847#action_12629847
 ] 

Thierry Yge commented on SLING-653:
---

I dont have a commiter account , but here is the attached java code for the 
maven-sling-plugin
first have to add 


org.apache.sling
org.apache.sling.commons.json
2.0.3-incubator-SNAPSHOT


Then use the attached file BundleValidateJSONFilesMojo.java  in the package 
org.apache.sling.maven.bundlesupport

Thanks.

> adding a validator plugin for .json files that could be found
> -
>
> Key: SLING-653
> URL: https://issues.apache.org/jira/browse/SLING-653
> Project: Sling
>  Issue Type: New Feature
>  Components: Maven Plugins
>Affects Versions: Maven Sling Plugin 2.0.2
>Reporter: Thierry Yge
>Priority: Minor
> Attachments: BundleValidateJSONFilesMojo.java, JSONValidator.java
>
>
> It could be nice to have the sling maven plugin that build the bundle to 
> validate the .json files that are found, thus it avoid to find the error 
> during the
> deployment of the bundle
> simple error message that would tell in which file and where the problem 
> occur would help.
> It could use the json library like "JSONObject.fromObject()" to parse the 
> .json files and catch the JSONException when it find an error.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (SLING-653) adding a validator plugin for .json files that could be found

2008-09-10 Thread Thierry Yge (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thierry Yge updated SLING-653:
--

Attachment: BundleValidateJSONFilesMojo.java

the class rewritten for maven sling plugin

> adding a validator plugin for .json files that could be found
> -
>
> Key: SLING-653
> URL: https://issues.apache.org/jira/browse/SLING-653
> Project: Sling
>  Issue Type: New Feature
>  Components: Maven Plugins
>Affects Versions: Maven Sling Plugin 2.0.2
>Reporter: Thierry Yge
>Priority: Minor
> Attachments: BundleValidateJSONFilesMojo.java, JSONValidator.java
>
>
> It could be nice to have the sling maven plugin that build the bundle to 
> validate the .json files that are found, thus it avoid to find the error 
> during the
> deployment of the bundle
> simple error message that would tell in which file and where the problem 
> occur would help.
> It could use the json library like "JSONObject.fromObject()" to parse the 
> .json files and catch the JSONException when it find an error.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (SLING-646) jcrinstall - take two

2008-09-10 Thread Bertrand Delacretaz (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629840#action_12629840
 ] 

Bertrand Delacretaz commented on SLING-646:
---

Revision 693873 contains a usable version, refactored in distinct and 
independent OSGi and JCR modules.

The "sling.jcrinstall.folder.name.regexp", if set, defines the regexp used to 
filter folder names (for example .*/install(\.custom)?$ causes both folders 
named "install" and "install.custom" to be used).

Missing:
-Deployment package support, need a class similar to the ConfigResourceProcessor
-Tests for the ConfigResourceProcessor

> jcrinstall - take two
> -
>
> Key: SLING-646
> URL: https://issues.apache.org/jira/browse/SLING-646
> Project: Sling
>  Issue Type: New Feature
>  Components: OSGi
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>
> Based on the jcrinstall [1] and jcrbundles [2][SLiNG-587] experiments, and 
> after playing a bit with these modules and talking to (our) Felix, I'll start 
> re-implementing the jcrinstall module under sling/extensions/jcrinstall, 
> based on a mix of both codebases (jcrbundles was based on the existing 
> jcrinstall anyway, so it's a mix already).
> Here's a quick specification.
> The jcrinstall module looks for OSGi resources (bundles in jar files, 
> configurations in text (.cfg) files, deployment packages in .dp files) under 
> a configurable set of paths in the repository.
> Those resources are "installed" in the OSGi framework when detected: bundles, 
> deployment packages and configurations are installed, updated or removed as 
> needed.
> The jcrinstall module is considered as another "user interface" to the OSGi 
> framework, besides the existing OSGi console, and as such aims to play well 
> with the console, and avoid any inconsistencies when both user interfaces are 
> used. That's only a best effort, though, as we'll probably find edge cases 
> when using both can cause problems.
> The module is split in two components:
> = OSGi controller component =
> Receives notifications of new, updated or deleted OSGi resources from the JCR 
> observation component.
> Does not use any JCR interfaces, so as to be reusable independently.
> Manages the required queues and retries to ensure that received bundles, 
> configurations and deployment packages are eventually activated, even if 
> their dependencies are made available later.
> Provides permanent storage (based on BundleContext.getDataFile()) for the JCR 
> component to store Properties for the resources that it detects.
> Uses handlers based on a common interface for the various types of resources 
> (bundles, configs, deployment packages).
> = JCR observation component =
> Observes a number of folders in the JCR repository, based on configurable 
> regular expressions for their paths. The default regexp causes folders named 
> "install" to be observed.
> Limited to a configurable list of root paths, by default /libs and /apps.
> Detects added or modified files in those folders and notifies the OSGi 
> controller of these events, providing the file's InputStream with the event, 
> along with an event type.
> Uses the permanent storage provided by the OSGi controller to store 
> information that allows for detecting updates and deletes of OSGi resources.
> = coda =
> Splitting the module in two well-separated components should also help 
> automated testing - as described above, both components should be readily 
> testable without requiring complicated setups.
> [1] http://svn.apache.org/repos/asf/incubator/sling/whiteboard/jcrinstall/
> [2] http://svn.apache.org/repos/asf/incubator/sling/whiteboard/jcrbundles/

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (SLING-393) default renderer for .xml

2008-09-10 Thread Carsten Ziegeler (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated SLING-393:
---

Affects Version/s: Servlets Get 2.0.2
Fix Version/s: Servlets Get 2.0.4

> default renderer for .xml
> -
>
> Key: SLING-393
> URL: https://issues.apache.org/jira/browse/SLING-393
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets Get
>Affects Versions: Servlets Get 2.0.2
>Reporter: Michael Marth
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: Servlets Get 2.0.4
>
>
> I would like to suggest a default renderer for .xml requests, similar to the 
> .json renderer that exists already. This would allow zero-config remote 
> access for clients that do not understand json, e.g. desktop apps.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (SLING-393) default renderer for .xml

2008-09-10 Thread Carsten Ziegeler (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629814#action_12629814
 ] 

Carsten Ziegeler commented on SLING-393:


I've implemented a first version which does not support depth (if we need it, 
we can add it later on anyway)
As I don't think that round-tripping is that important and as the docview is 
easier for later processing, I go with docview as default.

> default renderer for .xml
> -
>
> Key: SLING-393
> URL: https://issues.apache.org/jira/browse/SLING-393
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets Get
>Reporter: Michael Marth
>Assignee: Carsten Ziegeler
>Priority: Minor
>
> I would like to suggest a default renderer for .xml requests, similar to the 
> .json renderer that exists already. This would allow zero-config remote 
> access for clients that do not understand json, e.g. desktop apps.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (SLING-393) default renderer for .xml

2008-09-10 Thread Carsten Ziegeler (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler reassigned SLING-393:
--

Assignee: Carsten Ziegeler

> default renderer for .xml
> -
>
> Key: SLING-393
> URL: https://issues.apache.org/jira/browse/SLING-393
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets Get
>Reporter: Michael Marth
>Assignee: Carsten Ziegeler
>Priority: Minor
>
> I would like to suggest a default renderer for .xml requests, similar to the 
> .json renderer that exists already. This would allow zero-config remote 
> access for clients that do not understand json, e.g. desktop apps.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (SLING-528) ServletException on request for synthtic resource

2008-09-10 Thread Carsten Ziegeler (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler closed SLING-528.
--

   Resolution: Won't Fix
Fix Version/s: Servlets Get 2.0.4

I'll close this as the behaviour in the get servlets has changed. If there is 
still an issue please open a new bug.

> ServletException on request for synthtic resource
> -
>
> Key: SLING-528
> URL: https://issues.apache.org/jira/browse/SLING-528
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets Get
>Reporter: christian
>Assignee: Felix Meschberger
> Fix For: Servlets Get 2.0.4
>
>
> Have a Resource at path "/synthetic" 
> Requesting this resource SlingDefaultGetServlet throws an ServletException 
> with the message
> "path=/synthetic does not adapt to a Node or a Property".
> This is thrown by the PlainTextRendererSerlvet, which expects a JCR Resource.
> I would suggest to fail gracefully. Like rendering the ResourceMetadata

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (SLING-650) Support for vanity urls

2008-09-10 Thread Carsten Ziegeler (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler closed SLING-650.
--

Resolution: Fixed

Implemented with an additional priority field which is used if several 
resources use the same vanity url. The one with the highest priority is used 
then.

> Support for vanity urls
> ---
>
> Key: SLING-650
> URL: https://issues.apache.org/jira/browse/SLING-650
> Project: Sling
>  Issue Type: New Feature
>  Components: JCR Resource, Servlets Get
>Affects Versions: JCR Resource 2.0.2, Servlets Get 2.0.2
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.0.4, Servlets Get 2.0.4
>
>
> It would be nice to have support for vanity urls: these are urls that do not 
> directly point to a resource. Instead it is possible to give a resource a 
> "pretty" (vanity) url which can be used to address this resource.
> Example:
> /a/b/x/y/myPage
> You can either address this by /a/b/x/y/myPage or by /products
> This can be done by adding a new mixin: sling:VanityUrl
> which has two properties: vanityUrl (which has in the example above the value 
> /products)
> and redirect which is a boolean indication if a redirect should be done or if 
> the content should
> be directly displayed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.