Re: Sling Discovery implementation on AWS S3
Hi Timotheé, yes I think this is valuable - the idea of the discovery API is to abstract the discovery and if we can benefit in certain scenarios from already available mechanism/information I think it makes totally sense to use that instead of adding the same on top of it. Right now, the topology is formed of clusters containing instances - where all instances in a cluster share the same repository, but instances in different clusters use a different one. Is this kind of topology somehow possible by using the AWS API? Or would all instances end up in a single cluster? Regards Carsten 2014-05-11 18:54 GMT+02:00 Timothée Maret timothee.ma...@gmail.com: Hi, I would like to discuss a potential implementation of the Sling Discovery APIs over an eventually consistent distributed storages such as AWS S3. Assuming the instances being part of the topology runs in AWS, then we could leverage AWS APIs and service in order to implement the Discovery mechanism. The discovery of instances could be implemented implicitely using EC2 REST API [0] without sending heartbeats, the properties for each instance could be stored in AWS S3 and distributed eventually, the leader election could be implemented with [1] or similar. The benefits (over Sling impl) would be * Arguably the highest availablity we can get from the environment * Reduced bandwith consumption (no hearthbeats) * Environment specific informations is implicitely distributed (local ip, external ip, hostname, region, etc.) Of course, it would bind the implementation to an environment (AWS in this case), however I believe we could apply the same mechanism to other eventually consistent storage. Wdyt ? Is this something that would be valuable for Sling ? Regards, Timothee [0] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-DescribeInstances.html [1] http://gsyc.es/~anto/papers/2007-dsn.pdf -- Carsten Ziegeler cziege...@apache.org
Re: Sling Discovery implementation on AWS S3
Hi, +1 for distribution of properties via S3, makes perfect sense. Perhaps abstracting behind an API so that any low latency globally distributed storage provider could be used. Not sure about discovery. Although [0] described the AWS VM, it doesn't, without further validation describe if the Sling instance is running and available. Its perfectly possible for the VM to be in a running state, with no viable Sling instance running. I dont think that hard to achieve but it needs to be done to support the discovery use case. I think we are talking about instances running on independent repositories here, since if all instances share the same repository (ie are a Jackrabbit cluster), then the repository already has a mechanism of communicating running instances via the repository. Best Regards Ian On 12 May 2014 07:06, Carsten Ziegeler cziege...@apache.org wrote: Hi Timotheé, yes I think this is valuable - the idea of the discovery API is to abstract the discovery and if we can benefit in certain scenarios from already available mechanism/information I think it makes totally sense to use that instead of adding the same on top of it. Right now, the topology is formed of clusters containing instances - where all instances in a cluster share the same repository, but instances in different clusters use a different one. Is this kind of topology somehow possible by using the AWS API? Or would all instances end up in a single cluster? Regards Carsten 2014-05-11 18:54 GMT+02:00 Timothée Maret timothee.ma...@gmail.com: Hi, I would like to discuss a potential implementation of the Sling Discovery APIs over an eventually consistent distributed storages such as AWS S3. Assuming the instances being part of the topology runs in AWS, then we could leverage AWS APIs and service in order to implement the Discovery mechanism. The discovery of instances could be implemented implicitely using EC2 REST API [0] without sending heartbeats, the properties for each instance could be stored in AWS S3 and distributed eventually, the leader election could be implemented with [1] or similar. The benefits (over Sling impl) would be * Arguably the highest availablity we can get from the environment * Reduced bandwith consumption (no hearthbeats) * Environment specific informations is implicitely distributed (local ip, external ip, hostname, region, etc.) Of course, it would bind the implementation to an environment (AWS in this case), however I believe we could apply the same mechanism to other eventually consistent storage. Wdyt ? Is this something that would be valuable for Sling ? Regards, Timothee [0] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-DescribeInstances.html [1] http://gsyc.es/~anto/papers/2007-dsn.pdf -- Carsten Ziegeler cziege...@apache.org
[jira] [Created] (SLING-3547) Default handling for numerical types on Sling Models broken
Konrad Windszus created SLING-3547: -- Summary: Default handling for numerical types on Sling Models broken Key: SLING-3547 URL: https://issues.apache.org/jira/browse/SLING-3547 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Sling Models Implementation 1.0.2 Reporter: Konrad Windszus Currently all default annotations on numeric types lead to the following warning: org.apache.sling.models.impl.ModelAdapterFactory Default values for class java.lang.Boolean are not supported and the default is not used. This is due to the fact that first all types are converted from Primitives to Object Wrapper Classes (in mapPrimitiveClasses). Then the comparison against that type only considers Primitives (in getDefaultValue, except for Strings), which obviously failed, because either those were Object Wrapper Classes right from the beginning, or they were converted to those. In my regard you should compare the Type against e.g. Integer.class instead of Integer.TYPE (ModelAdapterFactory, line 428ff). Otherwise defaults for numerical types will not work. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3525) Launchpad notification thread cannot access JNDI ressources on Websphere
[
https://issues.apache.org/jira/browse/SLING-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13994953#comment-13994953
]
Carsten Ziegeler commented on SLING-3525:
-
[~jhoh] Could you provide the full stack trace?
Launchpad notification thread cannot access JNDI ressources on Websphere
Key: SLING-3525
URL: https://issues.apache.org/jira/browse/SLING-3525
Project: Sling
Issue Type: Improvement
Components: Launchpad
Affects Versions: Launchpad Base 2.5.0
Environment: Websphere 7 on Linux
Reporter: Jörg Hoh
We have an existing JavaEnterprise-based application, which we want to move
into sling running on IBM Websphere appserver. In some of the resulting
bundles we need to access JNDI resources.
We get this exception:
{code}
[29.04.14 03:14:01:790 CEST] FFDC
Exception:javax.naming.ConfigurationException
SourceId:com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS
ProbeId:440 Reporter:java.lang.Class@5ef85ef8
javax.naming.ConfigurationException: A JNDI operation on a java: name
cannot be completed because the server runtime is not able to associate the
operation's thread with any J2EE application component. This condition can
occur when the JNDI client using the java: name is not executed on the
thread of a server application request. Make sure that a J2EE application
does not execute JNDI operations on java: names within static code blocks
or in threads created by that J2EE application. Such code does not
necessarily run on the thread of a server application request and therefore
is not supported by JNDI operations on java: names. [Root exception is
javax.naming.NameNotFoundException: Name comp/env/tm not found in context
java:.]
at
com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:428)
at
com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:399)
at
com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:221)
at
com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:161)
at javax.naming.InitialContext.lookup(InitialContext.java:436)
...
at
org.apache.sling.launchpad.webapp.SlingServlet.startSling(SlingServlet.java:384)
at
org.apache.sling.launchpad.webapp.SlingServlet.updated(SlingServlet.java:262)
at
org.apache.sling.launchpad.base.impl.SlingFelix$Notifier.run(SlingFelix.java:172)
at java.lang.Thread.run(Thread.java:761)
Caused by: javax.naming.NameNotFoundException: Name comp/env/tm not found in
context java:.
at
com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1837)
at
com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1166)
at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:1095)
at
com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1235)
at
com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:395)
... 60 more
{code}
According to the JavaEnterprise spec, you should not create threads on your
own but use the mechanisms of the appserver (mostly because of the massive
use of threadlocals to access JDNI and stuff like that). See
http://stackoverflow.com/questions/533783/why-spawning-threads-in-java-ee-container-is-discouraged
for some discussion of it.
We would like the Launchpad to use a native Websphere thread so it can
actually do JNDI lookups, and not to create a new thread on the fly.
We would like to avoid any change to the way how JNDI resources are looked up
in our application.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: Sling Discovery implementation on AWS S3
Hi, 2014-05-12 9:02 GMT+01:00 Ian Boston i...@tfd.co.uk: Hi, +1 for distribution of properties via S3, makes perfect sense. Perhaps abstracting behind an API so that any low latency globally distributed storage provider could be used. Yes, discussing this offline with Felix, an alternative could be to implement a ResourceProvider for S3. S3 is really low level (key-value pair) with objects being binaries + metadata. We could implement the path structure based on the prefix property in [3] and stick to storing binaries only so that other S3 consumers can access the data directly (without using a Sling API). Not sure about discovery. Although [0] described the AWS VM, it doesn't, without further validation describe if the Sling instance is running and available. Its perfectly possible for the VM to be in a running state, with no viable Sling instance running. I dont think that hard to achieve but it needs to be done to support the discovery use case. Exactly, ootb, the AWS API has no concept of Sling instance and we should implement it. According to [2] we could *not* leverage instance metadata since they can't be modified at runtime. Thus, we would need to have The Sling instances publish their state in S3. I think we are talking about instances running on independent repositories here, since if all instances share the same repository (ie are a Jackrabbit cluster), then the repository already has a mechanism of communicating running instances via the repository. +1 Best Regards Ian On 12 May 2014 07:06, Carsten Ziegeler cziege...@apache.org wrote: Hi Timotheé, yes I think this is valuable - the idea of the discovery API is to abstract the discovery and if we can benefit in certain scenarios from already available mechanism/information I think it makes totally sense to use that instead of adding the same on top of it. Right now, the topology is formed of clusters containing instances - where all instances in a cluster share the same repository, but instances in different clusters use a different one. Is this kind of topology somehow possible by using the AWS API? Or would all instances end up in a single cluster? Regards Carsten 2014-05-11 18:54 GMT+02:00 Timothée Maret timothee.ma...@gmail.com: Hi, I would like to discuss a potential implementation of the Sling Discovery APIs over an eventually consistent distributed storages such as AWS S3. Assuming the instances being part of the topology runs in AWS, then we could leverage AWS APIs and service in order to implement the Discovery mechanism. The discovery of instances could be implemented implicitely using EC2 REST API [0] without sending heartbeats, the properties for each instance could be stored in AWS S3 and distributed eventually, the leader election could be implemented with [1] or similar. The benefits (over Sling impl) would be * Arguably the highest availablity we can get from the environment * Reduced bandwith consumption (no hearthbeats) * Environment specific informations is implicitely distributed (local ip, external ip, hostname, region, etc.) Of course, it would bind the implementation to an environment (AWS in this case), however I believe we could apply the same mechanism to other eventually consistent storage. Wdyt ? Is this something that would be valuable for Sling ? Regards, Timothee [0] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-DescribeInstances.html [1] http://gsyc.es/~anto/papers/2007-dsn.pdf -- Carsten Ziegeler cziege...@apache.org Regards Timothee [2] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html [3] http://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGET.html
Re: Sling Discovery implementation on AWS S3
If the usecase is only for Discovery it might be simpler to run Apache Zookeeper [1] and use Apache Curator [2] as noted in SLING-2939. While running on AWS one can possibly use Netflix Exhibitor [3] which manages the Zookeeper instances and backup there state in S3. The benefit of this approach is that Zookeeper abstract out all the complexities of leader election (which is hard!) and can also be used in on prem installation if required Chetan Mehrotra [1] http://zookeeper.apache.org/ [2] http://curator.apache.org/ [3] https://github.com/Netflix/exhibitor On Mon, May 12, 2014 at 2:54 PM, Timothée Maret timothee.ma...@gmail.com wrote: Hi, 2014-05-12 9:02 GMT+01:00 Ian Boston i...@tfd.co.uk: Hi, +1 for distribution of properties via S3, makes perfect sense. Perhaps abstracting behind an API so that any low latency globally distributed storage provider could be used. Yes, discussing this offline with Felix, an alternative could be to implement a ResourceProvider for S3. S3 is really low level (key-value pair) with objects being binaries + metadata. We could implement the path structure based on the prefix property in [3] and stick to storing binaries only so that other S3 consumers can access the data directly (without using a Sling API). Not sure about discovery. Although [0] described the AWS VM, it doesn't, without further validation describe if the Sling instance is running and available. Its perfectly possible for the VM to be in a running state, with no viable Sling instance running. I dont think that hard to achieve but it needs to be done to support the discovery use case. Exactly, ootb, the AWS API has no concept of Sling instance and we should implement it. According to [2] we could *not* leverage instance metadata since they can't be modified at runtime. Thus, we would need to have The Sling instances publish their state in S3. I think we are talking about instances running on independent repositories here, since if all instances share the same repository (ie are a Jackrabbit cluster), then the repository already has a mechanism of communicating running instances via the repository. +1 Best Regards Ian On 12 May 2014 07:06, Carsten Ziegeler cziege...@apache.org wrote: Hi Timotheé, yes I think this is valuable - the idea of the discovery API is to abstract the discovery and if we can benefit in certain scenarios from already available mechanism/information I think it makes totally sense to use that instead of adding the same on top of it. Right now, the topology is formed of clusters containing instances - where all instances in a cluster share the same repository, but instances in different clusters use a different one. Is this kind of topology somehow possible by using the AWS API? Or would all instances end up in a single cluster? Regards Carsten 2014-05-11 18:54 GMT+02:00 Timothée Maret timothee.ma...@gmail.com: Hi, I would like to discuss a potential implementation of the Sling Discovery APIs over an eventually consistent distributed storages such as AWS S3. Assuming the instances being part of the topology runs in AWS, then we could leverage AWS APIs and service in order to implement the Discovery mechanism. The discovery of instances could be implemented implicitely using EC2 REST API [0] without sending heartbeats, the properties for each instance could be stored in AWS S3 and distributed eventually, the leader election could be implemented with [1] or similar. The benefits (over Sling impl) would be * Arguably the highest availablity we can get from the environment * Reduced bandwith consumption (no hearthbeats) * Environment specific informations is implicitely distributed (local ip, external ip, hostname, region, etc.) Of course, it would bind the implementation to an environment (AWS in this case), however I believe we could apply the same mechanism to other eventually consistent storage. Wdyt ? Is this something that would be valuable for Sling ? Regards, Timothee [0] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-DescribeInstances.html [1] http://gsyc.es/~anto/papers/2007-dsn.pdf -- Carsten Ziegeler cziege...@apache.org Regards Timothee [2] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html [3] http://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGET.html
Re: [VOTE] Move commons compiler from contrib to bundles
Hi Chetan, On Thu, May 8, 2014 at 1:24 AM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: On Wed, May 7, 2014 at 11:29 AM, Carsten Ziegeler cziege...@apache.org wrote: Therefore I think we should move this bundle from its current place in the contrib section to the bundles section. Whats the general convention here. Do we have to move the bundle code to bundles folder if a release has to be made? Cannot we release from within contrib folder itself There's no requirement that a module be in bundles before being released. The bundles vs. contrib distinction is more about maintenance. Mostly it doesn't make sense to have a bundles module depend upon a contrib model. I'm +1 on the proposal. Justin Chetan Mehrotra
[jira] [Assigned] (SLING-3489) Fix the instructions on how to launch/deploy the demos
[ https://issues.apache.org/jira/browse/SLING-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-3489: --- Assignee: Carsten Ziegeler Fix the instructions on how to launch/deploy the demos -- Key: SLING-3489 URL: https://issues.apache.org/jira/browse/SLING-3489 Project: Sling Issue Type: Bug Components: Samples Reporter: David Bosschaert Assignee: Carsten Ziegeler Priority: Minor Attachments: launchdemos_4.diff Most Sling samples have incorrect instructions on how to get the Sling container running and on how to deploy the demo itself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3117) Node order changes made in .content.xml files are not persisted
[ https://issues.apache.org/jira/browse/SLING-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-3117: --- Assignee: Robert Munteanu Node order changes made in .content.xml files are not persisted --- Key: SLING-3117 URL: https://issues.apache.org/jira/browse/SLING-3117 Project: Sling Issue Type: Bug Components: IDE Reporter: Robert Munteanu Assignee: Robert Munteanu Fix For: Sling Eclipse IDE 1.0.0 If the node supports orderable child nodes we should reoder the child nodes to follow the order in the .content.xml file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-2635) [Tooling] Logging framework for Slingclipse
[ https://issues.apache.org/jira/browse/SLING-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13993559#comment-13993559 ] Robert Munteanu commented on SLING-2635: * http://svn.apache.org/viewvc?view=revisionrevision=1593531 - added API + impl for logging/debugging in org.apache.sling.ide.eclipse.core.debug * http://svn.apache.org/viewvc?view=revisionrevision=1593532 - remove duplicate tracer from resource-impl * http://svn.apache.org/viewvc?view=revisionrevision=1593533 - add tracing to eclipse-ui * http://svn.apache.org/viewvc?view=revisionrevision=1593534 - remove stray System.out from eclipse-test * http://svn.apache.org/viewvc?view=revisionrevision=1593535 - contribute to the platform tracing page [Tooling] Logging framework for Slingclipse --- Key: SLING-2635 URL: https://issues.apache.org/jira/browse/SLING-2635 Project: Sling Issue Type: Improvement Components: IDE Reporter: Antonio Sanso Assignee: Robert Munteanu Fix For: Sling Eclipse IDE 1.0.0 Attachments: SLING-2635.diff We need a Logging framework for Slingclipse. I see two options at the moment: - using a log framework as SLF4J logger or other similar - using the embedded Eclipse logging framework -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SLING-3116) Node structures serialized to a .content.xml file do not propagate deletions
[
https://issues.apache.org/jira/browse/SLING-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu resolved SLING-3116.
Resolution: Fixed
* http://svn.apache.org/viewvc?view=revisionrevision=1593959 implemented +
added IT
* http://svn.apache.org/viewvc?view=revisionrevision=1593960 improved generics
usage in Poller
Node structures serialized to a .content.xml file do not propagate deletions
Key: SLING-3116
URL: https://issues.apache.org/jira/browse/SLING-3116
Project: Sling
Issue Type: Bug
Components: IDE
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Fix For: Sling Eclipse IDE 1.0.0
Assume that a .content.xml file like the one below changes by
- removing the parent-1 node OR
- removing the child-1-2 node
We need to persist these deletions into the repository.
However, we need to be careful to propagate these only for full coverage
nodes.
{code}
?xml version=1.0 encoding=UTF-8?
jcr:root xmlns:sling=http://sling.apache.org/jcr/sling/1.0;
xmlns:vlt=http://www.day.com/jcr/vault/1.0;
xmlns:jcr=http://www.jcp.org/jcr/1.0;
jcr:mixinTypes=[vlt:FullCoverage]
jcr:primaryType=sling:Folder
jcr:title=Full coverage parent
parent-1
jcr:primaryType=sling:Folder
jcr:title=Parent 1
child-1-1
jcr:primaryType=sling:Folder
jcr:title=Child 1-1/
child-1-2
jcr:primaryType=sling:Folder
jcr:title=Child 1-2/
/parent-1
parent-2
jcr:primaryType=sling:Folder
jcr:title=Parent 2
child-2-1
jcr:primaryType=sling:Folder
jcr:title=Child 2-1/
child-2-2
jcr:primaryType=sling:Folder
jcr:title=Child 2-2/
/parent-2
/jcr:root
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: [VOTE] Release Apache Sling Tooling Support Install 1.0.0
For completeness, here's my +1 ( non-binding ) On Tue, May 6, 2014 at 12:26 PM, Robert Munteanu romb...@apache.org wrote: We're missing one binding vote, can someone else please take a look? Robert On Tue, May 6, 2014 at 9:16 AM, Carsten Ziegeler cziege...@apache.org wrote: +1 2014-05-05 17:16 GMT+02:00 Bertrand Delacretaz bdelacre...@apache.org: Hi, On Fri, May 2, 2014 at 2:32 PM, Robert Munteanu romb...@apache.org wrote: ... Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1056/ ... +1, checked signatures, build and svn tag of MD5 (./org.apache.sling.tooling.support.install/1.0.0/org.apache.sling.tooling.support.install-1.0.0-source-release.zip) = ab3ea7fdb9e874f4a5b8f0562cb7afbd -Bertrand -- Carsten Ziegeler cziege...@apache.org
[GitHub] sling pull request: SLING-3459, do not log exceptions which are re...
Github user asfgit closed the pull request at: https://github.com/apache/sling/pull/14 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (SLING-3552) Update minimum requirement to Eclipse Kepler
Robert Munteanu created SLING-3552: -- Summary: Update minimum requirement to Eclipse Kepler Key: SLING-3552 URL: https://issues.apache.org/jira/browse/SLING-3552 Project: Sling Issue Type: Task Components: IDE Affects Versions: Sling Eclipse IDE 1.0.0 Reporter: Robert Munteanu Assignee: Robert Munteanu To make use of enhanced APIs, we should set up a baseline with Eclipse Kepler. This should also be noted in the user guide. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Sling Discovery implementation on AWS S3
I'd agree with Chetan and Ian here in that S3 sounds feasible for persisting properties in a topology (rather than relying on the non-persistent nature of discovery-properties). The implementation of discovery itself I see as a separate discussion. Cheers, Stefan On 5/12/14 1:00 PM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: If the usecase is only for Discovery it might be simpler to run Apache Zookeeper [1] and use Apache Curator [2] as noted in SLING-2939. While running on AWS one can possibly use Netflix Exhibitor [3] which manages the Zookeeper instances and backup there state in S3. The benefit of this approach is that Zookeeper abstract out all the complexities of leader election (which is hard!) and can also be used in on prem installation if required Chetan Mehrotra [1] http://zookeeper.apache.org/ [2] http://curator.apache.org/ [3] https://github.com/Netflix/exhibitor On Mon, May 12, 2014 at 2:54 PM, Timothée Maret timothee.ma...@gmail.com wrote: Hi, 2014-05-12 9:02 GMT+01:00 Ian Boston i...@tfd.co.uk: Hi, +1 for distribution of properties via S3, makes perfect sense. Perhaps abstracting behind an API so that any low latency globally distributed storage provider could be used. Yes, discussing this offline with Felix, an alternative could be to implement a ResourceProvider for S3. S3 is really low level (key-value pair) with objects being binaries + metadata. We could implement the path structure based on the prefix property in [3] and stick to storing binaries only so that other S3 consumers can access the data directly (without using a Sling API). Not sure about discovery. Although [0] described the AWS VM, it doesn't, without further validation describe if the Sling instance is running and available. Its perfectly possible for the VM to be in a running state, with no viable Sling instance running. I dont think that hard to achieve but it needs to be done to support the discovery use case. Exactly, ootb, the AWS API has no concept of Sling instance and we should implement it. According to [2] we could *not* leverage instance metadata since they can't be modified at runtime. Thus, we would need to have The Sling instances publish their state in S3. I think we are talking about instances running on independent repositories here, since if all instances share the same repository (ie are a Jackrabbit cluster), then the repository already has a mechanism of communicating running instances via the repository. +1 Best Regards Ian On 12 May 2014 07:06, Carsten Ziegeler cziege...@apache.org wrote: Hi Timotheé, yes I think this is valuable - the idea of the discovery API is to abstract the discovery and if we can benefit in certain scenarios from already available mechanism/information I think it makes totally sense to use that instead of adding the same on top of it. Right now, the topology is formed of clusters containing instances - where all instances in a cluster share the same repository, but instances in different clusters use a different one. Is this kind of topology somehow possible by using the AWS API? Or would all instances end up in a single cluster? Regards Carsten 2014-05-11 18:54 GMT+02:00 Timothée Maret timothee.ma...@gmail.com: Hi, I would like to discuss a potential implementation of the Sling Discovery APIs over an eventually consistent distributed storages such as AWS S3. Assuming the instances being part of the topology runs in AWS, then we could leverage AWS APIs and service in order to implement the Discovery mechanism. The discovery of instances could be implemented implicitely using EC2 REST API [0] without sending heartbeats, the properties for each instance could be stored in AWS S3 and distributed eventually, the leader election could be implemented with [1] or similar. The benefits (over Sling impl) would be * Arguably the highest availablity we can get from the environment * Reduced bandwith consumption (no hearthbeats) * Environment specific informations is implicitely distributed (local ip, external ip, hostname, region, etc.) Of course, it would bind the implementation to an environment (AWS in this case), however I believe we could apply the same mechanism to other eventually consistent storage. Wdyt ? Is this something that would be valuable for Sling ? Regards, Timothee [0] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query -DescribeInstances.html [1] http://gsyc.es/~anto/papers/2007-dsn.pdf -- Carsten Ziegeler cziege...@apache.org Regards Timothee [2] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter-instance data.html [3] http://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGET.html
[jira] [Assigned] (SLING-3493) Javashell demo doesn't work
[ https://issues.apache.org/jira/browse/SLING-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-3493: --- Assignee: Carsten Ziegeler Javashell demo doesn't work --- Key: SLING-3493 URL: https://issues.apache.org/jira/browse/SLING-3493 Project: Sling Issue Type: Bug Components: Commons, Samples Reporter: David Bosschaert Assignee: Carsten Ziegeler Attachments: SLING-3493.diff The JavaShell demo doesn't work because its dependencies have issues with their metadata. The JavaShell demo has dependencies on the org.apache.sling.commons.compiler and org.apache.sling.scripting.java bundles. Both these bundles don't resolve. The org.apache.sling.commons.compiler bundle has: org.osgi.service.prefs,version=[1.1,2) -- Cannot be resolved The org.apache.sling.scripting.java bundle has: org.osgi.framework,version=[1.7,2) -- Cannot be resolved -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SLING-3548) Replication queue servlet doesn't use the queue parameter
[ https://issues.apache.org/jira/browse/SLING-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-3548. Resolution: Fixed fixed in r1593249 Replication queue servlet doesn't use the queue parameter - Key: SLING-3548 URL: https://issues.apache.org/jira/browse/SLING-3548 Project: Sling Issue Type: Bug Components: Extensions Reporter: Tommaso Teofili Assignee: Tommaso Teofili Priority: Trivial ReplicationQueueServlet gets but never uses an HTTP parameter to name the queue to be fetched, so that the default one is always returned. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3116) Node structures serialized to a .content.xml file do not propagate deletions
[
https://issues.apache.org/jira/browse/SLING-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995180#comment-13995180
]
Robert Munteanu commented on SLING-3116:
* http://svn.apache.org/viewvc?view=revisionrevision=1594005 fixed regression
when deploying file-like or folder-like nodes
Node structures serialized to a .content.xml file do not propagate deletions
Key: SLING-3116
URL: https://issues.apache.org/jira/browse/SLING-3116
Project: Sling
Issue Type: Bug
Components: IDE
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Fix For: Sling Eclipse IDE 1.0.0
Assume that a .content.xml file like the one below changes by
- removing the parent-1 node OR
- removing the child-1-2 node
We need to persist these deletions into the repository.
However, we need to be careful to propagate these only for full coverage
nodes.
{code}
?xml version=1.0 encoding=UTF-8?
jcr:root xmlns:sling=http://sling.apache.org/jcr/sling/1.0;
xmlns:vlt=http://www.day.com/jcr/vault/1.0;
xmlns:jcr=http://www.jcp.org/jcr/1.0;
jcr:mixinTypes=[vlt:FullCoverage]
jcr:primaryType=sling:Folder
jcr:title=Full coverage parent
parent-1
jcr:primaryType=sling:Folder
jcr:title=Parent 1
child-1-1
jcr:primaryType=sling:Folder
jcr:title=Child 1-1/
child-1-2
jcr:primaryType=sling:Folder
jcr:title=Child 1-2/
/parent-1
parent-2
jcr:primaryType=sling:Folder
jcr:title=Parent 2
child-2-1
jcr:primaryType=sling:Folder
jcr:title=Child 2-1/
child-2-2
jcr:primaryType=sling:Folder
jcr:title=Child 2-2/
/parent-2
/jcr:root
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SLING-3516) Sling Models Resource Child List Injector
[
https://issues.apache.org/jira/browse/SLING-3516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sechyn updated SLING-3516:
---
Attachment: ChildResourceInjectorPatch.diff
sorry for that. i have created and attached a new diff file. hope, it is better
now.
Sling Models Resource Child List Injector
-
Key: SLING-3516
URL: https://issues.apache.org/jira/browse/SLING-3516
Project: Sling
Issue Type: New Feature
Components: Extensions
Affects Versions: Sling Models Implementation 1.0.2
Reporter: Igor Sechyn
Priority: Minor
Attachments: ChildResourceInjectorPatch.diff
Hi All,
We have decided to use the sling models to process some hierarchical data in
our project and are facing the following issue right now.
Our content structure looks as follows:
{code}
+- dealer
|
+- addresses
|
+ -address1
|
+- address2
{code}
Dealer and address nodes have attributes, that can be injected through the
ValueMapInjector, so everything works fine here. Our goal however is also to
inject the List of AddressModel objects into the DealerModel object,
something like this:
{code}
@Inject
ListAddressModel addresses
{code}
The desired behavior would be:
- the injector resolves addresses as a child resource of the adaptable object
- iterates over the children of this resource (in this case „addresses)
- adapts each child to the actual type argument of the parameterized list type
- returns the list of adapted model objects
I have tried to play around with @Named but could not get it to work. The
only way of making it work, was to write a custom injector, which worked out
pretty fine.
But I was still wondering, if there might be an OOTB functionality, which can
be used for this use case
Cheers, Igor.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SLING-3493) Javashell demo doesn't work
[ https://issues.apache.org/jira/browse/SLING-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995095#comment-13995095 ] Carsten Ziegeler commented on SLING-3493: - [~bosschaert] Thanks for the work and patch - I think at least the scripting java pom was pretty outdated. It shouldn't point to a snapshot version. I've updated that one to the latest release and the current commons compiler looks different now as well (due to some updates for Java 8). Could you please recheck with the latest stuff from trunk? Javashell demo doesn't work --- Key: SLING-3493 URL: https://issues.apache.org/jira/browse/SLING-3493 Project: Sling Issue Type: Bug Components: Commons, Samples Reporter: David Bosschaert Assignee: Carsten Ziegeler Attachments: SLING-3493.diff The JavaShell demo doesn't work because its dependencies have issues with their metadata. The JavaShell demo has dependencies on the org.apache.sling.commons.compiler and org.apache.sling.scripting.java bundles. Both these bundles don't resolve. The org.apache.sling.commons.compiler bundle has: org.osgi.service.prefs,version=[1.1,2) -- Cannot be resolved The org.apache.sling.scripting.java bundle has: org.osgi.framework,version=[1.7,2) -- Cannot be resolved -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SLING-3529) Move startup handling to a separate bundle
[ https://issues.apache.org/jira/browse/SLING-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3529. - Resolution: Fixed Move startup handling to a separate bundle -- Key: SLING-3529 URL: https://issues.apache.org/jira/browse/SLING-3529 Project: Sling Issue Type: New Feature Components: Launchpad Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Launchpad Base 2.5.2, Launchpad Impl 1.0.0 The startup handler is currently embedded in the Sling launchpad base - which makes it impossible to use when Sling is installed in another container like e.g. Apache Karaf. We should move this to a separate bundle to make it more reusable -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3516) Sling Models Resource Child List Injector
[
https://issues.apache.org/jira/browse/SLING-3516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995163#comment-13995163
]
Justin Edelson commented on SLING-3516:
---
Please do not include formatting changes in patches. It makes it very difficult
to figure out what has actually changed.
Sling Models Resource Child List Injector
-
Key: SLING-3516
URL: https://issues.apache.org/jira/browse/SLING-3516
Project: Sling
Issue Type: New Feature
Components: Extensions
Affects Versions: Sling Models Implementation 1.0.2
Reporter: Igor Sechyn
Priority: Minor
Attachments: ChildResourceInjectorPatch.txt
Hi All,
We have decided to use the sling models to process some hierarchical data in
our project and are facing the following issue right now.
Our content structure looks as follows:
{code}
+- dealer
|
+- addresses
|
+ -address1
|
+- address2
{code}
Dealer and address nodes have attributes, that can be injected through the
ValueMapInjector, so everything works fine here. Our goal however is also to
inject the List of AddressModel objects into the DealerModel object,
something like this:
{code}
@Inject
ListAddressModel addresses
{code}
The desired behavior would be:
- the injector resolves addresses as a child resource of the adaptable object
- iterates over the children of this resource (in this case „addresses)
- adapts each child to the actual type argument of the parameterized list type
- returns the list of adapted model objects
I have tried to play around with @Named but could not get it to work. The
only way of making it work, was to write a custom injector, which worked out
pretty fine.
But I was still wondering, if there might be an OOTB functionality, which can
be used for this use case
Cheers, Igor.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SLING-3516) Sling Models Resource Child List Injector
[
https://issues.apache.org/jira/browse/SLING-3516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sechyn updated SLING-3516:
---
Attachment: (was: ChildResourceInjectorPatch.txt)
Sling Models Resource Child List Injector
-
Key: SLING-3516
URL: https://issues.apache.org/jira/browse/SLING-3516
Project: Sling
Issue Type: New Feature
Components: Extensions
Affects Versions: Sling Models Implementation 1.0.2
Reporter: Igor Sechyn
Priority: Minor
Attachments: ChildResourceInjectorPatch.diff
Hi All,
We have decided to use the sling models to process some hierarchical data in
our project and are facing the following issue right now.
Our content structure looks as follows:
{code}
+- dealer
|
+- addresses
|
+ -address1
|
+- address2
{code}
Dealer and address nodes have attributes, that can be injected through the
ValueMapInjector, so everything works fine here. Our goal however is also to
inject the List of AddressModel objects into the DealerModel object,
something like this:
{code}
@Inject
ListAddressModel addresses
{code}
The desired behavior would be:
- the injector resolves addresses as a child resource of the adaptable object
- iterates over the children of this resource (in this case „addresses)
- adapts each child to the actual type argument of the parameterized list type
- returns the list of adapted model objects
I have tried to play around with @Named but could not get it to work. The
only way of making it work, was to write a custom injector, which worked out
pretty fine.
But I was still wondering, if there might be an OOTB functionality, which can
be used for this use case
Cheers, Igor.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SLING-3459) sling:call should not log exceptions with the full stacktrace
[ https://issues.apache.org/jira/browse/SLING-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995106#comment-13995106 ] ASF GitHub Bot commented on SLING-3459: --- Github user asfgit closed the pull request at: https://github.com/apache/sling/pull/14 sling:call should not log exceptions with the full stacktrace - Key: SLING-3459 URL: https://issues.apache.org/jira/browse/SLING-3459 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: Scripting JSP-Taglib 2.1.8 Reporter: Konrad Windszus Fix For: Scripting JSP-Taglib 2.2.2 Currently within the sling:call tag all exceptions are both logged on error level and rethrown (https://fisheye6.atlassian.com/browse/~br=trunk/sling/trunk/bundles/scripting/jsp-taglib/src/main/java/org/apache/sling/scripting/jsp/taglib/CallTag.java?r=1398589r=1520554r=1398589#to139). That is not a good practice, because the same stack traces would appear twice in the log (once for the generic exception, logged by the CallTag and once for the wrapped JspException). Rather do not log the exception within the CallTag and leave that to other handlers. Just rewrapping the exception into the JspException should be enough. No information would be lost that way, and stack traces would only be logged once (by the code responsible to catch the JspException). -- This message was sent by Atlassian JIRA (v6.2#6252)
Jenkins build became unstable: sling-trunk-1.7 » Apache Sling Resource-Based Discovery Service #488
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.impl/488/
[GitHub] sling pull request: SLING-3547, add test for numerical defaults (b...
GitHub user kwin opened a pull request: https://github.com/apache/sling/pull/16 SLING-3547, add test for numerical defaults (both boolean and long, test exposing the wrong behaviour of numerical defaults in Sling Models You can merge this pull request into a Git repository by running: $ git pull https://github.com/kwin/sling SLING-3547 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/sling/pull/16.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #16 commit 63b59bceecae1670a58da257d9165a5905a52075 Author: Konrad Windszus konrad.winds...@netcentric.biz Date: 2014-05-08T12:37:19Z SLING-3547, add test for numerical defaults (both boolean and long, primitive and object wrapper) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Jenkins build is back to stable : sling-trunk-1.7 #489
See https://builds.apache.org/job/sling-trunk-1.7/489/changes
[jira] [Resolved] (SLING-3489) Fix the instructions on how to launch/deploy the demos
[ https://issues.apache.org/jira/browse/SLING-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3489. - Resolution: Fixed Thanks for your work and patch, David. It's applied with rev 1593967 Fix the instructions on how to launch/deploy the demos -- Key: SLING-3489 URL: https://issues.apache.org/jira/browse/SLING-3489 Project: Sling Issue Type: Bug Components: Samples Reporter: David Bosschaert Assignee: Carsten Ziegeler Priority: Minor Attachments: launchdemos_4.diff Most Sling samples have incorrect instructions on how to get the Sling container running and on how to deploy the demo itself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3551) Content sync does not propagate mixin types
[
https://issues.apache.org/jira/browse/SLING-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13993870#comment-13993870
]
Robert Munteanu commented on SLING-3551:
* http://svn.apache.org/viewvc?view=revisionrevision=1593604 make
RepositoryUtils API so that it can be used by the eclipse test utils
* http://svn.apache.org/viewvc?view=revisionrevision=1593605 make the
RepositoryAccessor use JCR APIs when needed.
* http://svn.apache.org/viewvc?view=revisionrevision=1593606 add helpers.jcr
package for working with JCR data
* http://svn.apache.org/viewvc?view=revisionrevision=1593607 make the Poller
propagate the last caught error after a timeout
* http://svn.apache.org/viewvc?view=revisionrevision=1593608 sync mixin types
whenever a node is created or updated ( + test )
Content sync does not propagate mixin types
---
Key: SLING-3551
URL: https://issues.apache.org/jira/browse/SLING-3551
Project: Sling
Issue Type: Bug
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Fix For: Sling Eclipse IDE 1.0.0
Assume that we have a full coverage aggregate as follows:
{code}
?xml version=1.0 encoding=UTF-8?
jcr:root xmlns:sling=http://sling.apache.org/jcr/sling/1.0;
xmlns:vlt=http://www.day.com/jcr/vault/1.0;
xmlns:jcr=http://www.jcp.org/jcr/1.0;
jcr:mixinTypes=[mix:language]
jcr:primaryType=nt:folder
jcr:language=en
message
jcr:primaryType=sling:MessageEntry
sling:key=message
sling:value=Message
/message
error
jcr:primaryType=sling:MessageEntry
sling:key=error
sling:value=Error
/error
warning
jcr:primaryType=sling:MessageEntry
sling:key=warning
sling:value=Warning
/warning
/jcr:root
{code}
When synced to the repo this will fail with the following message
{quote}!MESSAGE Failed publishing JcrResult[ success:false, exception:
org.apache.sling.ide.transport.RepositoryException -
javax.jcr.nodetype.ConstraintViolationException: no matching property
definition found for {http://www.jcp.org/jcr/1.0}language]{quote}
The reason is that the jcr:mixinTypes property is protected, and therefore
skipped. We need to handle this explicitly.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Jenkins build became unstable: sling-trunk-1.7 » Apache Sling Resource-Based Discovery Service #492
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.impl/492/
