[jira] [Assigned] (SLING-3713) VanityPathTest testRedirectOnPathWithExtension fails: Expecting temporary redirect expected:302 but was:404
[
https://issues.apache.org/jira/browse/SLING-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Sanso reassigned SLING-3713:
Assignee: Antonio Sanso
VanityPathTest testRedirectOnPathWithExtension fails: Expecting temporary
redirect expected:302 but was:404
Key: SLING-3713
URL: https://issues.apache.org/jira/browse/SLING-3713
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Reporter: Robert Munteanu
Assignee: Antonio Sanso
Fix For: Resource Resolver 1.1.2
This failure was first seen in
[https://builds.apache.org/view/S-Z/view/Sling/job/sling-trunk-1.7/612|sling-trunk-1.7
build 612] - rev 1606740 .
{code}Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.142
sec FAILURE! - in
org.apache.sling.launchpad.webapp.integrationtest.VanityPathTest
testRedirectOnPathWithExtension(org.apache.sling.launchpad.webapp.integrationtest.VanityPathTest)
Time elapsed: 0.546 sec FAILURE!
junit.framework.AssertionFailedError: Expecting temporary redirect
expected:302 but was:404
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:234)
at junit.framework.TestCase.assertEquals(TestCase.java:401)
at
org.apache.sling.launchpad.webapp.integrationtest.VanityPathTest.testRedirectOnPathWithExtension(VanityPathTest.java:186){code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: [VOTE] Release Apache Sling IDE Tooling 1.0.0
Thanks for redoing, Robert. +1 Carsten 2014-07-01 2:01 GMT+02:00 Justin Edelson jus...@justinedelson.com: +1 On Mon, Jun 30, 2014 at 12:14 PM, Robert Munteanu rob...@lmn.ro wrote: I think I've gotten the right Maven/Tycho incantations set up and deployed the 1.0.0 artifacts to https://repository.apache.org/content/repositories/orgapachesling-1072/ The single compromise that I had to make is that the integration tests were not included in the reactor build and therefore not deployed to the nexus repo. Hopefully that's acceptable for the release. I can restart the release vote if needed ( third time's the charm? ) but it would be good to know that I got things right this time. Note: check_staged_release.sh took about 30 minutes to complete for me. Thanks, Robert On Mon, Jun 30, 2014 at 1:53 PM, Carsten Ziegeler cziege...@apache.org wrote: Thanks for the info, Robert - I'm not sure what the best approach is, however the zip now contains 1.0.0-SNAPSHOT as versions but I guess the final release should be 1.0.0. This would mean we're voting on something which is then not released. On the other hand, if we put up 1.0.0 in a globally available space everyone can simply download it from there and voting, especially withdrawing the release is way harder. Carsten 2014-06-30 10:06 GMT+02:00 Robert Munteanu romb...@apache.org: Hi Carsten, On Mon, Jun 30, 2014 at 8:57 AM, Carsten Ziegeler cziege...@apache.org wrote: Why is this release not following the normal release procedure and available via the staging maven repo? There are two main reasons. 1. While the build is driven by Maven, building Eclipse plug-ins with Tycho means that some of the regular Maven plugins don't work. For instance, the source and javadoc plugin, see [1],[2] . Since IIUC the release is based on the source code, and the binaries are just for convenience, I opted not to make the release run on the output of individual projects, but on the whole source zip. 2. If I were to deploy the plug-ins by themselves to the repo, it would not be trivial to assemble back an p2/Eclipse update which can be used to test the functionality of the release. That being said, I'd be more than happy to refine this process, so suggestions on how to do that are welcome :-) Thanks, Robert [1]: https://dev.eclipse.org/mhonarc/lists/tycho-user/msg05730.html [2]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=398061 Carsten 2014-06-29 21:32 GMT+02:00 Robert Munteanu romb...@apache.org: Anyone? Robert On Thu, Jun 26, 2014 at 11:32 AM, Robert Munteanu romb...@apache.org wrote: Hi, We solved 144 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12324873 There are still some outstanding issues: https://issues.apache.org/jira/browse/SLING/component/12320908 The release candidate has been uploaded at https://dist.apache.org/repos/dist/dev/sling, and can be built using mvn clean package The resulting binaries can be installed into an Eclipse instance by installing from the update site which is found at p2update/target/repository after building the project. Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Sent from my (old) computer -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Created] (SLING-3719) MapEntries-updateTargetPaths holds incorrect information in case of exception while creating a MapEntry
Antonio Sanso created SLING-3719:
Summary: MapEntries-updateTargetPaths holds incorrect
information in case of exception while creating a MapEntry
Key: SLING-3719
URL: https://issues.apache.org/jira/browse/SLING-3719
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Reporter: Antonio Sanso
Assignee: Antonio Sanso
MapEntries-updateTargetPaths holds incorrect information in case of exception
while creating a MapEntry (e.g. if the vanity path is on the form
/content/mypage/en-us-{132 )
I will add a unit test that show this behaviour
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (SLING-3719) MapEntries-updateTargetPaths holds incorrect information in case of exception while creating a MapEntry
[
https://issues.apache.org/jira/browse/SLING-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Sanso resolved SLING-3719.
--
Resolution: Fixed
Fix Version/s: Resource Resolver 1.1.2
added unit test and fix in r1606994
MapEntries-updateTargetPaths holds incorrect information in case of
exception while creating a MapEntry
-
Key: SLING-3719
URL: https://issues.apache.org/jira/browse/SLING-3719
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Reporter: Antonio Sanso
Assignee: Antonio Sanso
Fix For: Resource Resolver 1.1.2
MapEntries-updateTargetPaths holds incorrect information in case of
exception while creating a MapEntry (e.g. if the vanity path is on the form
/content/mypage/en-us-{132 )
I will add a unit test that show this behaviour
--
This message was sent by Atlassian JIRA
(v6.2#6252)
adaptTo and results ....
Hi
There currently are two issues floating around dealing with the question of
returning more information than just null from the Adaptable.adaptTo(Class)
method: https://issues.apache.org/jira/browse/SLING-3714 and
https://issues.apache.org/jira/browse/SLING-3709. I think these requests
warrant some discussion on the list.
Background: adaptTo can be implemented by Adaptable implementations themselves
or, by extending from SlingAdaptable, they may defer to an AdapterMananager.
AdapterManager itself is extended by AdapterFactory services. All these
interfaces define an adaptTo method. All these methods return null if adaption
is not possible and don't declare or document to throw an exception.
While not explicitly documented as such, the intention is and was that adaptTo
never throws on the grounds that adaption may fail which is considered a valid
result and thus exceptions are not to be expected and handled.
Hence all implementations of the methods generally
catch-and-log-but-don't-throw. Interestingly SlingAdaptable.adaptTo and
AdapterManagerImpl.getAdapter don't catch — so any RuntimeException thrown from
an AdapterFactory would be forwarded.
Having said this there are options available:
(1) Add support for a new Result? class. We would probably implement this in
the AdapterManager.getAdapter implementation explicitly handling this case
because it would entail catching the adaptTo/getAdapter calls to get the
exception (the Result.getError should return Throwable probably not Error)
Use would be limited to new AdapterFactory implementations throwing
RuntimeExcpetion. For Sling Models this would be the case.
(2) Add a new adaptToOrThrow method, which is declared to throw a
RuntimeException and never return null: Either it can adapt or it throws. This
would require a new interface Adaptable2 (probably) to not break existing
Adaptable implementations. The SlingAdaptable base class would implement the
new method of course, probably something like this:
SlingAdaptable implements Adaptable2 {
…
public AdapterType AdapterType adaptToOrThrow(ClassAdapterType type) {
AdapterType result = this.adaptTo(type);
if (result != null) {
return result;
}
throw new CannotAdaptException(…);
}
}
Use is problematic because you would have to know whether you can call the new
method: So instead of an null check you now have an instanceof check … Except
for the Resource interface which would be extended to extend from Adaptable2 as
well.
(3) Document, that Adaptable.adaptTo may throw a RuntimeException.
The problem here is, that this may conceptually break existing callers of
Adaptable.adaptTo which don't expect an exception at all — presumably this is a
minor nuisance because technically a RuntimeException may always be thrown.
Regards
Felix
Re: adaptTo and results ....
Hi, On Tue, Jul 1, 2014 at 9:07 AM, Felix Meschberger fmesc...@adobe.com wrote: ..there are options available... Just a wild idea, how about this: Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class)); which could be handled by the AdapterManagerImpl, by wrapping whatever adapter it finds so that a null result throws a CannotAdaptException? Needs some magic so that RequireAdapter.for manufactures a class that triggers the AdapterManagerImpl wrapping, but that should be doable with proxies or bytecode manipulation, and that magic is just between RequireAdapter and AdapterManagerImpl, so doesn't leak everywhere. -Bertrand
Re: adaptTo and results ....
On Tue, Jul 1, 2014 at 9:41 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: ...how about this: Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class)); Actually, rereading SLING-3714, this can be made simpler with generics Foo f = someObject.adaptTo(RequireAdapterFoo.class)); where RequireAdapter causes AdapterManagerImpl to wrap the adapters to throw an exception if adaption returns null. -Bertrand
Re: adaptTo and results ....
Regarding 1) Having such a Result class would mean that all consumer would need
to unwrap the exception first. So instead of being forced of implementing a
null-check (as with the old solution) one would need to implement another
check. I want to prevent such a burden to the consumers.
Regarding 2) Since the client code knows on which object the adaptToOrThrow is
called I don’t get why an instanceof check is necessary. Whether this object
implements Adaptable2 is known at compile-time, so you do have the full
IDE-support here.
Regarding 3) In that case I would no longer allow a null value to be returned.
One drawback is, that all the null checks are no longer effective.
IMHO solution 2) is the best. At the same time I would deprecate the old
Adaptable, because I cannot come up with a real use-case where returning has an
advantage. I would rather implement another method boolean
hasAdapter(ClassAdapterType type) on the Adaptable2 interface.
Regards,
Konrad
On 01 Jul 2014, at 09:07, Felix Meschberger fmesc...@adobe.com wrote:
Hi
There currently are two issues floating around dealing with the question of
returning more information than just null from the Adaptable.adaptTo(Class)
method: https://issues.apache.org/jira/browse/SLING-3714 and
https://issues.apache.org/jira/browse/SLING-3709. I think these requests
warrant some discussion on the list.
Background: adaptTo can be implemented by Adaptable implementations
themselves or, by extending from SlingAdaptable, they may defer to an
AdapterMananager. AdapterManager itself is extended by AdapterFactory
services. All these interfaces define an adaptTo method. All these methods
return null if adaption is not possible and don't declare or document to
throw an exception.
While not explicitly documented as such, the intention is and was that
adaptTo never throws on the grounds that adaption may fail which is
considered a valid result and thus exceptions are not to be expected and
handled.
Hence all implementations of the methods generally
catch-and-log-but-don't-throw. Interestingly SlingAdaptable.adaptTo and
AdapterManagerImpl.getAdapter don't catch — so any RuntimeException thrown
from an AdapterFactory would be forwarded.
Having said this there are options available:
(1) Add support for a new Result? class. We would probably implement this
in the AdapterManager.getAdapter implementation explicitly handling this case
because it would entail catching the adaptTo/getAdapter calls to get the
exception (the Result.getError should return Throwable probably not Error)
Use would be limited to new AdapterFactory implementations throwing
RuntimeExcpetion. For Sling Models this would be the case.
(2) Add a new adaptToOrThrow method, which is declared to throw a
RuntimeException and never return null: Either it can adapt or it throws.
This would require a new interface Adaptable2 (probably) to not break
existing Adaptable implementations. The SlingAdaptable base class would
implement the new method of course, probably something like this:
SlingAdaptable implements Adaptable2 {
…
public AdapterType AdapterType adaptToOrThrow(ClassAdapterType type) {
AdapterType result = this.adaptTo(type);
if (result != null) {
return result;
}
throw new CannotAdaptException(…);
}
}
Use is problematic because you would have to know whether you can call the
new method: So instead of an null check you now have an instanceof check …
Except for the Resource interface which would be extended to extend from
Adaptable2 as well.
(3) Document, that Adaptable.adaptTo may throw a RuntimeException.
The problem here is, that this may conceptually break existing callers of
Adaptable.adaptTo which don't expect an exception at all — presumably this is
a minor nuisance because technically a RuntimeException may always be thrown.
Regards
Felix
Build failed in Jenkins: sling-contrib-1.6 » Apache Sling Replication Integration Tests #1161
See https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/1161/ -- [INFO] [INFO] [INFO] Building Apache Sling Replication Integration Tests 0.0.1-SNAPSHOT [INFO] Downloading: http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.testing.tools/1.0.7-SNAPSHOT/maven-metadata.xml [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ org.apache.sling.replication.it --- [INFO] Deleting https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target [INFO] Deleting https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/ (includes = [sling/**], excludes = []) [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-java) @ org.apache.sling.replication.it --- [INFO] [INFO] --- maven-antrun-plugin:1.7:run (set-bundle-required-execution-environment) @ org.apache.sling.replication.it --- [INFO] Executing tasks main: [INFO] Executed tasks [INFO] [INFO] --- maven-remote-resources-plugin:1.5:process (default) @ org.apache.sling.replication.it --- [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ org.apache.sling.replication.it --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/src/main/resources [INFO] Copying 3 resources [INFO] [INFO] --- maven-antrun-plugin:1.7:run (check-memory-task) @ org.apache.sling.replication.it --- [INFO] Executing tasks main: [echo] WARNING (SLING-443/SLING-1782) ** [echo] On most platforms, you'll get OutOfMemoryErrors when building unless you set [echo] on 32bit platforms: MAVEN_OPTS=-Xmx256M -XX:MaxPermSize=256M, see SLING-443 [echo] on 64bit platforms: MAVEN_OPTS=-Xmx512M -XX:MaxPermSize=512M, see SLING-1782 [echo] ** [INFO] Executed tasks [INFO] [INFO] --- maven-dependency-plugin:2.8:copy-dependencies (copy-runnable-jar) @ org.apache.sling.replication.it --- [INFO] Copying org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/dependency/org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar [INFO] [INFO] --- maven-dependency-plugin:2.8:copy-dependencies (copy-additional-bundles) @ org.apache.sling.replication.it --- [INFO] Copying org.apache.sling.commons.json-2.0.6.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/org.apache.sling.commons.json-2.0.6.jar [INFO] Copying jackrabbit-jcr-commons-2.7.2.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/jackrabbit-jcr-commons-2.7.2.jar [INFO] Copying slf4j-api-1.5.11.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/slf4j-api-1.5.11.jar [INFO] Copying jackrabbit-api-2.7.2.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/jackrabbit-api-2.7.2.jar [INFO] Copying commons-io-2.4.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/commons-io-2.4.jar [INFO] Copying jcr-2.0.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/jcr-2.0.jar [INFO] Copying junit-4.8.2.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/junit-4.8.2.jar [INFO] Copying org.apache.sling.replication-0.0.1-SNAPSHOT.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/org.apache.sling.replication-0.0.1-SNAPSHOT.jar [INFO] Copying bndlib-1.50.0.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/bndlib-1.50.0.jar [INFO] Copying org.apache.felix.scr.annotations-1.9.8.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/org.apache.felix.scr.annotations-1.9.8.jar [INFO] Copying org.apache.sling.api-2.5.0.jar to
Build failed in Jenkins: sling-contrib-1.6 #1161
See https://builds.apache.org/job/sling-contrib-1.6/1161/changes Changes: [olli] SLING-3027 use latest release (Sling Service User Mapper) -- [...truncated 2924 lines...] [INFO] Copying jackrabbit-jcr-commons-2.7.2.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/jackrabbit-jcr-commons-2.7.2.jar [INFO] Copying slf4j-api-1.5.11.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/slf4j-api-1.5.11.jar [INFO] Copying jackrabbit-api-2.7.2.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/jackrabbit-api-2.7.2.jar [INFO] Copying commons-io-2.4.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/commons-io-2.4.jar [INFO] Copying jcr-2.0.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/jcr-2.0.jar [INFO] Copying junit-4.8.2.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/junit-4.8.2.jar [INFO] Copying org.apache.sling.replication-0.0.1-SNAPSHOT.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/org.apache.sling.replication-0.0.1-SNAPSHOT.jar [INFO] Copying bndlib-1.50.0.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/bndlib-1.50.0.jar [INFO] Copying org.apache.felix.scr.annotations-1.9.8.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/org.apache.felix.scr.annotations-1.9.8.jar [INFO] Copying org.apache.sling.api-2.5.0.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/org.apache.sling.api-2.5.0.jar [INFO] Copying org.apache.sling.commons.osgi-2.2.0.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/org.apache.sling.commons.osgi-2.2.0.jar [INFO] Copying org.apache.sling.hc.core-1.0.6.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/org.apache.sling.hc.core-1.0.6.jar [INFO] Copying slf4j-simple-1.5.11.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/slf4j-simple-1.5.11.jar [INFO] Copying org.apache.sling.testing.tools-1.0.7-SNAPSHOT.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/org.apache.sling.testing.tools-1.0.7-SNAPSHOT.jar [INFO] Copying httpclient-osgi-4.3.2.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/httpclient-osgi-4.3.2.jar [INFO] Copying org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar [INFO] Copying servlet-api-2.4.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/servlet-api-2.4.jar [INFO] Copying org.apache.jackrabbit.vault-3.0.0.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/org.apache.jackrabbit.vault-3.0.0.jar [INFO] Copying httpcore-osgi-4.3.1.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/httpcore-osgi-4.3.1.jar [INFO] [INFO] --- build-helper-maven-plugin:1.8:reserve-network-port (reserve-server-port) @ org.apache.sling.replication.it --- [INFO] Reserved port 48806 for author.http.port [INFO] Reserved port 60564 for publish.http.port [INFO] [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ org.apache.sling.replication.it --- [INFO] No sources to compile [INFO] [INFO] --- maven-scr-plugin:1.16.0:scr (generate-scr-scrdescriptor) @ org.apache.sling.replication.it --- [WARNING] Source tree does not exist. Ignoring https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/src/main/java [WARNING] Source tree does not exist. Ignoring https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/src/main/java [WARNING] Source tree does not exist. Ignoring https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/src/main/java [INFO] [INFO] ---
Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Models Integration Tests #2240
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.models.integration-tests/2240/
Jenkins build is still unstable: sling-trunk-1.6 #2240
See https://builds.apache.org/job/sling-trunk-1.6/changes
[jira] [Updated] (SLING-3720) Make Crankstart launcher add path to its JAR as a system property
[ https://issues.apache.org/jira/browse/SLING-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artyom Stetsenko updated SLING-3720: Description: Crankstart launcher should determine the path to its JAR and add it as a system property. This property would be useful for Crankstart itself or for its applications to crankstart other applications programmatically. (was: Crankstart launcher should determine the path to its JAR and add it as a system property. This property would be useful for crankstart itself or for its applications to crankstart other applications programmatically.) Make Crankstart launcher add path to its JAR as a system property - Key: SLING-3720 URL: https://issues.apache.org/jira/browse/SLING-3720 Project: Sling Issue Type: Improvement Components: Crankstart Reporter: Artyom Stetsenko Labels: crankstart, jar, path, property Attachments: crankstart.jar.path.patch Crankstart launcher should determine the path to its JAR and add it as a system property. This property would be useful for Crankstart itself or for its applications to crankstart other applications programmatically. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3720) Make Crankstart launcher add path to its JAR as a system property
[
https://issues.apache.org/jira/browse/SLING-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artyom Stetsenko updated SLING-3720:
Attachment: crankstart.jar.path.patch
Attached patch that adds {{crankstart.jar.path}} property.
Make Crankstart launcher add path to its JAR as a system property
-
Key: SLING-3720
URL: https://issues.apache.org/jira/browse/SLING-3720
Project: Sling
Issue Type: Improvement
Components: Crankstart
Reporter: Artyom Stetsenko
Labels: crankstart, jar, path, property
Attachments: crankstart.jar.path.patch
Crankstart launcher should determine the path to its JAR and add it as a
system property. This property would be useful for Crankstart itself or for
its applications to crankstart other applications programmatically.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (SLING-3720) Make Crankstart launcher add path to its JAR as a system property
Artyom Stetsenko created SLING-3720: --- Summary: Make Crankstart launcher add path to its JAR as a system property Key: SLING-3720 URL: https://issues.apache.org/jira/browse/SLING-3720 Project: Sling Issue Type: Improvement Components: Crankstart Reporter: Artyom Stetsenko Attachments: crankstart.jar.path.patch Crankstart launcher should determine the path to its JAR and add it as a system property. This property would be useful for crankstart itself or for its applications to crankstart other applications programmatically. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: adaptTo and results ....
Adding a new interface would require us to implement it all over the place
and as Felix points out, client code would always need to check whether the
new interface is implemented or not Having to methods, like hasAdapter and
adaptOrThrow does not work very well as between the two calls things might
have changed already: while hasAdapter returns true, the underlying factory
gets unregistered before adaptOrThrow is called.
In many use cases, the current pattern works fine - the client does not
care whether an exception is thrown within the adaption - it just cares
whether an object is returned or not. And there are valid use cases, where
client code does different things whether the adaption works or not (e.g.
the post servlet checks for adaptTo(Node) and then does additional things
if the resource is backed up by a node.)
I see the point that there are also use cases where it would be fine to
simpy throw an exception if adaptTo is not successful. This would make the
client code easier. However as this most properly is a runtime exception,
client code can today just call a method on the object and end up with a
NPE - having the same result :)
This leaves us with use cases where the client code explicitely wants to
catch the exception and then do something depending on the exception. Maybe
we should just add something for this explicit use case instead of bloating
the general adaptTo mechanism?
Regards
Carsten
2014-07-01 9:44 GMT+02:00 Konrad Windszus konra...@gmx.de:
Regarding 1) Having such a Result class would mean that all consumer would
need to unwrap the exception first. So instead of being forced of
implementing a null-check (as with the old solution) one would need to
implement another check. I want to prevent such a burden to the consumers.
Regarding 2) Since the client code knows on which object the
adaptToOrThrow is called I don’t get why an instanceof check is necessary.
Whether this object implements Adaptable2 is known at compile-time, so you
do have the full IDE-support here.
Regarding 3) In that case I would no longer allow a null value to be
returned. One drawback is, that all the null checks are no longer effective.
IMHO solution 2) is the best. At the same time I would deprecate the old
Adaptable, because I cannot come up with a real use-case where returning
has an advantage. I would rather implement another method boolean
hasAdapter(ClassAdapterType type) on the Adaptable2 interface.
Regards,
Konrad
On 01 Jul 2014, at 09:07, Felix Meschberger fmesc...@adobe.com wrote:
Hi
There currently are two issues floating around dealing with the question
of returning more information than just null from the
Adaptable.adaptTo(Class) method:
https://issues.apache.org/jira/browse/SLING-3714 and
https://issues.apache.org/jira/browse/SLING-3709. I think these requests
warrant some discussion on the list.
Background: adaptTo can be implemented by Adaptable implementations
themselves or, by extending from SlingAdaptable, they may defer to an
AdapterMananager. AdapterManager itself is extended by AdapterFactory
services. All these interfaces define an adaptTo method. All these methods
return null if adaption is not possible and don't declare or document to
throw an exception.
While not explicitly documented as such, the intention is and was that
adaptTo never throws on the grounds that adaption may fail which is
considered a valid result and thus exceptions are not to be expected and
handled.
Hence all implementations of the methods generally
catch-and-log-but-don't-throw. Interestingly SlingAdaptable.adaptTo and
AdapterManagerImpl.getAdapter don't catch — so any RuntimeException thrown
from an AdapterFactory would be forwarded.
Having said this there are options available:
(1) Add support for a new Result? class. We would probably implement
this in the AdapterManager.getAdapter implementation explicitly handling
this case because it would entail catching the adaptTo/getAdapter calls to
get the exception (the Result.getError should return Throwable probably not
Error)
Use would be limited to new AdapterFactory implementations throwing
RuntimeExcpetion. For Sling Models this would be the case.
(2) Add a new adaptToOrThrow method, which is declared to throw a
RuntimeException and never return null: Either it can adapt or it throws.
This would require a new interface Adaptable2 (probably) to not break
existing Adaptable implementations. The SlingAdaptable base class would
implement the new method of course, probably something like this:
SlingAdaptable implements Adaptable2 {
…
public AdapterType AdapterType adaptToOrThrow(ClassAdapterType
type) {
AdapterType result = this.adaptTo(type);
if (result != null) {
return result;
}
throw new CannotAdaptException(…);
}
}
Use is problematic because you would have to know whether you can call
the new method: So instead of
[jira] [Resolved] (SLING-3720) Make Crankstart launcher add path to its JAR as a system property
[ https://issues.apache.org/jira/browse/SLING-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SLING-3720. Resolution: Fixed Assignee: Bertrand Delacretaz Patch applied in revision 1607018, thanks! Make Crankstart launcher add path to its JAR as a system property - Key: SLING-3720 URL: https://issues.apache.org/jira/browse/SLING-3720 Project: Sling Issue Type: Improvement Components: Crankstart Reporter: Artyom Stetsenko Assignee: Bertrand Delacretaz Labels: crankstart, jar, path, property Attachments: crankstart.jar.path.patch Crankstart launcher should determine the path to its JAR and add it as a system property. This property would be useful for Crankstart itself or for its applications to crankstart other applications programmatically. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: adaptTo and results ....
adaptTo() is currently commonly used as a test, similar to instanceof.
Throwing and catching to return null is a very poor implementation
(performance-wise) for this use.
Adding a hasAdapter() or canAdaptTo() might decrease the number of
implementations that think throwing is OK, but only if the new interface
is visible at the level of the specific implementation. (If they're just
done as wrappers with catches somewhere in the machinery, and the
AdapterFactory writer is unaware of them, then they probably don't help
this issue.)
Cheers,
Jeff.
On 01/07/2014 08:44, Konrad Windszus konra...@gmx.de wrote:
Regarding 1) Having such a Result class would mean that all consumer
would need to unwrap the exception first. So instead of being forced of
implementing a null-check (as with the old solution) one would need to
implement another check. I want to prevent such a burden to the consumers.
Regarding 2) Since the client code knows on which object the
adaptToOrThrow is called I don¹t get why an instanceof check is
necessary. Whether this object implements Adaptable2 is known at
compile-time, so you do have the full IDE-support here.
Regarding 3) In that case I would no longer allow a null value to be
returned. One drawback is, that all the null checks are no longer
effective.
IMHO solution 2) is the best. At the same time I would deprecate the old
Adaptable, because I cannot come up with a real use-case where returning
has an advantage. I would rather implement another method boolean
hasAdapter(ClassAdapterType type) on the Adaptable2 interface.
Regards,
Konrad
On 01 Jul 2014, at 09:07, Felix Meschberger fmesc...@adobe.com wrote:
Hi
There currently are two issues floating around dealing with the
question of returning more information than just null from the
Adaptable.adaptTo(Class) method:
https://issues.apache.org/jira/browse/SLING-3714 and
https://issues.apache.org/jira/browse/SLING-3709. I think these requests
warrant some discussion on the list.
Background: adaptTo can be implemented by Adaptable implementations
themselves or, by extending from SlingAdaptable, they may defer to an
AdapterMananager. AdapterManager itself is extended by AdapterFactory
services. All these interfaces define an adaptTo method. All these
methods return null if adaption is not possible and don't declare or
document to throw an exception.
While not explicitly documented as such, the intention is and was that
adaptTo never throws on the grounds that adaption may fail which is
considered a valid result and thus exceptions are not to be expected and
handled.
Hence all implementations of the methods generally
catch-and-log-but-don't-throw. Interestingly SlingAdaptable.adaptTo and
AdapterManagerImpl.getAdapter don't catch ‹ so any RuntimeException
thrown from an AdapterFactory would be forwarded.
Having said this there are options available:
(1) Add support for a new Result? class. We would probably implement
this in the AdapterManager.getAdapter implementation explicitly handling
this case because it would entail catching the adaptTo/getAdapter calls
to get the exception (the Result.getError should return Throwable
probably not Error)
Use would be limited to new AdapterFactory implementations throwing
RuntimeExcpetion. For Sling Models this would be the case.
(2) Add a new adaptToOrThrow method, which is declared to throw a
RuntimeException and never return null: Either it can adapt or it
throws. This would require a new interface Adaptable2 (probably) to not
break existing Adaptable implementations. The SlingAdaptable base class
would implement the new method of course, probably something like this:
SlingAdaptable implements Adaptable2 {
Š
public AdapterType AdapterType adaptToOrThrow(ClassAdapterType
type) {
AdapterType result = this.adaptTo(type);
if (result != null) {
return result;
}
throw new CannotAdaptException(Š);
}
}
Use is problematic because you would have to know whether you can call
the new method: So instead of an null check you now have an instanceof
check Š Except for the Resource interface which would be extended to
extend from Adaptable2 as well.
(3) Document, that Adaptable.adaptTo may throw a RuntimeException.
The problem here is, that this may conceptually break existing callers
of Adaptable.adaptTo which don't expect an exception at all ‹ presumably
this is a minor nuisance because technically a RuntimeException may
always be thrown.
Regards
Felix
Re: adaptTo and results ....
It is not (only) about throwing exceptions in case no suitable adapter is available. It rather is about the fact, that today the adaptTo is a barrier for all kinds of exceptions. In some cases the adaptation fails for a specific reason (one example is Sling Models where injection fails, another one is the issue mentioned in https://issues.apache.org/jira/browse/SLING-2712 (ValueMap not supporting primitives)). Both would be valid use cases where the client would be interested to catch the exception here. On 01 Jul 2014, at 10:34, Carsten Ziegeler cziege...@apache.org wrote: Adding a new interface would require us to implement it all over the place and as Felix points out, client code would always need to check whether the new interface is implemented or not Having to methods, like hasAdapter and adaptOrThrow does not work very well as between the two calls things might have changed already: while hasAdapter returns true, the underlying factory gets unregistered before adaptOrThrow is called. In many use cases, the current pattern works fine - the client does not care whether an exception is thrown within the adaption - it just cares whether an object is returned or not. And there are valid use cases, where client code does different things whether the adaption works or not (e.g. the post servlet checks for adaptTo(Node) and then does additional things if the resource is backed up by a node.) I see the point that there are also use cases where it would be fine to simpy throw an exception if adaptTo is not successful. This would make the client code easier. However as this most properly is a runtime exception, client code can today just call a method on the object and end up with a NPE - having the same result :) This leaves us with use cases where the client code explicitely wants to catch the exception and then do something depending on the exception. Maybe we should just add something for this explicit use case instead of bloating the general adaptTo mechanism? Regards Carsten 2014-07-01 9:44 GMT+02:00 Konrad Windszus konra...@gmx.de: Regarding 1) Having such a Result class would mean that all consumer would need to unwrap the exception first. So instead of being forced of implementing a null-check (as with the old solution) one would need to implement another check. I want to prevent such a burden to the consumers. Regarding 2) Since the client code knows on which object the adaptToOrThrow is called I don’t get why an instanceof check is necessary. Whether this object implements Adaptable2 is known at compile-time, so you do have the full IDE-support here. Regarding 3) In that case I would no longer allow a null value to be returned. One drawback is, that all the null checks are no longer effective. IMHO solution 2) is the best. At the same time I would deprecate the old Adaptable, because I cannot come up with a real use-case where returning has an advantage. I would rather implement another method boolean hasAdapter(ClassAdapterType type) on the Adaptable2 interface. Regards, Konrad On 01 Jul 2014, at 09:07, Felix Meschberger fmesc...@adobe.com wrote: Hi There currently are two issues floating around dealing with the question of returning more information than just null from the Adaptable.adaptTo(Class) method: https://issues.apache.org/jira/browse/SLING-3714 and https://issues.apache.org/jira/browse/SLING-3709. I think these requests warrant some discussion on the list. Background: adaptTo can be implemented by Adaptable implementations themselves or, by extending from SlingAdaptable, they may defer to an AdapterMananager. AdapterManager itself is extended by AdapterFactory services. All these interfaces define an adaptTo method. All these methods return null if adaption is not possible and don't declare or document to throw an exception. While not explicitly documented as such, the intention is and was that adaptTo never throws on the grounds that adaption may fail which is considered a valid result and thus exceptions are not to be expected and handled. Hence all implementations of the methods generally catch-and-log-but-don't-throw. Interestingly SlingAdaptable.adaptTo and AdapterManagerImpl.getAdapter don't catch — so any RuntimeException thrown from an AdapterFactory would be forwarded. Having said this there are options available: (1) Add support for a new Result? class. We would probably implement this in the AdapterManager.getAdapter implementation explicitly handling this case because it would entail catching the adaptTo/getAdapter calls to get the exception (the Result.getError should return Throwable probably not Error) Use would be limited to new AdapterFactory implementations throwing RuntimeExcpetion. For Sling Models this would be the case. (2) Add a new adaptToOrThrow method, which is declared to throw a RuntimeException and never return null: Either it can adapt or it
Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #614
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.launchpad.testing/614/
Re: adaptTo and results ....
adaption and validation are different concerns Carsten 2014-07-01 10:55 GMT+02:00 Jeff Young j...@adobe.com: We could solve that by defining a specific exception for adaptation-not-possible and then catch only that. Of course that would leak tons of exceptions from code written before that exception became available. Maybe do the catching based on some sort of version clue? Cheers, Jeff. On 01/07/2014 09:40, Konrad Windszus konra...@gmx.de wrote: It is not (only) about throwing exceptions in case no suitable adapter is available. It rather is about the fact, that today the adaptTo is a barrier for all kinds of exceptions. In some cases the adaptation fails for a specific reason (one example is Sling Models where injection fails, another one is the issue mentioned in https://issues.apache.org/jira/browse/SLING-2712 (ValueMap not supporting primitives)). Both would be valid use cases where the client would be interested to catch the exception here. On 01 Jul 2014, at 10:34, Carsten Ziegeler cziege...@apache.org wrote: Adding a new interface would require us to implement it all over the place and as Felix points out, client code would always need to check whether the new interface is implemented or not Having to methods, like hasAdapter and adaptOrThrow does not work very well as between the two calls things might have changed already: while hasAdapter returns true, the underlying factory gets unregistered before adaptOrThrow is called. In many use cases, the current pattern works fine - the client does not care whether an exception is thrown within the adaption - it just cares whether an object is returned or not. And there are valid use cases, where client code does different things whether the adaption works or not (e.g. the post servlet checks for adaptTo(Node) and then does additional things if the resource is backed up by a node.) I see the point that there are also use cases where it would be fine to simpy throw an exception if adaptTo is not successful. This would make the client code easier. However as this most properly is a runtime exception, client code can today just call a method on the object and end up with a NPE - having the same result :) This leaves us with use cases where the client code explicitely wants to catch the exception and then do something depending on the exception. Maybe we should just add something for this explicit use case instead of bloating the general adaptTo mechanism? Regards Carsten 2014-07-01 9:44 GMT+02:00 Konrad Windszus konra...@gmx.de: Regarding 1) Having such a Result class would mean that all consumer would need to unwrap the exception first. So instead of being forced of implementing a null-check (as with the old solution) one would need to implement another check. I want to prevent such a burden to the consumers. Regarding 2) Since the client code knows on which object the adaptToOrThrow is called I don¹t get why an instanceof check is necessary. Whether this object implements Adaptable2 is known at compile-time, so you do have the full IDE-support here. Regarding 3) In that case I would no longer allow a null value to be returned. One drawback is, that all the null checks are no longer effective. IMHO solution 2) is the best. At the same time I would deprecate the old Adaptable, because I cannot come up with a real use-case where returning has an advantage. I would rather implement another method boolean hasAdapter(ClassAdapterType type) on the Adaptable2 interface. Regards, Konrad On 01 Jul 2014, at 09:07, Felix Meschberger fmesc...@adobe.com wrote: Hi There currently are two issues floating around dealing with the question of returning more information than just null from the Adaptable.adaptTo(Class) method: https://issues.apache.org/jira/browse/SLING-3714 and https://issues.apache.org/jira/browse/SLING-3709. I think these requests warrant some discussion on the list. Background: adaptTo can be implemented by Adaptable implementations themselves or, by extending from SlingAdaptable, they may defer to an AdapterMananager. AdapterManager itself is extended by AdapterFactory services. All these interfaces define an adaptTo method. All these methods return null if adaption is not possible and don't declare or document to throw an exception. While not explicitly documented as such, the intention is and was that adaptTo never throws on the grounds that adaption may fail which is considered a valid result and thus exceptions are not to be expected and handled. Hence all implementations of the methods generally catch-and-log-but-don't-throw. Interestingly SlingAdaptable.adaptTo and AdapterManagerImpl.getAdapter don't catch ‹ so any RuntimeException thrown from an AdapterFactory would be forwarded. Having said this there are options available: (1)
[jira] [Reopened] (SLING-3505) Improve handling of updates to mapping (alias, vanity path)
[ https://issues.apache.org/jira/browse/SLING-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reopened SLING-3505: - Reopening due to reported NPE Improve handling of updates to mapping (alias, vanity path) --- Key: SLING-3505 URL: https://issues.apache.org/jira/browse/SLING-3505 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.1.0 Reporter: Carsten Ziegeler Assignee: Antonio Sanso Fix For: Resource Resolver 1.1.2 Attachments: MapEntry.java.rej, SLING-3505-patch.txt, SLING-3505-patch2.txt, SLING-3505-patch2.txt, SLING-3505-patch3-je.txt, SLING-3505-patch3.txt, SLING-3505-patch3.txt The update handling for the mapping including aliases and vanity path is a simple algorithm which simply updates the whole mapping. Especially with large mapping info spread across the repository, a simple update of a single property results in the whole mapping info to be recreated. It would be great if this could be improved. Right now, only the active mapping is hold in memory - as a change of a single property might cause to activate a totally different mapping than the one which was changed (e.h. when the ordering is changed), the update needs to be more complex or more information needs to be hold in memory. In addition there is more to consider, like if the vanity path info is changed, only the new value is available - but the old is gone. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: adaptTo and results ....
Hi Carsten, Can you say more? (I'm not sure I understand what you're getting at) Thanks, Jeff. On 01/07/2014 09:56, Carsten Ziegeler cziege...@apache.org wrote: adaption and validation are different concerns Carsten 2014-07-01 10:55 GMT+02:00 Jeff Young j...@adobe.com: We could solve that by defining a specific exception for adaptation-not-possible and then catch only that. Of course that would leak tons of exceptions from code written before that exception became available. Maybe do the catching based on some sort of version clue? Cheers, Jeff. On 01/07/2014 09:40, Konrad Windszus konra...@gmx.de wrote: It is not (only) about throwing exceptions in case no suitable adapter is available. It rather is about the fact, that today the adaptTo is a barrier for all kinds of exceptions. In some cases the adaptation fails for a specific reason (one example is Sling Models where injection fails, another one is the issue mentioned in https://issues.apache.org/jira/browse/SLING-2712 (ValueMap not supporting primitives)). Both would be valid use cases where the client would be interested to catch the exception here. On 01 Jul 2014, at 10:34, Carsten Ziegeler cziege...@apache.org wrote: Adding a new interface would require us to implement it all over the place and as Felix points out, client code would always need to check whether the new interface is implemented or not Having to methods, like hasAdapter and adaptOrThrow does not work very well as between the two calls things might have changed already: while hasAdapter returns true, the underlying factory gets unregistered before adaptOrThrow is called. In many use cases, the current pattern works fine - the client does not care whether an exception is thrown within the adaption - it just cares whether an object is returned or not. And there are valid use cases, where client code does different things whether the adaption works or not (e.g. the post servlet checks for adaptTo(Node) and then does additional things if the resource is backed up by a node.) I see the point that there are also use cases where it would be fine to simpy throw an exception if adaptTo is not successful. This would make the client code easier. However as this most properly is a runtime exception, client code can today just call a method on the object and end up with a NPE - having the same result :) This leaves us with use cases where the client code explicitely wants to catch the exception and then do something depending on the exception. Maybe we should just add something for this explicit use case instead of bloating the general adaptTo mechanism? Regards Carsten 2014-07-01 9:44 GMT+02:00 Konrad Windszus konra...@gmx.de: Regarding 1) Having such a Result class would mean that all consumer would need to unwrap the exception first. So instead of being forced of implementing a null-check (as with the old solution) one would need to implement another check. I want to prevent such a burden to the consumers. Regarding 2) Since the client code knows on which object the adaptToOrThrow is called I don¹t get why an instanceof check is necessary. Whether this object implements Adaptable2 is known at compile-time, so you do have the full IDE-support here. Regarding 3) In that case I would no longer allow a null value to be returned. One drawback is, that all the null checks are no longer effective. IMHO solution 2) is the best. At the same time I would deprecate the old Adaptable, because I cannot come up with a real use-case where returning has an advantage. I would rather implement another method boolean hasAdapter(ClassAdapterType type) on the Adaptable2 interface. Regards, Konrad On 01 Jul 2014, at 09:07, Felix Meschberger fmesc...@adobe.com wrote: Hi There currently are two issues floating around dealing with the question of returning more information than just null from the Adaptable.adaptTo(Class) method: https://issues.apache.org/jira/browse/SLING-3714 and https://issues.apache.org/jira/browse/SLING-3709. I think these requests warrant some discussion on the list. Background: adaptTo can be implemented by Adaptable implementations themselves or, by extending from SlingAdaptable, they may defer to an AdapterMananager. AdapterManager itself is extended by AdapterFactory services. All these interfaces define an adaptTo method. All these methods return null if adaption is not possible and don't declare or document to throw an exception. While not explicitly documented as such, the intention is and was that adaptTo never throws on the grounds that adaption may fail which is considered a valid result and thus exceptions are not to be expected and handled. Hence all implementations of the methods generally catch-and-log-but-don't-throw. Interestingly SlingAdaptable.adaptTo and
[jira] [Commented] (SLING-3505) Improve handling of updates to mapping (alias, vanity path)
[ https://issues.apache.org/jira/browse/SLING-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048668#comment-14048668 ] Antonio Sanso commented on SLING-3505: -- [~cziegeler] which NPE ? I fyou mean SLING-3706 is fixed now :) Improve handling of updates to mapping (alias, vanity path) --- Key: SLING-3505 URL: https://issues.apache.org/jira/browse/SLING-3505 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.1.0 Reporter: Carsten Ziegeler Assignee: Antonio Sanso Fix For: Resource Resolver 1.1.2 Attachments: MapEntry.java.rej, SLING-3505-patch.txt, SLING-3505-patch2.txt, SLING-3505-patch2.txt, SLING-3505-patch3-je.txt, SLING-3505-patch3.txt, SLING-3505-patch3.txt The update handling for the mapping including aliases and vanity path is a simple algorithm which simply updates the whole mapping. Especially with large mapping info spread across the repository, a simple update of a single property results in the whole mapping info to be recreated. It would be great if this could be improved. Right now, only the active mapping is hold in memory - as a change of a single property might cause to activate a totally different mapping than the one which was changed (e.h. when the ordering is changed), the update needs to be more complex or more information needs to be hold in memory. In addition there is more to consider, like if the vanity path info is changed, only the new value is available - but the old is gone. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (SLING-3505) Improve handling of updates to mapping (alias, vanity path)
[ https://issues.apache.org/jira/browse/SLING-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048668#comment-14048668 ] Antonio Sanso edited comment on SLING-3505 at 7/1/14 9:13 AM: -- [~cziegeler] which NPE ? If you mean SLING-3706 is fixed now :) was (Author: asanso): [~cziegeler] which NPE ? I fyou mean SLING-3706 is fixed now :) Improve handling of updates to mapping (alias, vanity path) --- Key: SLING-3505 URL: https://issues.apache.org/jira/browse/SLING-3505 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.1.0 Reporter: Carsten Ziegeler Assignee: Antonio Sanso Fix For: Resource Resolver 1.1.2 Attachments: MapEntry.java.rej, SLING-3505-patch.txt, SLING-3505-patch2.txt, SLING-3505-patch2.txt, SLING-3505-patch3-je.txt, SLING-3505-patch3.txt, SLING-3505-patch3.txt The update handling for the mapping including aliases and vanity path is a simple algorithm which simply updates the whole mapping. Especially with large mapping info spread across the repository, a simple update of a single property results in the whole mapping info to be recreated. It would be great if this could be improved. Right now, only the active mapping is hold in memory - as a change of a single property might cause to activate a totally different mapping than the one which was changed (e.h. when the ordering is changed), the update needs to be more complex or more information needs to be hold in memory. In addition there is more to consider, like if the vanity path info is changed, only the new value is available - but the old is gone. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: adaptTo and results ....
Sure :) For the adapter pattern, the client does not care why the adaption failed, the client is just interested in the result (success or not) Validation is a different beast, if validation fails you want to know specific reasons why it failed - and this can be multiple. I tried to explain in my first mail on this thread, that all other use cases mentioned can be handled with the current implementation - with the exception of validation. But I think validation requires a different concept than the adapter pattern. Carsten 2014-07-01 11:09 GMT+02:00 Jeff Young j...@adobe.com: Hi Carsten, Can you say more? (I'm not sure I understand what you're getting at) Thanks, Jeff. On 01/07/2014 09:56, Carsten Ziegeler cziege...@apache.org wrote: adaption and validation are different concerns Carsten 2014-07-01 10:55 GMT+02:00 Jeff Young j...@adobe.com: We could solve that by defining a specific exception for adaptation-not-possible and then catch only that. Of course that would leak tons of exceptions from code written before that exception became available. Maybe do the catching based on some sort of version clue? Cheers, Jeff. On 01/07/2014 09:40, Konrad Windszus konra...@gmx.de wrote: It is not (only) about throwing exceptions in case no suitable adapter is available. It rather is about the fact, that today the adaptTo is a barrier for all kinds of exceptions. In some cases the adaptation fails for a specific reason (one example is Sling Models where injection fails, another one is the issue mentioned in https://issues.apache.org/jira/browse/SLING-2712 (ValueMap not supporting primitives)). Both would be valid use cases where the client would be interested to catch the exception here. On 01 Jul 2014, at 10:34, Carsten Ziegeler cziege...@apache.org wrote: Adding a new interface would require us to implement it all over the place and as Felix points out, client code would always need to check whether the new interface is implemented or not Having to methods, like hasAdapter and adaptOrThrow does not work very well as between the two calls things might have changed already: while hasAdapter returns true, the underlying factory gets unregistered before adaptOrThrow is called. In many use cases, the current pattern works fine - the client does not care whether an exception is thrown within the adaption - it just cares whether an object is returned or not. And there are valid use cases, where client code does different things whether the adaption works or not (e.g. the post servlet checks for adaptTo(Node) and then does additional things if the resource is backed up by a node.) I see the point that there are also use cases where it would be fine to simpy throw an exception if adaptTo is not successful. This would make the client code easier. However as this most properly is a runtime exception, client code can today just call a method on the object and end up with a NPE - having the same result :) This leaves us with use cases where the client code explicitely wants to catch the exception and then do something depending on the exception. Maybe we should just add something for this explicit use case instead of bloating the general adaptTo mechanism? Regards Carsten 2014-07-01 9:44 GMT+02:00 Konrad Windszus konra...@gmx.de: Regarding 1) Having such a Result class would mean that all consumer would need to unwrap the exception first. So instead of being forced of implementing a null-check (as with the old solution) one would need to implement another check. I want to prevent such a burden to the consumers. Regarding 2) Since the client code knows on which object the adaptToOrThrow is called I don¹t get why an instanceof check is necessary. Whether this object implements Adaptable2 is known at compile-time, so you do have the full IDE-support here. Regarding 3) In that case I would no longer allow a null value to be returned. One drawback is, that all the null checks are no longer effective. IMHO solution 2) is the best. At the same time I would deprecate the old Adaptable, because I cannot come up with a real use-case where returning has an advantage. I would rather implement another method boolean hasAdapter(ClassAdapterType type) on the Adaptable2 interface. Regards, Konrad On 01 Jul 2014, at 09:07, Felix Meschberger fmesc...@adobe.com wrote: Hi There currently are two issues floating around dealing with the question of returning more information than just null from the Adaptable.adaptTo(Class) method: https://issues.apache.org/jira/browse/SLING-3714 and https://issues.apache.org/jira/browse/SLING-3709. I think these requests warrant some discussion on the list. Background: adaptTo can be implemented
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #2241
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/2241/
Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Event Support #2241
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.event/2241/
Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Sample Integration Tests #2241
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.testing.samples.integrationtests/2241/
Jenkins build is still unstable: sling-trunk-1.6 #2241
See https://builds.apache.org/job/sling-trunk-1.6/changes
[jira] [Resolved] (SLING-3505) Improve handling of updates to mapping (alias, vanity path)
[ https://issues.apache.org/jira/browse/SLING-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3505. - Resolution: Fixed Ah, SLING-3706 wasn't mentioned in the comment above. So everything is fine :) Improve handling of updates to mapping (alias, vanity path) --- Key: SLING-3505 URL: https://issues.apache.org/jira/browse/SLING-3505 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.1.0 Reporter: Carsten Ziegeler Assignee: Antonio Sanso Fix For: Resource Resolver 1.1.2 Attachments: MapEntry.java.rej, SLING-3505-patch.txt, SLING-3505-patch2.txt, SLING-3505-patch2.txt, SLING-3505-patch3-je.txt, SLING-3505-patch3.txt, SLING-3505-patch3.txt The update handling for the mapping including aliases and vanity path is a simple algorithm which simply updates the whole mapping. Especially with large mapping info spread across the repository, a simple update of a single property results in the whole mapping info to be recreated. It would be great if this could be improved. Right now, only the active mapping is hold in memory - as a change of a single property might cause to activate a totally different mapping than the one which was changed (e.h. when the ordering is changed), the update needs to be more complex or more information needs to be hold in memory. In addition there is more to consider, like if the vanity path info is changed, only the new value is available - but the old is gone. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [event] JobManager.findJobs question
Hi Tommaso, could you please open an issue for this? Thanks Carsten 2014-06-17 9:30 GMT+02:00 Stefan Egli stefane...@apache.org: Hi Tommaso, That sounds indeed odd. From a code point of view both should be equivalent, as findJobs checks for ( templates != null templates.length 0 ) - so an empty props Map should not have any influence at all.. Cheers, Stefan On 6/16/14 3:53 PM, Tommaso Teofili tommaso.teof...@gmail.com wrote: Hi all, while working with Sling replication I found a strange behavior, probably changed recently (as I didn't have it before), where calling: CollectionJob jobs = jobManager.findJobs(QueryType.QUEUED, topic, -1); returns me all the queued jobs, while calling: MapString,Object props = new HashMapString,Object(); CollectionJob jobs = jobManager.findJobs(QueryType.QUEUED, topic, -1, props); returns an empty collection. I don't think that's expected (a void template should work as no template given) and also it's a different behavior between 3.3.0 (my provided version) and 3.3.10 (my actual version). Am I missing something? Regards, Tommaso -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Updated] (SLING-3716) Sling Models: Add support for constructor dependency injection
[ https://issues.apache.org/jira/browse/SLING-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-3716: -- Attachment: 140701_SLING-3716_slingmodes_constructorinjection.patch attached is a patch for adding constructor injection support to sling models including unit tests. some remarks: * due to missing support in java reflection it is not possible to get the name of a constructor parameter without resorting external tools like objectweb ASM. i did not wanted to introduce this only for this usecase. So if an injector is used that depends on name-based injection a @Named parameter or equivalent injector-specific annotation with name attribute is mandatory. the existing injector implementations where extended to ensure that they can cope with a null name attribute and unit tests were added for this case. * by default only constructors which are annotated with @Inject are supported for constructor injection. to keep compatibility with previous sling implementation releases the special case with one-parameter constructor matching the adaptable is still supported. * to make the injection of the adaptable itself more generic and support it in multiple parameter constructors i added a new SelfInjector. this is supported for field injection as well. * currently there is no SelfInjector-specific annotation, the matching is class based. we can easily add one, this touches the topics discussed in SLING-3715 and SLING-3718 as well. * integration test added as well Sling Models: Add support for constructor dependency injection -- Key: SLING-3716 URL: https://issues.apache.org/jira/browse/SLING-3716 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Stefan Seifert Priority: Minor Attachments: 140701_SLING-3716_slingmodes_constructorinjection.patch Currently, Sling Models only supports dependency injection for fields (or interface getter methods), but not for constructor arguments. This ticket is for discussing what this constructor dependency injection should support, and perhaps finally provide a patch to implement it. This is somewhat related to SLING-3715 for class-based dependency injection, because this would come in especially handy for constructor injection. -- This message was sent by Atlassian JIRA (v6.2#6252)
Jenkins build is back to normal : sling-contrib-1.6 » Apache Sling Replication Integration Tests #1162
See https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/1162/
[jira] [Updated] (SLING-3716) Sling Models: Add support for constructor dependency injection
[ https://issues.apache.org/jira/browse/SLING-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-3716: -- Attachment: 140701_SLING-3716_slingmodes_constructorinjection.patch updated the patch, it accidentally included a change to the pom which added a debugging port Sling Models: Add support for constructor dependency injection -- Key: SLING-3716 URL: https://issues.apache.org/jira/browse/SLING-3716 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Stefan Seifert Priority: Minor Attachments: 140701_SLING-3716_slingmodes_constructorinjection.patch Currently, Sling Models only supports dependency injection for fields (or interface getter methods), but not for constructor arguments. This ticket is for discussing what this constructor dependency injection should support, and perhaps finally provide a patch to implement it. This is somewhat related to SLING-3715 for class-based dependency injection, because this would come in especially handy for constructor injection. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3716) Sling Models: Add support for constructor dependency injection
[ https://issues.apache.org/jira/browse/SLING-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-3716: -- Attachment: (was: 140701_SLING-3716_slingmodes_constructorinjection.patch) Sling Models: Add support for constructor dependency injection -- Key: SLING-3716 URL: https://issues.apache.org/jira/browse/SLING-3716 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Stefan Seifert Priority: Minor Attachments: 140701_SLING-3716_slingmodes_constructorinjection.patch Currently, Sling Models only supports dependency injection for fields (or interface getter methods), but not for constructor arguments. This ticket is for discussing what this constructor dependency injection should support, and perhaps finally provide a patch to implement it. This is somewhat related to SLING-3715 for class-based dependency injection, because this would come in especially handy for constructor injection. -- This message was sent by Atlassian JIRA (v6.2#6252)
Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #615
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.launchpad.testing/615/
Jenkins build is still unstable: sling-trunk-1.7 #615
See https://builds.apache.org/job/sling-trunk-1.7/changes
Re: [VOTE] Release Apache Sling IDE Tooling 1.0.0
+1 (verified md5 sha1 using the check_staged_release.sh) Cheers, Stefan On 7/1/14 8:34 AM, Carsten Ziegeler cziege...@apache.org wrote: Thanks for redoing, Robert. +1 Carsten 2014-07-01 2:01 GMT+02:00 Justin Edelson jus...@justinedelson.com: +1 On Mon, Jun 30, 2014 at 12:14 PM, Robert Munteanu rob...@lmn.ro wrote: I think I've gotten the right Maven/Tycho incantations set up and deployed the 1.0.0 artifacts to https://repository.apache.org/content/repositories/orgapachesling-1072/ The single compromise that I had to make is that the integration tests were not included in the reactor build and therefore not deployed to the nexus repo. Hopefully that's acceptable for the release. I can restart the release vote if needed ( third time's the charm? ) but it would be good to know that I got things right this time. Note: check_staged_release.sh took about 30 minutes to complete for me. Thanks, Robert On Mon, Jun 30, 2014 at 1:53 PM, Carsten Ziegeler cziege...@apache.org wrote: Thanks for the info, Robert - I'm not sure what the best approach is, however the zip now contains 1.0.0-SNAPSHOT as versions but I guess the final release should be 1.0.0. This would mean we're voting on something which is then not released. On the other hand, if we put up 1.0.0 in a globally available space everyone can simply download it from there and voting, especially withdrawing the release is way harder. Carsten 2014-06-30 10:06 GMT+02:00 Robert Munteanu romb...@apache.org: Hi Carsten, On Mon, Jun 30, 2014 at 8:57 AM, Carsten Ziegeler cziege...@apache.org wrote: Why is this release not following the normal release procedure and available via the staging maven repo? There are two main reasons. 1. While the build is driven by Maven, building Eclipse plug-ins with Tycho means that some of the regular Maven plugins don't work. For instance, the source and javadoc plugin, see [1],[2] . Since IIUC the release is based on the source code, and the binaries are just for convenience, I opted not to make the release run on the output of individual projects, but on the whole source zip. 2. If I were to deploy the plug-ins by themselves to the repo, it would not be trivial to assemble back an p2/Eclipse update which can be used to test the functionality of the release. That being said, I'd be more than happy to refine this process, so suggestions on how to do that are welcome :-) Thanks, Robert [1]: https://dev.eclipse.org/mhonarc/lists/tycho-user/msg05730.html [2]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=398061 Carsten 2014-06-29 21:32 GMT+02:00 Robert Munteanu romb...@apache.org: Anyone? Robert On Thu, Jun 26, 2014 at 11:32 AM, Robert Munteanu romb...@apache.org wrote: Hi, We solved 144 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12324873 There are still some outstanding issues: https://issues.apache.org/jira/browse/SLING/component/12320908 The release candidate has been uploaded at https://dist.apache.org/repos/dist/dev/sling, and can be built using mvn clean package The resulting binaries can be installed into an Eclipse instance by installing from the update site which is found at p2update/target/repository after building the project. Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Sent from my (old) computer -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: adaptTo and results ....
I like that approach. It is backwards-compatible and allows the developers to decide whether they want to check for null or to rely on exceptions. The AdapterManagerImpl indeed would need to deal with such a parametrisation and in addition the javadocs would need to be adjusted to make it clear that AdapterFactories may throw RuntimeExceptions. Those exceptions should be caught by the AdapterManagerImpl when the RequireAdapter was not requested and in the other case just passed along. On 01 Jul 2014, at 09:44, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jul 1, 2014 at 9:41 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: ...how about this: Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class)); Actually, rereading SLING-3714, this can be made simpler with generics Foo f = someObject.adaptTo(RequireAdapterFoo.class)); where RequireAdapter causes AdapterManagerImpl to wrap the adapters to throw an exception if adaption returns null. -Bertrand
RE: adaptTo and results ....
Foo f = someObject.adaptTo(RequireAdapterFoo.class)); this would still require an unwrapping of the object out of the RequireAdapterFoo instance. Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class)); this looks interesting, and does not need unwrapping if the return value is the input class. i assume it could be implemented using a ThreadLocal or similar as well? stefan -Original Message- From: Konrad Windszus [mailto:konra...@gmx.de] Sent: Tuesday, July 01, 2014 11:58 AM To: dev@sling.apache.org Cc: Bertrand Delacretaz Subject: Re: adaptTo and results I like that approach. It is backwards-compatible and allows the developers to decide whether they want to check for null or to rely on exceptions. The AdapterManagerImpl indeed would need to deal with such a parametrisation and in addition the javadocs would need to be adjusted to make it clear that AdapterFactories may throw RuntimeExceptions. Those exceptions should be caught by the AdapterManagerImpl when the RequireAdapter was not requested and in the other case just passed along. On 01 Jul 2014, at 09:44, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jul 1, 2014 at 9:41 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: ...how about this: Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class)); Actually, rereading SLING-3714, this can be made simpler with generics Foo f = someObject.adaptTo(RequireAdapterFoo.class)); where RequireAdapter causes AdapterManagerImpl to wrap the adapters to throw an exception if adaption returns null. -Bertrand
Re: adaptTo and results ....
Hi Carsten, Sure, but Konrad has a point in that I think sometimes the client *does* care why the adaption failed. For instance, if it had to do with something entirely different from whether or not adaption would normally work. Let's say that I have a resource that should adapt to XYZ, but that my adapter is currently buggy. I'd like to get an exception for that, but said exception is going to get eaten. I do agree that if I have a resource that should NOT adapt to XYZ, that getting back null is fine, and that I don't care why the adaption failed. Cheers, Jeff. On 01/07/2014 10:19, Carsten Ziegeler cziege...@apache.org wrote: Sure :) For the adapter pattern, the client does not care why the adaption failed, the client is just interested in the result (success or not) Validation is a different beast, if validation fails you want to know specific reasons why it failed - and this can be multiple. I tried to explain in my first mail on this thread, that all other use cases mentioned can be handled with the current implementation - with the exception of validation. But I think validation requires a different concept than the adapter pattern. Carsten 2014-07-01 11:09 GMT+02:00 Jeff Young j...@adobe.com: Hi Carsten, Can you say more? (I'm not sure I understand what you're getting at) Thanks, Jeff. On 01/07/2014 09:56, Carsten Ziegeler cziege...@apache.org wrote: adaption and validation are different concerns Carsten 2014-07-01 10:55 GMT+02:00 Jeff Young j...@adobe.com: We could solve that by defining a specific exception for adaptation-not-possible and then catch only that. Of course that would leak tons of exceptions from code written before that exception became available. Maybe do the catching based on some sort of version clue? Cheers, Jeff. On 01/07/2014 09:40, Konrad Windszus konra...@gmx.de wrote: It is not (only) about throwing exceptions in case no suitable adapter is available. It rather is about the fact, that today the adaptTo is a barrier for all kinds of exceptions. In some cases the adaptation fails for a specific reason (one example is Sling Models where injection fails, another one is the issue mentioned in https://issues.apache.org/jira/browse/SLING-2712 (ValueMap not supporting primitives)). Both would be valid use cases where the client would be interested to catch the exception here. On 01 Jul 2014, at 10:34, Carsten Ziegeler cziege...@apache.org wrote: Adding a new interface would require us to implement it all over the place and as Felix points out, client code would always need to check whether the new interface is implemented or not Having to methods, like hasAdapter and adaptOrThrow does not work very well as between the two calls things might have changed already: while hasAdapter returns true, the underlying factory gets unregistered before adaptOrThrow is called. In many use cases, the current pattern works fine - the client does not care whether an exception is thrown within the adaption - it just cares whether an object is returned or not. And there are valid use cases, where client code does different things whether the adaption works or not (e.g. the post servlet checks for adaptTo(Node) and then does additional things if the resource is backed up by a node.) I see the point that there are also use cases where it would be fine to simpy throw an exception if adaptTo is not successful. This would make the client code easier. However as this most properly is a runtime exception, client code can today just call a method on the object and end up with a NPE - having the same result :) This leaves us with use cases where the client code explicitely wants to catch the exception and then do something depending on the exception. Maybe we should just add something for this explicit use case instead of bloating the general adaptTo mechanism? Regards Carsten 2014-07-01 9:44 GMT+02:00 Konrad Windszus konra...@gmx.de: Regarding 1) Having such a Result class would mean that all consumer would need to unwrap the exception first. So instead of being forced of implementing a null-check (as with the old solution) one would need to implement another check. I want to prevent such a burden to the consumers. Regarding 2) Since the client code knows on which object the adaptToOrThrow is called I don¹t get why an instanceof check is necessary. Whether this object implements Adaptable2 is known at compile-time, so you do have the full IDE-support here. Regarding 3) In that case I would no longer allow a null value to be returned. One drawback is, that all the null checks are no longer effective. IMHO solution 2) is the best. At the same time I would deprecate the old Adaptable, because I cannot come up with a real use-case where
Re: adaptTo and results ....
On 01 Jul 2014, at 12:05, Stefan Seifert sseif...@pro-vision.de wrote: Foo f = someObject.adaptTo(RequireAdapterFoo.class)); this would still require an unwrapping of the object out of the RequireAdapterFoo instance. In my regard there is an instanceof RequireAdapter check within the AdapterManagerImpl which would in that case just pass/throw exceptions. So no need to unwrap anything for the client. The only questions is how to get the generic type at runtime (within the AdapterManagerImpl), but there are solutions to that as well: http://stackoverflow.com/questions/3403909/get-generic-type-of-class-at-runtime Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class)); this looks interesting, and does not need unwrapping if the return value is the input class. i assume it could be implemented using a ThreadLocal or similar as well? stefan -Original Message- From: Konrad Windszus [mailto:konra...@gmx.de] Sent: Tuesday, July 01, 2014 11:58 AM To: dev@sling.apache.org Cc: Bertrand Delacretaz Subject: Re: adaptTo and results I like that approach. It is backwards-compatible and allows the developers to decide whether they want to check for null or to rely on exceptions. The AdapterManagerImpl indeed would need to deal with such a parametrisation and in addition the javadocs would need to be adjusted to make it clear that AdapterFactories may throw RuntimeExceptions. Those exceptions should be caught by the AdapterManagerImpl when the RequireAdapter was not requested and in the other case just passed along. On 01 Jul 2014, at 09:44, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jul 1, 2014 at 9:41 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: ...how about this: Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class)); Actually, rereading SLING-3714, this can be made simpler with generics Foo f = someObject.adaptTo(RequireAdapterFoo.class)); where RequireAdapter causes AdapterManagerImpl to wrap the adapters to throw an exception if adaption returns null. -Bertrand
Re: adaptTo and results ....
So if your adapter is buggy and you get an exception, what do you do with it? Carsten 2014-07-01 12:08 GMT+02:00 Jeff Young j...@adobe.com: Hi Carsten, Sure, but Konrad has a point in that I think sometimes the client *does* care why the adaption failed. For instance, if it had to do with something entirely different from whether or not adaption would normally work. Let's say that I have a resource that should adapt to XYZ, but that my adapter is currently buggy. I'd like to get an exception for that, but said exception is going to get eaten. I do agree that if I have a resource that should NOT adapt to XYZ, that getting back null is fine, and that I don't care why the adaption failed. Cheers, Jeff. On 01/07/2014 10:19, Carsten Ziegeler cziege...@apache.org wrote: Sure :) For the adapter pattern, the client does not care why the adaption failed, the client is just interested in the result (success or not) Validation is a different beast, if validation fails you want to know specific reasons why it failed - and this can be multiple. I tried to explain in my first mail on this thread, that all other use cases mentioned can be handled with the current implementation - with the exception of validation. But I think validation requires a different concept than the adapter pattern. Carsten 2014-07-01 11:09 GMT+02:00 Jeff Young j...@adobe.com: Hi Carsten, Can you say more? (I'm not sure I understand what you're getting at) Thanks, Jeff. On 01/07/2014 09:56, Carsten Ziegeler cziege...@apache.org wrote: adaption and validation are different concerns Carsten 2014-07-01 10:55 GMT+02:00 Jeff Young j...@adobe.com: We could solve that by defining a specific exception for adaptation-not-possible and then catch only that. Of course that would leak tons of exceptions from code written before that exception became available. Maybe do the catching based on some sort of version clue? Cheers, Jeff. On 01/07/2014 09:40, Konrad Windszus konra...@gmx.de wrote: It is not (only) about throwing exceptions in case no suitable adapter is available. It rather is about the fact, that today the adaptTo is a barrier for all kinds of exceptions. In some cases the adaptation fails for a specific reason (one example is Sling Models where injection fails, another one is the issue mentioned in https://issues.apache.org/jira/browse/SLING-2712 (ValueMap not supporting primitives)). Both would be valid use cases where the client would be interested to catch the exception here. On 01 Jul 2014, at 10:34, Carsten Ziegeler cziege...@apache.org wrote: Adding a new interface would require us to implement it all over the place and as Felix points out, client code would always need to check whether the new interface is implemented or not Having to methods, like hasAdapter and adaptOrThrow does not work very well as between the two calls things might have changed already: while hasAdapter returns true, the underlying factory gets unregistered before adaptOrThrow is called. In many use cases, the current pattern works fine - the client does not care whether an exception is thrown within the adaption - it just cares whether an object is returned or not. And there are valid use cases, where client code does different things whether the adaption works or not (e.g. the post servlet checks for adaptTo(Node) and then does additional things if the resource is backed up by a node.) I see the point that there are also use cases where it would be fine to simpy throw an exception if adaptTo is not successful. This would make the client code easier. However as this most properly is a runtime exception, client code can today just call a method on the object and end up with a NPE - having the same result :) This leaves us with use cases where the client code explicitely wants to catch the exception and then do something depending on the exception. Maybe we should just add something for this explicit use case instead of bloating the general adaptTo mechanism? Regards Carsten 2014-07-01 9:44 GMT+02:00 Konrad Windszus konra...@gmx.de: Regarding 1) Having such a Result class would mean that all consumer would need to unwrap the exception first. So instead of being forced of implementing a null-check (as with the old solution) one would need to implement another check. I want to prevent such a burden to the consumers. Regarding 2) Since the client code knows on which object the adaptToOrThrow is called I don¹t get why an instanceof check is necessary. Whether this object implements Adaptable2 is known at compile-time, so you do have the full IDE-support here.
RE: adaptTo and results ....
example: usecase like here https://issues.apache.org/jira/browse/SLING-3714?focusedCommentId=14048040#comment-14048040 the caller code expects that the adaption is always successful if everything works correct - if not it is an application error which should be propagated through error handling and result in an error log message. stefan -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Tuesday, July 01, 2014 12:14 PM To: dev@sling.apache.org Subject: Re: adaptTo and results So if your adapter is buggy and you get an exception, what do you do with it? Carsten 2014-07-01 12:08 GMT+02:00 Jeff Young j...@adobe.com: Hi Carsten, Sure, but Konrad has a point in that I think sometimes the client *does* care why the adaption failed. For instance, if it had to do with something entirely different from whether or not adaption would normally work. Let's say that I have a resource that should adapt to XYZ, but that my adapter is currently buggy. I'd like to get an exception for that, but said exception is going to get eaten. I do agree that if I have a resource that should NOT adapt to XYZ, that getting back null is fine, and that I don't care why the adaption failed. Cheers, Jeff. On 01/07/2014 10:19, Carsten Ziegeler cziege...@apache.org wrote: Sure :) For the adapter pattern, the client does not care why the adaption failed, the client is just interested in the result (success or not) Validation is a different beast, if validation fails you want to know specific reasons why it failed - and this can be multiple. I tried to explain in my first mail on this thread, that all other use cases mentioned can be handled with the current implementation - with the exception of validation. But I think validation requires a different concept than the adapter pattern. Carsten 2014-07-01 11:09 GMT+02:00 Jeff Young j...@adobe.com: Hi Carsten, Can you say more? (I'm not sure I understand what you're getting at) Thanks, Jeff. On 01/07/2014 09:56, Carsten Ziegeler cziege...@apache.org wrote: adaption and validation are different concerns Carsten 2014-07-01 10:55 GMT+02:00 Jeff Young j...@adobe.com: We could solve that by defining a specific exception for adaptation-not-possible and then catch only that. Of course that would leak tons of exceptions from code written before that exception became available. Maybe do the catching based on some sort of version clue? Cheers, Jeff. On 01/07/2014 09:40, Konrad Windszus konra...@gmx.de wrote: It is not (only) about throwing exceptions in case no suitable adapter is available. It rather is about the fact, that today the adaptTo is a barrier for all kinds of exceptions. In some cases the adaptation fails for a specific reason (one example is Sling Models where injection fails, another one is the issue mentioned in https://issues.apache.org/jira/browse/SLING-2712 (ValueMap not supporting primitives)). Both would be valid use cases where the client would be interested to catch the exception here. On 01 Jul 2014, at 10:34, Carsten Ziegeler cziege...@apache.org wrote: Adding a new interface would require us to implement it all over the place and as Felix points out, client code would always need to check whether the new interface is implemented or not Having to methods, like hasAdapter and adaptOrThrow does not work very well as between the two calls things might have changed already: while hasAdapter returns true, the underlying factory gets unregistered before adaptOrThrow is called. In many use cases, the current pattern works fine - the client does not care whether an exception is thrown within the adaption - it just cares whether an object is returned or not. And there are valid use cases, where client code does different things whether the adaption works or not (e.g. the post servlet checks for adaptTo(Node) and then does additional things if the resource is backed up by a node.) I see the point that there are also use cases where it would be fine to simpy throw an exception if adaptTo is not successful. This would make the client code easier. However as this most properly is a runtime exception, client code can today just call a method on the object and end up with a NPE - having the same result :) This leaves us with use cases where the client code explicitely wants to catch the exception and then do something depending on the exception. Maybe we should just add something for this explicit use case instead of bloating the general adaptTo mechanism? Regards Carsten 2014-07-01 9:44 GMT+02:00 Konrad Windszus konra...@gmx.de: Regarding 1) Having such a Result class would mean that all
Re: adaptTo and results ....
Yes, but right now you would get an NPE accessing the object - so you already have a runtime exception and don't need to check for null (I'm not arguing that this is a good way, I'm just trying to avoid heavy changes). And we could change the adapter manager/factory implemntation to log the exceptions (if they're not doing it already) Carsten 2014-07-01 12:17 GMT+02:00 Stefan Seifert sseif...@pro-vision.de: example: usecase like here https://issues.apache.org/jira/browse/SLING-3714?focusedCommentId=14048040#comment-14048040 the caller code expects that the adaption is always successful if everything works correct - if not it is an application error which should be propagated through error handling and result in an error log message. stefan -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Tuesday, July 01, 2014 12:14 PM To: dev@sling.apache.org Subject: Re: adaptTo and results So if your adapter is buggy and you get an exception, what do you do with it? Carsten 2014-07-01 12:08 GMT+02:00 Jeff Young j...@adobe.com: Hi Carsten, Sure, but Konrad has a point in that I think sometimes the client *does* care why the adaption failed. For instance, if it had to do with something entirely different from whether or not adaption would normally work. Let's say that I have a resource that should adapt to XYZ, but that my adapter is currently buggy. I'd like to get an exception for that, but said exception is going to get eaten. I do agree that if I have a resource that should NOT adapt to XYZ, that getting back null is fine, and that I don't care why the adaption failed. Cheers, Jeff. On 01/07/2014 10:19, Carsten Ziegeler cziege...@apache.org wrote: Sure :) For the adapter pattern, the client does not care why the adaption failed, the client is just interested in the result (success or not) Validation is a different beast, if validation fails you want to know specific reasons why it failed - and this can be multiple. I tried to explain in my first mail on this thread, that all other use cases mentioned can be handled with the current implementation - with the exception of validation. But I think validation requires a different concept than the adapter pattern. Carsten 2014-07-01 11:09 GMT+02:00 Jeff Young j...@adobe.com: Hi Carsten, Can you say more? (I'm not sure I understand what you're getting at) Thanks, Jeff. On 01/07/2014 09:56, Carsten Ziegeler cziege...@apache.org wrote: adaption and validation are different concerns Carsten 2014-07-01 10:55 GMT+02:00 Jeff Young j...@adobe.com: We could solve that by defining a specific exception for adaptation-not-possible and then catch only that. Of course that would leak tons of exceptions from code written before that exception became available. Maybe do the catching based on some sort of version clue? Cheers, Jeff. On 01/07/2014 09:40, Konrad Windszus konra...@gmx.de wrote: It is not (only) about throwing exceptions in case no suitable adapter is available. It rather is about the fact, that today the adaptTo is a barrier for all kinds of exceptions. In some cases the adaptation fails for a specific reason (one example is Sling Models where injection fails, another one is the issue mentioned in https://issues.apache.org/jira/browse/SLING-2712 (ValueMap not supporting primitives)). Both would be valid use cases where the client would be interested to catch the exception here. On 01 Jul 2014, at 10:34, Carsten Ziegeler cziege...@apache.org wrote: Adding a new interface would require us to implement it all over the place and as Felix points out, client code would always need to check whether the new interface is implemented or not Having to methods, like hasAdapter and adaptOrThrow does not work very well as between the two calls things might have changed already: while hasAdapter returns true, the underlying factory gets unregistered before adaptOrThrow is called. In many use cases, the current pattern works fine - the client does not care whether an exception is thrown within the adaption - it just cares whether an object is returned or not. And there are valid use cases, where client code does different things whether the adaption works or not (e.g. the post servlet checks for adaptTo(Node) and then does additional things if the resource is backed up by a node.) I see the point that there are also use cases where it would be fine to simpy throw an exception if adaptTo is not successful. This would make the client code easier. However as this most properly is a runtime exception,
Re: adaptTo and results ....
I just fix it in the code ;-). Those exceptions should only happen during runtime (due to some false assumptions). For the same reasons methods do throw IllegalArgumentExceptions in case a given parameter is null (http://stackoverflow.com/questions/5172948/should-we-always-check-each-parameter-of-method-in-java-for-null-in-the-first-li). This is mainly for the developer, but makes the life much easier as with that information it is obvious how to fix :-) Konrad On 01 Jul 2014, at 12:14, Carsten Ziegeler cziege...@apache.org wrote: So if your adapter is buggy and you get an exception, what do you do with it? Carsten 2014-07-01 12:08 GMT+02:00 Jeff Young j...@adobe.com: Hi Carsten, Sure, but Konrad has a point in that I think sometimes the client *does* care why the adaption failed. For instance, if it had to do with something entirely different from whether or not adaption would normally work. Let's say that I have a resource that should adapt to XYZ, but that my adapter is currently buggy. I'd like to get an exception for that, but said exception is going to get eaten. I do agree that if I have a resource that should NOT adapt to XYZ, that getting back null is fine, and that I don't care why the adaption failed. Cheers, Jeff. On 01/07/2014 10:19, Carsten Ziegeler cziege...@apache.org wrote: Sure :) For the adapter pattern, the client does not care why the adaption failed, the client is just interested in the result (success or not) Validation is a different beast, if validation fails you want to know specific reasons why it failed - and this can be multiple. I tried to explain in my first mail on this thread, that all other use cases mentioned can be handled with the current implementation - with the exception of validation. But I think validation requires a different concept than the adapter pattern. Carsten 2014-07-01 11:09 GMT+02:00 Jeff Young j...@adobe.com: Hi Carsten, Can you say more? (I'm not sure I understand what you're getting at) Thanks, Jeff. On 01/07/2014 09:56, Carsten Ziegeler cziege...@apache.org wrote: adaption and validation are different concerns Carsten 2014-07-01 10:55 GMT+02:00 Jeff Young j...@adobe.com: We could solve that by defining a specific exception for adaptation-not-possible and then catch only that. Of course that would leak tons of exceptions from code written before that exception became available. Maybe do the catching based on some sort of version clue? Cheers, Jeff. On 01/07/2014 09:40, Konrad Windszus konra...@gmx.de wrote: It is not (only) about throwing exceptions in case no suitable adapter is available. It rather is about the fact, that today the adaptTo is a barrier for all kinds of exceptions. In some cases the adaptation fails for a specific reason (one example is Sling Models where injection fails, another one is the issue mentioned in https://issues.apache.org/jira/browse/SLING-2712 (ValueMap not supporting primitives)). Both would be valid use cases where the client would be interested to catch the exception here. On 01 Jul 2014, at 10:34, Carsten Ziegeler cziege...@apache.org wrote: Adding a new interface would require us to implement it all over the place and as Felix points out, client code would always need to check whether the new interface is implemented or not Having to methods, like hasAdapter and adaptOrThrow does not work very well as between the two calls things might have changed already: while hasAdapter returns true, the underlying factory gets unregistered before adaptOrThrow is called. In many use cases, the current pattern works fine - the client does not care whether an exception is thrown within the adaption - it just cares whether an object is returned or not. And there are valid use cases, where client code does different things whether the adaption works or not (e.g. the post servlet checks for adaptTo(Node) and then does additional things if the resource is backed up by a node.) I see the point that there are also use cases where it would be fine to simpy throw an exception if adaptTo is not successful. This would make the client code easier. However as this most properly is a runtime exception, client code can today just call a method on the object and end up with a NPE - having the same result :) This leaves us with use cases where the client code explicitely wants to catch the exception and then do something depending on the exception. Maybe we should just add something for this explicit use case instead of bloating the general adaptTo mechanism? Regards Carsten 2014-07-01 9:44 GMT+02:00 Konrad Windszus konra...@gmx.de: Regarding 1) Having such a Result class would mean that all consumer would need to unwrap the exception first. So instead of being forced of implementing a null-check (as with the old solution) one would
RE: adaptTo and results ....
the NPE would swallow all maybe usefull excpetion information, that might be contained in the root cause of the exception throws by a method like adaptToOrThrow method. always logging the exception internally by the adapter manager has the drawback that the application might not be interested in the failure and does not want to log it. the decision whether a adaption failure is relevant or not should be taken by the application. I'm not convinced that a new interface and a adaptToOrThrow is the best solution either - but lets start to convince ourselves that it is a relevant usecase to have (optional, but with full error information) exception handling on an adaptTo call, whatever solution we find to add this without a big mess in the interface design. bertrand opened an interesting discussion on alternatives. stefan -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Tuesday, July 01, 2014 12:21 PM To: dev@sling.apache.org Subject: Re: adaptTo and results Yes, but right now you would get an NPE accessing the object - so you already have a runtime exception and don't need to check for null (I'm not arguing that this is a good way, I'm just trying to avoid heavy changes). And we could change the adapter manager/factory implemntation to log the exceptions (if they're not doing it already) Carsten 2014-07-01 12:17 GMT+02:00 Stefan Seifert sseif...@pro-vision.de: example: usecase like here https://issues.apache.org/jira/browse/SLING- 3714?focusedCommentId=14048040#comment-14048040 the caller code expects that the adaption is always successful if everything works correct - if not it is an application error which should be propagated through error handling and result in an error log message. stefan -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Tuesday, July 01, 2014 12:14 PM To: dev@sling.apache.org Subject: Re: adaptTo and results So if your adapter is buggy and you get an exception, what do you do with it? Carsten 2014-07-01 12:08 GMT+02:00 Jeff Young j...@adobe.com: Hi Carsten, Sure, but Konrad has a point in that I think sometimes the client *does* care why the adaption failed. For instance, if it had to do with something entirely different from whether or not adaption would normally work. Let's say that I have a resource that should adapt to XYZ, but that my adapter is currently buggy. I'd like to get an exception for that, but said exception is going to get eaten. I do agree that if I have a resource that should NOT adapt to XYZ, that getting back null is fine, and that I don't care why the adaption failed. Cheers, Jeff. On 01/07/2014 10:19, Carsten Ziegeler cziege...@apache.org wrote: Sure :) For the adapter pattern, the client does not care why the adaption failed, the client is just interested in the result (success or not) Validation is a different beast, if validation fails you want to know specific reasons why it failed - and this can be multiple. I tried to explain in my first mail on this thread, that all other use cases mentioned can be handled with the current implementation - with the exception of validation. But I think validation requires a different concept than the adapter pattern. Carsten 2014-07-01 11:09 GMT+02:00 Jeff Young j...@adobe.com: Hi Carsten, Can you say more? (I'm not sure I understand what you're getting at) Thanks, Jeff. On 01/07/2014 09:56, Carsten Ziegeler cziege...@apache.org wrote: adaption and validation are different concerns Carsten 2014-07-01 10:55 GMT+02:00 Jeff Young j...@adobe.com: We could solve that by defining a specific exception for adaptation-not-possible and then catch only that. Of course that would leak tons of exceptions from code written before that exception became available. Maybe do the catching based on some sort of version clue? Cheers, Jeff. On 01/07/2014 09:40, Konrad Windszus konra...@gmx.de wrote: It is not (only) about throwing exceptions in case no suitable adapter is available. It rather is about the fact, that today the adaptTo is a barrier for all kinds of exceptions. In some cases the adaptation fails for a specific reason (one example is Sling Models where injection fails, another one is the issue mentioned in https://issues.apache.org/jira/browse/SLING-2712 (ValueMap not supporting primitives)). Both would be valid use cases where the client would be interested to catch the exception here. On 01 Jul 2014, at 10:34, Carsten Ziegeler cziege...@apache.org wrote: Adding a new interface would require us to implement it all over the place and as Felix points out, client code would always need to check whether the new
Re: adaptTo and results ....
I like the idea too, but I guess it's merely a question of taste as to which of the following two options is nicer: * Foo f = someObject.adaptTo(RequireAdapterFoo.class)); * Foo f = someObject.adaptToUnchecked(Foo.class); Cheers, Stefan On 7/1/14 11:57 AM, Konrad Windszus konra...@gmx.de wrote: I like that approach. It is backwards-compatible and allows the developers to decide whether they want to check for null or to rely on exceptions. The AdapterManagerImpl indeed would need to deal with such a parametrisation and in addition the javadocs would need to be adjusted to make it clear that AdapterFactories may throw RuntimeExceptions. Those exceptions should be caught by the AdapterManagerImpl when the RequireAdapter was not requested and in the other case just passed along. On 01 Jul 2014, at 09:44, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jul 1, 2014 at 9:41 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: ...how about this: Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class)); Actually, rereading SLING-3714, this can be made simpler with generics Foo f = someObject.adaptTo(RequireAdapterFoo.class)); where RequireAdapter causes AdapterManagerImpl to wrap the adapters to throw an exception if adaption returns null. -Bertrand
Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Sample Integration Tests #2242
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.testing.samples.integrationtests/2242/
Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Event Support #2242
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.event/2242/
Re: adaptTo and results ....
On Tue, Jul 1, 2014 at 12:38 PM, Stefan Egli stefane...@apache.org wrote: I like the idea too, but I guess it's merely a question of taste as to which of the following two options is nicer: * Foo f = someObject.adaptTo(RequireAdapterFoo.class)); * Foo f = someObject.adaptToUnchecked(Foo.class); The big difference is that the first variant requires no API changes and only requires code changes in AdapterManagerImpl (I think - haven't looked in full detail ;-) -Bertrand
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #2242
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/2242/
Jenkins build is still unstable: sling-trunk-1.6 #2242
See https://builds.apache.org/job/sling-trunk-1.6/changes
Re: adaptTo and results ....
Ok, this would solve the throw if adaption is not possible case, what about the validation use case? Carsten 2014-07-01 12:50 GMT+02:00 Bertrand Delacretaz bdelacre...@apache.org: On Tue, Jul 1, 2014 at 12:38 PM, Stefan Egli stefane...@apache.org wrote: I like the idea too, but I guess it's merely a question of taste as to which of the following two options is nicer: * Foo f = someObject.adaptTo(RequireAdapterFoo.class)); * Foo f = someObject.adaptToUnchecked(Foo.class); The big difference is that the first variant requires no API changes and only requires code changes in AdapterManagerImpl (I think - haven't looked in full detail ;-) -Bertrand -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (SLING-3618) Unable to create node at /var/discovery error in sling trunk
[
https://issues.apache.org/jira/browse/SLING-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048770#comment-14048770
]
Stefan Egli commented on SLING-3618:
bq. no matching child node definition found for {}discovery
That's indeed odd. '/var' is just a sling:Folder so it should allow any type of
child node - and '/var/discovery' is just another sling:Folder ..
[~yogi_1306], can you double-check what jcr:primaryType '/var' has in your
case? And, if the problem persists? As a simple workaround you should be able
to manually create '/var/discovery' (with jcr:primaryType==sling:Folder) and it
should work fine..
Unable to create node at /var/discovery error in sling trunk
Key: SLING-3618
URL: https://issues.apache.org/jira/browse/SLING-3618
Project: Sling
Issue Type: Bug
Components: Extensions
Environment: All
Reporter: Yogesh Upadhyay
Fix For: Discovery Impl 1.0.10
Getting following error after using trunk version of jar
29.05.2014 23:13:15.980 *ERROR* [Apache Sling JCR Resource Event Queue
Processor for path '/'] org.apache.sling.discovery.impl
[org.apache.sling.discovery.impl.DiscoveryServiceImpl(52)] The activate
method has thrown an exception (java.lang.RuntimeException: Exception while
talking to repository (org.apache.sling.api.resource.PersistenceException:
Unable to create node at /var/discovery))
java.lang.RuntimeException: Exception while talking to repository
(org.apache.sling.api.resource.PersistenceException: Unable to create node at
/var/discovery)
at
org.apache.sling.discovery.impl.topology.announcement.AnnouncementRegistryImpl.listAnnouncementsInSameCluster(AnnouncementRegistryImpl.java:204)
at
org.apache.sling.discovery.impl.topology.announcement.AnnouncementRegistryImpl.listInstances(AnnouncementRegistryImpl.java:487)
at
org.apache.sling.discovery.impl.DiscoveryServiceImpl.getTopology(DiscoveryServiceImpl.java:423)
at
org.apache.sling.discovery.impl.DiscoveryServiceImpl.activate(DiscoveryServiceImpl.java:145)
at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:231)
at
org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:39)
at
org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:624)
at
org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:508)
at
org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:149)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:315)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:127)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:871)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:838)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:777)
at
org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:320)
at
org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:231)
at
org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:327)
at org.apache.felix.framework.Felix.getService(Felix.java:3574)
at
org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:468)
at
org.apache.felix.scr.impl.helper.BindMethod.getServiceObject(BindMethod.java:572)
at
org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2012)
at
org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.prebind(DependencyManager.java:1005)
at
org.apache.felix.scr.impl.manager.DependencyManager.prebind(DependencyManager.java:1439)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:1119)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:807)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:777)
at
org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:320)
at
Re: adaptTo and results ....
That would be solved by just stating that RuntimeExceptions are allowed as alternative to returning null for all AdapterFactories (i.e. no API change necessary) and making sure that those exceptions are either being caught within the AdapterManagerImpl or just propagated to the caller. On 01 Jul 2014, at 13:08, Carsten Ziegeler cziege...@apache.org wrote: Ok, this would solve the throw if adaption is not possible case, what about the validation use case? Carsten 2014-07-01 12:50 GMT+02:00 Bertrand Delacretaz bdelacre...@apache.org: On Tue, Jul 1, 2014 at 12:38 PM, Stefan Egli stefane...@apache.org wrote: I like the idea too, but I guess it's merely a question of taste as to which of the following two options is nicer: * Foo f = someObject.adaptTo(RequireAdapterFoo.class)); * Foo f = someObject.adaptToUnchecked(Foo.class); The big difference is that the first variant requires no API changes and only requires code changes in AdapterManagerImpl (I think - haven't looked in full detail ;-) -Bertrand -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: adaptTo and results ....
Well, for one thing, display it in the Developer Mode console (or whatever other debugging UIs my app happens to have). Jeff. On 01/07/2014 11:14, Carsten Ziegeler cziege...@apache.org wrote: So if your adapter is buggy and you get an exception, what do you do with it? Carsten 2014-07-01 12:08 GMT+02:00 Jeff Young j...@adobe.com: Hi Carsten, Sure, but Konrad has a point in that I think sometimes the client *does* care why the adaption failed. For instance, if it had to do with something entirely different from whether or not adaption would normally work. Let's say that I have a resource that should adapt to XYZ, but that my adapter is currently buggy. I'd like to get an exception for that, but said exception is going to get eaten. I do agree that if I have a resource that should NOT adapt to XYZ, that getting back null is fine, and that I don't care why the adaption failed. Cheers, Jeff. On 01/07/2014 10:19, Carsten Ziegeler cziege...@apache.org wrote: Sure :) For the adapter pattern, the client does not care why the adaption failed, the client is just interested in the result (success or not) Validation is a different beast, if validation fails you want to know specific reasons why it failed - and this can be multiple. I tried to explain in my first mail on this thread, that all other use cases mentioned can be handled with the current implementation - with the exception of validation. But I think validation requires a different concept than the adapter pattern. Carsten 2014-07-01 11:09 GMT+02:00 Jeff Young j...@adobe.com: Hi Carsten, Can you say more? (I'm not sure I understand what you're getting at) Thanks, Jeff. On 01/07/2014 09:56, Carsten Ziegeler cziege...@apache.org wrote: adaption and validation are different concerns Carsten 2014-07-01 10:55 GMT+02:00 Jeff Young j...@adobe.com: We could solve that by defining a specific exception for adaptation-not-possible and then catch only that. Of course that would leak tons of exceptions from code written before that exception became available. Maybe do the catching based on some sort of version clue? Cheers, Jeff. On 01/07/2014 09:40, Konrad Windszus konra...@gmx.de wrote: It is not (only) about throwing exceptions in case no suitable adapter is available. It rather is about the fact, that today the adaptTo is a barrier for all kinds of exceptions. In some cases the adaptation fails for a specific reason (one example is Sling Models where injection fails, another one is the issue mentioned in https://issues.apache.org/jira/browse/SLING-2712 (ValueMap not supporting primitives)). Both would be valid use cases where the client would be interested to catch the exception here. On 01 Jul 2014, at 10:34, Carsten Ziegeler cziege...@apache.org wrote: Adding a new interface would require us to implement it all over the place and as Felix points out, client code would always need to check whether the new interface is implemented or not Having to methods, like hasAdapter and adaptOrThrow does not work very well as between the two calls things might have changed already: while hasAdapter returns true, the underlying factory gets unregistered before adaptOrThrow is called. In many use cases, the current pattern works fine - the client does not care whether an exception is thrown within the adaption - it just cares whether an object is returned or not. And there are valid use cases, where client code does different things whether the adaption works or not (e.g. the post servlet checks for adaptTo(Node) and then does additional things if the resource is backed up by a node.) I see the point that there are also use cases where it would be fine to simpy throw an exception if adaptTo is not successful. This would make the client code easier. However as this most properly is a runtime exception, client code can today just call a method on the object and end up with a NPE - having the same result :) This leaves us with use cases where the client code explicitely wants to catch the exception and then do something depending on the exception. Maybe we should just add something for this explicit use case instead of bloating the general adaptTo mechanism? Regards Carsten 2014-07-01 9:44 GMT+02:00 Konrad Windszus konra...@gmx.de: Regarding 1) Having such a Result class would mean that all consumer would need to unwrap the exception first. So instead of being forced of implementing a null-check (as with the old solution) one would need to implement another check. I want to prevent such a burden to the consumers. Regarding 2) Since the client code knows on which object the
[jira] [Commented] (SLING-3714) Allow for a caller to request a non-null response from adaptTo()
[
https://issues.apache.org/jira/browse/SLING-3714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048780#comment-14048780
]
Konrad Windszus commented on SLING-3714:
Idea from [~bdelacretaz]: Don't change the API of the Adapter nor of the
AdapterFactory, but only touch the AdapterManagerImpl
(https://github.com/apache/sling/blob/trunk/bundles/extensions/adapter/src/main/java/org/apache/sling/adapter/internal/AdapterManagerImpl.java)
to be able to deal with a parametrization like
{code}
Foo f = someObject.adaptTo(RequireAdapterFoo.class));
{code}
In that case
a) RuntimeExceptions from AdapterFactories should not be caught (already the
case)
b) Instead of returning null if no AdapterFactory can be found an exception
should be thrown
In all other cases
c) RuntimeExceptions should be caught and logged (still to be decided on what
level)
d) null is returned if adaptation was not successfull (for whatever reason)
In addition to that code change the javadoc of AdapterFactory
(https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/adapter/AdapterFactory.java)
should be extended to say that RuntimeExceptions should be thrown, if the
adaptation is not possible for some technical reasons.
Allow for a caller to request a non-null response from adaptTo()
Key: SLING-3714
URL: https://issues.apache.org/jira/browse/SLING-3714
Project: Sling
Issue Type: Improvement
Reporter: Justin Edelson
See SLING-3709 for a Sling Models-specific request. As I commented there, I
think this makes more sense as a core change to the Adaptable interface.
One option:
resource.adaptTo(ResultNode.class)
Which returns a Result object, which has an API like:
interface ResultT {
boolean isSuccess();
T getObject();
ListError getErrors();
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (SLING-3714) Allow for a caller to request a non-null response from adaptTo()
[
https://issues.apache.org/jira/browse/SLING-3714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048780#comment-14048780
]
Konrad Windszus edited comment on SLING-3714 at 7/1/14 11:51 AM:
-
Idea from [~bdelacretaz] in
http://www.mail-archive.com/dev@sling.apache.org/msg31261.html: Don't change
the API of the Adapter nor of the AdapterFactory, but only touch the
AdapterManagerImpl
(https://github.com/apache/sling/blob/trunk/bundles/extensions/adapter/src/main/java/org/apache/sling/adapter/internal/AdapterManagerImpl.java)
to be able to deal with a parametrization like
{code}
Foo f = someObject.adaptTo(RequireAdapterFoo.class));
{code}
In that case
a) RuntimeExceptions from AdapterFactories should not be caught (already the
case)
b) Instead of returning null if no AdapterFactory can be found an exception
should be thrown
In all other cases
c) RuntimeExceptions should be caught and logged (still to be decided on what
level)
d) null is returned if adaptation was not successfull (for whatever reason)
In addition to that code change the javadoc of AdapterFactory
(https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/adapter/AdapterFactory.java)
should be extended to say that RuntimeExceptions should be thrown, if the
adaptation is not possible for some technical reasons.
was (Author: kwin):
Idea from [~bdelacretaz]: Don't change the API of the Adapter nor of the
AdapterFactory, but only touch the AdapterManagerImpl
(https://github.com/apache/sling/blob/trunk/bundles/extensions/adapter/src/main/java/org/apache/sling/adapter/internal/AdapterManagerImpl.java)
to be able to deal with a parametrization like
{code}
Foo f = someObject.adaptTo(RequireAdapterFoo.class));
{code}
In that case
a) RuntimeExceptions from AdapterFactories should not be caught (already the
case)
b) Instead of returning null if no AdapterFactory can be found an exception
should be thrown
In all other cases
c) RuntimeExceptions should be caught and logged (still to be decided on what
level)
d) null is returned if adaptation was not successfull (for whatever reason)
In addition to that code change the javadoc of AdapterFactory
(https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/adapter/AdapterFactory.java)
should be extended to say that RuntimeExceptions should be thrown, if the
adaptation is not possible for some technical reasons.
Allow for a caller to request a non-null response from adaptTo()
Key: SLING-3714
URL: https://issues.apache.org/jira/browse/SLING-3714
Project: Sling
Issue Type: Improvement
Reporter: Justin Edelson
See SLING-3709 for a Sling Models-specific request. As I commented there, I
think this makes more sense as a core change to the Adaptable interface.
One option:
resource.adaptTo(ResultNode.class)
Which returns a Result object, which has an API like:
interface ResultT {
boolean isSuccess();
T getObject();
ListError getErrors();
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Build failed in Jenkins: sling-contrib-1.6 » Apache Sling Replication Integration Tests #1163
See https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/1163/ -- [INFO] [INFO] [INFO] Building Apache Sling Replication Integration Tests 0.0.1-SNAPSHOT [INFO] Downloading: http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.testing.tools/1.0.7-SNAPSHOT/maven-metadata.xml [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ org.apache.sling.replication.it --- [INFO] Deleting https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target [INFO] Deleting https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/ (includes = [sling/**], excludes = []) [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-java) @ org.apache.sling.replication.it --- [INFO] [INFO] --- maven-antrun-plugin:1.7:run (set-bundle-required-execution-environment) @ org.apache.sling.replication.it --- [INFO] Executing tasks main: [INFO] Executed tasks [INFO] [INFO] --- maven-remote-resources-plugin:1.5:process (default) @ org.apache.sling.replication.it --- [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ org.apache.sling.replication.it --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/src/main/resources [INFO] Copying 3 resources [INFO] [INFO] --- maven-antrun-plugin:1.7:run (check-memory-task) @ org.apache.sling.replication.it --- [INFO] Executing tasks main: [echo] WARNING (SLING-443/SLING-1782) ** [echo] On most platforms, you'll get OutOfMemoryErrors when building unless you set [echo] on 32bit platforms: MAVEN_OPTS=-Xmx256M -XX:MaxPermSize=256M, see SLING-443 [echo] on 64bit platforms: MAVEN_OPTS=-Xmx512M -XX:MaxPermSize=512M, see SLING-1782 [echo] ** [INFO] Executed tasks [INFO] [INFO] --- maven-dependency-plugin:2.8:copy-dependencies (copy-runnable-jar) @ org.apache.sling.replication.it --- [INFO] Copying org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/dependency/org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar [INFO] [INFO] --- maven-dependency-plugin:2.8:copy-dependencies (copy-additional-bundles) @ org.apache.sling.replication.it --- [INFO] Copying org.apache.sling.commons.json-2.0.6.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/org.apache.sling.commons.json-2.0.6.jar [INFO] Copying jackrabbit-jcr-commons-2.7.2.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/jackrabbit-jcr-commons-2.7.2.jar [INFO] Copying slf4j-api-1.5.11.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/slf4j-api-1.5.11.jar [INFO] Copying jackrabbit-api-2.7.2.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/jackrabbit-api-2.7.2.jar [INFO] Copying commons-io-2.4.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/commons-io-2.4.jar [INFO] Copying jcr-2.0.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/jcr-2.0.jar [INFO] Copying junit-4.8.2.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/junit-4.8.2.jar [INFO] Copying org.apache.sling.replication-0.0.1-SNAPSHOT.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/org.apache.sling.replication-0.0.1-SNAPSHOT.jar [INFO] Copying bndlib-1.50.0.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/bndlib-1.50.0.jar [INFO] Copying org.apache.felix.scr.annotations-1.9.8.jar to https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/ws/target/sling/additional-bundles/org.apache.felix.scr.annotations-1.9.8.jar [INFO] Copying org.apache.sling.api-2.5.0.jar to
Build failed in Jenkins: sling-contrib-1.6 #1163
See https://builds.apache.org/job/sling-contrib-1.6/1163/changes Changes: [bdelacretaz] Fix registration of multiple resources via the Sling installer -- [...truncated 2945 lines...] [INFO] Copying jackrabbit-jcr-commons-2.7.2.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/jackrabbit-jcr-commons-2.7.2.jar [INFO] Copying slf4j-api-1.5.11.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/slf4j-api-1.5.11.jar [INFO] Copying jackrabbit-api-2.7.2.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/jackrabbit-api-2.7.2.jar [INFO] Copying commons-io-2.4.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/commons-io-2.4.jar [INFO] Copying jcr-2.0.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/jcr-2.0.jar [INFO] Copying junit-4.8.2.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/junit-4.8.2.jar [INFO] Copying org.apache.sling.replication-0.0.1-SNAPSHOT.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/org.apache.sling.replication-0.0.1-SNAPSHOT.jar [INFO] Copying bndlib-1.50.0.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/bndlib-1.50.0.jar [INFO] Copying org.apache.felix.scr.annotations-1.9.8.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/org.apache.felix.scr.annotations-1.9.8.jar [INFO] Copying org.apache.sling.api-2.5.0.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/org.apache.sling.api-2.5.0.jar [INFO] Copying org.apache.sling.commons.osgi-2.2.0.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/org.apache.sling.commons.osgi-2.2.0.jar [INFO] Copying org.apache.sling.hc.core-1.0.6.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/org.apache.sling.hc.core-1.0.6.jar [INFO] Copying slf4j-simple-1.5.11.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/slf4j-simple-1.5.11.jar [INFO] Copying org.apache.sling.testing.tools-1.0.7-SNAPSHOT.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/org.apache.sling.testing.tools-1.0.7-SNAPSHOT.jar [INFO] Copying httpclient-osgi-4.3.2.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/httpclient-osgi-4.3.2.jar [INFO] Copying org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar [INFO] Copying servlet-api-2.4.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/servlet-api-2.4.jar [INFO] Copying org.apache.jackrabbit.vault-3.0.0.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/org.apache.jackrabbit.vault-3.0.0.jar [INFO] Copying httpcore-osgi-4.3.1.jar to https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/target/sling/additional-bundles/httpcore-osgi-4.3.1.jar [INFO] [INFO] --- build-helper-maven-plugin:1.8:reserve-network-port (reserve-server-port) @ org.apache.sling.replication.it --- [INFO] Reserved port 57502 for author.http.port [INFO] Reserved port 55169 for publish.http.port [INFO] [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ org.apache.sling.replication.it --- [INFO] No sources to compile [INFO] [INFO] --- maven-scr-plugin:1.16.0:scr (generate-scr-scrdescriptor) @ org.apache.sling.replication.it --- [WARNING] Source tree does not exist. Ignoring https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/src/main/java [WARNING] Source tree does not exist. Ignoring https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/src/main/java [WARNING] Source tree does not exist. Ignoring https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/extensions/replication/it/src/main/java [INFO] [INFO] ---
Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Event Support #2243
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.event/2243/
Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Sample Integration Tests #2243
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.testing.samples.integrationtests/2243/
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #2243
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/2243/
Jenkins build is still unstable: sling-trunk-1.6 #2243
See https://builds.apache.org/job/sling-trunk-1.6/changes
Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Models Integration Tests #2243
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.models.integration-tests/2243/
Re: [VOTE] Release Apache Sling IDE Tooling 1.0.0
+1 On Tue, Jul 1, 2014 at 5:55 AM, Stefan Egli stefane...@apache.org wrote: +1 (verified md5 sha1 using the check_staged_release.sh) Cheers, Stefan On 7/1/14 8:34 AM, Carsten Ziegeler cziege...@apache.org wrote: Thanks for redoing, Robert. +1 Carsten 2014-07-01 2:01 GMT+02:00 Justin Edelson jus...@justinedelson.com: +1 On Mon, Jun 30, 2014 at 12:14 PM, Robert Munteanu rob...@lmn.ro wrote: I think I've gotten the right Maven/Tycho incantations set up and deployed the 1.0.0 artifacts to https://repository.apache.org/content/repositories/orgapachesling-1072/ The single compromise that I had to make is that the integration tests were not included in the reactor build and therefore not deployed to the nexus repo. Hopefully that's acceptable for the release. I can restart the release vote if needed ( third time's the charm? ) but it would be good to know that I got things right this time. Note: check_staged_release.sh took about 30 minutes to complete for me. Thanks, Robert On Mon, Jun 30, 2014 at 1:53 PM, Carsten Ziegeler cziege...@apache.org wrote: Thanks for the info, Robert - I'm not sure what the best approach is, however the zip now contains 1.0.0-SNAPSHOT as versions but I guess the final release should be 1.0.0. This would mean we're voting on something which is then not released. On the other hand, if we put up 1.0.0 in a globally available space everyone can simply download it from there and voting, especially withdrawing the release is way harder. Carsten 2014-06-30 10:06 GMT+02:00 Robert Munteanu romb...@apache.org: Hi Carsten, On Mon, Jun 30, 2014 at 8:57 AM, Carsten Ziegeler cziege...@apache.org wrote: Why is this release not following the normal release procedure and available via the staging maven repo? There are two main reasons. 1. While the build is driven by Maven, building Eclipse plug-ins with Tycho means that some of the regular Maven plugins don't work. For instance, the source and javadoc plugin, see [1],[2] . Since IIUC the release is based on the source code, and the binaries are just for convenience, I opted not to make the release run on the output of individual projects, but on the whole source zip. 2. If I were to deploy the plug-ins by themselves to the repo, it would not be trivial to assemble back an p2/Eclipse update which can be used to test the functionality of the release. That being said, I'd be more than happy to refine this process, so suggestions on how to do that are welcome :-) Thanks, Robert [1]: https://dev.eclipse.org/mhonarc/lists/tycho-user/msg05730.html [2]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=398061 Carsten 2014-06-29 21:32 GMT+02:00 Robert Munteanu romb...@apache.org: Anyone? Robert On Thu, Jun 26, 2014 at 11:32 AM, Robert Munteanu romb...@apache.org wrote: Hi, We solved 144 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12324873 There are still some outstanding issues: https://issues.apache.org/jira/browse/SLING/component/12320908 The release candidate has been uploaded at https://dist.apache.org/repos/dist/dev/sling, and can be built using mvn clean package The resulting binaries can be installed into an Eclipse instance by installing from the update site which is found at p2update/target/repository after building the project. Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Sent from my (old) computer -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #616
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.launchpad.testing/616/
Jenkins build is still unstable: sling-trunk-1.7 #616
See https://builds.apache.org/job/sling-trunk-1.7/changes
[RESULT][VOTE] Release Apache Sling IDE Tooling 1.0.0
Hi, The vote has passed with the following result : +1 (binding): Robert Munteanu, Justin Edelson, Carsten Ziegler, Stefan Egli, Daniel Klco I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. Robert
Re: [VOTE] Release Apache Sling Models API 1.0.2 Implementation 1.0.6
Need one more binding vote On Friday, June 27, 2014, Stefan Seifert sseif...@pro-vision.de wrote: +1 (non-binding) p.s. integration tests are running fine on my machine -Original Message- From: justinedel...@gmail.com javascript:; [mailto: justinedel...@gmail.com javascript:;] On Behalf Of Justin Edelson Sent: Wednesday, June 25, 2014 6:02 PM To: dev@sling.apache.org javascript:; Subject: [VOTE] Release Apache Sling Models API 1.0.2 Implementation 1.0.6 Hi, We solved 9 issues in these releases: https://issues.apache.org/jira/browse/SLING/fixforversion/12326850 https://issues.apache.org/jira/browse/SLING/fixforversion/12327153 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1070/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1070 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours.
[jira] [Updated] (SLING-3718) Sling Models: Add self Injector for supporting chains of object injecting dependencies from a common source
[
https://issues.apache.org/jira/browse/SLING-3718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated SLING-3718:
--
Attachment:
140701_SLING-3716_slingmodes_constructorinjection_SLING-3718_selfinjector.patch
attached is a combined patch for SLING-3716 and SLING-3718 (replacing the patch
already attached to SLING-3716).
remarks:
* your comments are correct - adapting inside the injector is wrong. as
recommended i introduced a @Self annotation (which was missing in the patch
from SLING-3716) and tweaked the implementation of the SelfInjector a bit. not
it works as expected re-using the adaption logic from ModelAdapterFactory.
* i added a component unit test and a counteraction for cyclic dependencies
based on a threadlocal - please review
* the max. number of recursive invocations is currently hardcoded - perhaps it
makes sense to expose it as OSGi property to make it configurable
i'm currenty not fully happy with the @Self annotation name. although its
consistent with the other injectors and annotations the code reads not so
intuitive if not the adaptable itself, but an object that can be adapted from
the adaptable is injected:
{code:java}
@Model(adaptables=SlingHttpServletRequest.class)
public class MyController {
@Self
private MyBusiness myBusiness;
}
@Model(adaptables=SlingHttpServletRequest.class)
public class MyBusiness {
}
{code}
but perhaps one gets accustomed soon to this.
p.s. in the meantime a lot of inner classes have accumulated inside the
ModelAdapterFactory class. perhaps it makes sense to extract them to separate
files to make the class a bit more readable again.
Sling Models: Add self Injector for supporting chains of object injecting
dependencies from a common source
---
Key: SLING-3718
URL: https://issues.apache.org/jira/browse/SLING-3718
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Stefan Seifert
Priority: Minor
Attachments:
140701_SLING-3716_slingmodes_constructorinjection_SLING-3718_selfinjector.patch
as discussed in my post on the sling mailing list
http://mail-archives.apache.org/mod_mbox/sling-dev/201406.mbox/%3c580afa6c6dab8a4196956da5ee17c8ca8f7619e...@feanor.pro-vision.de%3E
it would be very helpful to have a self-adapting injector to support chains
of objects (e.g. controller classes depending on business classes) that all
can adapt themselves from a common source, e.g. a SlingHttpServletRequest or
a ResourceResolver.
souch an injector can be simple like this:
{code:java}
@Component
@Service
@Property(name = Constants.SERVICE_RANKING, intValue = 50)
public class SelfAdaptInjector implements Injector {
public String getName() {
return selfadapt;
}
public Object getValue(Object pAdaptable, String pName, Type pType,
AnnotatedElement pElement,
DisposalCallbackRegistry pCallbackRegistry) {
if (!(pType instanceof Class)) {
return null;
}
if (!(pAdaptable instanceof Adaptable)) {
return null;
}
return ((Adaptable)pAdaptable).adaptTo((Class?)pType);
}
}
{code}
comment from Justin on this in the mailing list:
{quote}
The self injector is interesting. I held off on that initially because
it seems too easy to create a circular injection. Any thoughts on how
that can be avoided?
\[...\]
Regards,
Justin
{quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SLING-3716) Sling Models: Add support for constructor dependency injection
[ https://issues.apache.org/jira/browse/SLING-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048841#comment-14048841 ] Stefan Seifert commented on SLING-3716: --- please note: SLING-3718 contains an updated patch that implements both requirements from this ticket and SLING-3718, because they both have the requirement for a SelfInjector implementation. Sling Models: Add support for constructor dependency injection -- Key: SLING-3716 URL: https://issues.apache.org/jira/browse/SLING-3716 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Stefan Seifert Priority: Minor Attachments: 140701_SLING-3716_slingmodes_constructorinjection.patch Currently, Sling Models only supports dependency injection for fields (or interface getter methods), but not for constructor arguments. This ticket is for discussing what this constructor dependency injection should support, and perhaps finally provide a patch to implement it. This is somewhat related to SLING-3715 for class-based dependency injection, because this would come in especially handy for constructor injection. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (SLING-3718) Sling Models: Add self Injector for supporting chains of object injecting dependencies from a common source
[
https://issues.apache.org/jira/browse/SLING-3718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048840#comment-14048840
]
Stefan Seifert edited comment on SLING-3718 at 7/1/14 1:15 PM:
---
attached is a combined patch for SLING-3716 and SLING-3718 (replacing the patch
already attached to SLING-3716).
remarks:
* your comments are correct - adapting inside the injector is wrong. as
recommended i introduced a @Self annotation (which was missing in the patch
from SLING-3716) and tweaked the implementation of the SelfInjector a bit. now
it works as expected re-using the adaption logic from ModelAdapterFactory.
* i added a component unit test and a counteraction for cyclic dependencies
based on a threadlocal - please review
* the max. number of recursive invocations is currently hardcoded - perhaps it
makes sense to expose it as OSGi property to make it configurable
i'm currently not fully happy with the @Self annotation name. although its
consistent with the other injectors and annotations the code reads not so
intuitive if not the adaptable itself, but an object that can be adapted from
the adaptable is injected:
{code:java}
@Model(adaptables=SlingHttpServletRequest.class)
public class MyController {
@Self
private MyBusiness myBusiness;
}
@Model(adaptables=SlingHttpServletRequest.class)
public class MyBusiness {
}
{code}
but perhaps one gets accustomed soon to this.
p.s. in the meantime a lot of inner classes have accumulated inside the
ModelAdapterFactory class. perhaps it makes sense to extract them to separate
files to make the class a bit more readable again.
was (Author: sseif...@pro-vision.de):
attached is a combined patch for SLING-3716 and SLING-3718 (replacing the patch
already attached to SLING-3716).
remarks:
* your comments are correct - adapting inside the injector is wrong. as
recommended i introduced a @Self annotation (which was missing in the patch
from SLING-3716) and tweaked the implementation of the SelfInjector a bit. not
it works as expected re-using the adaption logic from ModelAdapterFactory.
* i added a component unit test and a counteraction for cyclic dependencies
based on a threadlocal - please review
* the max. number of recursive invocations is currently hardcoded - perhaps it
makes sense to expose it as OSGi property to make it configurable
i'm currenty not fully happy with the @Self annotation name. although its
consistent with the other injectors and annotations the code reads not so
intuitive if not the adaptable itself, but an object that can be adapted from
the adaptable is injected:
{code:java}
@Model(adaptables=SlingHttpServletRequest.class)
public class MyController {
@Self
private MyBusiness myBusiness;
}
@Model(adaptables=SlingHttpServletRequest.class)
public class MyBusiness {
}
{code}
but perhaps one gets accustomed soon to this.
p.s. in the meantime a lot of inner classes have accumulated inside the
ModelAdapterFactory class. perhaps it makes sense to extract them to separate
files to make the class a bit more readable again.
Sling Models: Add self Injector for supporting chains of object injecting
dependencies from a common source
---
Key: SLING-3718
URL: https://issues.apache.org/jira/browse/SLING-3718
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Stefan Seifert
Priority: Minor
Attachments:
140701_SLING-3716_slingmodes_constructorinjection_SLING-3718_selfinjector.patch
as discussed in my post on the sling mailing list
http://mail-archives.apache.org/mod_mbox/sling-dev/201406.mbox/%3c580afa6c6dab8a4196956da5ee17c8ca8f7619e...@feanor.pro-vision.de%3E
it would be very helpful to have a self-adapting injector to support chains
of objects (e.g. controller classes depending on business classes) that all
can adapt themselves from a common source, e.g. a SlingHttpServletRequest or
a ResourceResolver.
souch an injector can be simple like this:
{code:java}
@Component
@Service
@Property(name = Constants.SERVICE_RANKING, intValue = 50)
public class SelfAdaptInjector implements Injector {
public String getName() {
return selfadapt;
}
public Object getValue(Object pAdaptable, String pName, Type pType,
AnnotatedElement pElement,
DisposalCallbackRegistry pCallbackRegistry) {
if (!(pType instanceof Class)) {
return null;
}
if (!(pAdaptable instanceof Adaptable)) {
return null;
}
return ((Adaptable)pAdaptable).adaptTo((Class?)pType);
}
}
{code}
comment from Justin on this in the mailing list:
{quote}
The self injector is interesting. I held off on that initially because
it seems too easy to create a circular injection.
Re: SLING-3667 - SlingQuery contribution
Anyone? On Sun, Jun 22, 2014 at 10:19 PM, Robert Munteanu romb...@apache.org wrote: Hi, In SLING-3667 [1] Tomek Rękawek was kind enough to submit the SlingQuery library to the Sling project. I am not certain whether this contribution needs to go through the extra process described at [2] or not, so I'd appreciate if someone with more experience can weigh in on this issue. Thanks, Robert [1]: https://issues.apache.org/jira/browse/SLING-3667 [2]: https://www.apache.org/dev/committers.html#code-import
Re: [cms] Updating the downloads section for the IDE Tooling
On Tue, Jul 1, 2014 at 3:14 PM, Robert Munteanu romb...@apache.org wrote: ...Does anyone know how to debug this?... You'd have to install the CMS locally AFAIK...someone should really create a Vagrant box for that but ENOTIME. In the meantime I think I fixed it in http://svn.apache.org/r1607079 ;-) -Bertrand
Re: [cms] Updating the downloads section for the IDE Tooling
On Tue, Jul 1, 2014 at 4:56 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jul 1, 2014 at 3:14 PM, Robert Munteanu romb...@apache.org wrote: ...Does anyone know how to debug this?... You'd have to install the CMS locally AFAIK...someone should really create a Vagrant box for that but ENOTIME. In the meantime I think I fixed it in http://svn.apache.org/r1607079 ;-) Thanks! Robert -- Sent from my (old) computer
[jira] [Comment Edited] (SLING-3685) Document and further automate the IDE tooling release process
[
https://issues.apache.org/jira/browse/SLING-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040663#comment-14040663
]
Robert Munteanu edited comment on SLING-3685 at 7/1/14 2:42 PM:
For reference, this is the current release process, assuming that the current
version is 1.0.1-SNAPSHOT
* set the fix version as released: {{mvn tycho-versions:set-version
-DnewVersion=1.0.2}}
* commit the change to svn
* manually tag in svn {{svn copy
https://svn.apache.org/repos/asf/sling/trunk/tooling/ide
https://svn.apache.org/repos/asf/sling/tags/sling-ide-tooling-1.0.2}}
* deploy the project with p2/gpg signing enabled {{mvn clean deploy
-Psign,!eclipse-test}} ( alternatively {{mvn clean deploy
-Psign,\!eclipse-test}} to make bash happy)
* inspect the staging repository from nexus to ensure that all artifacts are
properly deployed
* call the vote
* Update to next version, e.g. {{mvn tycho-versions:set-version
-DnewVersion=1.0.3-SNAPSHOT}}
Once the release has passed, the following must be done:
* upload p2update.zip* to https://dist.apache.org/repos/dist/release/sling/
* upload unzipped update site to
https://dist.apache.org/repos/dist/release/sling/eclipse/1.0.2
* update
https://dist.apache.org/repos/dist/release/sling/eclipse/composite{Content,Artifacts}.xml
to point to the latest $VERSION ( remove old one )
* (TODO how?) archive the old artifact versions but leave pointers to
archive.apache.org
was (Author: rombert):
For reference, this is the current release process, assuming that the current
version is 1.0.1-SNAPSHOT
* set the fix version as released: {{mvn tycho-versions:set-version
-DnewVersion=1.0.2}}
* commit the change to svn
* manually tag in svn {{svn copy
https://svn.apache.org/repos/asf/sling/trunk/tooling/ide
https://svn.apache.org/repos/asf/sling/tags/sling-ide-tooling-1.0.2}}
* deploy the project with p2/gpg signing enabled {{mvn clean deploy
-Psign,!eclipse-test}} ( alternatively {{mvn clean deploy
-Psign,\!eclipse-test}} to make bash happy)
* inspect the staging repository from nexus to ensure that all artifacts are
properly deployed
* call the vote
* Update to next version, e.g. {{mvn tycho-versions:set-version
-DnewVersion=1.0.3-SNAPSHOT}}
Document and further automate the IDE tooling release process
-
Key: SLING-3685
URL: https://issues.apache.org/jira/browse/SLING-3685
Project: Sling
Issue Type: Task
Components: IDE
Reporter: Robert Munteanu
Fix For: Sling Eclipse IDE 1.0.2
The current release process is very much manual, due to some of tycho's
peculiarities ( see also SLING-3620 ). This task tracks the documentation of
this release process and possible automation enhancements.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (SLING-3685) Document and further automate the IDE tooling release process
[
https://issues.apache.org/jira/browse/SLING-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040663#comment-14040663
]
Robert Munteanu edited comment on SLING-3685 at 7/1/14 2:44 PM:
For reference, this is the current release process, assuming that the current
version is 1.0.1-SNAPSHOT
* set the fix version as released: {{mvn tycho-versions:set-version
-DnewVersion=1.0.2}}
* commit the change to svn
* manually tag in svn {{svn copy
https://svn.apache.org/repos/asf/sling/trunk/tooling/ide
https://svn.apache.org/repos/asf/sling/tags/sling-ide-tooling-1.0.2}}
* deploy the project with p2/gpg signing enabled {{mvn clean deploy
-Psign,!eclipse-test}} ( alternatively {{mvn clean deploy
-Psign,\!eclipse-test}} to make bash happy)
* inspect the staging repository from nexus to ensure that all artifacts are
properly deployed
* call the vote
* Update to next version, e.g. {{mvn tycho-versions:set-version
-DnewVersion=1.0.3-SNAPSHOT}}
Once the release has passed, the following must be done:
* upload p2update.zip* to https://dist.apache.org/repos/dist/release/sling/
* upload unzipped update site to
https://dist.apache.org/repos/dist/release/sling/eclipse/1.0.2
* update
https://dist.apache.org/repos/dist/release/sling/eclipse/composite\{Content,Artifacts\}.xml
to point to the latest $VERSION ( remove old one )
* (TODO how?) archive the old artifact versions but leave pointers to
archive.apache.org
was (Author: rombert):
For reference, this is the current release process, assuming that the current
version is 1.0.1-SNAPSHOT
* set the fix version as released: {{mvn tycho-versions:set-version
-DnewVersion=1.0.2}}
* commit the change to svn
* manually tag in svn {{svn copy
https://svn.apache.org/repos/asf/sling/trunk/tooling/ide
https://svn.apache.org/repos/asf/sling/tags/sling-ide-tooling-1.0.2}}
* deploy the project with p2/gpg signing enabled {{mvn clean deploy
-Psign,!eclipse-test}} ( alternatively {{mvn clean deploy
-Psign,\!eclipse-test}} to make bash happy)
* inspect the staging repository from nexus to ensure that all artifacts are
properly deployed
* call the vote
* Update to next version, e.g. {{mvn tycho-versions:set-version
-DnewVersion=1.0.3-SNAPSHOT}}
Once the release has passed, the following must be done:
* upload p2update.zip* to https://dist.apache.org/repos/dist/release/sling/
* upload unzipped update site to
https://dist.apache.org/repos/dist/release/sling/eclipse/1.0.2
* update
https://dist.apache.org/repos/dist/release/sling/eclipse/composite{Content,Artifacts}.xml
to point to the latest $VERSION ( remove old one )
* (TODO how?) archive the old artifact versions but leave pointers to
archive.apache.org
Document and further automate the IDE tooling release process
-
Key: SLING-3685
URL: https://issues.apache.org/jira/browse/SLING-3685
Project: Sling
Issue Type: Task
Components: IDE
Reporter: Robert Munteanu
Fix For: Sling Eclipse IDE 1.0.2
The current release process is very much manual, due to some of tycho's
peculiarities ( see also SLING-3620 ). This task tracks the documentation of
this release process and possible automation enhancements.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: adaptTo and results ....
I quickly tried to implement a POC, but due to type erasure the interface is not as simple as just putting RequireAdapterFoo.class I found the following reference: http://gafter.blogspot.de/2006/12/super-type-tokens.html and tried to implement something like that but could not get it to work in a simple fashion. @Bertrand: Do you have an example in mind on how to get the wrapped type of RequireAdapter? Thanks, Konrad On 01 Jul 2014, at 12:09, Konrad Windszus konra...@gmx.de wrote: On 01 Jul 2014, at 12:05, Stefan Seifert sseif...@pro-vision.de wrote: Foo f = someObject.adaptTo(RequireAdapterFoo.class)); this would still require an unwrapping of the object out of the RequireAdapterFoo instance. In my regard there is an instanceof RequireAdapter check within the AdapterManagerImpl which would in that case just pass/throw exceptions. So no need to unwrap anything for the client. The only questions is how to get the generic type at runtime (within the AdapterManagerImpl), but there are solutions to that as well: http://stackoverflow.com/questions/3403909/get-generic-type-of-class-at-runtime Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class)); this looks interesting, and does not need unwrapping if the return value is the input class. i assume it could be implemented using a ThreadLocal or similar as well? stefan -Original Message- From: Konrad Windszus [mailto:konra...@gmx.de] Sent: Tuesday, July 01, 2014 11:58 AM To: dev@sling.apache.org Cc: Bertrand Delacretaz Subject: Re: adaptTo and results I like that approach. It is backwards-compatible and allows the developers to decide whether they want to check for null or to rely on exceptions. The AdapterManagerImpl indeed would need to deal with such a parametrisation and in addition the javadocs would need to be adjusted to make it clear that AdapterFactories may throw RuntimeExceptions. Those exceptions should be caught by the AdapterManagerImpl when the RequireAdapter was not requested and in the other case just passed along. On 01 Jul 2014, at 09:44, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jul 1, 2014 at 9:41 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: ...how about this: Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class)); Actually, rereading SLING-3714, this can be made simpler with generics Foo f = someObject.adaptTo(RequireAdapterFoo.class)); where RequireAdapter causes AdapterManagerImpl to wrap the adapters to throw an exception if adaption returns null. -Bertrand
Re: adaptTo and results ....
Hi Am 01.07.2014 um 09:44 schrieb Bertrand Delacretaz bdelacre...@apache.org: On Tue, Jul 1, 2014 at 9:41 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: ...how about this: Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class)); Actually, rereading SLING-3714, this can be made simpler with generics Foo f = someObject.adaptTo(RequireAdapterFoo.class)); where RequireAdapter causes AdapterManagerImpl to wrap the adapters to throw an exception if adaption returns null. Unfortunately, I don't think this works, because the adaptTo signature is: public AdapterType AdapterType adaptTo(ClassAdapterType type); Hence the return type is the same as provided as the argument, that is if you pass RequireAdapterFoo, you get a RequireAdapterFoo object and not a Foo object. Regards Felix -Bertrand
[jira] [Created] (SLING-3721) Crankstart does not stop the framework gracefully on exit
Artyom Stetsenko created SLING-3721: --- Summary: Crankstart does not stop the framework gracefully on exit Key: SLING-3721 URL: https://issues.apache.org/jira/browse/SLING-3721 Project: Sling Issue Type: Improvement Components: Crankstart Reporter: Artyom Stetsenko When Crankstart is terminated manually (e.g. via Ctrl-C), it does not shut down the OSGi framework gracefully, which prevents the OSGi application from running its cleanup routines, if any. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3721) Crankstart does not stop the framework gracefully on exit
[ https://issues.apache.org/jira/browse/SLING-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artyom Stetsenko updated SLING-3721: Attachment: frameworkShutdown.patch Attached patch which adds a shutdown hook to the JVM, in which the framework is stopped. Crankstart does not stop the framework gracefully on exit - Key: SLING-3721 URL: https://issues.apache.org/jira/browse/SLING-3721 Project: Sling Issue Type: Improvement Components: Crankstart Reporter: Artyom Stetsenko Labels: crankstart, framework, shutdown Attachments: frameworkShutdown.patch When Crankstart is terminated manually (e.g. via Ctrl-C), it does not shut down the OSGi framework gracefully, which prevents the OSGi application from running its cleanup routines, if any. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (SLING-3722) Add metatype information for source and target vm version
Carsten Ziegeler created SLING-3722: --- Summary: Add metatype information for source and target vm version Key: SLING-3722 URL: https://issues.apache.org/jira/browse/SLING-3722 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting JSP 2.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Scripting JSP 2.1.2 All settings are changeable through metatype except source and target vm. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SLING-3722) Add metatype information for source and target vm version
[ https://issues.apache.org/jira/browse/SLING-3722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3722. - Resolution: Fixed Added in rev 1607118 The default value is empty (for compatibility) Add metatype information for source and target vm version - Key: SLING-3722 URL: https://issues.apache.org/jira/browse/SLING-3722 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting JSP 2.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Scripting JSP 2.1.2 All settings are changeable through metatype except source and target vm. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (SLING-3723) MapEntries-resolveMapsMap holds incorrect information in case of vanityPath removal
Antonio Sanso created SLING-3723: Summary: MapEntries-resolveMapsMap holds incorrect information in case of vanityPath removal Key: SLING-3723 URL: https://issues.apache.org/jira/browse/SLING-3723 Project: Sling Issue Type: Bug Components: ResourceResolver Reporter: Antonio Sanso Assignee: Antonio Sanso MapEntries-resolveMapsMap holds incorrect information in case of vanityPath removal I will also add a test case that shows the issue -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SLING-3723) MapEntries-resolveMapsMap holds incorrect information in case of vanityPath removal
[ https://issues.apache.org/jira/browse/SLING-3723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Sanso resolved SLING-3723. -- Resolution: Fixed Fix Version/s: Resource Resolver 1.1.2 added test case and fix in r1607119 MapEntries-resolveMapsMap holds incorrect information in case of vanityPath removal Key: SLING-3723 URL: https://issues.apache.org/jira/browse/SLING-3723 Project: Sling Issue Type: Bug Components: ResourceResolver Reporter: Antonio Sanso Assignee: Antonio Sanso Fix For: Resource Resolver 1.1.2 MapEntries-resolveMapsMap holds incorrect information in case of vanityPath removal I will also add a test case that shows the issue -- This message was sent by Atlassian JIRA (v6.2#6252)
Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #617
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.launchpad.testing/617/
Jenkins build is still unstable: sling-trunk-1.7 #617
See https://builds.apache.org/job/sling-trunk-1.7/changes
[jira] [Created] (SLING-3724) Provide option to always use current vm version for source and target
Carsten Ziegeler created SLING-3724: --- Summary: Provide option to always use current vm version for source and target Key: SLING-3724 URL: https://issues.apache.org/jira/browse/SLING-3724 Project: Sling Issue Type: Improvement Components: Scripting Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Scripting JSP 2.1.2 Right now, target and source vm version can only be set to a specific version. However it would be nice to simply just use the vm version the instance is running it and not worry about the details -- This message was sent by Atlassian JIRA (v6.2#6252)
Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Models Integration Tests #2244
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.models.integration-tests/2244/
Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #2244
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/2244/
Jenkins build is still unstable: sling-trunk-1.6 #2244
See https://builds.apache.org/job/sling-trunk-1.6/changes
[jira] [Resolved] (SLING-3724) Provide option to always use current vm version for source and target
[ https://issues.apache.org/jira/browse/SLING-3724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3724. - Resolution: Fixed If the value auto is specified as the version, the current vm version is used. As the configuration is compared with the previous configuration, restarting the instance with a new vm results in automatic removal of the compiled jsps Provide option to always use current vm version for source and target - Key: SLING-3724 URL: https://issues.apache.org/jira/browse/SLING-3724 Project: Sling Issue Type: Improvement Components: Scripting Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Scripting JSP 2.1.2 Right now, target and source vm version can only be set to a specific version. However it would be nice to simply just use the vm version the instance is running it and not worry about the details -- This message was sent by Atlassian JIRA (v6.2#6252)
Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Sample Integration Tests #2244
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.testing.samples.integrationtests/2244/
[jira] [Updated] (SLING-3724) Provide option to always use current vm version for source and target
[ https://issues.apache.org/jira/browse/SLING-3724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3724: Fix Version/s: Scripting Java 2.0.8 Provide option to always use current vm version for source and target - Key: SLING-3724 URL: https://issues.apache.org/jira/browse/SLING-3724 Project: Sling Issue Type: Improvement Components: Scripting Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Scripting JSP 2.1.2, Scripting Java 2.0.8 Right now, target and source vm version can only be set to a specific version. However it would be nice to simply just use the vm version the instance is running it and not worry about the details -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [VOTE] Release Apache Sling Installer Core 3.5.2 and Installer Configuration Factoy 1.0.14
It seems we're still missing a vote on this pretty old vote thread... Carsten 2014-06-04 9:30 GMT+02:00 Carsten Ziegeler cziege...@apache.org: +1 Carsten 2014-06-04 8:13 GMT+02:00 Ian Boston i...@tfd.co.uk: +1 Signatures checked. Ian On 4 June 2014 07:06, Carsten Ziegeler cziege...@apache.org wrote: Hi, We solved 3 issues in Installer Core 3.5.2 https://issues.apache.org/jira/browse/SLING/fixforversion/12325943 We solved 1 issue in Installer Configuration Factory 1.0.14 https://issues.apache.org/jira/browse/SLING/fixforversion/12326553 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1068 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1068 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Regards Carsten -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling Installer Core 3.5.2 and Installer Configuration Factoy 1.0.14
+1 On Tue, Jul 1, 2014 at 12:05 PM, Carsten Ziegeler cziege...@apache.org wrote: It seems we're still missing a vote on this pretty old vote thread... Carsten 2014-06-04 9:30 GMT+02:00 Carsten Ziegeler cziege...@apache.org: +1 Carsten 2014-06-04 8:13 GMT+02:00 Ian Boston i...@tfd.co.uk: +1 Signatures checked. Ian On 4 June 2014 07:06, Carsten Ziegeler cziege...@apache.org wrote: Hi, We solved 3 issues in Installer Core 3.5.2 https://issues.apache.org/jira/browse/SLING/fixforversion/12325943 We solved 1 issue in Installer Configuration Factory 1.0.14 https://issues.apache.org/jira/browse/SLING/fixforversion/12326553 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1068 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1068 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Regards Carsten -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (SLING-3724) Provide option to always use current vm version for source and target
[ https://issues.apache.org/jira/browse/SLING-3724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14049008#comment-14049008 ] Carsten Ziegeler commented on SLING-3724: - Also implemented for scripting java Provide option to always use current vm version for source and target - Key: SLING-3724 URL: https://issues.apache.org/jira/browse/SLING-3724 Project: Sling Issue Type: Improvement Components: Scripting Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Scripting JSP 2.1.2, Scripting Java 2.0.8 Right now, target and source vm version can only be set to a specific version. However it would be nice to simply just use the vm version the instance is running it and not worry about the details -- This message was sent by Atlassian JIRA (v6.2#6252)
