Re: Script Context custom Bindings for engines
Hi, Juan José Vázquez Delgado schrieb: > Hi, > >> i want to inject custom objects to our scripts and did not find a solution >> to perform the task. > > If you´re custom class belongs to an exported package from some > bundle, just make: > > (some_script.esp) > > var myCustomObject = new some.package.CustomClass(); > >> The idea is to provide the scripts with modelWrappers for the current node >> ... >> >> Any suggestions ? > > If you mean mapping jcr nodes to domain objects you might want to use > OCM [1]. You have an example appying OCM at [2]. And if you want to hand-craft the adapters you may even want to implement an AdapterFactory.. > > Hope this helps. Ditto. Regards Felix > > Regards, > > Juanjo. > > [1] http://svn.apache.org/repos/asf/sling/trunk/bundles/jcr/ocm > [2] http://svn.apache.org/repos/asf/sling/trunk/samples/simple-demo >
Re: Revisiting the resource super type handling
Hi, Carsten Ziegeler schrieb: > Felix Meschberger wrote: >> I agree, that the behaviour of the Resource.getResourceType() >> implementation for the bundle resource and filesystem resource >> implementations is inconsistent. >> >> The filesystem provider returns "sling/fs/resource" as its super type. >> IMHO this is an interesting abstraction to apply common behaviour to >> filesystem provided resources. >> >> Therefore, I suggest we enhance the bundle resource provider to return >> "sling/bundle/resource" as the resource super type. > +1, I'll do the change. > >>> I would change it >>> that if a resource does not know it's super type, it should return null. >> So it is currently implemented and defined, IIUIC. > No, see below. > >>> So basically this effects the implementation of the jcr resource. >> So the JcrNodeResource returns the value of the sling:resourceSuperType >> property if set. If the property is not set, null is just returned. The >> JcrPropertyResource returns null immediately, since a property does not >> have a property. > No, the JcrNodeResource does the lookup of the resource type if it does > not have a super type atm. Hmm, maybe my description is about the desired state not about the current reality ;-) > >> The servlet resolver should first do a Resource.getSuperType(). After >> that the resource type (or the resource super type) is used as the basis >> for the ResourceUtil.getResourceSuperType(ResourceResolver, String) >> method. Right ? > Yes, exactly. > >> Consequently: >> >> * ResourceUtil.getResourceSuperType(ResourceResolver, String) remains >>as is resolving the resource super type as the supertype of the >>resource type resource. > Yes. > >> * ResourceUtil.getResourceSuperType(Resource) is removed, since it >>brings no added value (it only has been added yesterday). > Yes, I thought this, too. > >> * JcrResourceUtil.getResourceSuperType(ResourceResolver, String) is >>deprecated and is implemented calling the new >>ResourceUtil.getResourceSuperType(ResourceResolver, String) >>method. > Yes > >> * JcrResourceUtil.getResourceSuperType(Resource) is deprecated and is >>implemented to call Resource.getSuperType() on the resource first >>and then calling ResourceUtil.getSuperType(ResourceResolver, >>resource.getResourceType()) as a fallback. > Yes > >> Is that what you had in mind ? > With the addition that JcrNodeResource returns null for the super type > if it doesn't have the property. Yes, as I described above the "desired state". Regards Felix > > Carsten >> Regards >> Felix >> >>> Otherwise each resource implemenation should apply the algorithm to be >>> consistent. But I would prefer the first solution. >> >>> While the change is incompatible, I think this doesn't have any real effect. >>> >>> WDYT? >> >> > >
Re: Revisiting the resource super type handling
Hi, Carsten Ziegeler schrieb: > Hi, > > while changing the script resolution in the last days a little bit to > make it cacheable, I stumbled across the handling of the resource super > type. > The jcr resource implementation checks if the node has the > sling:resourceSuperType property and returns this value if existent. > If not, it tries to find a resource under the search paths (usually libs > and apps) with the resource type converted to a path. So if a resource > has the type "a/b", the resources /apps/a/b and /libs/a/b are tested if > they exist and contain a resource super type property. > > Other resource implementations like the bundle resource always returns > null. The fs resource implemenations returns a special resource type for > the resource super type. > > I think this behaviour is a little bit inconsistent. I agree, that the behaviour of the Resource.getResourceType() implementation for the bundle resource and filesystem resource implementations is inconsistent. The filesystem provider returns "sling/fs/resource" as its super type. IMHO this is an interesting abstraction to apply common behaviour to filesystem provided resources. Therefore, I suggest we enhance the bundle resource provider to return "sling/bundle/resource" as the resource super type. > I would change it > that if a resource does not know it's super type, it should return null. So it is currently implemented and defined, IIUIC. > So basically this effects the implementation of the jcr resource. So the JcrNodeResource returns the value of the sling:resourceSuperType property if set. If the property is not set, null is just returned. The JcrPropertyResource returns null immediately, since a property does not have a property. > The script resolver already checks if the resource super type is null > and then applies the above algoritm from the jcr resource as well. The servlet resolver should first do a Resource.getSuperType(). After that the resource type (or the resource super type) is used as the basis for the ResourceUtil.getResourceSuperType(ResourceResolver, String) method. Right ? Consequently: * ResourceUtil.getResourceSuperType(ResourceResolver, String) remains as is resolving the resource super type as the supertype of the resource type resource. * ResourceUtil.getResourceSuperType(Resource) is removed, since it brings no added value (it only has been added yesterday). * JcrResourceUtil.getResourceSuperType(ResourceResolver, String) is deprecated and is implemented calling the new ResourceUtil.getResourceSuperType(ResourceResolver, String) method. * JcrResourceUtil.getResourceSuperType(Resource) is deprecated and is implemented to call Resource.getSuperType() on the resource first and then calling ResourceUtil.getSuperType(ResourceResolver, resource.getResourceType()) as a fallback. Is that what you had in mind ? Regards Felix > > Otherwise each resource implemenation should apply the algorithm to be > consistent. But I would prefer the first solution. > > While the change is incompatible, I think this doesn't have any real effect. > > WDYT?
Re: Revisiting the resource super type handling
Hi, Tobias Bocanegra schrieb: > On Fri, Jun 26, 2009 at 10:30 AM, Carsten Ziegeler > wrote: >> Hi, >> >> while changing the script resolution in the last days a little bit to >> make it cacheable, I stumbled across the handling of the resource super >> type. >> The jcr resource implementation checks if the node has the >> sling:resourceSuperType property and returns this value if existent. >> If not, it tries to find a resource under the search paths (usually libs >> and apps) with the resource type converted to a path. So if a resource >> has the type "a/b", the resources /apps/a/b and /libs/a/b are tested if >> they exist and contain a resource super type property. >> >> Other resource implementations like the bundle resource always returns >> null. The fs resource implemenations returns a special resource type for >> the resource super type. >> >> I think this behaviour is a little bit inconsistent. I would change it >> that if a resource does not know it's super type, it should return null. >> So basically this effects the implementation of the jcr resource. >> The script resolver already checks if the resource super type is null >> and then applies the above algoritm from the jcr resource as well. >> >> Otherwise each resource implemenation should apply the algorithm to be >> consistent. But I would prefer the first solution. >> >> While the change is incompatible, I think this doesn't have any real effect. > > i agree that the resource should not know about search paths. imo, the > resource resolver should be used for 'resolving' the resource super > type. Actually, the ResourceResolver *is* used to resolve the super type from a resource type resource: // resource type rel path, e.g. nt/file String path = resourceTypeToPath(resourceType); // resolve resource type resource Resource rtResource = resourceResolver.getResource(path); The getResource method applies the current search path as described and required and requested. Regards Felix
Re: [Fwd: git://git.apache.org/sling.git]
Hi, Ok, will do that. Thanks. Regards Felix Tony Stevenson schrieb: > Felix, > > Send this to infrastructure-dev -- Where Jukka and Gregorz will likely > see it and fix it up for you. > > > On 26 Jun 2009, at 10:33, Felix Meschberger wrote: > >> Hi all, >> >> We have move the Sling source code to its new top level location >> http://svn.apache.org/repos/asf/sling. >> >> It looks like the GIT mirror setup is still referring to the old >> incubator location at http://svn.apache.org/repos/asf/incubator/sling. >> >> Can someone please take care of this ? Thanks alot. >> >> Regards >> Felix >> >> Original-Nachricht >> Betreff: git://git.apache.org/sling.git >> Datum: Fri, 26 Jun 2009 09:58:07 +0100 >> Von: Ian Boston >> Antwort an: sling-dev@incubator.apache.org >> An: sling-dev@incubator.apache.org >> >> Now that the svn repo has moved, >> has the git mirror been updated ? >> >> I am not getting any updates through. >> Ian >> >> > > > > > Cheers, > Tony > > > > Tony Stevenson > > t...@pc-tony.com - pct...@apache.org > pct...@freenode.net - t...@caret.cam.ac.uk > > http://blog.pc-tony.com > > 1024D/51047D66 ECAF DC55 C608 5E82 0B5E > 3359 C9C7 924E 5104 7D66 > > > > > > >
Re: OSGi Compendium
Carsten Ziegeler schrieb: > Dominik Süß wrote: >> Wouldn't it be more straight forward to exclude the Compendium Libraries >> from the Declarative Services as well and have it as seperate bundle in >> general? >> I know this thoughts might lead to a big amount of small bundles and some >> might not like this, but in this case I think it really would make sense. > This actually would require to split up the compendium into the various > parts and have an api bundle for each part. > Updating the DS then would require to update the api and the impl bundle. > > Hmm, not sure what the better option is. At least, it seems that pre > bundling the compendium libs is wrong. So +1 to remove them from > launchpad/base. > > I like the way how the Apache Felix DS implementation does it. You get > one bundle containing everything you need. So updating to a new spec > version is pretty simply as the bundle is self contained. Actually the Apache Felix DS implementation also exports the Configuration Admin packages. This will probably be removed for the next release. > > How do other implementations do this? AFAICT the Eclipse/Equinox project is using the approach of not including the API in the implementation bundles but to have you install the compendium library bundle. There are basically two approaches to the question of where to locate API with respect to the implementations: One is to include the implemented API with the implementation. The other is to strictly separate API from implementation. My stance is somewhere in-between. Generally I prefer separating the API from the implementation, unless ... For example, in Sling we have the Sling API bundle. This is IMHO a coherent API which is implemented by multiple bundles, e.g. the engine and the jcr/resource bundles. This API is separate. On the other hand we have the exported API of the jcr/resource bundle. While we could separate it out into a separate bundle, the resulting bundle would be so small, that it probably makes no sense. In addition, chances of another implementation of that API are close to zero. For the compendium API, the case is that the Compendium library is a collection of more or less unrelated packages (there is close to no interpackage references on the API level). So having one Compendium bundle tends to lead to issues if we upgrade the implementations independetly of the versioning of the different packages. As a result, in Apache Felix we export the respective API from the implementation bundles. This also makes it easy to upgrade the API. Regards Felix > > Carsten >> Regards, >> Dominik >> >> On Thu, Jun 25, 2009 at 4:39 PM, Felix Meschberger wrote: >> >>> Hi all, >>> >>> Currently the Sling launcher (in the launchpad/base module) contains the >>> Felix framework, the OSGi Core libraries as well as the OSGi Compendium >>> libraries. >>> >>> While working on the implementation of the new Declarative Services 1.1 >>> features planned for addition in the OSGi Compendium Specification 4.2 I >>> ran into a problem with this setup. >>> >>> Consider a bundle X importing the Declarative Services packages *before* >>> the new implementation is installed. Both the system bundle (as per the >>> launchpad/base module) and the Declarative Services implementation >>> export version 1.0 of the org.osgi.service.component package. This >>> results in all bundles wiring to the system bundle. Everything is fine. >>> >>> Now update the Declarative Services bundle which now exports version 1.1 >>> of the org.osgi.service.component package. The Declarative Services >>> bundle binds to its own export using the latest version available. >>> Bundle X is still wired to the system bundle because there is no >>> rewiring taking place. >>> >>> The consequence is, that the new Declarative Services bundle cannot call >>> any of the activate or deactivate methods of the components in Bundle X >>> because the ComponentContext argument is not compatible. >>> >>> As a fix, I suggest we modify the launchpad/base bundle to *not* provide >>> the Compendium packages any more. Instead we will expect that either the >>> Compendium implementation bundles export the packages (as for example >>> the Apache Felix Declarative Services bundle does) or that the >>> compendium packages are installed as a bundle. >>> >>> WDYT ? >>> >>> Regards >>> Felix >>> > >
[Fwd: git://git.apache.org/sling.git]
Hi all, We have move the Sling source code to its new top level location http://svn.apache.org/repos/asf/sling. It looks like the GIT mirror setup is still referring to the old incubator location at http://svn.apache.org/repos/asf/incubator/sling. Can someone please take care of this ? Thanks alot. Regards Felix Original-Nachricht Betreff: git://git.apache.org/sling.git Datum: Fri, 26 Jun 2009 09:58:07 +0100 Von: Ian Boston Antwort an: sling-dev@incubator.apache.org An: sling-dev@incubator.apache.org Now that the svn repo has moved, has the git mirror been updated ? I am not getting any updates through. Ian
OSGi Compendium
Hi all, Currently the Sling launcher (in the launchpad/base module) contains the Felix framework, the OSGi Core libraries as well as the OSGi Compendium libraries. While working on the implementation of the new Declarative Services 1.1 features planned for addition in the OSGi Compendium Specification 4.2 I ran into a problem with this setup. Consider a bundle X importing the Declarative Services packages *before* the new implementation is installed. Both the system bundle (as per the launchpad/base module) and the Declarative Services implementation export version 1.0 of the org.osgi.service.component package. This results in all bundles wiring to the system bundle. Everything is fine. Now update the Declarative Services bundle which now exports version 1.1 of the org.osgi.service.component package. The Declarative Services bundle binds to its own export using the latest version available. Bundle X is still wired to the system bundle because there is no rewiring taking place. The consequence is, that the new Declarative Services bundle cannot call any of the activate or deactivate methods of the components in Bundle X because the ComponentContext argument is not compatible. As a fix, I suggest we modify the launchpad/base bundle to *not* provide the Compendium packages any more. Instead we will expect that either the Compendium implementation bundles export the packages (as for example the Apache Felix Declarative Services bundle does) or that the compendium packages are installed as a bundle. WDYT ? Regards Felix
Re: GWT Tests with Sling
Hi, Torgeir Veimo schrieb: > 2009/6/26 Felix Meschberger : >> Hi, >> >> Torgeir Veimo schrieb: >>> 2009/6/26 Felix Meschberger : >>>> Hi, >>>> >>>> Torgeir Veimo schrieb: >>>>>>> I'm in the development team of a new CMS which is based on Sling. >>>>> It seems there are several that are doing this, basing their admin >>>>> console on GWT. There might be an opportunity to put together an open >>>>> source project here around this, since there would otherwise be a lot >>>>> of duplicate effort, and I don't think there's much competitive >>>>> advantage in having a proprietary admin console for an open source >>>>> cms. >>>> What do you mean by "admin console" ? If you have something like the >>>> Felix Web Console [1] in mind, there is already such a beast, which is >>>> being actively developed. >>>> >>>> Otherwise, I would be eager to hear your requirements and to discuss, >>>> whether we could use the Web Console for your requirements or whether >>>> another console is required. >>> No I was of course thinking about content editors. The "admin console" >>> is an umbrella term we use internally here to mean those things. >> Thanks for the clarification. >> >> In this case, I would assume, that the Sling project is probably a good >> candidate to be such an open-source project. > > Even GWT based content editors? It would drag in a number of > dependencies, not all of them apache licensed. Well, that of course then amounts to a problem - luckily GWT itself is ASL2 licensed. And as long as the dependencies have acceptable licenses (MIT and BSD come to mind) there is not an issue, either. Where it starts getting problematic is the LGPL and GPL licenses. Regards Felix
Re: GWT Tests with Sling
Hi, Torgeir Veimo schrieb: > 2009/6/26 Felix Meschberger : >> Hi, >> >> Torgeir Veimo schrieb: >>>>> I'm in the development team of a new CMS which is based on Sling. >>> It seems there are several that are doing this, basing their admin >>> console on GWT. There might be an opportunity to put together an open >>> source project here around this, since there would otherwise be a lot >>> of duplicate effort, and I don't think there's much competitive >>> advantage in having a proprietary admin console for an open source >>> cms. >> What do you mean by "admin console" ? If you have something like the >> Felix Web Console [1] in mind, there is already such a beast, which is >> being actively developed. >> >> Otherwise, I would be eager to hear your requirements and to discuss, >> whether we could use the Web Console for your requirements or whether >> another console is required. > > No I was of course thinking about content editors. The "admin console" > is an umbrella term we use internally here to mean those things. Thanks for the clarification. In this case, I would assume, that the Sling project is probably a good candidate to be such an open-source project. Regards Felix
Re: GWT Tests with Sling
Hi, Torgeir Veimo schrieb: >>> I'm in the development team of a new CMS which is based on Sling. > > It seems there are several that are doing this, basing their admin > console on GWT. There might be an opportunity to put together an open > source project here around this, since there would otherwise be a lot > of duplicate effort, and I don't think there's much competitive > advantage in having a proprietary admin console for an open source > cms. What do you mean by "admin console" ? If you have something like the Felix Web Console [1] in mind, there is already such a beast, which is being actively developed. Otherwise, I would be eager to hear your requirements and to discuss, whether we could use the Web Console for your requirements or whether another console is required. Regards Felix [1] http://felix.apache.org/site/apache-felix-web-console.html
Re: [RT] Script Resolution
Hi Ian, Ian Boston schrieb: > > On 23 Jun 2009, at 14:06, Felix Meschberger wrote: > >> Hi, >> >> Ian Boston schrieb: >>> >>> On 23 Jun 2009, at 12:28, Bertrand Delacretaz wrote: >>>>> Although Sling might choose to ignore this, I/we (sakai) are going >>>>> to need to do something since all our users have write access to the >>>>> repo, and at least 10% of them are Computer Science first year >>>>> students just itching to prove their prowess by hacking/defacing an >>>>> institutional system :) >>>> >>>> Brings back memories ;-) >>>> >>>> If we're using a distinct session for script resolution, we might want >>>> to make its credentials configurable, and setup that user to see >>>> scripts only under /libs and /apps. Would that suit your needs? >>> >>> yes, >>> certainly would, >>> We already have a "securityloader" along the same lines as the >>> "contentloader" so configuration of that would be easy for us. >> >> The first step will be to use an admin session to access the scripts. So >> you may lock down read-access on these areas, where you deam read-access >> is not suitable. > > > Forgive me, this might sound dumb (and it wont the fist time). Or maybe it was me ... and not the first time, either. > If the admin session is used to *load* scripts for execute, then surely > it can load scripts from anywhere ? Yes. > I agree users wont be able to write or read scripts in the special > area... but my concern is not stopping them reading scripts that might > run, or uploading scripts to somewhere where they can write, but to stop > untrusted scripts from executing. I see. > I the absence of any other control, the admin session will allow execute > of all scripts on the content system. > > Please tell me I have missed something, and I am being dumb :) Correct, so I would then say: the actual user is to be configurable but default to admin. Would that be ok for you ? Regards Felix
Re: [RT] Script Resolution
Hi, Bertrand Delacretaz schrieb: > Hi, > > On Tue, Jun 23, 2009 at 12:03 PM, Ian Boston wrote: >> On 23 Jun 2009, at 09:42, Felix Meschberger wrote: >>> ... What exact problem do you want to solve with the restriction on script >>> access ? Do you have some kind of "x-bit" in mind ? The repository >>> itself has no support for (and cannot support) this kind of permission >>> itself > > Doesn't JCR 2.0 support arbitrary permissions? The spec says > > "A privilege represents the ability to perform a particular set of > operations on a node. Each privilege is identified by a JCR name. > JCR defines a set of standard privileges within the Privilege > interface. An implementation may add additional privileges, using an > appropriate implementation specific namespace for their names" > > So IIUC we (or rather Jackrabbit) might be able to define a > jackrabbit:execute privilege? Yes, that's the line of thinking here. Regards Felix
Re: [RT] Script Resolution
Hi, Ian Boston schrieb: > > On 23 Jun 2009, at 12:28, Bertrand Delacretaz wrote: >>> Although Sling might choose to ignore this, I/we (sakai) are going >>> to need to do something since all our users have write access to the >>> repo, and at least 10% of them are Computer Science first year >>> students just itching to prove their prowess by hacking/defacing an >>> institutional system :) >> >> Brings back memories ;-) >> >> If we're using a distinct session for script resolution, we might want >> to make its credentials configurable, and setup that user to see >> scripts only under /libs and /apps. Would that suit your needs? > > yes, > certainly would, > We already have a "securityloader" along the same lines as the > "contentloader" so configuration of that would be easy for us. The first step will be to use an admin session to access the scripts. So you may lock down read-access on these areas, where you deam read-access is not suitable. Of course, extending this to be able to provide configuration with credentials of a user to use to access the scripts is simple. Regards Felix
Re: [RT] Script Resolution
Hi, Dominik Süß schrieb: > Wouldn't this take us the ability to restrict allowed actions by taking > reading rights of the scriptlocation by ACLs? > How would you solve restriction on scriptaccess? What exact problem do you want to solve with the restriction on script access ? Do you have some kind of "x-bit" in mind ? The repository itself has no support for (and cannot support) this kind of permission itself. As Bertrand already said, lets ignore this for now and add it later (proabbly to the scripting infrastructure in the scripting/core bundle). Regards Felix > > Best regards, > Dominik > > On Mon, Jun 22, 2009 at 9:20 PM, Carsten Ziegeler wrote: > >> Another minor issue are the helper methods of the JcrResourceUtil class >> (the getResourceSuperType, resourceTypeToPath methods). I think we can >> make them completly JCR free and move them to the ResourceUtil class in >> the API. >> >> Carsten >> >> Carsten Ziegeler wrote: >>> Hi, >>> >>> I'm currently working on improving the script resolution in terms of >>> performance. >>> While looking at how it works today, I've discovered two problematic >> points: >>> 1) Currently the scripts are searched by using the session of the >>> current request. Now, I think using the user session to search the >>> script is wrong. The content, the user requests, is already retrieved >>> with the user session and its the content (or the acl's on the content) >>> who define if the user is allowed to access something. >>> The script should always be executable (and I'm speaking of execution >>> not reading, writing etc.) for any user. This also matches the current >>> handling for scripts which are not stored in the repository like the >>> servlets or scripts contained in bundle resources. >>> >>> Therefore I suggest to change the script resolution to use the admin >>> session. >>> >>> Btw, this would also make caching the script resolution easier as the >>> current approach requires the caching of the script resolution to be a >>> per user cache. With the changes from above the cache can be global. >>> >>> 2) Resource events >>> >>> We need to implement https://issues.apache.org/jira/browse/SLING-944 and >>> some extension of this to properly update the cache if scripts are >>> changed, added removed. As scripts can be coming from any data source >>> (jcr, file system, bundle, database etc.) we need a generic mechanism >> here. >>> For now I think we could start with OSGi events for >>> - Resource added, removed, changed >>> - Resource Provider added, removed >>> >>> WDYT? >>> >>> Carsten >> >> -- >> Carsten Ziegeler >> cziege...@apache.org >> >
Re: [RT] Script Resolution
Hi, Carsten Ziegeler schrieb: > Another minor issue are the helper methods of the JcrResourceUtil class > (the getResourceSuperType, resourceTypeToPath methods). I think we can > make them completly JCR free and move them to the ResourceUtil class in > the API. +1 But leave the methods in the JcrResourceUtil forwarding to the new mehotds in the ResoureUtil class and deprecate them. Regards Felix > > Carsten > > Carsten Ziegeler wrote: >> Hi, >> >> I'm currently working on improving the script resolution in terms of >> performance. >> While looking at how it works today, I've discovered two problematic points: >> >> 1) Currently the scripts are searched by using the session of the >> current request. Now, I think using the user session to search the >> script is wrong. The content, the user requests, is already retrieved >> with the user session and its the content (or the acl's on the content) >> who define if the user is allowed to access something. >> The script should always be executable (and I'm speaking of execution >> not reading, writing etc.) for any user. This also matches the current >> handling for scripts which are not stored in the repository like the >> servlets or scripts contained in bundle resources. >> >> Therefore I suggest to change the script resolution to use the admin >> session. >> >> Btw, this would also make caching the script resolution easier as the >> current approach requires the caching of the script resolution to be a >> per user cache. With the changes from above the cache can be global. >> >> 2) Resource events >> >> We need to implement https://issues.apache.org/jira/browse/SLING-944 and >> some extension of this to properly update the cache if scripts are >> changed, added removed. As scripts can be coming from any data source >> (jcr, file system, bundle, database etc.) we need a generic mechanism here. >> For now I think we could start with OSGi events for >> - Resource added, removed, changed >> - Resource Provider added, removed >> >> WDYT? >> >> Carsten > >
[jira] Commented: (SLING-1013) Feed Entry IDs are URL-encoded
[ https://issues.apache.org/jira/browse/SLING-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721789#action_12721789 ] Felix Meschberger commented on SLING-1013: -- Can you be a bit more specific with respect to the concrete issue ? Thanks. > Feed Entry IDs are URL-encoded > -- > > Key: SLING-1013 > URL: https://issues.apache.org/jira/browse/SLING-1013 > Project: Sling > Issue Type: Bug > Components: Scripting JSP >Reporter: Lars Trieloff > > The JSP taglib will URL-encode all IDs, but actually IDs should be URLs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
SVN moved
Hi all, Thanks to Jukka I could already move the Sling source in SVN to the new location. To adapt your local check-out just use the "svn switch", like in: $ svn switch http://svn.apache.org/repos/asf/incubator/sling/trunk from inside your trunk checkout. Regards Felix
Graduation tasks
Hi all, as per the graduation task list [1], we have to move things around a bit. I have asked infra@ to support us here [2]. On the frontend the following tasks will be done: * Move SVN from below incubator to our new TLP location * "Rename" the mailing lists (I have asked infra to keep current subscriptions) * Prepare our new TLP web site I will keep you posted, most notably regarding the SVN move. Regards Felix [1]http://incubator.apache.org/guides/graduation.html#life-after-graduation [2]https://issues.apache.org/jira/browse/INFRA-2102
Re: User Manager and Charset
Hi, Juan José Vázquez Delgado schrieb: >> There is an issue with accented chars and the sling user manager. >> >> I do a web based interface for the nodes below /system/userManager. >> >> When I POST to createUser or updateUser, then accented chars are messed up >> in the server side authorizable resource: eg. the char "ü" becomes "ü". it >> looks to me like the servlet interprets the incoming data as single-byte >> latin-1, while it is in fact utf-8. >> >> I am quite sure this happens in the servlet: I made the form explicitly >> submit "application/x-www-form-urlencoded; charset=UTF-8", and looking at >> the wireshark, thats whats happening. While two bytes go to the server, the >> value returned later is four bytes... >> >> Would you please look into this issue? Accented chars are not a problem with >> nodes in other paths of jcr/sling. > > Hi Peter, > > You can try with a hidden field of the name "_charset_" containing the > encoding in your form. Have a look at this [1]. In addition you might want to send the form itself using the same encoding as set in the _charset_ parameter. We have the best results doing everything in UTF-8 and doing that explicitly. Regards Felix > > Regards, > > Juanjo. > > [1] http://incubator.apache.org/sling/site/request-parameters.html >
Re: getting error in sling
Hi Tanmay, do you get this regularly ? Always on the same resource (or script/servlet) ? This looks like the client has terminated the connection before the service could send the response. Could it be some long-running processing on the server causing the client to time out and abort ? Regards Felix Tanmay Barman schrieb: > Hi All, > In my Sling Application I'm having some sling error. > > 17.06.2009 18:46:52.696 *ERROR* [btpool1-2] > org.apache.sling.engine.impl.SlingMainServlet service: Uncaught Throwable > org.mortbay.jetty.EofException > at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:760) > at > org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:566) > at > org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:905) > at > org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:642) > at > org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:577) > at > org.apache.sling.engine.impl.output.BufferedServletOutputStream.write(BufferedServletOutputStream.java:247) > at > org.apache.sling.engine.impl.SlingHttpServletResponseImpl$LoggerResponseOutputStream.write(SlingHttpServletResponseImpl.java:483) > at > org.apache.sling.servlets.get.helpers.StreamRendererServlet.doGet(StreamRendererServlet.java:117) > at > org.apache.sling.api.servlets.SlingSafeMethodsServlet.mayService(SlingSafeMethodsServlet.java:262) > at > org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:338) > at > org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:370) > at > org.apache.sling.servlets.get.DefaultGetServlet.doGet(DefaultGetServlet.java:113) > at > org.apache.sling.api.servlets.SlingSafeMethodsServlet.mayService(SlingSafeMethodsServlet.java:262) > at > org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:338) > at > org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:370) > at > org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:462) > at > org.apache.sling.engine.impl.SlingMainServlet.processRequest(SlingMainServlet.java:419) > at > org.apache.sling.engine.impl.filter.RequestSlingFilterChain.render(RequestSlingFilterChain.java:48) > at > org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:54) > at > org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter.doFilter(RequestProgressTrackerLogFilter.java:59) > at > org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:52) > at > org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:273) > at > org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:171) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) > at > org.ops4j.pax.web.service.internal.HttpServiceServletHandler.handle(HttpServiceServletHandler.java:51) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:722) > at > org.ops4j.pax.web.service.internal.HttpServiceContext.handle(HttpServiceContext.java:87) > at > org.ops4j.pax.web.service.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:63) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:828) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450) > Caused by: java.net.SocketException: Software caused connection abort: > socket write error > at java.net.SocketOutputStream.socketWrite0(Native Method) > at java.net.SocketOutputStream.socketWrite(Unknown Source) > at java.net.SocketOutputStream.write(Unknown Source) > at org.mortbay.io.ByteArrayBuffer.writeTo(ByteArrayBuffer.java:169) > at org.mortbay.io.bio.StreamEndPoint.flush(StreamEndPoint.java:122) > at org.mortbay.io.bio.StreamEndPoint.flush(StreamEndPoint.java:154) >
[jira] Closed: (SLING-1008) Mapping configuration below /etc/map should not require default port number on host level
[ https://issues.apache.org/jira/browse/SLING-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-1008. Resolution: Fixed Fixed by checking the host level of the configuration and ensuring the port numbers in Rev. 785394. Also added unit tests. > Mapping configuration below /etc/map should not require default port number > on host level > - > > Key: SLING-1008 > URL: https://issues.apache.org/jira/browse/SLING-1008 > Project: Sling > Issue Type: Bug > Components: JCR Resource >Affects Versions: JCR Resource 2.0.4 > Reporter: Felix Meschberger > Assignee: Felix Meschberger > Fix For: JCR Resource 2.0.6 > > > Currently the host level of mapping configuration at /etc/map must be > configured with a port number even if the port number would be the default > for the respective protocol. > For ease of use, it would be good to be able to configure just the host name > and have the internal mapping structure to apply the default port number. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1008) Mapping configuration below /etc/map should not require default port number on host level
Mapping configuration below /etc/map should not require default port number on host level - Key: SLING-1008 URL: https://issues.apache.org/jira/browse/SLING-1008 Project: Sling Issue Type: Bug Components: JCR Resource Affects Versions: JCR Resource 2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: JCR Resource 2.0.6 Currently the host level of mapping configuration at /etc/map must be configured with a port number even if the port number would be the default for the respective protocol. For ease of use, it would be good to be able to configure just the host name and have the internal mapping structure to apply the default port number. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Queries with large result sets and sorting.
Hi Ian, Maybe you might want to ask this question on the Jackrabbit dev list where JCR Query implementation specialist is also lurking. Regards Felix Ian Boston schrieb: > yes it was that thread that triggered the concern. > > " > Obviously, a stupid example, but, unfortunately, not really to much to > do about it except not sorting on large property fields...if you need to > sort on the title of 200.000 docs...you better sort on the short_title > (which I would prefer to be an index only property defined in > indexing_configuration, but I think people have different opinions on > this) " > > Does that mean that sorting huge numbers of documents on *small* fields > has a similar problems. Unless there is a pre-query to estimate the > number of hits (using the Jackrabbit getTotalCount() IIRC methods), then > its going to be impossible to avoid submitting queries that could result > in a sort on huge numbers of results. > > I had thought in the special case of sort by date the solution would be > to split the searches up into chunks to avoid a massive sort. > > eg search for items in the last hour, > if there are not enough items the next hour with some extending range. > > or perform a sequence of unsorted pre queries on a date range to > determine the range required to return a set large enough to sort. > > On the basis that lastModified is a long, am I worrying unnecessarily ? > > Ian > > > On 15 Jun 2009, at 17:59, Marc Speck wrote: > >> I've just read the thread http://markmail.org/message/wnn2bfwzwx2hn6v4 . >> Maybe it helps, >> Marc >> >> >> >> On Mon, Jun 15, 2009 at 6:52 PM, Ian Boston wrote: >> >>> Hi, >>> >>> I want to perform a query where the full result set could be millions of >>> items. That set needs to be sorted by the lastModified attribute on the >>> node, and I only want to see a small number of items eg 100 after a >>> particular date. >>> >>> If I do this, will there be scalability issues, or is the sorting of >>> a date >>> field optimized in the query engine ? >>> >>> Thanks >>> Ian >>> > >
[jira] Commented: (SLING-1003) Integration of 3rd party servlet filters problematic
[ https://issues.apache.org/jira/browse/SLING-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12720115#action_12720115 ] Felix Meschberger commented on SLING-1003: -- Hmm, it looks like the SlingHttpServletRequest/ResponseAdapter classes are calling just getRequest/Response which returns the wrapped HttpServletRequest/Response which of course cannot be cast. So we have to overwrite the getSlingRequest/Response methods in the adapters to ensure the baseclass getRequest/Response mehod is called, which then is the SlingHttpServlet/Request/Response. Applied a fix in Rev. 785200. Can you please check ? Thanks. > Integration of 3rd party servlet filters problematic > > > Key: SLING-1003 > URL: https://issues.apache.org/jira/browse/SLING-1003 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.0.4 > Environment: Windows Vista, > java version "1.6.0_13" > Java(TM) SE Runtime Environment (build 1.6.0_13-b03) > Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing) >Reporter: Christian Sprecher >Assignee: Felix Meschberger >Priority: Minor > Fix For: Engine 2.0.6 > > Attachments: SlingWebCastellum-1.0.jar > > > There is a problem within the chain handling: the 3rd party filter uses it's > own wrapper for requests and response, and supplies it to the chain in the > chain.doFilter() call. This leads to a ClassCastException on line 54 of > AbstractSlingFilterChain: > ... >RequestProgressTracker tracker = ((SlingHttpServletRequest) > request).getRequestProgressTracker(); > ... > I am not sure if this cast is valid in the context of a filter chain. On the > other hand I am not sure wether such a use case (filter that manipulates > request and response) has a chance to run in Sling. > ==> Please note that this servlet filter needs to run as early as possible in > the filter chain > java.lang.ClassCastException: org.webcastellum.RequestWrapper cannot be cast > to > org.apache.sling.api.SlingHttpServletRequest >at > org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter > (AbstractSlingFilterChain.java:54) >at > org.webcastellum.WebCastellumFilter.internalDoFilter(WebCastellumFilt > er.java:2610) >at > org.webcastellum.WebCastellumFilter.doFilter(WebCastellumFilter.java: > 1710) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SLING-490, SystemStatus service discussion
Hi, Bertrand Delacretaz schrieb: >> Now, this is very simple and easy: As Alex Klimetschek proposes we are >> using ConfigurationAdmin for this. Each service can be described by a >> few properties: >> >> (a) Service Name >> (b) Service Filter >> (c) Number of services... > > And in some case (like script engines), additional properties. Use > case is "I want the JSP script engine to be ready" - can we express > that with a filter? Yes, filters are matched against service registration properties. > >> ...The system status service itself : >> >> * requires the ConfigAdmin service to be present >> * registers as a ManagedService to receive the configuration >> >> Thats basically all. Very simple, very lean > > But how do you bootstrap that ConfigAdmin information for the first > startup of a Sling instance, where no OSGi state is stored? > > Use case: > 1) I create a variant of the launchpad app with my own set of bundles > 2) I define a custom list of services (according to the above syntax) > that must be active for my system to be ready > 3) I want my SystemStatus configuration to be available from the first > startup of the system > > How can I put 2) in my custom executable jar? > > Again, I think using sling.properties to define where this info comes > from is the most flexible way, going back to yesterday's example from > sling.properties: > > # Values like myServiceA uses the syntax proposed by Felix > sling.readyness.check.1 = services:myServiceA, myServiceB > > # jcr: means look in the repository for additional definitions > sling.readyness.check.2 = jcr:/system/sling/status Again, this is sling, so this would be resource tree, right ? > > # osgi:ConfigAdmin means use that service to get additional required > # services definition. If not present, the ConfigAdmin service is not > # required (for super-lean Sling instances) > sling.readyness.check.3 = osgi:ConfigAdmin:nameOfTheConfigThatHoldsThisInfo > > This is easy to implement, flexible, and implementing it is probably > faster than spending ages discussing exactly which options we allow > ;-) ok, let's go this route: *sling.properties for some settings (how do you get them into a finished web app ???) * ConfigAdmin service is required * system status requires configuration to consider the system ready Now configuration could enter the system (as I said above, and sorry to reiterate) through: * Deployment Admin * JCR Install * an Administrative Bundle doing nothing else but setting this config Regards Felix > > -Bertrand >
Re: SLING-490, SystemStatus service discussion
Hi, Alexander Klimetschek schrieb: > On Tue, Jun 16, 2009 at 8:02 AM, Felix Meschberger wrote: >> (1) The most basic criterion for the system to be ready is the available >> of certain services. > > Yes, services is probably enough. The availability of bundles doesn't > actually help for readyness detection, it's their services that are > important. > >> (2) There must be away to specify which services are required. >> >> >> Now, this is very simple and easy: As Alex Klimetschek proposes we are >> using ConfigurationAdmin for this. Each service can be described by a >> few properties: >> >> (a) Service Name >> (b) Service Filter >> (c) Number of services >> >> The configuration of required services is a multivalued string property >> of the format >> >>[ number ] ( serviceName | serviceFilter ) >> >> where >> >>numberis an optional positive number of required services >>serviceName is the name of a service interface >>serviceFilter is a service filter according to 3.2.6, Filter Syntax > > +1 for Filter syntax > > Just to be sure: we can also define service implementations by > filters, right? Eg. for the scripting case, we want to be able to say, > we need the "jsp" and the "esp" scripting engines available, and not > just 2 services implementing the scripting engine service interface. you might define two entries: &((OBJECT_CLASS=javax.jcr.ScriptEngineFactory)(extension=jsp)) &((OBJECT_CLASS=javax.jcr.ScriptEngineFactory)(extension=esp)) Regards Felix > > Regards, > Alex >
Re: SLING-490, SystemStatus service discussion
Hi, Well, *if* we want to check the system state, that check should be done continuously during the whole lifetime otherwise it makes no sense, honestly: The goal is to not stop the system, so a system startup is a seldom case and bruning cycles for a case, which almost never (in theory and as a goal) happens, sounds not very productive Regards Felix Alexander Klimetschek schrieb: > On Tue, Jun 16, 2009 at 7:55 AM, Felix Meschberger wrote: >>> Isn't it possible to avoid that case with start levels? (we are >>> talking about the initial startup only, if the configadmin goes away >>> later, no problem, the system ready state should IMHO never switch >>> from true to false as it is only for the startup) >> This is of course wrong. *If* we have a system status service, this is >> used throughout the lifetime of the system. That is it may happen that >> the system becomes unavailable if something is going away. >> >> Just to have a status mechanism for startup makes no sense. > > Well, the whole point of the system ready detection is to find out at > what point in time everything is up and running to serve requests (and > not send a 503 Service Unavailable) after a startup. With "legacy" > frameworks such as the old Spring, where components were hardwired, > startup was deterministic and quite easily to detect. Now within the > context of a highly asynchronous system we need a separate solution. > > But I don't think that bundles going away or crashing during the > lifetime should lead to a 503 immediately. They might indicate a > problem and one wants to see this problem rather than a 503. Or the > system ready config has to be changed alongside a major redeployment > took place and you don't want to restart the system (considering the > config is stored in the sling.properties that are only read on > restart). If we don't get this right, you see a 503 way too often also > things might be running perfectly. > > Regards, > Alex >
Re: SLING-490, SystemStatus service discussion
Hi, Carsten Ziegeler schrieb: > Felix Meschberger wrote: >> Hi, >> >> Replying to this message, but my response applies to the complete thread. >> >> Let's step back a second and look at what we really need to know to be >> able to decide the system is ready or not. And who is responsible to >> provide this knowledge. >> >> >> (1) The most basic criterion for the system to be ready is the available >> of certain services. >> >> >> (2) There must be away to specify which services are required. >> >> >> Now, this is very simple and easy: As Alex Klimetschek proposes we are >> using ConfigurationAdmin for this. Each service can be described by a >> few properties: >> >>(a) Service Name >>(b) Service Filter >>(c) Number of services >> >> The configuration of required services is a multivalued string property >> of the format >> >> [ number ] ( serviceName | serviceFilter ) >> >> where >> >> numberis an optional positive number of required services >> serviceName is the name of a service interface >> serviceFilter is a service filter according to 3.2.6, Filter Syntax >> >> The system status service itself : >> >>* requires the ConfigAdmin service to be present >>* registers as a ManagedService to receive the configuration >> >> Thats basically all. Very simple, very lean. > > I still hae my problem with storing the config in the config admin. > 1) How does it get there? Yes, this is the paramount question of all: How will default setup go anywhere. It does not matter where we get the setup from. It always amounts to the question: How to get it there ? > 2) What happens between the time when a) the main servlet and the config > admin are started but the config from 1) isn't there? Maybe there is some default config provided from a system deployer installed by various means such as * a BundleActivator setting the config * Deployment Admin auto conf * JCR Install configuration Notably the two latter options let the deployer control the configuration. Regards Felix
Re: SLING-490, SystemStatus service discussion
Hi, Carsten Ziegeler schrieb: > Felix Meschberger wrote: > >> Yes, of course. ConfigAdmin is *not* required for DS. > Ah yes, you're right (of course) - I was mistaken as the import for the > config admin are not optional in the *pom* of the scr implementation; I > didn't see that it actually exports and imports them. :) Well, it imports the service API but this is different from the service instance being present in the framework ;-) Regard Felix
Re: SLING-490, SystemStatus service discussion
Hi, Replying to this message, but my response applies to the complete thread. Let's step back a second and look at what we really need to know to be able to decide the system is ready or not. And who is responsible to provide this knowledge. (1) The most basic criterion for the system to be ready is the available of certain services. (2) There must be away to specify which services are required. Now, this is very simple and easy: As Alex Klimetschek proposes we are using ConfigurationAdmin for this. Each service can be described by a few properties: (a) Service Name (b) Service Filter (c) Number of services The configuration of required services is a multivalued string property of the format [ number ] ( serviceName | serviceFilter ) where numberis an optional positive number of required services serviceName is the name of a service interface serviceFilter is a service filter according to 3.2.6, Filter Syntax The system status service itself : * requires the ConfigAdmin service to be present * registers as a ManagedService to receive the configuration Thats basically all. Very simple, very lean. Regards Felix Bertrand Delacretaz schrieb: > Hi, > > Felix and Carsten made some comments in SLING-490 that are probably > worth discussing here. > > Here's how I view this service, comments are welcome. > > 1. The goal is to return a 503 status until the system is ready to > process requests. > > 2. Defining readyness is hard due to the dynamic nature of OSGi and > especially Declarative Services. My idea is to use scripts found under > /system/sling/status in the JCR repository to let programmers define > what they require for their system to be ready. > > 3. If it finds an *.foo script there, the default SystemStatus service > will complain if no script engine is found to execute *.foo scripts. > This avoids problems with requests coming in while the required script > engines are not started yet. > > 4. Currently, a SystemStatus service is required for the > SlingMainServlet to operate. I'm not sure how to avoid this coupling - > if the SystemStatus service is made optional and a request comes in > before it is started, the SlingMainServlet might erroneously think the > system is ready. > > 5. As the default SystemStatus implementation uses scripts, it is not > practical to make it a part of the engine bundle, which has no > dependency to script engines at the moment. Hence the separate bundle. > > I'm happy to rediscuss this if needed, but I think giving a > customizable server-side way for people to "compute" the readyness of > their Sling system is a must. > > -Bertrand >
Re: SLING-490, SystemStatus service discussion
HI, Alexander Klimetschek schrieb: > On Mon, Jun 15, 2009 at 5:10 PM, Carsten Ziegeler wrote: >> Now, this depends on how this is done. We're using the declarative >> services in Sling, so when DS is starting the sling main servlet it >> checks for a configuration to provide it to the service. If it is there, >> fine. >> However at this point of time, the ConfigAdmin service might not have >> been startet yet > > Really? Other services are started albeit the presence of the > (non-started) ConfigAdmin? That means services are started and then > stopped again once the configadmin is running and they get restarted > with their configuration? Yes, of course. ConfigAdmin is *not* required for DS. But if configuration becomes available the components have to be restarted. This is how is defined. Startlevels has nothing to do with this. > > Isn't it possible to avoid that case with start levels? (we are > talking about the initial startup only, if the configadmin goes away > later, no problem, the system ready state should IMHO never switch > from true to false as it is only for the startup) This is of course wrong. *If* we have a system status service, this is used throughout the lifetime of the system. That is it may happen that the system becomes unavailable if something is going away. Just to have a status mechanism for startup makes no sense. Regards Felix > >> , or if for example the configuration is "installed" >> using jcrinstall, jcr install might kick in later, pass the config to >> the config admin and then the servlet is restarted with the config. > > Does jcr install re-set all the values on startup? I thought it would > behave like this: > > 1) system running, no system-ready config present > 2) configure system-ready service via a config node in JCR > 3) system-ready service is restarted, config is applied and config is > persisted by Apache Felix > 3) this has no effect on the running system (system-ready is already > "true", needs a global state variable) > 4) restart > 5) SlingMainServlet / system-ready service are started with the > persisted config (here we have a list of deps to check), system-ready > = false > 6) waits for the deps to be running > 7) finally after some time, system-ready = true > >> Therefore there might be a time, where the servlet is active without >> having the config you want it to have. >> Of course, you can handle this case by taking care of it - which is with >> DS a little bit difficult or...as soon as DS 1.1 is available (which >> should be very shortly), you have the possibility to require a service >> to have a configuration stored in ConfigAdmin. > > Sounds like a good feature to me. > >> So the sling main servlet >> would not start without it. However obviously this has another draw back >> as someone has to take care that the config is there. >> >> Therefore, the easiest thing for me seems to be the sling properties. >> They're guaranteed to be delivered to the sling main servlet as soon as >> the service can be started. And the props do not change over time. > > Would be working as well, but they are not so easy to find, modify and deploy. > > Regards, > Alex >
[jira] Commented: (SLING-1007) Implement helper classloader
[ https://issues.apache.org/jira/browse/SLING-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719530#action_12719530 ] Felix Meschberger commented on SLING-1007: -- > Take a look at the JSP compiler then. It has exactly the same problem. Maybe yes, when looking from inside. But since we are using Jasper (with slight modifications) we don't have an issue there. > Implement helper classloader > > > Key: SLING-1007 > URL: https://issues.apache.org/jira/browse/SLING-1007 > Project: Sling > Issue Type: New Feature > Components: Commons OSGi >Affects Versions: Commons OSGi 2.0.4 >Reporter: Felix Meschberger > > Currently we require the ScriptEngine[Factory] implementation bundles to > create bundle header >DynamicImport-Package: * > to be able to access anything from the scripts since scripts are executed in > the class loader of the script engine bundle. > The downside of running the scripts in the class loader of the script engine > bundle and using this global dynamic import are: > * scripts see internal classes of the script engine bundle > * scripts engine bundles must provide for classes for the scripts > * whenever a wire has been created for a script and the providing bundle is > updated or uninstalled, the script engine bundle is also cycled. > A better approach might be to provide a ClassLoader implementation which > behind the scenes manages access to packages exported by the bundles > installed in the system. I would imagine such an implementation along the > following lines: > * Uses PackageAdmin to find a bundle providing the required class > * Copes with bundles being updated or uninstalled > Maybe coping with bundles being updated or uninstalled requires a two level > approach: a fronend class loader which answers the class and resource > accesses by relaying to a backend class loader. The back end classloader does > the hardwork of loading classes and resources by querying bundles. Whenever a > bundle is updated or uninstalled the backend classloader gets replaced. A > similar approach has been chosen for the Repository ClassLoader in the > jcr/classloader bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1007) Implement helper classloader
[ https://issues.apache.org/jira/browse/SLING-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719509#action_12719509 ] Felix Meschberger commented on SLING-1007: -- As I said before this is not a primary issue for now (the only scripting language I know of with similar problems is Scala). For this concrete issue, it is completely out of scope and should not be considered right now. If we later think we have to broaden the issue/solution, we still can do that. For now a "simple" classloader is what we need. > Implement helper classloader > > > Key: SLING-1007 > URL: https://issues.apache.org/jira/browse/SLING-1007 > Project: Sling > Issue Type: New Feature > Components: Commons OSGi >Affects Versions: Commons OSGi 2.0.4 >Reporter: Felix Meschberger > > Currently we require the ScriptEngine[Factory] implementation bundles to > create bundle header >DynamicImport-Package: * > to be able to access anything from the scripts since scripts are executed in > the class loader of the script engine bundle. > The downside of running the scripts in the class loader of the script engine > bundle and using this global dynamic import are: > * scripts see internal classes of the script engine bundle > * scripts engine bundles must provide for classes for the scripts > * whenever a wire has been created for a script and the providing bundle is > updated or uninstalled, the script engine bundle is also cycled. > A better approach might be to provide a ClassLoader implementation which > behind the scenes manages access to packages exported by the bundles > installed in the system. I would imagine such an implementation along the > following lines: > * Uses PackageAdmin to find a bundle providing the required class > * Copes with bundles being updated or uninstalled > Maybe coping with bundles being updated or uninstalled requires a two level > approach: a fronend class loader which answers the class and resource > accesses by relaying to a backend class loader. The back end classloader does > the hardwork of loading classes and resources by querying bundles. Whenever a > bundle is updated or uninstalled the backend classloader gets replaced. A > similar approach has been chosen for the Repository ClassLoader in the > jcr/classloader bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1007) Implement helper classloader
Implement helper classloader Key: SLING-1007 URL: https://issues.apache.org/jira/browse/SLING-1007 Project: Sling Issue Type: New Feature Components: Commons OSGi Affects Versions: Commons OSGi 2.0.4 Reporter: Felix Meschberger Currently we require the ScriptEngine[Factory] implementation bundles to create bundle header DynamicImport-Package: * to be able to access anything from the scripts since scripts are executed in the class loader of the script engine bundle. The downside of running the scripts in the class loader of the script engine bundle and using this global dynamic import are: * scripts see internal classes of the script engine bundle * scripts engine bundles must provide for classes for the scripts * whenever a wire has been created for a script and the providing bundle is updated or uninstalled, the script engine bundle is also cycled. A better approach might be to provide a ClassLoader implementation which behind the scenes manages access to packages exported by the bundles installed in the system. I would imagine such an implementation along the following lines: * Uses PackageAdmin to find a bundle providing the required class * Copes with bundles being updated or uninstalled Maybe coping with bundles being updated or uninstalled requires a two level approach: a fronend class loader which answers the class and resource accesses by relaying to a backend class loader. The back end classloader does the hardwork of loading classes and resources by querying bundles. Whenever a bundle is updated or uninstalled the backend classloader gets replaced. A similar approach has been chosen for the Repository ClassLoader in the jcr/classloader bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Make our first release available on central Maven repo? (was: Problems with dependency paths)
Hi, The artifacts of the first Sling release are now also available through central. Regards Felix Bertrand Delacretaz schrieb: > Hi Ian, > > On Thu, Jun 11, 2009 at 11:59 PM, Ian Boston wrote: >> ...I have a jar that depends on >> org.apache.sling:org.apache.sling.engine:jar:2.0.4-incubator, which since >> its released I think is a "reasonable" thing to do... > > Of course. > >> . But if you clean out >> your maven repo (rm -rf ~/.m2/repository/org/apache/sling ) and build you >> find the build fails with a dependency path of: >> ... >>5) org.apache.sling:org.apache.sling.commons.osgi:jar:2.0.2-incubator >> >> and no 5 doesnt exist in the repo. see [1] >> >> There is a simple solution to this, force the versions of those releases >> that are missing to versions that are not, but that a) feels dangerous and >> b) creates a maintenance headache >> >> >> A quick scan of the repo1 looks like *all* the 202 versions have gone >> missing from the repo, perhaps they were never there ? > > That's correct, the artifacts of the first Sling release are in > > http://people.apache.org/repo/m2-incubating-repository/org/apache/sling/org.apache.sling.commons.osgi/ > > for example, so currently you need to add that repository to your > setup, as described in > http://incubator.apache.org/sling/site/getting-and-building-sling.html > > Now, considering that since our first release the incubator voted [2] > to allow podlings to deploy to the main Maven repository, I think we > should make the whole > http://people.apache.org/repo/m2-incubating-repository/org/apache/sling/ > available on repo1.maven.org. What do people think? And how do we do > that, is there a way to copy the whole thing at once? > > -Bertrand > >> [1] >> http://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.commons.osgi/ > > [2] https://issues.apache.org/jira/browse/INCUBATOR-82 >
[jira] Commented: (SLING-490) SlingStatusServlet - find out whether a Sling application is ready after startup
[
https://issues.apache.org/jira/browse/SLING-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719166#action_12719166
]
Felix Meschberger commented on SLING-490:
-
> It's no big deal to have to add the systemstatus bundle to existing setups,
> and the error message ("No SystemStatus service available") is clear enough
> to indicate the problem.
The message "No SystemStatus service available" is IMHO not very clear to the
casual end user: "what is the SystemStatus service for any way ?" ... A better
message would probably be something like "Unable to handle requests. System
status is unknown due to missing SystemStatus service."
> The idea is that /system/sling/status returns a plain text page with details
> about the current
> status, as reported by the status scripts found under /system/sling/status in
> the repository.
Hmm, the "status scripts" may not be available for execution if they depend on
any scripting language not yet available.
> This info could also be made available in a console plugin, is that what you
> mean?
That's what I mean.
The problem with the special treatment of the path is that (1) it is special
treatment (which I disgust from the bottom of my heart) and (2) it triggers the
doGet method no matter what HTTP request method has been used.
> SlingStatusServlet - find out whether a Sling application is ready after
> startup
>
>
> Key: SLING-490
> URL: https://issues.apache.org/jira/browse/SLING-490
> Project: Sling
> Issue Type: Improvement
> Components: Engine
>Reporter: Bertrand Delacretaz
>Priority: Minor
>
> Being discussed in http://markmail.org/message/jtdnqneoudxbmb6k
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: JSONQueryServlet questions
I have committed a fix in Rev. 784278. You might want to update the servlets/get bundle and crosscheck. Thanks. Regards Felix Felix Meschberger schrieb: > Hi Stuart, > > After re-reading the JsonQueryServlet, I saw the bug. It is not related > to any JCR query stuff but to how we add properties to the result as per > the property parameters. This is done by only accessing the property > value as a single value which fails for multi-value properties ... > > I created SLING-1006 [1] to track this and will commit a fix shortly. > > Do you still need the full node dump functionality ? > > Regards > Felix > > [1] https://issues.apache.org/jira/browse/SLING-1006 > > D. Stuart Freeman schrieb: >> On Fri, Jun 12, 2009 at 08:18:01PM +0200, Felix Meschberger wrote: >>> Hi Stuart, >>> >>> >>> D. Stuart Freeman schrieb: >>>> I'm trying to get back a multivalued property from the JSON Query >>>> Servlet, but it appears that that doesn't work. Here's what I did: >>>> >>>> curl -Ftitle="some title text" -Ftext="some body text content" \ >>>> -Ftest="1" -Ftest="2" http://admin:ad...@localhost:8080/some/new/content >>>> >>>> That posts successfully, and I can view it at >>>> http://localhost:8080/some/new/content.json and see that test is >>>> ["1","2"]. If I try to find it with JQS though at >>>> http://localhost:8080/some.query.json?queryType=xpath&statement=/jcr:root/some/new/*&property=title&property=test >>>> >>>> The title property is correctly displayed, but test is shown as "". Is >>>> this a known issue, or should I open a Jira? >>> This is a fundamental problem of JCR Query: Multi-value properties are >>> not returned in the Query rows. There is nothing Sling can do about it, >>> unfortunately. >>> >>> >>>> Also, is there a way to request that the JQS return all defined >>>> properties on a node? >>> Using the JsonQuery servlet you list explicitly the properties, which >>> you want to get back. This servlet cannot return all properties of a >>> node, right now. >>> >>> I could imagine though, that we could provide an enhancement of the >>> JsonQueryServlet, which would return the contents of the QueryResult >>> rows but the contents of the nodes matching the query. >>> >>> This would also allow you to get back the multi-value properties, since >>> those values would be access through the matching node directly. >>> >>> WDYT ? >> That sounds like exactly what I would need. >> >>> Regards >>> Felix >
[jira] Resolved: (SLING-1006) JsonQueryServlet does not return multi-value properties
[ https://issues.apache.org/jira/browse/SLING-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1006. -- Resolution: Fixed I have committed a fix in Rev. 784278. The JsonQueryServlet now uses the ValueMap adapter of the node resource to access the properties instead of requesting a separate resoure for each required property from the resource resolver. In addition it correctly handles mult-value properties. Keeping open until feedback from the reporter on the list. > JsonQueryServlet does not return multi-value properties > --- > > Key: SLING-1006 > URL: https://issues.apache.org/jira/browse/SLING-1006 > Project: Sling > Issue Type: Bug > Components: Servlets Get >Affects Versions: Servlets Get 2.0.4 > Reporter: Felix Meschberger > Assignee: Felix Meschberger > Fix For: Servlets Get 2.0.6 > > > From the mailing list: > I'm trying to get back a multivalued property from the JSON Query Servlet, > but it appears that that doesn't work. Here's what I did: >curl -Ftitle="some title text" -Ftext="some body text content" \ > -Ftest="1" -Ftest="2" > http://admin:ad...@localhost:8080/some/new/content > That posts successfully, and I can view it at > http://localhost:8080/some/new/content.json and see that test is ["1","2"]. > If I try to find it with JQS though at > > http://localhost:8080/some.query.json?queryType=xpath&statement=/jcr:root/some/new/*&property=title&property=test > The title property is correctly displayed, but test is shown as "". Is this > a known issue, or should I open a Jira? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JSONQueryServlet questions
Hi Stuart, After re-reading the JsonQueryServlet, I saw the bug. It is not related to any JCR query stuff but to how we add properties to the result as per the property parameters. This is done by only accessing the property value as a single value which fails for multi-value properties ... I created SLING-1006 [1] to track this and will commit a fix shortly. Do you still need the full node dump functionality ? Regards Felix [1] https://issues.apache.org/jira/browse/SLING-1006 D. Stuart Freeman schrieb: > On Fri, Jun 12, 2009 at 08:18:01PM +0200, Felix Meschberger wrote: >> Hi Stuart, >> >> >> D. Stuart Freeman schrieb: >>> I'm trying to get back a multivalued property from the JSON Query >>> Servlet, but it appears that that doesn't work. Here's what I did: >>> >>> curl -Ftitle="some title text" -Ftext="some body text content" \ >>> -Ftest="1" -Ftest="2" http://admin:ad...@localhost:8080/some/new/content >>> >>> That posts successfully, and I can view it at >>> http://localhost:8080/some/new/content.json and see that test is >>> ["1","2"]. If I try to find it with JQS though at >>> http://localhost:8080/some.query.json?queryType=xpath&statement=/jcr:root/some/new/*&property=title&property=test >>> >>> The title property is correctly displayed, but test is shown as "". Is >>> this a known issue, or should I open a Jira? >> This is a fundamental problem of JCR Query: Multi-value properties are >> not returned in the Query rows. There is nothing Sling can do about it, >> unfortunately. >> >> >>> Also, is there a way to request that the JQS return all defined >>> properties on a node? >> Using the JsonQuery servlet you list explicitly the properties, which >> you want to get back. This servlet cannot return all properties of a >> node, right now. >> >> I could imagine though, that we could provide an enhancement of the >> JsonQueryServlet, which would return the contents of the QueryResult >> rows but the contents of the nodes matching the query. >> >> This would also allow you to get back the multi-value properties, since >> those values would be access through the matching node directly. >> >> WDYT ? > > That sounds like exactly what I would need. > >> Regards >> Felix >
[jira] Created: (SLING-1006) JsonQueryServlet does not return multi-value properties
JsonQueryServlet does not return multi-value properties --- Key: SLING-1006 URL: https://issues.apache.org/jira/browse/SLING-1006 Project: Sling Issue Type: Bug Components: Servlets Get Affects Versions: Servlets Get 2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Servlets Get 2.0.6 >From the mailing list: I'm trying to get back a multivalued property from the JSON Query Servlet, but it appears that that doesn't work. Here's what I did: curl -Ftitle="some title text" -Ftext="some body text content" \ -Ftest="1" -Ftest="2" http://admin:ad...@localhost:8080/some/new/content That posts successfully, and I can view it at http://localhost:8080/some/new/content.json and see that test is ["1","2"]. If I try to find it with JQS though at http://localhost:8080/some.query.json?queryType=xpath&statement=/jcr:root/some/new/*&property=title&property=test The title property is correctly displayed, but test is shown as "". Is this a known issue, or should I open a Jira? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JSONQueryServlet questions
Hi Stuart, D. Stuart Freeman schrieb: > I'm trying to get back a multivalued property from the JSON Query > Servlet, but it appears that that doesn't work. Here's what I did: > > curl -Ftitle="some title text" -Ftext="some body text content" \ > -Ftest="1" -Ftest="2" http://admin:ad...@localhost:8080/some/new/content > > That posts successfully, and I can view it at > http://localhost:8080/some/new/content.json and see that test is > ["1","2"]. If I try to find it with JQS though at > http://localhost:8080/some.query.json?queryType=xpath&statement=/jcr:root/some/new/*&property=title&property=test > > The title property is correctly displayed, but test is shown as "". Is > this a known issue, or should I open a Jira? This is a fundamental problem of JCR Query: Multi-value properties are not returned in the Query rows. There is nothing Sling can do about it, unfortunately. > > Also, is there a way to request that the JQS return all defined > properties on a node? Using the JsonQuery servlet you list explicitly the properties, which you want to get back. This servlet cannot return all properties of a node, right now. I could imagine though, that we could provide an enhancement of the JsonQueryServlet, which would return the contents of the QueryResult rows but the contents of the nodes matching the query. This would also allow you to get back the multi-value properties, since those values would be access through the matching node directly. WDYT ? Regards Felix
Versions of new modules
Hi all, It seems to be custom to add new modules with versions like 2.0.5-incubator-SNAPSHOT. I think this is not very sexy and might even be misleading. I suggest we add new modules at version 0.9.0-incubator-SNAPSHOT such that we can release the first version as 1.0.0-incubator. Historical background for our 2.x versions: Apache Sling started as an internal project inside Day which we internally release as 1.0. When Sling came into the incubator, we raised the version numbers to 2.0.0-incubator-SNAPSHOT to clearly distinguish against our internal Sling. WDYT ? Regards Felix
[jira] Commented: (SLING-490) SlingStatusServlet - find out whether a Sling application is ready after startup
[ https://issues.apache.org/jira/browse/SLING-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718923#action_12718923 ] Felix Meschberger commented on SLING-490: - Thanks for taking a stab at this. Here are some comments: * I would suggest we set the initial version to 0.9.0-incubator-SNAPSHOT * For compatibility reason, I would suggest to just ignore system status if no SystemStatus service is registered * I don't like interface methods with "throws Exception" signature, I suggest to define the method such as to return a status info why the service considers the system not ready, this might be something like a string or more elaborate. At least the signature should define an explicit, publicly available exception to be thrown. * I would register the extension/systemstatus as a web console plugin to provide end user status info. The current approach is too static. Alternatively the status information could be registered as a normal Sling servlet, though this will of course not be available if Sling is not ready > SlingStatusServlet - find out whether a Sling application is ready after > startup > > > Key: SLING-490 > URL: https://issues.apache.org/jira/browse/SLING-490 > Project: Sling > Issue Type: Improvement > Components: Engine >Reporter: Bertrand Delacretaz >Priority: Minor > > Being discussed in http://markmail.org/message/jtdnqneoudxbmb6k -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1005) JcrResourceResolver2.map should consider request path info for mapping
[ https://issues.apache.org/jira/browse/SLING-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718864#action_12718864 ] Felix Meschberger commented on SLING-1005: -- Fixed this as described above in Rev. 784146. Actually now also handling of existing and non-existing resource path is equal in that in both cases the resource path info is included in the mapping decisions. Keeping this issue open to also create unit tests for this problem. > JcrResourceResolver2.map should consider request path info for mapping > -- > > Key: SLING-1005 > URL: https://issues.apache.org/jira/browse/SLING-1005 > Project: Sling > Issue Type: Bug > Components: JCR Resource >Affects Versions: JCR Resource 2.0.4 > Reporter: Felix Meschberger > Assignee: Felix Meschberger > Fix For: JCR Resource 2.0.6 > > > The currently the JcrResourceResolver2.map method applies the following basic > algorithm for reverse mapping a resource path: >* Resolve resource cutting of resource path info. E.g. /content/page.html > would give a resource /content/page and resource path info .html >* Resolve alias names of the resource (if any) >* Apply mapping on the resource >* Append resource path Info > This is probably wrong, since any incoming mapping / --> /content/page.html > would not be revers mapped from /content/page.html to / due to the resource > path info not bein appended after resolve the resource and alias names. > The fix is to append the resource path info *before* applying the mappings. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1005) JcrResourceResolver2.map should consider request path info for mapping
JcrResourceResolver2.map should consider request path info for mapping -- Key: SLING-1005 URL: https://issues.apache.org/jira/browse/SLING-1005 Project: Sling Issue Type: Bug Components: JCR Resource Affects Versions: JCR Resource 2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: JCR Resource 2.0.6 The currently the JcrResourceResolver2.map method applies the following basic algorithm for reverse mapping a resource path: * Resolve resource cutting of resource path info. E.g. /content/page.html would give a resource /content/page and resource path info .html * Resolve alias names of the resource (if any) * Apply mapping on the resource * Append resource path Info This is probably wrong, since any incoming mapping / --> /content/page.html would not be revers mapped from /content/page.html to / due to the resource path info not bein appended after resolve the resource and alias names. The fix is to append the resource path info *before* applying the mappings. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Integrate a Servlet Filter: init-params
Hi, Christian Sprecher schrieb: > Felix Meschberger schrieb: >> Hi, >> Yes. And if you have the scr plugin generate the Metatype data (not >> setting metatype="no" on the @scr.component tag) you will be able to >> configure the properties on the Configuration page of the Web Console. >> >> > Wow, it works. This is pretty dramatic, imho. Changing a property even > automatically calls the init() method. Superb! Yeah ;-) >>> This live-configuration possibility sounds superb for my use case: I am >>> trying to integrate WebCastellum (http://www.webcastellum.org) with >>> Sling. WebCastellum is a web application firewall implemented as filter. >>> This WAF is configured via init-param. The possibilty to configure that >>> WAF in real-time is intriguing... >>> >> >> Interesting. Would you be able to provide some description of this in >> the Wiki ? Thanks in advance. >> >> > What are you exactly interessted in: the possibility to integrate a 3rd > party filter into Sling, or the WAF functionality for? > I would have to factor out the usage of the maven-scr-plugin in the > first case (because I am fiddling around in the source code atm), and > for the second case I would have to get this stuped filter to run like > it should:). And then try to configure it sensibly for Sling. Both, probably and if possible ;-) Regards Felix
[jira] Resolved: (SLING-1003) Integration of 3rd party servlet filters problematic
[ https://issues.apache.org/jira/browse/SLING-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1003. -- Resolution: Fixed Fix Version/s: Engine 2.0.6 Thanks for reporting the bug. Fixed the AbstractSlingFilterChain to cope with non-SlingHttpServletRequest/Response objects in Rev. 784140. Please close this issue if this solves your problem. Thanks. > Integration of 3rd party servlet filters problematic > > > Key: SLING-1003 > URL: https://issues.apache.org/jira/browse/SLING-1003 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.0.4 > Environment: Windows Vista, > java version "1.6.0_13" > Java(TM) SE Runtime Environment (build 1.6.0_13-b03) > Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing) >Reporter: Christian Sprecher >Assignee: Felix Meschberger >Priority: Minor > Fix For: Engine 2.0.6 > > > There is a problem within the chain handling: the 3rd party filter uses it's > own wrapper for requests and response, and supplies it to the chain in the > chain.doFilter() call. This leads to a ClassCastException on line 54 of > AbstractSlingFilterChain: > ... >RequestProgressTracker tracker = ((SlingHttpServletRequest) > request).getRequestProgressTracker(); > ... > I am not sure if this cast is valid in the context of a filter chain. On the > other hand I am not sure wether such a use case (filter that manipulates > request and response) has a chance to run in Sling. > ==> Please note that this servlet filter needs to run as early as possible in > the filter chain > java.lang.ClassCastException: org.webcastellum.RequestWrapper cannot be cast > to > org.apache.sling.api.SlingHttpServletRequest >at > org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter > (AbstractSlingFilterChain.java:54) >at > org.webcastellum.WebCastellumFilter.internalDoFilter(WebCastellumFilt > er.java:2610) >at > org.webcastellum.WebCastellumFilter.doFilter(WebCastellumFilter.java: > 1710) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1003) Integration of 3rd party servlet filters problematic
[ https://issues.apache.org/jira/browse/SLING-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-1003: Assignee: Felix Meschberger > Integration of 3rd party servlet filters problematic > > > Key: SLING-1003 > URL: https://issues.apache.org/jira/browse/SLING-1003 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.0.4 > Environment: Windows Vista, > java version "1.6.0_13" > Java(TM) SE Runtime Environment (build 1.6.0_13-b03) > Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing) >Reporter: Christian Sprecher >Assignee: Felix Meschberger >Priority: Minor > > There is a problem within the chain handling: the 3rd party filter uses it's > own wrapper for requests and response, and supplies it to the chain in the > chain.doFilter() call. This leads to a ClassCastException on line 54 of > AbstractSlingFilterChain: > ... >RequestProgressTracker tracker = ((SlingHttpServletRequest) > request).getRequestProgressTracker(); > ... > I am not sure if this cast is valid in the context of a filter chain. On the > other hand I am not sure wether such a use case (filter that manipulates > request and response) has a chance to run in Sling. > ==> Please note that this servlet filter needs to run as early as possible in > the filter chain > java.lang.ClassCastException: org.webcastellum.RequestWrapper cannot be cast > to > org.apache.sling.api.SlingHttpServletRequest >at > org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter > (AbstractSlingFilterChain.java:54) >at > org.webcastellum.WebCastellumFilter.internalDoFilter(WebCastellumFilt > er.java:2610) >at > org.webcastellum.WebCastellumFilter.doFilter(WebCastellumFilter.java: > 1710) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling configuration
Thanks for reporting. I added the findings of the mail thread as implementation notes. Regards Felix Claude Vedovini schrieb: > Salut B. > > Just created SLING-1004 > I did not bother reading any guideline for issue creation but I hope > you'll like it :) > > Cheers, > Claude > > > On Thu, Jun 11, 2009 at 2:36 PM, Bertrand > Delacretaz wrote: >> Salut Claude, >> >> On Thu, Jun 11, 2009 at 2:07 PM, Claude >> Vedovini wrote: >>> ...Should I (can I) open a JIRA issue for this?.. >> yes please - the sling.home.prefix way seems to be the best, as Felix >> suggests in his last message here. >> >> -Bertrand >> >
[jira] Commented: (SLING-1004) The folder where Sling servlets store their configuration should be configurable at deployment
[
https://issues.apache.org/jira/browse/SLING-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718849#action_12718849
]
Felix Meschberger commented on SLING-1004:
--
Actually, the default Sling web app does *not* configure the sling.home
property in the web.xml and thus uses the default which is
"sling/" + ServletContext.getContextPath().replace('/', '_')
We agreed on the list to introduce support for a new system property
sling.home.prefix for the Sling web application such that the default
sling.home property is defined as
System.getProperty(sling.home.prefix) + "/" +
ServletContext.getContextPath().replace('/', '_')
The sling.home.prefix will only be looked up in the system properties and will
only be supported by the Sling Web app. The default value of the
sling.home.prefix property is "sling" for backwards compatibility.
> The folder where Sling servlets store their configuration should be
> configurable at deployment
> --
>
> Key: SLING-1004
> URL: https://issues.apache.org/jira/browse/SLING-1004
> Project: Sling
> Issue Type: Improvement
>Affects Versions: Launchpad Webapp 5
>Reporter: Claude Vedovini
>
> Integrating Sling as an external off-the-shelf component should be made as
> simple as possible, especially in web containers.
> Today, when using the launchpad webapp, to configure the folder where Sling
> servlets will store their configuration, one as to open the war, change a
> file (either sling.properties or web.xml) and repack.
> This is impractical for the following reasons:
> - it prevents Sling webapp war to be upgraded by simply replacing the war
> - it places the responsibility of the environment configuration solely on the
> development team whereas in some organization this is the responsibility of
> another team
> - it does not enable easy change of the configuration to follow environmental
> constraints (eg. Windows/*nix)
> See this mailing-list thread for further information, discussion and
> suggested solutions:
> http://mail-archives.apache.org/mod_mbox/incubator-sling-dev/200906.mbox/browser
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Sling Artifacts from incubator repository
Hi all, In the incubating Sling project we deployed the initial release to the incubator maven 2 repository instead of the central mirror as it was custom until a few months ago. Now that we use repository.a.o it would be cool and good for our users to have the artifacts available from repository.a.o, too. Would it be possible to copy those over from the incubator repository to repository.a.o ? Do you need a JIRA or would you be able to do it as a corollary to INFRA-2081 ? [2] Thanks and Regards Felix On behalf of the Sling project [1]http://people.apache.org/repo/m2-incubating-repository/org/apache/sling [2]https://issues.apache.org/jira/browse/INFRA-2081
Re: Make our first release available on central Maven repo? (was: Problems with dependency paths)
Hi, Jukka Zitting schrieb: > Hi, > > On Fri, Jun 12, 2009 at 8:46 AM, Felix Meschberger wrote: >> My first try to would be to checkout the Sling 3 tag and deploy it to >> repository.apache.org setting the altDeploymentRepository property >> appropriately. > > I'd rather not do that, as then we'd have separate copies of the same > artifacts with different checksums and signatures. Yeah, right. Thanks for the reminder. > > We could ask the people at reposit...@apache.org to copy the existing > artifacts from p.a.o to r.a.o. Will do that. Regards Felix
Re: Make our first release available on central Maven repo? (was: Problems with dependency paths)
Hi, Yes at the time of our first release poddlings had to deploy to the incubator repository at http://people.apache.org/repo/m2-incubating-repository And, yes, I agree we should probably deploy this to central, now. Central being managed through the Nexus repository nowadays, it would probably be easiest to see how to deploy to there. My first try to would be to checkout the Sling 3 tag and deploy it to repository.apache.org setting the altDeploymentRepository property appropriately. Carsten, would that be correct ? Regards Felix Bertrand Delacretaz schrieb: > Hi Ian, > > On Thu, Jun 11, 2009 at 11:59 PM, Ian Boston wrote: >> ...I have a jar that depends on >> org.apache.sling:org.apache.sling.engine:jar:2.0.4-incubator, which since >> its released I think is a "reasonable" thing to do... > > Of course. > >> . But if you clean out >> your maven repo (rm -rf ~/.m2/repository/org/apache/sling ) and build you >> find the build fails with a dependency path of: >> ... >>5) org.apache.sling:org.apache.sling.commons.osgi:jar:2.0.2-incubator >> >> and no 5 doesnt exist in the repo. see [1] >> >> There is a simple solution to this, force the versions of those releases >> that are missing to versions that are not, but that a) feels dangerous and >> b) creates a maintenance headache >> >> >> A quick scan of the repo1 looks like *all* the 202 versions have gone >> missing from the repo, perhaps they were never there ? > > That's correct, the artifacts of the first Sling release are in > > http://people.apache.org/repo/m2-incubating-repository/org/apache/sling/org.apache.sling.commons.osgi/ > > for example, so currently you need to add that repository to your > setup, as described in > http://incubator.apache.org/sling/site/getting-and-building-sling.html > > Now, considering that since our first release the incubator voted [2] > to allow podlings to deploy to the main Maven repository, I think we > should make the whole > http://people.apache.org/repo/m2-incubating-repository/org/apache/sling/ > available on repo1.maven.org. What do people think? And how do we do > that, is there a way to copy the whole thing at once? > > -Bertrand > >> [1] >> http://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.commons.osgi/ > > [2] https://issues.apache.org/jira/browse/INCUBATOR-82 >
Re: Caching for ResourceResolver.map()
Jukka Zitting schrieb:
> Hi,
>
> On Wed, Jun 10, 2009 at 3:10 PM, Carsten Ziegeler wrote:
>> While caching in the resource resolver might be a good idea anyway,
>> perhaps caching one layer above might give even more benefit. Instead
>> of querying the resource resolver a lot, caching above the resolver
>> would even avoid querying the resolver.
>
> This turns out to be the best approach in my case. Especially since a
> new ResourceResolver gets instantiated for each new request, which
> makes it more difficult to add global caching.
Not sure, whether it really is the best approach. Though it is true,
that the ResourceResolver instance is created on each request, it is
still created from the JcrResourceResolverFactory, which might as well
be the holder of the cache and provide the user-specific subset of the
cache to the per-request-ResourceResolver.
>
> However, since the resolution process depends on access rights, I
> currently need to do something like this to include the potential
> username in the cache key:
>
> String user = "";
> Session session = resourceResolver.adaptTo(Session.class);
> if (session != null) {
> user = session.getUserId();
> }
>
> This seems a bit fragile, so I was wondering if getting the username
> from the request would work better:
>
> String user = "";
> Principal principal = request.getUserPrincipal();
> if (principal != null) {
> user = principal.getName();
> }
>
> I guess there are cases where the JCR Session (or whatever is used for
> resource resolution) is authenticated using something else than the
> user principal associated with the HTTP request.
You might want to use request.getRemoteUser(), which is backed by
Session.getUserId().
>
> Ultimately we should probably solve the performance issue on the
> repository layer by making path lookups (especially negative ones)
> blazingly fast. They're already pretty good in Jackrabbit, but for my
> use case I'd need about an order of magnitude more performance. With a
> simple high-level cache I was able to achieve this.
oh yeah ;-)
Regards
Felix
Re: launchpad app Snapshot
Hi Ian, Ian Boston schrieb: > Hi, > Looking at [1] there is no > > org.apache.sling:org.apache.sling.launchpad.base:jar:app:2.0.5-incubator-SNAPSHOT > > > but looking at [2] there is > > org.apache.sling:org.apache.sling.launchpad.base:jar:app:2.0.4-incubator It looks like Hudson is not deploying any artifact attachements. That is of course not good, since then all attached source artifacts are also missing. I cannot tell, how Hudson is deploying artifacts, obviously the build definition does not cause a deployment. Maybe Bertrand or Jukka can tell ? > > NB the "app" classifier, was that intentional ? Yes. The launchpad/base module generates the jar artifact, which is the main base module, which contains the shared launcher stuff as well as the Felix framework. In addition there are two artifacts with classifiers generated: The "app" artifact contains the standalone Java Application base, which is used by launchpad/base to create standalone Sling Application by merging the "app" artifact with the bundles from launchpadd/bundles. The "webapp" artifact serves the same purpose for web applications and is the base web application to be built to the Sling web application in the launchpad/webapp module adding the launchpad/bundles. Hope this helps. Regards Felix > > Ian > > > [1] > http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.launchpad.base/2.0.5-incubator-SNAPSHOT/ > > [2] > http://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.launchpad.base/2.0.4-incubator/ > >
Re: Integrate a Servlet Filter: init-params
Hi, Christian Sprecher schrieb: > Hi Felix > > Felix Meschberger schrieb: >> >> Actually, the Sling Main Servlet initializes servlets and filters by >> calling the respective init(ServletConfig) and init(FilterConfig) >> methods. >> >> The parameters provided by the ServletConfig and/or FilterConfig (the >> traditional init-param settings) are taken from the OSGi service >> registration properties. >> >> This is actually quite interesting: For example by using declarative >> services you may have OSGi Configuration (from ConfigurationAdmin) added >> as service registration properties and thus as ServletConfig or >> FilterConfig parameters. This means you will have live-configuration >> support for such parameters ! >> >> > > Interesting indeed! Could you plz elaborate a bit? What do I have to do > to have such a servlet of filter properly configurated? Using the > scr-plugin, are all @scr.property automatically made available to the > filter? Yes. And if you have the scr plugin generate the Metatype data (not setting metatype="no" on the @scr.component tag) you will be able to configure the properties on the Configuration page of the Web Console. > > This live-configuration possibility sounds superb for my use case: I am > trying to integrate WebCastellum (http://www.webcastellum.org) with > Sling. WebCastellum is a web application firewall implemented as filter. > This WAF is configured via init-param. The possibilty to configure that > WAF in real-time is intriguing... Interesting. Would you be able to provide some description of this in the Wiki ? Thanks in advance. Regards Felix > > Cheers > > CSp >
Re: Integrate a Servlet Filter: init-params
Hi Christian, Christian Sprecher schrieb: > Ok, I am a step further with the integration: I still have to find out > about the dynamic providing of init-params, but I do see that the > filterConfig is there & populated with the @scr.property values. Good > stuff! ;-) > > Now, there is a problem within the chain handling: the webcastellum > filter uses it's own wrapper for requests and response, and supplies it > to the chain in the chain.doFilter() call. This leads to a > ClassCastException on line 54 of AbstractSlingFilterChain: > ... >RequestProgressTracker tracker = ((SlingHttpServletRequest) > request).getRequestProgressTracker(); > ... > > I am not sure if this cast is valid in the context of a filter chain. On > the other hand I am not sure wether such a use case (filter that > manipulates request and response) has a chance to run in Sling. > > WDYT? I would say, that this is really not a good thing. The AbstractSlingFilterChain should use internal API of the Engine bundle to access the real request progress tracker. Could you please file an issue ? Thanks alot. Regards Felix > > > java.lang.ClassCastException: org.webcastellum.RequestWrapper cannot be > cast to > org.apache.sling.api.SlingHttpServletRequest >at > org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter > (AbstractSlingFilterChain.java:54) >at > org.webcastellum.WebCastellumFilter.internalDoFilter(WebCastellumFilt > er.java:2610) >at > org.webcastellum.WebCastellumFilter.doFilter(WebCastellumFilter.java: > 1710) > >
Re: Caching for ResourceResolver.map()
Hi, Jukka Zitting schrieb: > Hi, > > I have a case where we're doing lots of reverse mappings with the > ResourceResolver.map() method and all the repository accesses caused > by that are hurting performance. In general I'm not a big fan of extra > caching, but in this case it seems like the only easy way to solve the > problem. > > Would it make sense to embed such caching into JcrResourceResolver2 or > should it rather be a separate add-on layer? The former approach would > avoid complexities with the HttpServletRequest argument affecting the > caching, while the latter would make it easier to only apply the > caching in limited cases where it's truly needed (though at the cost > of the cache not being global). I think we should embed the caching rather deeply into the JcrResourceResolver2 to leverage as much globally valid cache data as possible. What we might consider is doing per-user caches to leverage access control of the repository. And while implementing a cache for the map() methods, implementing a cache for the resolve() methods would probably come in handy and almost free, since both methods internally use the same resolveInternal() method. Regards Felix
Re: Moving rewriter to contrib
Hi, Carsten Ziegeler schrieb: > Hi, > > I've added a new bundle in our whiteboard: the rewriter. > The rewriter bundle allows to rewrite the output from Sling. It is > possible to configure a pipeline (based on SAX events) which processes > the whole output. > This pipeline can be used for various use cases, like checking the links > in the content, adding stuff, using xslt to generate different output etc. > > I'm planning to move this from the whiteboard to the contrib section. > If noone objects, I'll do this in the next days. > > WDYT? Sounds like a good plan to me. Regards Felix
Re: Sling configuration
Hi Claude, Claude Vedovini schrieb: > Hi Felix, Bertrand, > > There is something I don't get :) > > Felix, in the example you gave previously, each deployed servlet adds > its own context path to the sling.home folder This is not correct. What I said is that sling.home is derieved from the prefix "sling" plus the mangled servlet context path. >> E.g. sling.home for the web app at /sling/i1 is "sling/_sling_i1". Correct. But if you set sling.home as an init-param, the default does not apply and the init-param value is used as-is. (which is another problem, if you deploy the exact same web app with the same sling.home init-param in the same container, you lost again). > > In that case, setting the sling.home at the system property level > would not do any harm. It does not because it is ignored by the Sling web app. > Anyway, if there are gotchas, this can be considered an acceptable > solution with known limitations that would be useful for people with > my kind of requirements, cannot it? The problem is that this is one of those kinds of things where it is very hard to find out whether using a system property is ok (in your case presumably) and when not (in cases where there are multiple Sling instances in the same servlet container. But then, as proposed by Bertrand: we could add a sling.home.prefix property, which would be used taken from the init-param or system property and replace the current "sling" prefix. Thus given the system poroperty sling.home.prefix is set to "/var/sling". In this case the default sling.home for the /sling/i1 web app would be "/var/sling/_sling_i1". Would such a prefix suit your needs ? Regards Felix > > Cheers, > Claude > > > On Tue, Jun 9, 2009 at 8:53 AM, Felix Meschberger wrote: >> Hi, >> >> Bertrand Delacretaz schrieb: >>> Hi, >>> >>> On Tue, Jun 9, 2009 at 8:03 AM, Felix Meschberger wrote: >>>> Claude Vedovini schrieb: >>>>> ...I guess that now that each deployed sling servlet has it's own >>>>> subfolder under sling.home to store configuration to, then may be >>>>> overriding the sling.home from the system properties could be a good >>>>> idea. >>>> Since system properties apply to the whole VM, multiple sling web >>>> applications deployed to the same servlet container would then use the >>>> same sling.home system property, which will not work >>> But if each deployed Sling servlet adds its own suffix (its context >>> path) to the base sling.home path, that would work, not? >>> >>> The best might be to allow overriding sling.home from system >>> properties (to allow people to control where that goes), yet have each >>> sling servlet add its own context path to that value to define its own >>> storage path. >> I was also thinking about such a prefix. But I would then name it >> sling.home.prefix or such to not confuse the use of sling.home as the >> actual location or just the prefix. >> >> Just using this special prefix property as from the system properties >> looks ok for me. >> >> Regards >> Felix >> >> >
[jira] Updated: (SLING-998) Request fails with HTTP ERROR 200 - Reason: OK if anonymous access is disabled
[ https://issues.apache.org/jira/browse/SLING-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-998: Fix Version/s: Extensions httpauth 2.0.6 Also marking as fixed in HTTP Authenticator since the LoginServlet has been moved from that bundle to the engine > Request fails with HTTP ERROR 200 - Reason: OK if anonymous access is disabled > -- > > Key: SLING-998 > URL: https://issues.apache.org/jira/browse/SLING-998 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.0.4 >Reporter: Bertrand Delacretaz > Fix For: Engine 2.0.6, Extensions httpauth 2.0.6 > > > See discussion in http://markmail.org/message/smbbphesab42fwnz - a request to > / with no credentials returns a page saying: > HTTP ERROR 200 > Problem accessing / Reason: > OK > If "allow anonymous access" is disabled on > /system/console/configMgr/org.apache.sling.engine.impl.auth.SlingAuthenticator -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-995) resource types for users are sling:users in some places and sling/users in others.
[ https://issues.apache.org/jira/browse/SLING-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-995. - Resolution: Fixed Fix Version/s: JCR Jackrabbit User Manager 2.0.4 Thanks for providing the patch. I applied it in Rev. 782947. Yes, I agree, that for pure resource types we should favor the slashy style. But for the script resolution it does not matter, since before using the resource type as a path, the colon is replaced by a slash anyway. This is done to support using primary node types as resource types as-is. If you consider this issue solved, please close. Thanks. > resource types for users are sling:users in some places and sling/users in > others. > -- > > Key: SLING-995 > URL: https://issues.apache.org/jira/browse/SLING-995 > Project: Sling > Issue Type: Bug >Affects Versions: JCR Jackrabbit User Manager 2.0.2 >Reporter: Ian Boston > Assignee: Felix Meschberger > Fix For: JCR Jackrabbit User Manager 2.0.4 > > Attachments: SLING-995.patch > > > I think they should be sling/users et al everywhere ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-995) resource types for users are sling:users in some places and sling/users in others.
[ https://issues.apache.org/jira/browse/SLING-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-995: --- Assignee: Felix Meschberger > resource types for users are sling:users in some places and sling/users in > others. > -- > > Key: SLING-995 > URL: https://issues.apache.org/jira/browse/SLING-995 > Project: Sling > Issue Type: Bug >Affects Versions: JCR Jackrabbit User Manager 2.0.2 >Reporter: Ian Boston > Assignee: Felix Meschberger > Attachments: SLING-995.patch > > > I think they should be sling/users et al everywhere ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Nexus Repository and Parent POM
Hi all, We are now setup to use the Nexus Repository at repository.apache.org for our releases and SNAPSHOTs. Thus we should not deploy anymore to the old locations on people.a.o. A first step supporting this new setup for us is to updated the Sling parent pom. As per SLING-917 [1] I have updated the parent pom to use the latest Apache Parent POM 6, which has much of the release setup already included (release profile, repositories). Thus our SNAPSHOT only contains the Assembly plugin in the release profile (naming only the project assembly, we don't generally need the binary assembly) and upgraded some plugins to the latest version (scr, jspc, sling, bundle, etc.) Please review the new parent POM so that we can cut a release of it sometime next week. Thanks. A consequence of using repository.a.o is also that the your local maven setup has to be slightly modified. I will update the respective page on the site. Regards Felix [1] https://issues.apache.org/jira/browse/SLING-917
[jira] Commented: (SLING-917) Use repository.apache.org for deployments
[ https://issues.apache.org/jira/browse/SLING-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717616#action_12717616 ] Felix Meschberger commented on SLING-917: - Now that we are registered on the Nexus Repository I committed a slightly modifed patch in Rev. 782915 with the following changes: * Update to Apache Parent POM 6 * Strip down and rename release profile * Remove generation of binary from Assembly Plugin config * Remove Apache Incubator Repository reference * Upgrade to latest plugin releases > Use repository.apache.org for deployments > - > > Key: SLING-917 > URL: https://issues.apache.org/jira/browse/SLING-917 > Project: Sling > Issue Type: Task > Components: General >Affects Versions: Parent 5 >Reporter: Bertrand Delacretaz > Fix For: Parent 6 > > Attachments: SLING-917.patch > > > See INFRA-1896 for getting access to repository.apache.org . > Once that's done, we'll need to configure http://vmbuild.apache.org to push > snapshots there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-985) Allow ATOM Syndication Format output
[ https://issues.apache.org/jira/browse/SLING-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-985. - Resolution: Fixed Applied my last patch. This is probably it for now. If you agree, please close this issue. > Allow ATOM Syndication Format output > > > Key: SLING-985 > URL: https://issues.apache.org/jira/browse/SLING-985 > Project: Sling > Issue Type: New Feature >Reporter: Lars Trieloff > Assignee: Felix Meschberger >Priority: Minor > Attachments: SLING-985-BundleActivator.patch, SLING-985.patch > > > Having a JSON output for Sling is quite nice, but many web applications > require RSS/Atom support these days. Having an extension module that provides > a tag library for creating Atom feeds and atom entries out of JCR nodes would > be very helpful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Integrate a Servlet Filter: init-params
Hi, Ian Boston schrieb: > You can make a filter available to a servlet managed by the > MainSlingServlet, by creating a declarative service implementing the > java.servlet.Filter Interface. Basically, you register an OSGi service for the javax.servlet.Filter interface. You do not need to use declarative services. > > eg > > RequestProgressTrackerLogFilter > > Unfortunately OSGi and the Main Sling Servlet do not directly support > so or web.xml, you have several options. Actually, the Sling Main Servlet initializes servlets and filters by calling the respective init(ServletConfig) and init(FilterConfig) methods. The parameters provided by the ServletConfig and/or FilterConfig (the traditional init-param settings) are taken from the OSGi service registration properties. This is actually quite interesting: For example by using declarative services you may have OSGi Configuration (from ConfigurationAdmin) added as service registration properties and thus as ServletConfig or FilterConfig parameters. This means you will have live-configuration support for such parameters ! Regards Felix > > provide an activate(ComponentContext context) in the servlet and it will > be invoked when the component starts, at which point you could get hold > of the OSGi configuration and create a fake context to initialize the > filter. > > --- > > If your servlet are not loaded by the MainSlingServlet then you can > always implement your own version of the same and get it to invoke your > filters manually, or possibly use the PAX Web Extender which does > understand web.xml (however I don't know if that is compatible with Sling). > > HTH > Ian > > On 8 Jun 2009, at 19:23, Christian Sprecher wrote: > >> Hi all >> >> In order to make a servlet filter available to sling, how are the the >> made available to the servlet filter? Those parameters >> are usually defined in web.xml >> >> Thx in advance > >
Re: Sling configuration
Hi, Bertrand Delacretaz schrieb: > Hi, > > On Tue, Jun 9, 2009 at 8:03 AM, Felix Meschberger wrote: >> Claude Vedovini schrieb: >>> ...I guess that now that each deployed sling servlet has it's own >>> subfolder under sling.home to store configuration to, then may be >>> overriding the sling.home from the system properties could be a good >>> idea. >> Since system properties apply to the whole VM, multiple sling web >> applications deployed to the same servlet container would then use the >> same sling.home system property, which will not work > > But if each deployed Sling servlet adds its own suffix (its context > path) to the base sling.home path, that would work, not? > > The best might be to allow overriding sling.home from system > properties (to allow people to control where that goes), yet have each > sling servlet add its own context path to that value to define its own > storage path. I was also thinking about such a prefix. But I would then name it sling.home.prefix or such to not confuse the use of sling.home as the actual location or just the prefix. Just using this special prefix property as from the system properties looks ok for me. Regards Felix
[jira] Updated: (SLING-985) Allow ATOM Syndication Format output
[ https://issues.apache.org/jira/browse/SLING-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-985: Attachment: SLING-985-BundleActivator.patch Patch implementing the Abdera instance as a ServletContext attribute managed by a BundleActivator. WDYT ? > Allow ATOM Syndication Format output > > > Key: SLING-985 > URL: https://issues.apache.org/jira/browse/SLING-985 > Project: Sling > Issue Type: New Feature >Reporter: Lars Trieloff > Assignee: Felix Meschberger >Priority: Minor > Attachments: SLING-985-BundleActivator.patch, SLING-985.patch > > > Having a JSON output for Sling is quite nice, but many web applications > require RSS/Atom support these days. Having an extension module that provides > a tag library for creating Atom feeds and atom entries out of JCR nodes would > be very helpful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-985) Allow ATOM Syndication Format output
[ https://issues.apache.org/jira/browse/SLING-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717575#action_12717575 ] Felix Meschberger commented on SLING-985: - So how about creating a BundleActivator which * manages the Abdera instance as a servlet context attribute * sets up or ensures the factories in the Abdera instance * the getAbdera method is modified to access the servlet context property, failing if the attribute is missing BTW: This tag library has no Sling dependencies (except for a TagUtil call, which may easily be replaced). Why not contribute it to the Apache Abdera project ? > Allow ATOM Syndication Format output > > > Key: SLING-985 > URL: https://issues.apache.org/jira/browse/SLING-985 > Project: Sling > Issue Type: New Feature >Reporter: Lars Trieloff >Assignee: Felix Meschberger >Priority: Minor > Attachments: SLING-985.patch > > > Having a JSON output for Sling is quite nice, but many web applications > require RSS/Atom support these days. Having an extension module that provides > a tag library for creating Atom feeds and atom entries out of JCR nodes would > be very helpful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling configuration
Hi Claude, Claude Vedovini schrieb: > my problem currently is that not only UAT and production should use > the same binaries with different sling.home (under linux) but > developers are using windows, thus we cannot have one war for all and > this obviously complicates the build and is error prone for admins and > developers alike. I understand. So you *don't* set the sling.home init-param and use the built-in default. > > a fact as well is that upgrading Sling could be as simple as dropping > a new war if I had not to unpack it. Exactly, don't touch the war ;-) > > I guess that now that each deployed sling servlet has it's own > subfolder under sling.home to store configuration to, then may be > overriding the sling.home from the system properties could be a good > idea. Since system properties apply to the whole VM, multiple sling web applications deployed to the same servlet container would then use the same sling.home system property, which will not work. For this reason, I removed support for setting sling.home as a system property for the Sling web application (it is only supported for the sling standalone application). In general system properties are fine for standalone applications but for web applications it is a bit more complicated and I am not sure, whether using system properties to configure web applications is a good thing. Regards Felix > > my 2cts > Claude > > On Sun, Jun 7, 2009 at 12:09 PM, Felix Meschberger wrote: >> Hi, >> >> Claude Vedovini schrieb: >>> Hi all, >>> >>> I use the sling web app on jBoss and I have issue with the location of >>> the sling home folder. >>> >>> >From what I read in [1] it seems one can setup the sling.home property >>> either using the sling.property or the web.xml file, both located >>> inside the sling war file, am I right? >> For the Sling Web app, the sling home folder is set through the >> sling.home init-property of the Sling Servlet or the Sling Servlet Context. >> >> If neither is set, the sling home folder is derived from the servlet >> context path prepended with "sling" and the path converted to a single >> name replacing slashes by underscores. >> >> E.g. sling.home for the web app at /sling/i1 is "sling/_sling_i1". >> >> This ensures sensible default values and prevents collisions if the >> sling web app is installed multiple times in the same container. >> >>> If so, how may I deliver an application that can be deployed on >>> different environments (test, UAT, prod) without repackaging the whole >>> stuff each time? >> If you don't really care, where your sling.home is, you might be happy >> using the default value. >> >> Otherwise, there is not currently another option that to repackage. >> >> If you have a good idea on how to prevent this, we are certainly >> open-ears ;-) >> >> Hope this helps. >> >> Regards >> Felix >> >
[jira] Commented: (SLING-985) Allow ATOM Syndication Format output
[ https://issues.apache.org/jira/browse/SLING-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717261#action_12717261 ] Felix Meschberger commented on SLING-985: - Thanks for providing this patch. I have applied it slightly modified in Rev. 782630. The modifications include: * Reformat to replace all tabs by spaces * Set version number to 0.9.0-incubator-SNAPSHOT * Added serial version uids Now for setting up the Abdera instance: You check for a request attribute named "abdera" and if this attribute does not exist, you create an instance and setup the factory. I wonder: * Is it required to have an Abdera instance per request ? * How leightweight is the creation of the Abdera instance or can the instance be shared ? * You have a stray "new FOMFactory()" statement in the getAbdera method. Is this required ? * Setting up the factory on each request looks wrong. Can you do this in a BundleActivator once and for all ? Now, you write in the comment, that setting up the factory is "broken" in the OSGi-fied Abdera libraries. Can this be fixed somehow, for example by adding a BundleActivator to the factory provider bundles or by adding code to the Abdera core to collect bundles providing factories ? I agree, that is completely wrong to have the taglib set up the factories. > Allow ATOM Syndication Format output > > > Key: SLING-985 > URL: https://issues.apache.org/jira/browse/SLING-985 > Project: Sling > Issue Type: New Feature > Reporter: Lars Trieloff >Assignee: Felix Meschberger >Priority: Minor > Attachments: SLING-985.patch > > > Having a JSON output for Sling is quite nice, but many web applications > require RSS/Atom support these days. Having an extension module that provides > a tag library for creating Atom feeds and atom entries out of JCR nodes would > be very helpful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-985) Allow ATOM Syndication Format output
[ https://issues.apache.org/jira/browse/SLING-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-985: --- Assignee: Felix Meschberger > Allow ATOM Syndication Format output > > > Key: SLING-985 > URL: https://issues.apache.org/jira/browse/SLING-985 > Project: Sling > Issue Type: New Feature >Reporter: Lars Trieloff > Assignee: Felix Meschberger >Priority: Minor > Attachments: SLING-985.patch > > > Having a JSON output for Sling is quite nice, but many web applications > require RSS/Atom support these days. Having an extension module that provides > a tag library for creating Atom feeds and atom entries out of JCR nodes would > be very helpful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SLING-993) Sling Explorer with jquery
Hi, Renaud Richardet (JIRA) schrieb: > What is left to be done to have it "fully" integrated? Depends on how we defined "fully integrated" ;-) I think having an explorer in the first place is already a good thing and a good start (incidentally there is a second approach based on GWT [1]. I think ultimately both approaches (as well as some sample approaches using Dojo) have their rights. Of course, I could still imagine some enhancements to the current JQuery based implementation, e.g. using a JQuery tree plugin to render the resource tree on the left or creating the web console plugin (where I think the JQuery based approach is more appropriate than the GWT or Dojo based one) or "extensibility" (whatever that means ;-) ). Regards Felix [1] https://issues.apache.org/jira/browse/SLING-990 > > Maybe someone with design skills could make it a bit nicer (CSS)... > >> Sling Explorer with jquery >> -- >> >> Key: SLING-993 >> URL: https://issues.apache.org/jira/browse/SLING-993 >> Project: Sling >> Issue Type: New Feature >> Components: Launchpad >> Environment: osx >>Reporter: Renaud Richardet >>Priority: Minor >> Attachments: explorer.zip, Picture 2.png, sling.zip >> >> >> a jcr explorer based on jquery. goals: minimum install and dependencies >
[jira] Updated: (SLING-993) Sling Explorer with jquery
[ https://issues.apache.org/jira/browse/SLING-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-993: Attachment: explorer.zip Attaching a slight modification: * Created a maven project providing the scripts as bundle resources * Small fixes to the JQuery scripts (mostly CSS class handling) * Refactored server side scripts to use Resource API and to not render some elements if access is not allowed To use this, simply deploy the bundle and access any location with the explorer selector, e.g. http://localhost:/.explorer.html > Sling Explorer with jquery > -- > > Key: SLING-993 > URL: https://issues.apache.org/jira/browse/SLING-993 > Project: Sling > Issue Type: New Feature > Components: Launchpad > Environment: osx >Reporter: Renaud Richardet >Priority: Minor > Attachments: explorer.zip, Picture 2.png, sling.zip > > > a jcr explorer based on jquery. goals: minimum install and dependencies -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Possible sling JSONObject bug
Hi, Alexander Klimetschek schrieb: > On Sat, Jun 6, 2009 at 5:55 PM, Felix Meschberger wrote: >>> On Fri, Jun 05, 2009 at 09:18:05PM +0200, Alexander Klimetschek wrote: >>>> I think they are not equivalent in the strict Javascript sense, as the >>>> order of the properties in an object is defined (you can iterate over >>>> it). It is not to be seen as a pure hash map. >> This is wrong. The spec explicitly states that there is no defined order >> amongst the properties of an object. >> >> Now, in reality, the known browsers implement objects in a way, that the >> properties have a factual insertion order. But, this is an >> implementation specific thing. > > Ok, I didn't know it was specified as free. But since the popular > implementations (browsers) all follow the same way, ie. keep the order > (in Javascript), one should follow this to keep free from unwanted > problems. I do not agree. One should follow the spec and consider the browser implementations what they are: implementations of the spec where it happens to be that the properties seem to have an order. But yes, the Sling JSONObject also supports the property ordering due to popular request of users depending on this implementation specific... Regards Felix
[jira] Issue Comment Edited: (SLING-993) Sling Explorer with jquery
[ https://issues.apache.org/jira/browse/SLING-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717036#action_12717036 ] Felix Meschberger edited comment on SLING-993 at 6/7/09 5:12 AM: - This looks very light-weight and probably nicely embeddable. I could imagine the following: * Enhance the scripts to use the Resource tree API to list the resources instead of just the JCR items * Use [Persistable]ValueMap to display the properties (if adaptable to PersistableValueMap the resource is editable, if only mappable to ValueMap or Map, the resource is readonly) * Add some glue to make it a Web Console plugin Thus we could create an "Resource Explorer" bundle, which contains the scripts as bundle-resources for direct use plus contains the Web Console plugin for embedding the explorer in the Web Console. WDYT ? was (Author: fmeschbe): This looks very light-weight and probably nicely embeddable. I could imagine the following: * Enhance the scripts to use the Resource tree API to list the resources instead of just the JCR items * Use [Persistable]ValueMap to display the properties (if adaptable to PersistableValueMap the resource is editable, if only mappable to ValueMap or Map, the resource is readonly) * Add some glue to make it a Web Console plugin WDYT ? > Sling Explorer with jquery > -- > > Key: SLING-993 > URL: https://issues.apache.org/jira/browse/SLING-993 > Project: Sling > Issue Type: New Feature > Components: Launchpad > Environment: osx >Reporter: Renaud Richardet >Priority: Minor > Attachments: Picture 2.png, sling.zip > > > a jcr explorer based on jquery. goals: minimum install and dependencies -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-993) Sling Explorer with jquery
[ https://issues.apache.org/jira/browse/SLING-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717036#action_12717036 ] Felix Meschberger commented on SLING-993: - This looks very light-weight and probably nicely embeddable. I could imagine the following: * Enhance the scripts to use the Resource tree API to list the resources instead of just the JCR items * Use [Persistable]ValueMap to display the properties (if adaptable to PersistableValueMap the resource is editable, if only mappable to ValueMap or Map, the resource is readonly) * Add some glue to make it a Web Console plugin WDYT ? > Sling Explorer with jquery > -- > > Key: SLING-993 > URL: https://issues.apache.org/jira/browse/SLING-993 > Project: Sling > Issue Type: New Feature > Components: Launchpad > Environment: osx >Reporter: Renaud Richardet >Priority: Minor > Attachments: Picture 2.png, sling.zip > > > a jcr explorer based on jquery. goals: minimum install and dependencies -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling configuration
Hi, Claude Vedovini schrieb: > Hi all, > > I use the sling web app on jBoss and I have issue with the location of > the sling home folder. > >>From what I read in [1] it seems one can setup the sling.home property > either using the sling.property or the web.xml file, both located > inside the sling war file, am I right? For the Sling Web app, the sling home folder is set through the sling.home init-property of the Sling Servlet or the Sling Servlet Context. If neither is set, the sling home folder is derived from the servlet context path prepended with "sling" and the path converted to a single name replacing slashes by underscores. E.g. sling.home for the web app at /sling/i1 is "sling/_sling_i1". This ensures sensible default values and prevents collisions if the sling web app is installed multiple times in the same container. > > If so, how may I deliver an application that can be deployed on > different environments (test, UAT, prod) without repackaging the whole > stuff each time? If you don't really care, where your sling.home is, you might be happy using the default value. Otherwise, there is not currently another option that to repackage. If you have a good idea on how to prevent this, we are certainly open-ears ;-) Hope this helps. Regards Felix
Re: Possible sling JSONObject bug
Hi,
D. Stuart Freeman schrieb:
> OK, in that case it sounds like comparing the results of toString()
> should suffice for my purposes.
No, this won't work - technically - since the order of properties in an
object is *explicitly* defined as not being defined in the spec. In our
implementation we cheated a bit and make the order defined as "insertion
order" using a LinkedHashMap.
If you really would want to compare JSONObjects, we would have to
implement the equals method - probably in terms of the equals() method
of the underlying Map used internally.
Comparing toString is unreliable.
>
> On Fri, Jun 05, 2009 at 09:18:05PM +0200, Alexander Klimetschek wrote:
>> I think they are not equivalent in the strict Javascript sense, as the
>> order of the properties in an object is defined (you can iterate over
>> it). It is not to be seen as a pure hash map.
This is wrong. The spec explicitly states that there is no defined order
amongst the properties of an object.
Now, in reality, the known browsers implement objects in a way, that the
properties have a factual insertion order. But, this is an
implementation specific thing.
Regards
Felix
>>
>> Regards,
>> Alex
>>
>> --
>> Alexander Klimetschek @iPhone
>>
>>
>> Am 05.06.2009 um 21:00 schrieb "D. Stuart Freeman"
>> :
>>
>>> In the example I do both a toString() comparison and an Object
>>> comparison
>>> to show that it doesn't work. The problem is that in the current
>>> setup
>>> is as follows:
>>>
>>> JSONObject j = new JSONObject("{a:a, b:b}");
>>> JSONObject j = new JSONObject("{b:b, a:a}");
>>>
>>> There's no easy way to find out these are functionally equivalent.
>>> The
>>> toString() methods of those objects will return them with the
>>> properties
>>> in that order and as such will not be equal. Calling .equals on the
>>> JSONObjects won't work either because it calls Object.equals which is
>>> false.
>>>
>>> On Fri, Jun 05, 2009 at 12:16:13PM -0500, John Crawford wrote:
Well in you're example you used toString() before comparing.
Sent from my iPhone
On Jun 5, 2009, at 12:14 PM, "D. Stuart Freeman"
wrote:
> I just realized this is because JSONObject doesn't override equals.
> Maybe it should?
>
> On Fri, Jun 05, 2009 at 01:10:30PM -0400, D. Stuart Freeman wrote:
>> Should it hold that if we have two JSONObjects, j and k, that if
>> j.toString().equals(k.toString()) then j.equals(k)? I ask because
>> I've
>> found that it's possible to create JSONObjects where that isn't the
>> case.
>> Here's a quick, minimal example I worked up:
>> http://pastebin.com/f12de25b9
>>
>> --
>> D. Stuart Freeman
>> Georgia Institute of Technology
>
>
> --
> D. Stuart Freeman
> Georgia Institute of Technology
>>> --
>>> D. Stuart Freeman
>>> Georgia Institute of Technology
>
Re: Openid integration for Sling 3
Hi Tanmay, Tanmay Barman schrieb: > I was trying to integrate openid in my project that is based on sling 3. I > was trying with openid4java api. But I am having the following error > > java.lang.NoClassDefFoundError: > org/apache/commons/httpclient/methods/RequestEntity > at > org.apache.sling.samples.jcrdev.servlets.SampleConsumerServlet.authRequest(SampleConsumerServlet.java:93) > at > org.apache.sling.samples.jcrdev.servlets.SampleConsumerServlet.doPost(SampleConsumerServlet.java:67) > at > org.apache.sling.samples.jcrdev.servlets.SampleConsumerServlet.doGet(SampleConsumerServlet.java:59) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) > at > org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:462) > at > org.apache.sling.engine.impl.SlingMainServlet.processRequest(SlingMainServlet.java:419) > at > org.apache.sling.engine.impl.filter.RequestSlingFilterChain.render(RequestSlingFilterChain.java:48) > at > org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:54) > at > org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter.doFilter(RequestProgressTrackerLogFilter.java:59) > at > org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:52) > at > org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:273) > at > org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:171) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) > at > org.ops4j.pax.web.service.internal.HttpServiceServletHandler.handle(HttpServiceServletHandler.java:51) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:722) > at > org.ops4j.pax.web.service.internal.HttpServiceContext.handle(HttpServiceContext.java:87) > at > org.ops4j.pax.web.service.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:63) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:828) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450) > > I have also included commons-httpclient-2.0.2.jar in my felix > environment. If anyone has some idea about that problem please let me > know. Could it be that your are using a httpclient library, which is too old ? (Oh yes, this should not happend since the httpclient library user is supposed to specify the importing package version and the commons-httpclient-2.0.2 bundle should expose the version of the exported packages, but this might not be the case here) Hope this helps. Regards Felix
Re: Exposing DB Data
Hi Andreas, Andreas Kollegger schrieb: > Hi, > > I'd like to expose data stored in an external database as resource nodes > in Sling. Access to the database is already wrapped in an OSGi service > (MyService.java), and there is a Java model for the data (MyModel.java). > From what I can understand from reading the examples, searching the > mailing list and looking at documentation, the steps to integrate with > Sling could be: > > 1. MyResourceProvider implements ResourceProvider > - bridge to MyService for getting data rows > - provider.roots = /my/resources/ > - sub-path of root used to select row in table > (/my/resources/3245.html retrieves row index 3245 as Resource) > - listChildren() of root would list all database rows (probably add > query params to limit number of rows returned) > - getResource() returns a MyResourceWrapper Makes perfect sense. > 2. MyResourceWrapper implements Resource > - wraps MyModel > - resourceType = my/Model > - adaptable to javax.jcr.Node (exposing columns as node properties) I would not adapt it to a Node. Rather I would adapt it to the MyModel class and propbably to ValueMap (or even PersistableValueMap) to get at the properties. > > That would take care of read access to the data. I can then easily add > scripts to render the data as appropriate. > > Write access is a little less clear to me. I'd like to have a servlet > which handles json, xml or form POSTs for anything submitted to the path > of my ResourceProvider. I think I need to do this: > > 1. MyResourceTypeProvider implements JcrResourceTypeProvider > - provider.roots = /my/resources > - any node below the root is returned as resourceType my/Model, > otherwise return null The problem exists mainly for non-existing resources (rows). Existing rows already map to the correct implementation (see above) and thus have the correct resource type. For non-existing resources, Ian Boston is preparing a patch providing a PathResourceTypeProvider which may be used to assign a special resource type to non-existing nodes much like the JcrResourceTypeProvider does for plain JCR Item based resources. So in your use case Ian's PathResourceTypeProvider would probably be appropriate. > > 2. MyPostServlet extends SlingAllMethodsServlet > - registered to handle nodes of type my/Model > - override doPost() to handle data based on content-type > - creates new database entries using MyService Makes perfect sense to me. We might want to inspect how much of the existing SlingPostServlet could be abstracted to support general resource creation, modification, removal, not just JCR Item based ones. > > That would allow the creation of a new database row by posting an > appropriate json or xml file to /my/resource/*.html . For the form data, > I'd conform to the SlingPostServlet interface to remain compatible with > generic node editing. > > Am I thinking about this correctly, or is their a more appropriate > Sling-Way? I think you are approach looks perfectly like the Sling way. Another approach could of course be to create a Jackrabbit PersistenceManager for your database and access your database through Jackrabbit. But I suspect that this would be more complicated. Regards Felix
Re: Binding to a resource Type
Hi Ian I have posted a review there. Regards Felix Ian Boston schrieb: > I have pushed a patch for inspection at > http://codereview.appspot.com/67146 > > Is this along the lines you were thinking ? > Ian > > On 3 Jun 2009, at 10:14, Felix Meschberger wrote: > >> It might be conceivable though to set the resourceSuperType of such >> non-existing resources to something configurable. To do this I would >> suggest to introduce a new service interface, which would be called when >> the ResourceResolver is about to create the NonExistingResource > >
[jira] Created: (SLING-992) Document Servlet Resolution and Error Handling
Document Servlet Resolution and Error Handling -- Key: SLING-992 URL: https://issues.apache.org/jira/browse/SLING-992 Project: Sling Issue Type: Task Components: Documentation Reporter: Felix Meschberger The Sling Servlet Resovler bundle provides elaborate functionality to select a Script or Servlet to handle a request. In addition it provides nice functionality to select error handler Scripts or Servlets to handle HttpServletResponse.sendError calls. This functionality should be described. Some rough information has already been gathered on our wiki at [1] from mail conversations. This should be enhanced and extended. [1] http://cwiki.apache.org/confluence/display/SLING/URL+to+Script+Resolution -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Binding to a resource Type
Hi,
Each ResourceProvider is responsible for setting up resources
themselves, including setting the resource type. For example the
BundleResourceProvider sets the resource type to nt:file or nt:folder
depending on whether the resource is a file or folder.
The JcrResourceProvider now uses the ResourceTypeProvider service to
enhance its resource type resolution:
(1) check sling:resourceType property
(2) check ResourceTypeProvider services
(3) take primary node type
Your (remaining) problem probably is the resource type of non-existing
resources which is currently hard coded to sling:nonexisting and it is
also defined in the API that a non existing resource has the
sling:nonexisting resource type.
It might be conceivable though to set the resourceSuperType of such
non-existing resources to something configurable. To do this I would
suggest to introduce a new service interface, which would be called when
the ResourceResolver is about to create the NonExistingResource.
Regards
Felix
Ian Boston schrieb:
>
> On 3 Jun 2009, at 09:26, Felix Meschberger wrote:
>
>> Not in the sense of "inheriting the resource type from the parent node
>> if none is set".
>>
>> But: We have a ResourceTypeProvider service interface, which you may
>> implement. This provider is called by the JcrResourceProvider if a node
>> has no sling:resourceType property.
>>
>> In a custom resource provider, you could find a sling:resourceType
>> property up the ancestors of the node to build inheritance this way.
>>
>> HTH
>
> Felix,
>
> Yes It does to a degree
>
> I had a look at that interface and it works if there is a Node, but URL
> does not directly map to the JCR path either because the JCR path doesnt
> exist yet, or because there is mapping between the URL and the JCR path,
> then there is no Node, so the JcrResourceType doesnt get called.
>
> What *would* work is something like
>
> /**
> * Provide a resource type for resource paths which do not have
> * resourceType.
> */
> public interface ResourceTypeProvider {
>
> /**
> * Return the resource type to use for the node.
> * @param absPath The node.
> * @return The resource type to use or null.
> */
> String getResourceTypeForPath(String absPath) throws
> RepositoryException;
> }
>
> That would also get rid of the need for my patch local on
> ResourceProvider registrations (classifier)
>
> Ian
>
>
>>
>>
>> Regards
>> Felix
>
>
[jira] Commented: (SLING-990) Prototype for a Sling Explorer implementation based on GWT
[ https://issues.apache.org/jira/browse/SLING-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715868#action_12715868 ] Felix Meschberger commented on SLING-990: - > I will modify the JSON scripts. Cool, so we get a Resource tree explorer ! > The resources (images, css & js) are under LGPL. I took those files from > Smart GWT 1.1 distribution. Maybe we can use others. Could these be extracted from the artifact downloaded from the maven repository on build time ? So that we don't have to store this in our SVN. > If LGPL is an issue, we cannot continue to use SmartGwt because the current > implementention requires 2 SmartGWT jars > (see the pom.xml). Those jars are also under LGPL. There are used to run the > application in the hosted mode and compile > de java code into js. Would it be a big problem to not be able to use SmartGWT ? > Prototype for a Sling Explorer implementation based on GWT > -- > > Key: SLING-990 > URL: https://issues.apache.org/jira/browse/SLING-990 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Christophe Lombart > Attachments: Sling Explorer.zip > > > Following the Sling Explorer proposal [1], I have started an implementation > with the SwartGwt UI framework [2] (based on GWT and under LGPL licence). > Not sure but I think that LGPL is compatible with the Apache project. > Until now, it is just a prototype. Can you review the code and see if this > Gwt application is well integrated with Sling ? > [1] http://cwiki.apache.org/SLING/sling-based-jcr-explorer.html > [2] http://code.google.com/p/smartgwt/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Binding to a resource Type
Hi, Ian Boston schrieb: > > On 3 Jun 2009, at 06:32, Felix Meschberger wrote: > >> Hi Ian, >> >> Ian Boston schrieb: >>> Should a servlet (with sling.servlet.resourceTypes value="x") bind to >>> JCR nodes where a parent node has a resourceType of x, or will it only >>> bind to JCR nodes where the node itself has the resourceType x ? >> >> I do not exactly understand what you mean by "bind to JCR nodes" ? >> > > > I mean, when I have servlet with >> sling.servlet.resourceTypes = "x" > > and send a request for node with a sling:resourceType=x the request will > get routed to the servlet (assuming it can handle the request method, > and selector) > > However, > If I send a request for a child node of the node with > sling:resourceType=x, the request does not get routed to the servlet. Correct. Each resource has its own resource type. > ie there is no resourceType inheritance by default in Sling. Not in the sense of "inheriting the resource type from the parent node if none is set". But: We have a ResourceTypeProvider service interface, which you may implement. This provider is called by the JcrResourceProvider if a node has no sling:resourceType property. In a custom resource provider, you could find a sling:resourceType property up the ancestors of the node to build inheritance this way. HTH Regards Felix > > Ian > > >> Registered servlets are not "bound to JCR nodes" but are added to the >> resource tree at predefined locations. For example a servlet >> registered with >> >> sling.servlet.resourceTypes = "x" >> sling.servlet.extensions = "html" >> >> is added to the resource tree (by default) at >> >> /apps/x/html.servlet >> >> This node (a leaf actually) in the resource tree is not backed by a JCR >> item and is only accessible through the resource resolver and only >> exists as long as the Servlet Resolver is active and the servlet is >> registered. >> >> Hope this helps. >> >> Regards >> Felix > >
[jira] Closed: (SLING-991) JcrResourceResolver2.map does not handle resource paths with fragments and queries correctly
[ https://issues.apache.org/jira/browse/SLING-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-991. --- This can be closed > JcrResourceResolver2.map does not handle resource paths with fragments and > queries correctly > > > Key: SLING-991 > URL: https://issues.apache.org/jira/browse/SLING-991 > Project: Sling > Issue Type: Bug > Components: JCR Resource >Affects Versions: JCR Resource 2.0.4 > Reporter: Felix Meschberger > Assignee: Felix Meschberger > Fix For: JCR Resource 2.0.6 > > > The JcrResourceResolver2.map(HttpServletRequest, String) method does not > handle any fragements and queries in the resource path correctly, when > mapping from the internal path to the external URL. > The intent of the map method is to take any string, which is prepared to act > as a link URL and to map the resource path to a valid URL, which may be > resovled by the resolve method. Any selectors, extension and suffix are > correctly cut of the path to get the raw resource path to map. But fragments > and queries are not handled correclty. > Consider the following examples based on an existing resource /content/home: > /content/home --> use as is, nothing to cut off > /content/home.html --> cut off extension before mapping > /content/home.sel.html --> cut off selector and extension before mapping > /content/home.html/some/suffix --> cut off extension and suffix before > mapping > /content/home.html#sec1?a:b=1 --> cut off extension, fragment and query > before mapping > The last part is not being done currently, which is a problem and might leed > to wrong mapping results, particularly if the query contains colons, which > would result in wrong namespace mangling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-991) JcrResourceResolver2.map does not handle resource paths with fragments and queries correctly
[ https://issues.apache.org/jira/browse/SLING-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-991. - Resolution: Fixed Applied fix to this problem in Rev. 781285: * Cut off fragment and/or query before applying mapping algorithm * Append fragment and/or query after the mapping * Remove special query handling from the mangleNameSpaces method introduced with SLING-906 * Add test cases > JcrResourceResolver2.map does not handle resource paths with fragments and > queries correctly > > > Key: SLING-991 > URL: https://issues.apache.org/jira/browse/SLING-991 > Project: Sling > Issue Type: Bug > Components: JCR Resource >Affects Versions: JCR Resource 2.0.4 > Reporter: Felix Meschberger > Assignee: Felix Meschberger > Fix For: JCR Resource 2.0.6 > > > The JcrResourceResolver2.map(HttpServletRequest, String) method does not > handle any fragements and queries in the resource path correctly, when > mapping from the internal path to the external URL. > The intent of the map method is to take any string, which is prepared to act > as a link URL and to map the resource path to a valid URL, which may be > resovled by the resolve method. Any selectors, extension and suffix are > correctly cut of the path to get the raw resource path to map. But fragments > and queries are not handled correclty. > Consider the following examples based on an existing resource /content/home: > /content/home --> use as is, nothing to cut off > /content/home.html --> cut off extension before mapping > /content/home.sel.html --> cut off selector and extension before mapping > /content/home.html/some/suffix --> cut off extension and suffix before > mapping > /content/home.html#sec1?a:b=1 --> cut off extension, fragment and query > before mapping > The last part is not being done currently, which is a problem and might leed > to wrong mapping results, particularly if the query contains colons, which > would result in wrong namespace mangling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-991) JcrResourceResolver2.map does not handle resource paths with fragments and queries correctly
JcrResourceResolver2.map does not handle resource paths with fragments and queries correctly Key: SLING-991 URL: https://issues.apache.org/jira/browse/SLING-991 Project: Sling Issue Type: Bug Components: JCR Resource Affects Versions: JCR Resource 2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: JCR Resource 2.0.6 The JcrResourceResolver2.map(HttpServletRequest, String) method does not handle any fragements and queries in the resource path correctly, when mapping from the internal path to the external URL. The intent of the map method is to take any string, which is prepared to act as a link URL and to map the resource path to a valid URL, which may be resovled by the resolve method. Any selectors, extension and suffix are correctly cut of the path to get the raw resource path to map. But fragments and queries are not handled correclty. Consider the following examples based on an existing resource /content/home: /content/home --> use as is, nothing to cut off /content/home.html --> cut off extension before mapping /content/home.sel.html --> cut off selector and extension before mapping /content/home.html/some/suffix --> cut off extension and suffix before mapping /content/home.html#sec1?a:b=1 --> cut off extension, fragment and query before mapping The last part is not being done currently, which is a problem and might leed to wrong mapping results, particularly if the query contains colons, which would result in wrong namespace mangling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Clarification for ResourceResolver#map
Hi, Carsten Ziegeler schrieb: > Felix Meschberger wrote: >> Hi Carsten >> >> Carsten Ziegeler schrieb: >>> how is the ResourceResolver#map method supposed to work or more precisly >>> what input is expected. The javadoc mentions a resource path as input >>> parameter. >>> What is supposed to happen if the path contains a query string or an anchor? >> The query string is cut off IIRC before applying the mapping and >> appended again at the end. > Great, I didn't find this in the code. Can you give me a pointer please? :) Its in the JcrResourceResolver2.map(HttpServletRequest, String) method where the resource is resolved from the resource path calling resolveInternal (line 277). This yields the raw path (the path of the resource) and the part of the path not belonging to the resource. It seems that here, we should cut off the query and/or anchor *before* calling the resolveInternal method. Regards Felix > > Regards > Carsten > >> The anchor is not currently handled, which >> might be considered a bug to be fixed. >> >> Actually the resource path may also contain appended selectors and >> extensions, which are also cut off at the beginning and reappended at >> the end. >> >> Regards >> Felix >> >> > >
[jira] Commented: (SLING-990) Prototype for a Sling Explorer implementation based on GWT
[
https://issues.apache.org/jira/browse/SLING-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715822#action_12715822
]
Felix Meschberger commented on SLING-990:
-
I did not run the code, I just looked at the contents of the package. This
lookes very interesting but misses a few things:
* We need the LICENSE and NOTICE file (and the DISCLAIMER, but this we can
add on SVN commit)
* What is the licencse (and source) of the images and CSS files included ?
These might have to be
attributed in the NOTICE file and *not* be (L)GPL-ed. Also a LICENSE
file would be required for
them unless they are ASL licensed.
In tree-node.json.esp you do :
if (childNode == null)
{
name += child.path;
}
else
{
name += childNode.name;
//name = child.path;
}
To get the label of the resource. You might use ResourceUtil.getName(resource)
here, which does the same and does not rely on the resource being a node.
children.json.esp seems to be JCR-based: How about using the Sling Resource
abstractions here : listing children using ResourceResolver.listChildren and
getting the propreties with Resource.adaptTo(ValueMap.class) ?
> Prototype for a Sling Explorer implementation based on GWT
> --
>
> Key: SLING-990
> URL: https://issues.apache.org/jira/browse/SLING-990
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
>Reporter: Christophe Lombart
> Attachments: Sling Explorer.zip
>
>
> Following the Sling Explorer proposal [1], I have started an implementation
> with the SwartGwt UI framework [2] (based on GWT and under LGPL licence).
> Not sure but I think that LGPL is compatible with the Apache project.
> Until now, it is just a prototype. Can you review the code and see if this
> Gwt application is well integrated with Sling ?
> [1] http://cwiki.apache.org/SLING/sling-based-jcr-explorer.html
> [2] http://code.google.com/p/smartgwt/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SLING-990) Prototype for a Sling Explorer implementation based on GWT
Hi all, Felix Meschberger (JIRA) schrieb: >> Not sure but I think that LGPL is compatible with the Apache project. > > Unfortunately not. Apache projects are not allowed to distribute artifacts > including artifacts licensed under any GPL or LGPL license. I think, this primarily means we are not allowed to distribute the final bundle build as a JAR file containing the (L)GPL licensed stuff. IIRC we are allowed to have the source in the SVN repo provided it only contains properly licensed files and we probably should make sure that anyone using this is aware of using (L)GPL licensed when building and running. Maybe Jukka may add to this ? Regards Felix > >> Prototype for a Sling Explorer implementation based on GWT >> -- >> >> Key: SLING-990 >> URL: https://issues.apache.org/jira/browse/SLING-990 >> Project: Sling >> Issue Type: New Feature >> Components: Extensions >>Reporter: Christophe Lombart >> Attachments: Sling Explorer.zip >> >> >> Following the Sling Explorer proposal [1], I have started an implementation >> with the SwartGwt UI framework [2] (based on GWT and under LGPL licence). >> Not sure but I think that LGPL is compatible with the Apache project. >> Until now, it is just a prototype. Can you review the code and see if this >> Gwt application is well integrated with Sling ? >> [1] http://cwiki.apache.org/SLING/sling-based-jcr-explorer.html >> [2] http://code.google.com/p/smartgwt/ >
[jira] Commented: (SLING-990) Prototype for a Sling Explorer implementation based on GWT
[ https://issues.apache.org/jira/browse/SLING-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715811#action_12715811 ] Felix Meschberger commented on SLING-990: - > Not sure but I think that LGPL is compatible with the Apache project. Unfortunately not. Apache projects are not allowed to distribute artifacts including artifacts licensed under any GPL or LGPL license. > Prototype for a Sling Explorer implementation based on GWT > -- > > Key: SLING-990 > URL: https://issues.apache.org/jira/browse/SLING-990 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Christophe Lombart > Attachments: Sling Explorer.zip > > > Following the Sling Explorer proposal [1], I have started an implementation > with the SwartGwt UI framework [2] (based on GWT and under LGPL licence). > Not sure but I think that LGPL is compatible with the Apache project. > Until now, it is just a prototype. Can you review the code and see if this > Gwt application is well integrated with Sling ? > [1] http://cwiki.apache.org/SLING/sling-based-jcr-explorer.html > [2] http://code.google.com/p/smartgwt/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Binding to a resource Type
Hi Ian, Ian Boston schrieb: > Should a servlet (with sling.servlet.resourceTypes value="x") bind to > JCR nodes where a parent node has a resourceType of x, or will it only > bind to JCR nodes where the node itself has the resourceType x ? I do not exactly understand what you mean by "bind to JCR nodes" ? Registered servlets are not "bound to JCR nodes" but are added to the resource tree at predefined locations. For example a servlet registered with sling.servlet.resourceTypes = "x" sling.servlet.extensions = "html" is added to the resource tree (by default) at /apps/x/html.servlet This node (a leaf actually) in the resource tree is not backed by a JCR item and is only accessible through the resource resolver and only exists as long as the Servlet Resolver is active and the servlet is registered. Hope this helps. Regards Felix
Re: Clarification for ResourceResolver#map
Hi Carsten Carsten Ziegeler schrieb: > how is the ResourceResolver#map method supposed to work or more precisly > what input is expected. The javadoc mentions a resource path as input > parameter. > What is supposed to happen if the path contains a query string or an anchor? The query string is cut off IIRC before applying the mapping and appended again at the end. The anchor is not currently handled, which might be considered a bug to be fixed. Actually the resource path may also contain appended selectors and extensions, which are also cut off at the beginning and reappended at the end. Regards Felix
Re: JcrResoruceResolver2, by design ?
Hi Ian, I could imagine two approaches to your problem: (1) Register a resource provider for the root node of your "hashed" tree. When asked for a resource, it will apply the mapping function to find the actual resource. (2) Employ the dynamic URL Rewriting patch you proposed in SLING-986: You attach that rewriter such that it resoloves and maps as required. The advantage of the second approach is, that you have a "free" two-way mapping for resolving URLs (incoming) and mapping resource paths to URLs (outgoing). The disadvantage of both approaches is, that it is actually configuration and a simple resource creation à-la curl -F"sling:resourceType:sakai/store" http://localhost:8080/bigstore might not be enough and you would have some additional functionality (a listener maybe) to set this up on demand. Regards Felix Ian Boston schrieb: > > On 2 Jun 2009, at 16:09, Paul Noden wrote: > >> Hi Ian, >> >> 2009/6/2 Ian Boston >> >>> AFAICT its impossible to virtualize paths (URI wrt JCR path) using this >>> approach in the JCR. >>> >>> Unfortunately for me, its a use case I can't ignore as we have lots of >>> situations where a non listable could contain millions of items. >>> Back to square one. >>> >>> > The current design and intention is, that for any one (root) path > there > may only be one resource provider registered. So for example, for a > (root) path "/some/path", there may only one. Of course there may be > another one at "/some" or at "/some/path/below". > > I want to be able to bind a special Resource to a node with a corresponding resourceType (created by the application) anywhere in the content system, so that all the standard Sling processing can access that Resource. For example: I want to be able to create a node anywhere in the content system, and under that node have a hashed store that is managed as if the entire node space was flattened. eg the URL /x/y/z/store/12312312/a/b/c is mapped to JCR space /x/y/z/store/content/aa/bb/cc/dd/12312312/a/b/c using the ResourceProducer mechanism. >>> >> Can you go into some more detail regarding the requirements for this >> strategy? > > Paul, > > Sure, > I need to create stores of potentially a large number of items single > locations in URL space where the items can be > accessed by a URL > reference each other. > be listed by paged search. > > The main requirement is that the collection should be addressable with > the following form > /x/y/z/1001 > > The path might extend further eg > /x/y/z/1001/d/e/f > > the cannonical form being > /x/y/z/n/** > where n is one of a set of a large number of items (eg 10M) > > AFAIK, to make this work JCR n needs to be expanded to a hashed tree eg > /x/y/z/aa/bb/cc/dd/n/** > > Having performed the hashing, I would ideally like to reuse the > SlingPostServlet and related functionality, so that > > curl -F"sling:resourceType:sakai/store" http://localhost:8080/bigstore > > creates a store (identified by the sakai/store resourceType) > > curl -F"status:stage1" http://localhost:8080/bigstore.create.html > > a redirect coming back to (ad23415g4 is an opaque token) > http://localhost:8080/bigstore/ad23415g4 > > Which can then be used in further operations on that item. > > >> >> >> Could you use node representations in store to placehold/redirect to the >> nested content at "content/aa/bb/cc/dd/"? > > Provided that HTTP would never see content/aa/bb/cc/dd/, but I guess by > redirect, you mean http redirect, in which case, no since relative URL's > break at this point. > eg ../ad23415g4/related_information.html > > >> >> >> Regards, >> >> Paul Noden > >
Re: Google Analytics for the Sling web site
Hi, Jukka Zitting schrieb: > Jackrabbit is using Google Analytics to track usage of the > jackrabbit.apache.org web site, and I was wondering if Sling would be > interested in similar data. See [1] for an example report. With my Sling Hat on I could be interested in these figures and favor it. With my Internet Surfer hat on I am not really sure whether I like the idea of Google gathering this information. All in all I tend to rather not be in favor of this. Regards Felix
[jira] Commented: (SLING-917) Use repository.apache.org for deployments
[ https://issues.apache.org/jira/browse/SLING-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715518#action_12715518 ] Felix Meschberger commented on SLING-917: - Created INFRA-2081 to ask for addition of Sling to the Nexus Repository > Use repository.apache.org for deployments > - > > Key: SLING-917 > URL: https://issues.apache.org/jira/browse/SLING-917 > Project: Sling > Issue Type: Task > Components: General >Affects Versions: Parent 5 >Reporter: Bertrand Delacretaz > Fix For: Parent 6 > > Attachments: SLING-917.patch > > > See INFRA-1896 for getting access to repository.apache.org . > Once that's done, we'll need to configure http://vmbuild.apache.org to push > snapshots there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
