[jira] Created: (SLING-1806) Include helper classes in bundle
Include helper classes in bundle Key: SLING-1806 URL: https://issues.apache.org/jira/browse/SLING-1806 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Extensions Event 2.4.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Priority: Minor Fix For: Extensions Event 2.4.2 ResourceUtil (from api) and JcrResourceUtil (from jcr resource) are currently uses as helper classes; this creates import statemenets for sling api and jcr resource We should rather include the two utility classes, reducing the dependencies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1807) Don't lock node for local jobs
Don't lock node for local jobs -- Key: SLING-1807 URL: https://issues.apache.org/jira/browse/SLING-1807 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Extensions Event 2.4.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Priority: Minor Locking is used to avoid processing on several nodes in a clusterd environment. However if the job is marked to run on a specific instance, locking is not needed at all Avoiding the lock reduces the load on the repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1808) Don't use thread pool for system threads
Don't use thread pool for system threads Key: SLING-1808 URL: https://issues.apache.org/jira/browse/SLING-1808 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Extensions Event 2.4.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 3.0.0 The system threads (background threads that run as long as the bundle runs) are currently taken from the thread pool; this is not necessary and in addition reduces the number of available threads from the pool; it makes calculating the required threads more difficult. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1809) Eclipse compiler used commons.compiler causes Illegal type in constant pool with enums
Eclipse compiler used commons.compiler causes Illegal type in constant pool
with enums
Key: SLING-1809
URL: https://issues.apache.org/jira/browse/SLING-1809
Project: Sling
Issue Type: Bug
Components: Commons
Affects Versions: Commons Compiler 2.0.0
Reporter: Bertrand Delacretaz
According to [0] the eclipse compiler can't handle enums in certain
environments.
The trunk org.apache.sling.commons.compiler bundle embeds (eclipse-jdt)
core-3.3.0-v_771.jar which exposes this issue.
According to [0] the issue should be fixed in v3.5.2, but the central Maven
repository does not provide a more recent version than the one we currently use.
To reproduce the problem, install the compiler and java scripting bundle and
create a scripted java servlet that uses enums (example below), at runtime this
causes:
java.lang.VerifyError:
(class: enumtest/EnumTest, method: valueOf signature:
(Ljava/lang/String;)Lenumtest/EnumTest;)
Illegal type in constant pool
[0] https://bugs.eclipse.org/bugs/show_bug.cgi?id=291985
Here's the example servlet, store in
/apps/JavaScriptingTest2/JavaScriptingTest2.java and use JavaScriptingTest2
resource type:
package apps.JavaScriptingTest2;
import javax.servlet.http.*;
import java.io.IOException;
public class JavaScriptingTest2 extends HttpServlet {
static enum EnumTest { FOO, BAR };
public void doGet(HttpServletRequest req, HttpServletResponse resp) throws
IOException {
resp.getWriter().write(FOO= + EnumTest.FOO);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1809) Eclipse compiler used in commons.compiler causes Illegal type in constant pool with enums
[
https://issues.apache.org/jira/browse/SLING-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated SLING-1809:
---
Summary: Eclipse compiler used in commons.compiler causes Illegal type in
constant pool with enums (was: Eclipse compiler used commons.compiler causes
Illegal type in constant pool with enums)
Eclipse compiler used in commons.compiler causes Illegal type in constant
pool with enums
---
Key: SLING-1809
URL: https://issues.apache.org/jira/browse/SLING-1809
Project: Sling
Issue Type: Bug
Components: Commons
Affects Versions: Commons Compiler 2.0.0
Reporter: Bertrand Delacretaz
According to [0] the eclipse compiler can't handle enums in certain
environments.
The trunk org.apache.sling.commons.compiler bundle embeds (eclipse-jdt)
core-3.3.0-v_771.jar which exposes this issue.
According to [0] the issue should be fixed in v3.5.2, but the central Maven
repository does not provide a more recent version than the one we currently
use.
To reproduce the problem, install the compiler and java scripting bundle and
create a scripted java servlet that uses enums (example below), at runtime
this causes:
java.lang.VerifyError:
(class: enumtest/EnumTest, method: valueOf signature:
(Ljava/lang/String;)Lenumtest/EnumTest;)
Illegal type in constant pool
[0] https://bugs.eclipse.org/bugs/show_bug.cgi?id=291985
Here's the example servlet, store in
/apps/JavaScriptingTest2/JavaScriptingTest2.java and use JavaScriptingTest2
resource type:
package apps.JavaScriptingTest2;
import javax.servlet.http.*;
import java.io.IOException;
public class JavaScriptingTest2 extends HttpServlet {
static enum EnumTest { FOO, BAR };
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws IOException {
resp.getWriter().write(FOO= + EnumTest.FOO);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1809) Eclipse compiler used in commons.compiler causes Illegal type in constant pool with enums
[
https://issues.apache.org/jira/browse/SLING-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12915326#action_12915326
]
Bertrand Delacretaz commented on SLING-1809:
The tycho project seems to provide a more recent version of the compiler:
dependency
groupIdorg.sonatype.tycho/groupId
artifactIdorg.eclipse.jdt.core/artifactId
version3.6.0.v_A58/version
/dependency
Eclipse compiler used in commons.compiler causes Illegal type in constant
pool with enums
---
Key: SLING-1809
URL: https://issues.apache.org/jira/browse/SLING-1809
Project: Sling
Issue Type: Bug
Components: Commons
Affects Versions: Commons Compiler 2.0.0
Reporter: Bertrand Delacretaz
According to [0] the eclipse compiler can't handle enums in certain
environments.
The trunk org.apache.sling.commons.compiler bundle embeds (eclipse-jdt)
core-3.3.0-v_771.jar which exposes this issue.
According to [0] the issue should be fixed in v3.5.2, but the central Maven
repository does not provide a more recent version than the one we currently
use.
To reproduce the problem, install the compiler and java scripting bundle and
create a scripted java servlet that uses enums (example below), at runtime
this causes:
java.lang.VerifyError:
(class: enumtest/EnumTest, method: valueOf signature:
(Ljava/lang/String;)Lenumtest/EnumTest;)
Illegal type in constant pool
[0] https://bugs.eclipse.org/bugs/show_bug.cgi?id=291985
Here's the example servlet, store in
/apps/JavaScriptingTest2/JavaScriptingTest2.java and use JavaScriptingTest2
resource type:
package apps.JavaScriptingTest2;
import javax.servlet.http.*;
import java.io.IOException;
public class JavaScriptingTest2 extends HttpServlet {
static enum EnumTest { FOO, BAR };
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws IOException {
resp.getWriter().write(FOO= + EnumTest.FOO);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1069) Servlets registered with for resourceTypes = sling/servlet/default responds to all extensions
[ https://issues.apache.org/jira/browse/SLING-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12915329#action_12915329 ] Felix Meschberger commented on SLING-1069: -- Commited to Rev. 1001774: - Bertrand's integration test enhancement (actually the HtmlDefaultServlet starts disabled and is enabled by the testcase for the duration of the test case to not influence (in a bad way) the other integration tests) - My own patch with some unit tests ensuring proper permutation of registration properties Servlets registered with for resourceTypes = sling/servlet/default responds to all extensions - Key: SLING-1069 URL: https://issues.apache.org/jira/browse/SLING-1069 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Resolver 2.0.4 Reporter: Vidar S. Ramdal Assignee: Felix Meschberger Fix For: Servlets Resolver 2.1.0 Attachments: RogueServlet.java, SLING-1069-fmeschbe.patch, SLING-1069-test.patch, SLING-1069.patch A servlet registered with @scr.property name=sling.servlet.extensions value=html @scr.property name=sling.servlet.resourceTypes value=sling/servlet/default in the Javadoc, responds to all requests, in effect ignoring the sling.servlet.extensions property. To reproduce: 1. Install servlet from attachment (coming up) 2. Let the browser fetch /somenode.json Expected result: The server returns the JSON rendering of /somenode Actual result: The server returns Rogue Servlet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1475) Create a web console plugin
[ https://issues.apache.org/jira/browse/SLING-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-1475: Fix Version/s: Extensions Event 3.0.0 (was: Extensions Event 2.4.2) Create a web console plugin --- Key: SLING-1475 URL: https://issues.apache.org/jira/browse/SLING-1475 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Extensions Event 2.3.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 3.0.0 It would be nice to have a web console plugin for the configuration status which displays all available information, like available job queues, number of jobs in processing etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Node added event type filter applies to parent node
Vidar Ramdal wrote I'm adding nodes to a parent node. The parent node has nt:primaryType=sling:OrderedFolder, while the child node I'm adding has nt:primaryType=slingevent:Event. Now, I have an event listener set up to receive NODE_ADDED events with nodetype slingevent:Event. The event listener is never invoked, but I can see that an event is being triggered, by having a breakpoing in o.a.j.c.observation.EventConsumer. Upon investigating, it seems the event is filtered out, because it reports the node type of the parent node (sling:OrderedFolder) instead of the node type of the child node being added (slingevent:Event). Is this the expected behaviour? On Mon, Sep 27, 2010 at 6:34 PM, Carsten Ziegeler cziege...@apache.org wrote: Funnily I stumbled across the same problem last week - actually the behaviour is correct. The spec states that the node type of the parent item is checked - in case of node added/removed events, this is the parent node. I think this limits its usage but its the spec... Thanks for the clarification! Looks like we have a bug in Sling, then. I'll investigate some more and post a bug there. (Cross-posting to d...@sling) -- Vidar S. Ramdal vi...@idium.no - http://www.idium.no Sommerrogata 13-15, N-0255 Oslo, Norway + 47 22 00 84 00 / +47 22 00 84 76 Quando omni flunkus moritatus!
Re: Node added event type filter applies to parent node
Vidar Ramdal wrote I'm adding nodes to a parent node. The parent node has nt:primaryType=sling:OrderedFolder, while the child node I'm adding has nt:primaryType=slingevent:Event. Now, I have an event listener set up to receive NODE_ADDED events with nodetype slingevent:Event. The event listener is never invoked, but I can see that an event is being triggered, by having a breakpoing in o.a.j.c.observation.EventConsumer. Upon investigating, it seems the event is filtered out, because it reports the node type of the parent node (sling:OrderedFolder) instead of the node type of the child node being added (slingevent:Event). Is this the expected behaviour? On Mon, Sep 27, 2010 at 6:34 PM, Carsten Ziegeler cziege...@apache.org wrote: Funnily I stumbled across the same problem last week - actually the behaviour is correct. The spec states that the node type of the parent item is checked - in case of node added/removed events, this is the parent node. I think this limits its usage but its the spec... On Mon, Sep 27, 2010 at 6:54 PM, Vidar Ramdal vi...@idium.no wrote: Thanks for the clarification! Looks like we have a bug in Sling, then. I'll investigate some more and post a bug there. Never mind this - it seems it was fixed with SLING-1494. -- Vidar S. Ramdal vi...@idium.no - http://www.idium.no Sommerrogata 13-15, N-0255 Oslo, Norway + 47 22 00 84 00 / +47 22 00 84 76 Quando omni flunkus moritatus!
Re: Node added event type filter applies to parent node
Vidar Ramdal wrote Vidar Ramdal wrote I'm adding nodes to a parent node. The parent node has nt:primaryType=sling:OrderedFolder, while the child node I'm adding has nt:primaryType=slingevent:Event. Now, I have an event listener set up to receive NODE_ADDED events with nodetype slingevent:Event. The event listener is never invoked, but I can see that an event is being triggered, by having a breakpoing in o.a.j.c.observation.EventConsumer. Upon investigating, it seems the event is filtered out, because it reports the node type of the parent node (sling:OrderedFolder) instead of the node type of the child node being added (slingevent:Event). Is this the expected behaviour? On Mon, Sep 27, 2010 at 6:34 PM, Carsten Ziegeler cziege...@apache.org wrote: Funnily I stumbled across the same problem last week - actually the behaviour is correct. The spec states that the node type of the parent item is checked - in case of node added/removed events, this is the parent node. I think this limits its usage but its the spec... On Mon, Sep 27, 2010 at 6:54 PM, Vidar Ramdal vi...@idium.no wrote: Thanks for the clarification! Looks like we have a bug in Sling, then. I'll investigate some more and post a bug there. Never mind this - it seems it was fixed with SLING-1494. I think I finally fixed this in the Sling eventing last week, so current trunk should be fine now. Carsten -- Carsten Ziegeler cziege...@apache.org
