[jira] Closed: (SLING-529) Global logging reconfiguration results in configuration error
[ https://issues.apache.org/jira/browse/SLING-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-529. --- Resolution: Fixed Fixed in Rev. 667371. Now global configuration sets the value for the applicable logger names to the constant LogConfigManager.ROOT. This special configuration value for loggers is recognized during logger name processing to indicate a set only containg the root logger name. Global logging reconfiguration results in configuration error - Key: SLING-529 URL: https://issues.apache.org/jira/browse/SLING-529 Project: Sling Issue Type: Bug Components: Commons Log Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.1 After the implementation of SLING-525, the global logging configuration does not work any more. Instead a ConfigurationException is thrown and logged: 13.06.2008 07:44:22.647 *ERROR* [Configuration Updater] org.apache.felix.configadmin Updating configuration property org.apache.sling.commons.log.names caused a problem: Missing categories in configuration org.apache.sling.commons.log.LogManager (org.osgi.service.cm.ConfigurationException: org.apache.sling.commons.log.names : Missing categories in configuration org.apache.sling.commons.log.LogManager) org.osgi.service.cm.ConfigurationException: org.apache.sling.commons.log.names : Missing categories in configuration org.apache.sling.commons.log.LogManager at org.apache.sling.commons.log.slf4j.LogConfigManager.updateLoggerConfiguration(LogConfigManager.java:388) at org.apache.sling.commons.log.LogManager$GlobalConfigurator.updated(LogManager.java:180) at org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1125) at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:90) The problem seems to be that there is no acceptable entry for the logger names in the global configuration, whereas this setting should be indicating the ROOT logger meaning apply to all loggers as a default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-530) JspScriptEngineFactory throws NullPointerException on deactivate
JspScriptEngineFactory throws NullPointerException on deactivate Key: SLING-530 URL: https://issues.apache.org/jira/browse/SLING-530 Project: Sling Issue Type: Bug Components: Scripting JSP Affects Versions: 2.0.1 Environment: Darwin 9.3.0 Darwin Kernel Version 9.3.0: Fri May 23 00:49:16 PDT 2008; root:xnu-1228.5.18~1/RELEASE_I386 i386 Reporter: Dominique Jäggi Priority: Minor Upon shutting down Sling, the following exception is thrown: 13.06.2008 09:32:17.491 *ERROR* [main] org.apache.sling.scripting.jsp.JspScriptEngineFactory deactivate: Caught NullPointerException ! Just logging java.lang.NullPointerException at org.eclipse.equinox.http.servlet.internal.ServletContextAdaptor.removeAttribute(ServletContextAdaptor.java:75) at org.apache.sling.engine.impl.helper.SlingServletContext.removeAttribute(SlingServletContext.java:204) at org.apache.sling.scripting.jsp.JspScriptEngineFactory.deactivate(JspScriptEngineFactory.java:244) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.felix.scr.impl.ImmediateComponentManager.disposeImplementationObject(ImmediateComponentManager.java:269) at org.apache.felix.scr.impl.ImmediateComponentManager.deleteComponent(ImmediateComponentManager.java:150) at org.apache.felix.scr.impl.DelayedComponentManager.deleteComponent(DelayedComponentManager.java:61) at org.apache.felix.scr.impl.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:549) at org.apache.felix.scr.impl.AbstractComponentManager.deactivate(AbstractComponentManager.java:233) at org.apache.felix.scr.impl.DependencyManager.serviceRemoved(DependencyManager.java:242) at org.apache.felix.scr.impl.DependencyManager.serviceChanged(DependencyManager.java:124) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:765) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:623) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:554) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3612) at org.apache.felix.framework.Felix.access$000(Felix.java:36) at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:626) at org.apache.felix.framework.ServiceRegistry.fireServiceChanged(ServiceRegistry.java:559) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:96) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:112) at org.apache.sling.engine.impl.helper.SlingServletContext.dispose(SlingServletContext.java:101) at org.apache.sling.engine.impl.SlingMainServlet.deactivate(SlingMainServlet.java:629) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.felix.scr.impl.ImmediateComponentManager.disposeImplementationObject(ImmediateComponentManager.java:269) at org.apache.felix.scr.impl.ImmediateComponentManager.deleteComponent(ImmediateComponentManager.java:150) at org.apache.felix.scr.impl.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:549) at org.apache.felix.scr.impl.AbstractComponentManager.deactivate(AbstractComponentManager.java:233) at org.apache.felix.scr.impl.DependencyManager.serviceRemoved(DependencyManager.java:242) at org.apache.felix.scr.impl.DependencyManager.serviceChanged(DependencyManager.java:124) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:765) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:623) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:554) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3612) at org.apache.felix.framework.Felix.access$000(Felix.java:36) at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:626) at org.apache.felix.framework.ServiceRegistry.fireServiceChanged(ServiceRegistry.java:559) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:96) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:112) at
Re: License and notice files
Hi, On Thu, Jun 12, 2008 at 1:45 PM, Felix Meschberger [EMAIL PROTECTED] wrote: In Rev. 667038 I just commited a proposal to commons/log bundle [1] to what we have been discussing: Looks good. - The disclaimer is not part of the README.txt (yet), maybe this should be added as a section there replacing the existing DISCLAIMER file ? +1 - The src/main/resources/META-INF(LICENSE file has no reference to the LICENSE.slf4j file The LICENSE.* files seem pretty obvious, so I'm not sure if the reference is really needed. I'd say we either leave it as is (no references), or include all the license information in the single LICENSE file. - The src/main/resources/META-INF/NOTICE file contains an attribution of the SLF4J libraries. As I can see no requirement for such an attribution, I am not sure, whether this is required ? The license calls for the copyright notice [...] shall be included in all copies or substantial portions of the Software, and AFAIUI (and I may be wrong) the NOTICE file is the place for such copyright notices even when they are also included in the LICENSE file. PS. I looked at doing the same for the launchpad app and webapp components. Do we really need the separate -bin packaging, or could we just use the normal jar and war artifacts as the binary packages to go with the release? BR, Jukka Zitting
Re: License and notice files
On Jun 13, 2008, at 12:54 AM, Jukka Zitting wrote: - The src/main/resources/META-INF(LICENSE file has no reference to the LICENSE.slf4j file The LICENSE.* files seem pretty obvious, so I'm not sure if the reference is really needed. I'd say we either leave it as is (no references), or include all the license information in the single LICENSE file. The LICENSE file needs to answer the question: what is the license for this bundle/compilation as a redistributable unit? You should assume that it will be taken out of context (printed or included in third-party docs), so the fact that there are other files nearby is not sufficient. I would list them by reference. httpd includes them in one big file. - The src/main/resources/META-INF/NOTICE file contains an attribution of the SLF4J libraries. As I can see no requirement for such an attribution, I am not sure, whether this is required ? The license calls for the copyright notice [...] shall be included in all copies or substantial portions of the Software, and AFAIUI (and I may be wrong) the NOTICE file is the place for such copyright notices even when they are also included in the LICENSE file. The NOTICE file is only supposed to contain attributions that are relevant to the package. The board made a mess of that when they added the collation copyright notice. However, since the license states that irrelevant notices can be removed from the NOTICE file, we only need to include the words that remain relevant to the distributed work. For example, the Jetty and Derby stuff can be trimmed down to just the attributions -- the rest is actually present in the Derby and Jetty jar files and need not be repeated outside. I meant to do that today, but ran out of time (it's past 2am here). Roy
[jira] Created: (SLING-531) launcher/app: Restarting the OPS4J Pax Server fails
launcher/app: Restarting the OPS4J Pax Server fails --- Key: SLING-531 URL: https://issues.apache.org/jira/browse/SLING-531 Project: Sling Issue Type: Improvement Components: Launchpad Launcher Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.1 When the OPS4J Pax Server which is included in the Standalone launcher to implement the OSGi HttpService is restarted, no new servlet registrations work any more. The reason for this problem is linkage errors between the OSGi HttpService and the Servlet API classes: The tricky thing is, that in the standalone launcher the HttpService interfaces are exported by the system bundle, while the Servlet API classes are exported by the Pax Server bundle. Now, the HttpService interfaces refer to Servlet API interfaces and when the Pax Server bundle is started the first thime, these HttpService interfaces seem to be linked with the Servlet API classes of the Pax Server bundle. If the Pax Server bundle is restarted, the HttpService interfaces are still linked with the old classes, while the Pax Server is now using the new Servlet API classes. Now, when the Pax Server uses the HttpService a linkage error occurrs because the class instances of the Servlet API classes are not the same for the HttpService interface and the Pax Server The fix to this delicate issue, is to export the Servlet API classes from the standalone launcher together with the HttpService API. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-531) launcher/app: Restarting the OPS4J Pax Server fails
[ https://issues.apache.org/jira/browse/SLING-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-531. --- Resolution: Fixed Fixed in Rev. 667440. The launcher/app now includes the Servlet API and exports it from the system bundle for use. This places the Servlet API and HttpService interfaces into the same class loader preventing this Linkage problems. This change has no influence on the launcher/webapp, because the web app always exported the Servlet API from the system bundle and hence did not suffer from this issue. launcher/app: Restarting the OPS4J Pax Server fails --- Key: SLING-531 URL: https://issues.apache.org/jira/browse/SLING-531 Project: Sling Issue Type: Improvement Components: Launchpad Launcher Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.1 When the OPS4J Pax Server which is included in the Standalone launcher to implement the OSGi HttpService is restarted, no new servlet registrations work any more. The reason for this problem is linkage errors between the OSGi HttpService and the Servlet API classes: The tricky thing is, that in the standalone launcher the HttpService interfaces are exported by the system bundle, while the Servlet API classes are exported by the Pax Server bundle. Now, the HttpService interfaces refer to Servlet API interfaces and when the Pax Server bundle is started the first thime, these HttpService interfaces seem to be linked with the Servlet API classes of the Pax Server bundle. If the Pax Server bundle is restarted, the HttpService interfaces are still linked with the old classes, while the Pax Server is now using the new Servlet API classes. Now, when the Pax Server uses the HttpService a linkage error occurrs because the class instances of the Servlet API classes are not the same for the HttpService interface and the Pax Server The fix to this delicate issue, is to export the Servlet API classes from the standalone launcher together with the HttpService API. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Exception in maven-sling-plugin 2.0.1-incbuator-SNAPSHOT, missing commons-httpclient class
Hi, It seems that there has been a change in the default scope of the http client and in addition the transitive dependency on commons loggin has been removed. Fixing this now with SLING-532. Regards Felix Am Donnerstag, den 12.06.2008, 17:51 +0200 schrieb Alexander Klimetschek: Hi Sling folks, when I run the newest maven sling plugin (2.0.1-incbuator-SNAPSHOT, built from current trunk), I get an error of a missing commons-httpclient class, see below. I run it with the full groupId/artifactId because the project does not contain the maven-sling-plugin configuration. After having a look at the maven-sling-plugin pom and recent changes, I have no clue what's wrong here... I didn't see anything what affects the dependency to commons-httpclient. mvn -e -Dsling.url=http://localhost:8080/wcms/system/console org.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install [...] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install': Unable to find the mojo 'org.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install' in the plugin 'org.apache.sling:maven-sling-plugin' org/apache/commons/httpclient/methods/multipart/PartSource [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install': Unable to find the mojo 'org.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install' in the plugin 'org.apache.sling:maven-sling-plugin' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:543) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.PluginManagerException: Unable to find the mojo 'org.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install' in the plugin 'org.apache.sling:maven-sling-plugin' at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:571) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:421) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.codehaus.plexus.component.repository.exception.ComponentLookupException: Unable to lookup component 'org.apache.maven.plugin.Mojoorg.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install', it could not be created at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:335) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:562) ... 18 more Caused by: org.codehaus.plexus.component.factory.ComponentInstantiationException: Could not instanciate component: role: 'null', implementation: 'org.apache.sling.maven.bundlesupport.BundleInstallMojo' at org.codehaus.plexus.component.factory.java.JavaComponentFactory.makeException(JavaComponentFactory.java:77) at org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(JavaComponentFactory.java:62) at
[jira] Closed: (SLING-532) Latest maven-sling-plugin fails to run due to missing dependencies
[ https://issues.apache.org/jira/browse/SLING-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-532. --- Resolution: Fixed Fixed scope and missing dependency in Rev. 667511. Works now. Latest maven-sling-plugin fails to run due to missing dependencies -- Key: SLING-532 URL: https://issues.apache.org/jira/browse/SLING-532 Project: Sling Issue Type: Bug Components: Maven Plugins Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.1 Reported by Alex Klimetschek: when I run the newest maven sling plugin (2.0.1-incbuator-SNAPSHOT, built from current trunk), I get an error of a missing commons-httpclient class, see below. I run it with the full groupId/artifactId because the project does not contain the maven-sling-plugin configuration. After having a look at the maven-sling-plugin pom and recent changes, I have no clue what's wrong here... I didn't see anything what affects the dependency to commons-httpclient. mvn -e -Dsling.url=http://localhost:8080/wcms/system/console org.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install [...] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install': Unable to find the mojo 'org.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install' in the plugin 'org.apache.sling:maven-sling-plugin' org/apache/commons/httpclient/methods/multipart/PartSource [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install': Unable to find the mojo 'org.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install' in the plugin 'org.apache.sling:maven-sling-plugin' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:543) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.PluginManagerException: Unable to find the mojo 'org.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install' in the plugin 'org.apache.sling:maven-sling-plugin' at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:571) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:421) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.codehaus.plexus.component.repository.exception.ComponentLookupException: Unable to lookup component 'org.apache.maven.plugin.Mojoorg.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install', it could not be created at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:335) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:562) ... 18 more
[jira] Created: (SLING-532) Latest maven-sling-plugin fails to run due to missing dependencies
Latest maven-sling-plugin fails to run due to missing dependencies -- Key: SLING-532 URL: https://issues.apache.org/jira/browse/SLING-532 Project: Sling Issue Type: Bug Components: Maven Plugins Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.1 Reported by Alex Klimetschek: when I run the newest maven sling plugin (2.0.1-incbuator-SNAPSHOT, built from current trunk), I get an error of a missing commons-httpclient class, see below. I run it with the full groupId/artifactId because the project does not contain the maven-sling-plugin configuration. After having a look at the maven-sling-plugin pom and recent changes, I have no clue what's wrong here... I didn't see anything what affects the dependency to commons-httpclient. mvn -e -Dsling.url=http://localhost:8080/wcms/system/console org.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install [...] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install': Unable to find the mojo 'org.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install' in the plugin 'org.apache.sling:maven-sling-plugin' org/apache/commons/httpclient/methods/multipart/PartSource [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install': Unable to find the mojo 'org.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install' in the plugin 'org.apache.sling:maven-sling-plugin' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:543) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.PluginManagerException: Unable to find the mojo 'org.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install' in the plugin 'org.apache.sling:maven-sling-plugin' at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:571) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:421) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.codehaus.plexus.component.repository.exception.ComponentLookupException: Unable to lookup component 'org.apache.maven.plugin.Mojoorg.apache.sling:maven-sling-plugin:2.0.1-incubator-SNAPSHOT:install', it could not be created at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:335) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:562) ... 18 more Caused by: org.codehaus.plexus.component.factory.ComponentInstantiationException: Could not instanciate component: role: 'null', implementation: 'org.apache.sling.maven.bundlesupport.BundleInstallMojo' at org.codehaus.plexus.component.factory.java.JavaComponentFactory.makeException(JavaComponentFactory.java:77) at
Requiring Maven 2.0.9
Hi, I think we should require the latest maven version 2.0.9, as this one seems to be more stable than 2.0.7. If noone objects, I'll update the parent pom before the release. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Requiring Maven 2.0.9
Hi, Am Freitag, den 13.06.2008, 14:56 +0200 schrieb Carsten Ziegeler: Hi, I think we should require the latest maven version 2.0.9, as this one seems to be more stable than 2.0.7. Does it help fix the OutOfMemoryError issue we have ? If not, I would not require 2.0.9 for now as our build just as well works with 2.0.7. Regards Felix
Re: Logging config broken?
Thanks, it works now. Only changing Sling Logging Configuration (org.apache.sling.commons.log.LogManager) worked, changing the log level in Sling Logging Logger Configuration (org.apache.sling.commons.log.LogManager.factory.config) did have no effect. Regards, Alex 2008/6/13 Felix Meschberger [EMAIL PROTECTED]: Am Freitag, den 13.06.2008, 07:48 +0200 schrieb Felix Meschberger: So, this is definitely a bug. SLING-529. Fixed in Rev. 667371 Regards Felix -- Alexander Klimetschek [EMAIL PROTECTED]
Re: Logging config broken?
Hi, Am Freitag, den 13.06.2008, 15:13 +0200 schrieb Alexander Klimetschek: Thanks, it works now. Only changing Sling Logging Configuration (org.apache.sling.commons.log.LogManager) worked, This is the global configuration changing the log level in Sling Logging Logger Configuration (org.apache.sling.commons.log.LogManager.factory.config) did have no This is a factory configuration support which I built in yesterday. This is still to be documented Regards Felix effect. Regards, Alex 2008/6/13 Felix Meschberger [EMAIL PROTECTED]: Am Freitag, den 13.06.2008, 07:48 +0200 schrieb Felix Meschberger: So, this is definitely a bug. SLING-529. Fixed in Rev. 667371 Regards Felix
Re: Requiring Maven 2.0.9
Felix Meschberger wrote: Does it help fix the OutOfMemoryError issue we have ? No, it doesn't. If not, I would not require 2.0.9 for now as our build just as well works with 2.0.7. Hmm, not sure - yes, it works with 2.0.7 - but it seems that people new to maven haven less problems if they use 2.0.9 than using 2.0.7 - both work, but it should be less pain for our users (and us), if everyone uses the latest (and greatest?) version of maven. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Updated: (SLING-522) Default POST Servlet writes single-value property even though node type mandates multi-value.
[ https://issues.apache.org/jira/browse/SLING-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-522: --- Fix Version/s: (was: 2.0.1) 2.1.0 Moving this to a later release for now. Default POST Servlet writes single-value property even though node type mandates multi-value. - Key: SLING-522 URL: https://issues.apache.org/jira/browse/SLING-522 Project: Sling Issue Type: Bug Components: Servlets Post Affects Versions: 2.0.1 Reporter: Julian Sedding Priority: Minor Fix For: 2.1.0 If a JCR node-type defines a multi-value property (e.g. String[]) and only a single value for this property is posted, the property will become single-value (e.g String). The POST Servlet should check, if the property is multi-value and respect that. Otherwise, any code reading the property value would need to check, whether it is multi-value or not and handle both cases. It might even be beneficial to force a multi-value property, if there is no node-type that defines it. This would provide for better control of unstructured data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-522) Default POST Servlet writes single-value property even though node type mandates multi-value.
[ https://issues.apache.org/jira/browse/SLING-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604897#action_12604897 ] Carsten Ziegeler commented on SLING-522: The problem is the detection of the property definition - JCR does not provide a method for this. So, in order to propertly implement this, we have to scan the primary node type of a node, followed by all mixins etc. I have the feeling that this is a costly operation compared to the problem it might solve. I haven't looked at JCR 2.0 yet, if it provides something in this area. Therefore I would be very happy if you could live with the explicit hint for now :) Default POST Servlet writes single-value property even though node type mandates multi-value. - Key: SLING-522 URL: https://issues.apache.org/jira/browse/SLING-522 Project: Sling Issue Type: Bug Components: Servlets Post Affects Versions: 2.0.1 Reporter: Julian Sedding Priority: Minor Fix For: 2.1.0 If a JCR node-type defines a multi-value property (e.g. String[]) and only a single value for this property is posted, the property will become single-value (e.g String). The POST Servlet should check, if the property is multi-value and respect that. Otherwise, any code reading the property value would need to check, whether it is multi-value or not and handle both cases. It might even be beneficial to force a multi-value property, if there is no node-type that defines it. This would provide for better control of unstructured data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: License and notice files
Hi, I've changed the handling of the notice/licence files as discussed recently. Each module has now a readme as well. So I think it's time to review this stuff and fix what needs to be fixed for a release. I hope we get through all of this by monday and can finally release Sling :) Most of the modules should be fine as they just contain Apache stuff. The most problematik ones are the binary versions of the launchpad. I haven't added links to additional licences yet as I'm not sure how to do this best. So if someone wants to do this, please go ahead. Thanks Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Closed: (SLING-521) Revert to hand written notice files
[ https://issues.apache.org/jira/browse/SLING-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-521. -- Resolution: Fixed We have reverted, so we can close this issue. Revert to hand written notice files --- Key: SLING-521 URL: https://issues.apache.org/jira/browse/SLING-521 Project: Sling Issue Type: Task Affects Versions: 2.0.1 Reporter: Carsten Ziegeler Fix For: 2.0.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-522) Default POST Servlet writes single-value property even though node type mandates multi-value.
[ https://issues.apache.org/jira/browse/SLING-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604905#action_12604905 ] Julian Sedding commented on SLING-522: -- Agreed,. The explicit hint will allow for the required flexibility and is definitely cheaper than getting the information from the nodetype. Default POST Servlet writes single-value property even though node type mandates multi-value. - Key: SLING-522 URL: https://issues.apache.org/jira/browse/SLING-522 Project: Sling Issue Type: Bug Components: Servlets Post Affects Versions: 2.0.1 Reporter: Julian Sedding Priority: Minor Fix For: 2.1.0 If a JCR node-type defines a multi-value property (e.g. String[]) and only a single value for this property is posted, the property will become single-value (e.g String). The POST Servlet should check, if the property is multi-value and respect that. Otherwise, any code reading the property value would need to check, whether it is multi-value or not and handle both cases. It might even be beneficial to force a multi-value property, if there is no node-type that defines it. This would provide for better control of unstructured data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-533) Support mulit-value type hints (eg. @TypeHint=String[])
Support mulit-value type hints (eg. @TypeHint=String[]) --- Key: SLING-533 URL: https://issues.apache.org/jira/browse/SLING-533 Project: Sling Issue Type: New Feature Components: Servlets Post Reporter: Alexander Klimetschek As discussed in SLING-522, when posting a single value to a property that should be multi-valued, an extension to the @TypeHint is needed that allows the explicit definition of a multi-value type. For example, for Strings this would be @TypeHint=String[]. Based on a quick look at the code, it should happen in o.a.s.servlets.post.impl.helper.SlingPropertyValueHandler.setPropertyAsIs(). First of all the parsing of the getTypeHint() must be changed to look for an ending [] first, and then this isMultiValued information must be used to call the multi-value version of setProperty() in all cases (values.length = 0). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-522) Default POST Servlet writes single-value property even though node type mandates multi-value.
[ https://issues.apache.org/jira/browse/SLING-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604911#action_12604911 ] Alexander Klimetschek commented on SLING-522: - I have the same problem (same use case as Julian ;-)). What do you think about extending the type hint? So you can send an additional (hidden) parameter, defining that the property should be a multi value one. Example: property is paths, so you post paths=hallo and [EMAIL PROTECTED] Just to be sure: a multi-value type hint, and thus String[], is not yet implemented. o.a.s.servlets.post.impl.helper.SlingPropertyValueHandler does not support multi-value type hints (ending with []). I created SLING-533 for this. Default POST Servlet writes single-value property even though node type mandates multi-value. - Key: SLING-522 URL: https://issues.apache.org/jira/browse/SLING-522 Project: Sling Issue Type: Bug Components: Servlets Post Affects Versions: 2.0.1 Reporter: Julian Sedding Priority: Minor Fix For: 2.1.0 If a JCR node-type defines a multi-value property (e.g. String[]) and only a single value for this property is posted, the property will become single-value (e.g String). The POST Servlet should check, if the property is multi-value and respect that. Otherwise, any code reading the property value would need to check, whether it is multi-value or not and handle both cases. It might even be beneficial to force a multi-value property, if there is no node-type that defines it. This would provide for better control of unstructured data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-533) Support multi-value type hints (eg. @TypeHint=String[])
[ https://issues.apache.org/jira/browse/SLING-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated SLING-533: Summary: Support multi-value type hints (eg. @TypeHint=String[]) (was: Support mulit-value type hints (eg. @TypeHint=String[])) Support multi-value type hints (eg. @TypeHint=String[]) --- Key: SLING-533 URL: https://issues.apache.org/jira/browse/SLING-533 Project: Sling Issue Type: New Feature Components: Servlets Post Reporter: Alexander Klimetschek As discussed in SLING-522, when posting a single value to a property that should be multi-valued, an extension to the @TypeHint is needed that allows the explicit definition of a multi-value type. For example, for Strings this would be @TypeHint=String[]. Based on a quick look at the code, it should happen in o.a.s.servlets.post.impl.helper.SlingPropertyValueHandler.setPropertyAsIs(). First of all the parsing of the getTypeHint() must be changed to look for an ending [] first, and then this isMultiValued information must be used to call the multi-value version of setProperty() in all cases (values.length = 0). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-522) Default POST Servlet writes single-value property even though node type mandates multi-value.
[ https://issues.apache.org/jira/browse/SLING-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605013#action_12605013 ] Eric Norman commented on SLING-522: --- I encountered this issue as well. My solution was basically the same as has been described in the comments. I scanned the primary type and mixin types to find a matching property definition and use the definition to provide defaults for the property type and for determining if the property is multi-valued. I'll attach a patch with my changes. Default POST Servlet writes single-value property even though node type mandates multi-value. - Key: SLING-522 URL: https://issues.apache.org/jira/browse/SLING-522 Project: Sling Issue Type: Bug Components: Servlets Post Affects Versions: 2.0.1 Reporter: Julian Sedding Priority: Minor Fix For: 2.1.0 If a JCR node-type defines a multi-value property (e.g. String[]) and only a single value for this property is posted, the property will become single-value (e.g String). The POST Servlet should check, if the property is multi-value and respect that. Otherwise, any code reading the property value would need to check, whether it is multi-value or not and handle both cases. It might even be beneficial to force a multi-value property, if there is no node-type that defines it. This would provide for better control of unstructured data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-534) Multi-Value Reference properties are not exposed to scripting the same way as single-value reference properties
Multi-Value Reference properties are not exposed to scripting the same way as single-value reference properties --- Key: SLING-534 URL: https://issues.apache.org/jira/browse/SLING-534 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: 2.0.0 Reporter: Eric Norman If a node contains a multi-valued reference property, it is exposed to scripts as an array of UUID strings. For single-value reference properties the value is resolved to the referenced node. I'd expect the multi-value reference properties to be resolved the same way and exposed to scripting as an array of nodes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
