[jira] Closed: (SLING-612) When several jobs of the same time are run in parallel, these are tried without a wait time in a cycle
[ https://issues.apache.org/jira/browse/SLING-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-612. -- Resolution: Fixed > When several jobs of the same time are run in parallel, these are tried > without a wait time in a cycle > -- > > Key: SLING-612 > URL: https://issues.apache.org/jira/browse/SLING-612 > Project: Sling > Issue Type: Improvement > Components: Event >Affects Versions: Extensions Event 2.0.2 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Extensions Event 2.0.4 > > > Each job should be put back in the queue *after* the configured wait time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-606) Event to cancel a job
[ https://issues.apache.org/jira/browse/SLING-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-606: --- Fix Version/s: Extensions Event 2.0.4 > Event to cancel a job > - > > Key: SLING-606 > URL: https://issues.apache.org/jira/browse/SLING-606 > Project: Sling > Issue Type: New Feature > Components: Event >Affects Versions: Extensions Event 2.0.2 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Extensions Event 2.0.4 > > > It should be possible to cancel a running job by sending a special event. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SLING-571) JspServletWrapper swallows jsp exceptions if root cause is null
[
https://issues.apache.org/jira/browse/SLING-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reopened SLING-571:
Reopen this bug so we don't forget it
> JspServletWrapper swallows jsp exceptions if root cause is null
> ---
>
> Key: SLING-571
> URL: https://issues.apache.org/jira/browse/SLING-571
> Project: Sling
> Issue Type: Bug
> Components: Scripting JSP
>Affects Versions: Scripting JSP 2.0.2
>Reporter: Tobias Bocanegra
>Assignee: Carsten Ziegeler
> Fix For: Scripting JSP 2.0.4
>
> Attachments: SLING-571-reloaded.patch, SLING-571-third.patch,
> SLING-571.patch
>
>
> For example for a JSP compile error the 'realException' is null and the
> following stack-frame resolution fails:
> (JspServletWrapper.java, line 492ff)
> // First identify the stack frame in the trace that represents
> the JSP
> StackTraceElement[] frames = realException.getStackTrace();
> StackTraceElement jspFrame = null;
> for (int i=0; i if (
> frames[i].getClassName().equals(this.getServlet().getClass().getName()) ) {
> jspFrame = frames[i];
> break;
> }
> }
> Suggest to check for (realException == null)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-616) Provide better filter options to search for job
Provide better filter options to search for job --- Key: SLING-616 URL: https://issues.apache.org/jira/browse/SLING-616 Project: Sling Issue Type: New Feature Components: Event Affects Versions: Extensions Event 2.0.2 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 2.0.4 Currently it's only possible to search for all jobs, activate jobs and filter by an exact matching topics. This can be enhanced to allow pattern matching for the job topic - like the OSGi eventing does and to provide a map of properties that must match as well. This map acts like a search template. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Script resolution based on node types in /libs/*/my/type instead of just /libs/my/type?
Hi all, if you use both the "standard" servlet/script resolution using an explicit resource type (eg. myapp/foobar) and sometimes (for convenience) via the node type (eg. my:type) you get mixed locations for both scripts: /libs/myapp/foobar /libs/my/type Often you'd like to put them together, which would organize your repository much better, ie. like this: /libs/myapp/foobar /libs/myapp/my/type Therefore do you think it is possible to extend the script resolution for node types to search not only /apps// /libs// but also to search via wildcards: /apps/*// /libs/*// ? The first match would win. It's up to the developers to ensure only one occurence of my:type under /apps/* or /libs/*. WDYT? Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
Re: Script resolution based on node types in /libs/*/my/type instead of just /libs/my/type?
Hi, Alexander Klimetschek schrieb: Hi all, if you use both the "standard" servlet/script resolution using an explicit resource type (eg. myapp/foobar) and sometimes (for convenience) via the node type (eg. my:type) you get mixed locations for both scripts: /libs/myapp/foobar /libs/my/type Just a quick question: Why don't you set your resource type to be my/foobar or even my:foobar ? So you are at /libs/my/foobar /libs/my/type Regards Felix Often you'd like to put them together, which would organize your repository much better, ie. like this: /libs/myapp/foobar /libs/myapp/my/type Therefore do you think it is possible to extend the script resolution for node types to search not only /apps// /libs// but also to search via wildcards: /apps/*// /libs/*// ? The first match would win. It's up to the developers to ensure only one occurence of my:type under /apps/* or /libs/*. WDYT? Regards, Alex
Re: Script resolution based on node types in /libs/*/my/type instead of just /libs/my/type?
On Fri, Aug 15, 2008 at 3:54 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Just a quick question: Why don't you set your resource type to be my/foobar > or even my:foobar ? > > So you are at > > /libs/my/foobar > /libs/my/type Because the namespace prefix "my" is a very generic one (it is "cq" ;-)), but the "myapp" stuff is much more specific. I should have better named the example "mylib", since I am in the /lib folder, which gets typically more oriented towards smaller library parts than entire applications. These smaller parts are more fine-granular than the namespace, so it unfortunately doesn't fit. Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
Re: Script resolution based on node types in /libs/*/my/type instead of just /libs/my/type?
Hi, Alexander Klimetschek schrieb: On Fri, Aug 15, 2008 at 3:54 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: Just a quick question: Why don't you set your resource type to be my/foobar or even my:foobar ? So you are at /libs/my/foobar /libs/my/type Because the namespace prefix "my" is a very generic one (it is "cq" ;-)), but the "myapp" stuff is much more specific. I should have better named the example "mylib", since I am in the /lib folder, which gets typically more oriented towards smaller library parts than entire applications. These smaller parts are more fine-granular than the namespace, so it unfortunately doesn't fit. Hmm, ok. Then I have to say, that out of the box, we cannot fullfill your request. The reason for this is, that servlet resolution only considers the resource type, whereas the resource type is iteself (for node based resources) taken from the sling:resourceType property or the primary node type. There is however a service interface, where you might hook into, which allows finer control over the resource type resolution for JCR based resources: o.a.s.jcr.resource.JcrResourceTypeProvider. You can register such a service, which is called by the JCR based resource if the sling:resourceType property is not set but before falling back to the primary node type. In such a service, you might map the primary node type to something different and get where you want. Regards Felix
Re: Script resolution based on node types in /libs/*/my/type instead of just /libs/my/type?
On 8/15/08, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: > Hi all, > > if you use both the "standard" servlet/script resolution using an > explicit resource type (eg. myapp/foobar) and sometimes (for > convenience) via the node type (eg. my:type) you get mixed locations > for both scripts: > > /libs/myapp/foobar > /libs/my/type > > Often you'd like to put them together, which would organize your > repository much better, ie. like this: > > /libs/myapp/foobar > /libs/myapp/my/type > > Therefore do you think it is possible to extend the script resolution > for node types to search not only > > /apps// > /libs// > > but also to search via wildcards: > > /apps/*// > /libs/*// > > ? > > The first match would win. It's up to the developers to ensure only > one occurence of my:type under /apps/* or /libs/*. i don't think that is a good idea. the script resolution is complicated enough and this would even add more complexity to it. regards, toby > > WDYT? > > Regards, > Alex > > > -- > Alexander Klimetschek > [EMAIL PROTECTED] >
ClassCircularityError when using LdapLoginModule (updated)
Apologies if this is a repeat, my first post didn't seem to make it:
I disabled the SimpleLoginModule in repository.xml and configured a
login.conf file with the com.sun.security.auth.module.
LdapLoginModule (from JDK 6). After creating LDAP users for the admin &
anonymous identities, Sling starts up fine.
However, when requesting a node with a JSP rendering script, the
JspScriptEngineFactory throws an ClassCircularityError on activate - it
seems to be looping in the RepositoryClassLoader as it tries to login to
the repository (stack trace is below). I debugged through this and find
that RepositoryClassLoaderProviderImpl has this code in
getSession(String owner):
if (admin.getUserID().equals(owner)) {
return admin;
}
otherwise it tries to impersonate the "owner". I've verified that by
commenting out the owner check & always returning the admin session, the
ClassCircularityError doesn't occur.
When using LdapLoginModule, the userID returned from Session is the full
LDAP distinguished name (uid=admin,ou=People,ou=test1,o=test.com
),while owner is just "admin". This occurs because the
Jackrabbit SessionImpl class just grabs the first Principal from the
Subject when it is initialized, and that principal is LdapPrincipal in
the case of the LdapLoginModule. The LoginModule actually adds another
(UserPrincipal), whose name is just "admin", but this is not used or
checked.
I'm not sure what the right approach to fix this is. It would be good
if RepositoryClassLoaderProviderImpl checked the owner string against
all Principal names in the Session's Subject. However, Session doesn't
expose it's Subject, so you can't do this. And there doesn't seem to be
a way to tell Jackrabbit which Principal to choose (like specify it
should use first instance of UserPrincipal, or first Principal whose
name matches some regex). The last option appears to be rewriting the
LoginModule to store the UserPrincipal first, which isn't desirable (and
may not be possible for other LoginModules).
15.08.2008 12:25:24.171 **ERROR** [SCR Component Actor]
org.apache.sling.scripting.jsp
[org.apache.sling.scripting.jsp.JspScriptEngineFactory] The activate
method has thrown an exception (java.lang.ClassCircularityError:
com/sun/security/auth/module/LdapLoginModule)
java.lang.ClassCircularityError:
com/sun/security/auth/module/LdapLoginModule
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:731)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
at
org.apache.jackrabbit.core.security.AuthContext$JAAS.login(AuthContext.java:88)
at
org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1245)
at
org.apache.sling.jcr.base.internal.SessionPool.acquireSession(SessionPool.java:268)
at
org.apache.sling.jcr.base.internal.SessionPoolManager.login(SessionPoolManager.java:99)
at
org.apache.sling.jcr.base.AbstractSlingRepository.login(AbstractSlingRepository.java:240)
at
org.apache.sling.jcr.base.AbstractSlingRepository.loginAdministrative(AbstractSlingRepository.java:206)
at
org.apache.sling.jcr.classloader.internal.RepositoryClassLoaderProviderImpl.getSession(RepositoryClassLoaderProviderImpl.java:103)
at
org.apache.sling.jcr.classloader.internal.RepositoryClassLoaderFacade.getSession(RepositoryClassLoaderFacade.java:185)
at
org.apache.sling.jcr.classloader.internal.RepositoryClassLoaderFacade.getDelegateClassLoader(RepositoryClassLoaderFacade.java:195)
at
org.apache.sling.jcr.classloader.internal.RepositoryClassLoaderFacade.loadClass(RepositoryClassLoaderFacade.java:105)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:731)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
at
org.apache.jackrabbit.core.security.AuthContext$JAAS.login(AuthContext.java:88)
at
org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1245)
at
org.apache.jackrabbit.core.SessionImpl.impersonate(SessionImpl.java:810)
at
org.apache.sling.jcr.base.internal.Sessi
ClassCircularityError when using LdapLoginModule
I disabled the SimpleLoginModule in repository.xml and configured a login.conf file with the com.sun.security.auth.module.LdapLoginModule (from JDK 6). After creating LDAP users for the admin & anonymous identities, Sling starts up fine. However, when requesting a node with a JSP rendering script, the JspScriptEngineFactory throws an ClassCircularityError on activate - it seems to be looping in the RepositoryClassLoader as it tries to login to the repository (stack trace is below): 15.08.2008 12:25:24.171 *ERROR* [SCR Component Actor] org.apache.sling.scripting.jsp [org.apache.sling.scripting.jsp.JspScriptEngineFactory] The activate method has thrown an exception (java.lang.ClassCircularityError: com/sun/security/auth/module/LdapLoginModule) java.lang.ClassCircularityError: com/sun/security/auth/module/LdapLoginModule at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:731) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) at javax.security.auth.login.LoginContext.login(LoginContext.java:579) at org.apache.jackrabbit.core.security.AuthContext$JAAS.login(AuthContext.java:88) at org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1245) at org.apache.sling.jcr.base.internal.SessionPool.acquireSession(SessionPool.java:268) at org.apache.sling.jcr.base.internal.SessionPoolManager.login(SessionPoolManager.java:99) at org.apache.sling.jcr.base.AbstractSlingRepository.login(AbstractSlingRepository.java:240) at org.apache.sling.jcr.base.AbstractSlingRepository.loginAdministrative(AbstractSlingRepository.java:206) at org.apache.sling.jcr.classloader.internal.RepositoryClassLoaderProviderImpl.getSession(RepositoryClassLoaderProviderImpl.java:103) at org.apache.sling.jcr.classloader.internal.RepositoryClassLoaderFacade.getSession(RepositoryClassLoaderFacade.java:185) at org.apache.sling.jcr.classloader.internal.RepositoryClassLoaderFacade.getDelegateClassLoader(RepositoryClassLoaderFacade.java:195) at org.apache.sling.jcr.classloader.internal.RepositoryClassLoaderFacade.loadClass(RepositoryClassLoaderFacade.java:105) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:731) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) at javax.security.auth.login.LoginContext.login(LoginContext.java:579) at org.apache.jackrabbit.core.security.AuthContext$JAAS.login(AuthContext.java:88) at org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1245) at org.apache.jackrabbit.core.SessionImpl.impersonate(SessionImpl.java:810) at org.apache.sling.jcr.base.internal.SessionPool.acquireSession(SessionPool.java:330) at org.apache.sling.jcr.base.internal.SessionPoolManager.impersonate(SessionPoolManager.java:127) at org.apache.sling.jcr.base.internal.PooledSession.impersonate(PooledSession.java:220) at org.apache.sling.jcr.classloader.internal.RepositoryClassLoaderProviderImpl.getSession(RepositoryClassLoaderProviderImpl.java:112) at org.apache.sling.jcr.classloader.internal.RepositoryClassLoaderFacade.getSession(RepositoryClassLoaderFacade.java:185) at org.apache.sling.jcr.classloader.internal.RepositoryClassLoaderFacade.getDelegateClassLoader(RepositoryClassLoaderFacade.java:195) at org.apache.sling.jcr.classloader.internal.RepositoryClassLoaderFacade.getResource(RepositoryClassLoaderFacade.java:114) at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1168) at javax.xml.parsers.SecuritySupport$4.run(SecuritySupport.java:96) at java.security.AccessController.doPrivileged(Native Method) at javax.xml.parsers.SecuritySupport.getResourceAsStream(SecuritySupport.java:89) at javax.xml.parsers.FactoryFinder.findJarServiceProvider(FactoryFinder.java:250) at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:223) at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:123) at org.apache.sling.scripting.jsp.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:89) at org.apache.sling.scripting.jsp.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:133) at org.apache.sling.scripting.j
