Re: Integrate a Servlet Filter: init-params
Hi, Christian Sprecher schrieb: Hi Felix Felix Meschberger schrieb: Actually, the Sling Main Servlet initializes servlets and filters by calling the respective init(ServletConfig) and init(FilterConfig) methods. The parameters provided by the ServletConfig and/or FilterConfig (the traditional init-param settings) are taken from the OSGi service registration properties. This is actually quite interesting: For example by using declarative services you may have OSGi Configuration (from ConfigurationAdmin) added as service registration properties and thus as ServletConfig or FilterConfig parameters. This means you will have live-configuration support for such parameters ! Interesting indeed! Could you plz elaborate a bit? What do I have to do to have such a servlet of filter properly configurated? Using the scr-plugin, are all @scr.property automatically made available to the filter? Yes. And if you have the scr plugin generate the Metatype data (not setting metatype=no on the @scr.component tag) you will be able to configure the properties on the Configuration page of the Web Console. This live-configuration possibility sounds superb for my use case: I am trying to integrate WebCastellum (http://www.webcastellum.org) with Sling. WebCastellum is a web application firewall implemented as filter. This WAF is configured via init-param. The possibilty to configure that WAF in real-time is intriguing... Interesting. Would you be able to provide some description of this in the Wiki ? Thanks in advance. Regards Felix Cheers CSp
[jira] Created: (SLING-1001) Take the Maven -SNAPSHOT convention into account when comparing bundle version numbers
Take the Maven -SNAPSHOT convention into account when comparing bundle version numbers -- Key: SLING-1001 URL: https://issues.apache.org/jira/browse/SLING-1001 Project: Sling Issue Type: Improvement Components: JCR Install Affects Versions: JCR Install 2.0.4 Reporter: Bertrand Delacretaz When doing Maven-based development, it is common to create a new version of a bundle with the same xyz-SNAPSHOT version number as the previous one. Currently, jcrinstall does not update the bundle if a new one with the same xyz-SNAPSHOT version number is copied into the repository. It should update in this case, i.e. consider the bundle as a new version if the version string is the same as the installed one but contains -SNAPSHOT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1001) Take the Maven -SNAPSHOT convention into account when comparing bundle version numbers
[ https://issues.apache.org/jira/browse/SLING-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12718321#action_12718321 ] Bertrand Delacretaz commented on SLING-1001: This behavior should be configurable (configure the -SNAPSHOT string, empty means no special behavior), as there could be unwanted side effects. Take the Maven -SNAPSHOT convention into account when comparing bundle version numbers -- Key: SLING-1001 URL: https://issues.apache.org/jira/browse/SLING-1001 Project: Sling Issue Type: Improvement Components: JCR Install Affects Versions: JCR Install 2.0.4 Reporter: Bertrand Delacretaz When doing Maven-based development, it is common to create a new version of a bundle with the same xyz-SNAPSHOT version number as the previous one. Currently, jcrinstall does not update the bundle if a new one with the same xyz-SNAPSHOT version number is copied into the repository. It should update in this case, i.e. consider the bundle as a new version if the version string is the same as the installed one but contains -SNAPSHOT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-987) Jobs/Events are purged in an uncontrolled way
[ https://issues.apache.org/jira/browse/SLING-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-987: -- Assignee: Carsten Ziegeler Jobs/Events are purged in an uncontrolled way - Key: SLING-987 URL: https://issues.apache.org/jira/browse/SLING-987 Project: Sling Issue Type: Bug Components: Event Reporter: Philipp Koch Assignee: Carsten Ziegeler Priority: Blocker We already had this problem for pretty big event/job queues once (a month ago or so. could not find a jira issue) that the job in the queue got purged because the job acknowledge timed out for that job (by default the job/event is purged after 3 timeouts). the above mentioned fix fixed the issue quite well. it appeared now again when running such big queues on very fast boxes: 9.05.2009 13:00:07.904 *INFO* [pool-4-thread-1] org.apache.sling.event.impl.JobEventHandler No acknowledge received for job org.osgi.service.event.Event [topic=com/day/cq/workflow/job] stored at /var/eventing/jobs/com.day.cq.workflow.job/Job5a50f993-8f36-4eae-81d5-3124ca455bf5. Requeueing job. the funny thing is now that the timeout does not happen after hours but already after 10 mins. there are no (debug) log entries that would point to some event handler problems... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-987) Jobs/Events are purged in an uncontrolled way
[ https://issues.apache.org/jira/browse/SLING-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-987: --- Affects Version/s: Extensions Event 2.0.4 Fix Version/s: Extensions Event 2.0.6 It seems that this problem is caused by massive job events being sent from the event admin - the current thread pool used for the eventing has a maximum queue size of 50; as soon as this limit is reached the request for putting something into the queue is blocked until a place gets available inside the queue. Jobs/Events are purged in an uncontrolled way - Key: SLING-987 URL: https://issues.apache.org/jira/browse/SLING-987 Project: Sling Issue Type: Bug Components: Event Affects Versions: Extensions Event 2.0.4 Reporter: Philipp Koch Assignee: Carsten Ziegeler Priority: Blocker Fix For: Extensions Event 2.0.6 We already had this problem for pretty big event/job queues once (a month ago or so. could not find a jira issue) that the job in the queue got purged because the job acknowledge timed out for that job (by default the job/event is purged after 3 timeouts). the above mentioned fix fixed the issue quite well. it appeared now again when running such big queues on very fast boxes: 9.05.2009 13:00:07.904 *INFO* [pool-4-thread-1] org.apache.sling.event.impl.JobEventHandler No acknowledge received for job org.osgi.service.event.Event [topic=com/day/cq/workflow/job] stored at /var/eventing/jobs/com.day.cq.workflow.job/Job5a50f993-8f36-4eae-81d5-3124ca455bf5. Requeueing job. the funny thing is now that the timeout does not happen after hours but already after 10 mins. there are no (debug) log entries that would point to some event handler problems... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-987) Jobs/Events are purged in an uncontrolled way
[ https://issues.apache.org/jira/browse/SLING-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12718372#action_12718372 ] Carsten Ziegeler commented on SLING-987: I've set the queue size to unlimited in Revision 783711 Jobs/Events are purged in an uncontrolled way - Key: SLING-987 URL: https://issues.apache.org/jira/browse/SLING-987 Project: Sling Issue Type: Bug Components: Event Affects Versions: Extensions Event 2.0.4 Reporter: Philipp Koch Assignee: Carsten Ziegeler Priority: Blocker Fix For: Extensions Event 2.0.6 We already had this problem for pretty big event/job queues once (a month ago or so. could not find a jira issue) that the job in the queue got purged because the job acknowledge timed out for that job (by default the job/event is purged after 3 timeouts). the above mentioned fix fixed the issue quite well. it appeared now again when running such big queues on very fast boxes: 9.05.2009 13:00:07.904 *INFO* [pool-4-thread-1] org.apache.sling.event.impl.JobEventHandler No acknowledge received for job org.osgi.service.event.Event [topic=com/day/cq/workflow/job] stored at /var/eventing/jobs/com.day.cq.workflow.job/Job5a50f993-8f36-4eae-81d5-3124ca455bf5. Requeueing job. the funny thing is now that the timeout does not happen after hours but already after 10 mins. there are no (debug) log entries that would point to some event handler problems... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1002) Reduce memory consumption and improve startup behaviour of the job handler
Reduce memory consumption and improve startup behaviour of the job handler -- Key: SLING-1002 URL: https://issues.apache.org/jira/browse/SLING-1002 Project: Sling Issue Type: Improvement Components: Event Affects Versions: Extensions Event 2.0.4 Reporter: Carsten Ziegeler Currently the job handler holds all received jobs in memory until the job has been processed completly. In addition on startup all unprocessed jobs are loaded from the repository. If for example thousands of jobs are unprocessed in the repository and a new instance is started (or restarted) all these events are first load into memory and then put into the queue. It would be better to have a fixed max size for the in memory queue - and check the repository from time to time for unprocessed jobs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling configuration
Hi all, Should I (can I) open a JIRA issue for this? C.
Re: Sling configuration
Salut Claude, On Thu, Jun 11, 2009 at 2:07 PM, Claude Vedoviniclaude.vedov...@gmail.com wrote: ...Should I (can I) open a JIRA issue for this?.. yes please - the sling.home.prefix way seems to be the best, as Felix suggests in his last message here. -Bertrand
launchpad app Snapshot
Hi, Looking at [1] there is no org.apache.sling:org.apache.sling.launchpad.base:jar:app:2.0.5- incubator-SNAPSHOT but looking at [2] there is org.apache.sling:org.apache.sling.launchpad.base:jar:app:2.0.4-incubator NB the app classifier, was that intentional ? Ian [1] http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.launchpad.base/2.0.5-incubator-SNAPSHOT/ [2] http://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.launchpad.base/2.0.4-incubator/
Re: launchpad app Snapshot
Hi Ian, Ian Boston schrieb: Hi, Looking at [1] there is no org.apache.sling:org.apache.sling.launchpad.base:jar:app:2.0.5-incubator-SNAPSHOT but looking at [2] there is org.apache.sling:org.apache.sling.launchpad.base:jar:app:2.0.4-incubator It looks like Hudson is not deploying any artifact attachements. That is of course not good, since then all attached source artifacts are also missing. I cannot tell, how Hudson is deploying artifacts, obviously the build definition does not cause a deployment. Maybe Bertrand or Jukka can tell ? NB the app classifier, was that intentional ? Yes. The launchpad/base module generates the jar artifact, which is the main base module, which contains the shared launcher stuff as well as the Felix framework. In addition there are two artifacts with classifiers generated: The app artifact contains the standalone Java Application base, which is used by launchpad/base to create standalone Sling Application by merging the app artifact with the bundles from launchpadd/bundles. The webapp artifact serves the same purpose for web applications and is the base web application to be built to the Sling web application in the launchpad/webapp module adding the launchpad/bundles. Hope this helps. Regards Felix Ian [1] http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.launchpad.base/2.0.5-incubator-SNAPSHOT/ [2] http://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.launchpad.base/2.0.4-incubator/
Re: Caching for ResourceResolver.map()
Hi,
On Wed, Jun 10, 2009 at 3:10 PM, Carsten Ziegelercziege...@apache.org wrote:
While caching in the resource resolver might be a good idea anyway,
perhaps caching one layer above might give even more benefit. Instead
of querying the resource resolver a lot, caching above the resolver
would even avoid querying the resolver.
This turns out to be the best approach in my case. Especially since a
new ResourceResolver gets instantiated for each new request, which
makes it more difficult to add global caching.
However, since the resolution process depends on access rights, I
currently need to do something like this to include the potential
username in the cache key:
String user = ;
Session session = resourceResolver.adaptTo(Session.class);
if (session != null) {
user = session.getUserId();
}
This seems a bit fragile, so I was wondering if getting the username
from the request would work better:
String user = ;
Principal principal = request.getUserPrincipal();
if (principal != null) {
user = principal.getName();
}
I guess there are cases where the JCR Session (or whatever is used for
resource resolution) is authenticated using something else than the
user principal associated with the HTTP request.
Ultimately we should probably solve the performance issue on the
repository layer by making path lookups (especially negative ones)
blazingly fast. They're already pretty good in Jackrabbit, but for my
use case I'd need about an order of magnitude more performance. With a
simple high-level cache I was able to achieve this.
BR,
Jukka Zitting
Re: Caching for ResourceResolver.map()
Jukka Zitting schrieb:
Hi,
On Wed, Jun 10, 2009 at 3:10 PM, Carsten Ziegelercziege...@apache.org wrote:
While caching in the resource resolver might be a good idea anyway,
perhaps caching one layer above might give even more benefit. Instead
of querying the resource resolver a lot, caching above the resolver
would even avoid querying the resolver.
This turns out to be the best approach in my case. Especially since a
new ResourceResolver gets instantiated for each new request, which
makes it more difficult to add global caching.
Not sure, whether it really is the best approach. Though it is true,
that the ResourceResolver instance is created on each request, it is
still created from the JcrResourceResolverFactory, which might as well
be the holder of the cache and provide the user-specific subset of the
cache to the per-request-ResourceResolver.
However, since the resolution process depends on access rights, I
currently need to do something like this to include the potential
username in the cache key:
String user = ;
Session session = resourceResolver.adaptTo(Session.class);
if (session != null) {
user = session.getUserId();
}
This seems a bit fragile, so I was wondering if getting the username
from the request would work better:
String user = ;
Principal principal = request.getUserPrincipal();
if (principal != null) {
user = principal.getName();
}
I guess there are cases where the JCR Session (or whatever is used for
resource resolution) is authenticated using something else than the
user principal associated with the HTTP request.
You might want to use request.getRemoteUser(), which is backed by
Session.getUserId().
Ultimately we should probably solve the performance issue on the
repository layer by making path lookups (especially negative ones)
blazingly fast. They're already pretty good in Jackrabbit, but for my
use case I'd need about an order of magnitude more performance. With a
simple high-level cache I was able to achieve this.
oh yeah ;-)
Regards
Felix
Re: launchpad app Snapshot
Hi, On Thu, Jun 11, 2009 at 3:27 PM, Bertrand Delacretazbdelacre...@apache.org wrote: I haven't found any info about artifact attachments in the hudson docs or issue tracker, does anyone know more about that? Not really. Hudson does hook rather deeply into Maven so I would assume it to pick up any attached artifacts from the build, but apparently that's not the case here. It's always possible to tick off the deploy option from Hudson and instead configure the Maven build to use the normal deploy goal. The downside of this is the potential for partial deployments of multi-module projects. BR, Jukka Zitting
Re: Caching for ResourceResolver.map()
Hi, On Thu, Jun 11, 2009 at 3:08 PM, Felix Meschberger fmesc...@gmail.comwrote: Not sure, whether it really is the best approach. Though it is true, that the ResourceResolver instance is created on each request, it is still created from the JcrResourceResolverFactory, which might as well be the holder of the cache and provide the user-specific subset of the cache to the per-request-ResourceResolver. It sounds a bit strange to have a factory holding a cache. IMHO caching shouldn't be too hardwired since there are always situations where the caching as it's implemented doesn't fit the requirements. I think it would be nice to have a global ResourceResolver cache like you described which each ResourceResolver can adapt but does not have to (configurable). WDYT? Best regards, Dominik
Problems with dependency paths
I have been trying to make a build that was previously based on a trunk build of Sling work off the official release or snapshots of sling. I am hitting a number of problems related to missing dependencies, that I thought I should share with the list. for example I have a jar that depends on org.apache.sling:org.apache.sling.engine:jar:2.0.4-incubator, which since its released I think is a reasonable thing to do. But if you clean out your maven repo (rm -rf ~/.m2/repository/org/apache/sling ) and build you find the build fails with a dependency path of: Path to dependency: 1) org.sakaiproject.kernel:org.sakaiproject.kernel.jcr:bundle:0.1- SNAPSHOT 2) org.apache.sling:org.apache.sling.engine:jar:2.0.4-incubator 3) org.apache.sling:org.apache.sling.jcr.resource:jar:2.0.2- incubator 4) org.apache.sling:org.apache.sling.adapter:jar:2.0.2-incubator 5) org.apache.sling:org.apache.sling.commons.osgi:jar:2.0.2- incubator and no 5 doesnt exist in the repo. see [1] There is a simple solution to this, force the versions of those releases that are missing to versions that are not, but that a) feels dangerous and b) creates a maintenance headache A quick scan of the repo1 looks like *all* the 202 versions have gone missing from the repo, perhaps they were never there ? Any suggestions on what the right way of dealing with this is ? Ian [1] http://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.commons.osgi/
load root node from a bundle
Hi all, The content loading web page [1] is pretty helpful for getting initial content for directories below root. But, is it possible to use a content definition file for the root node? Up to now I've just been using a static index.html file. Instead, I'd like to set the resource type and other properties of the root node, and render it with appropriate scripts. Any tips or an example I can look at? Thanks, Andreas [1] http://incubator.apache.org/sling/site/content-loading.html
Re: Integrate a Servlet Filter: init-params
Felix Meschberger schrieb: Hi, Yes. And if you have the scr plugin generate the Metatype data (not setting metatype=no on the @scr.component tag) you will be able to configure the properties on the Configuration page of the Web Console. Wow, it works. This is pretty dramatic, imho. Changing a property even automatically calls the init() method. Superb! This live-configuration possibility sounds superb for my use case: I am trying to integrate WebCastellum (http://www.webcastellum.org) with Sling. WebCastellum is a web application firewall implemented as filter. This WAF is configured via init-param. The possibilty to configure that WAF in real-time is intriguing... Interesting. Would you be able to provide some description of this in the Wiki ? Thanks in advance. What are you exactly interessted in: the possibility to integrate a 3rd party filter into Sling, or the WAF functionality for? I would have to factor out the usage of the maven-scr-plugin in the first case (because I am fiddling around in the source code atm), and for the second case I would have to get this stuped filter to run like it should:). And then try to configure it sensibly for Sling.
[jira] Created: (SLING-1003) Integration of 3rd party servlet filters problematic
Integration of 3rd party servlet filters problematic Key: SLING-1003 URL: https://issues.apache.org/jira/browse/SLING-1003 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.0.4 Environment: Windows Vista, java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing) Reporter: Christian Sprecher Priority: Minor There is a problem within the chain handling: the 3rd party filter uses it's own wrapper for requests and response, and supplies it to the chain in the chain.doFilter() call. This leads to a ClassCastException on line 54 of AbstractSlingFilterChain: ... RequestProgressTracker tracker = ((SlingHttpServletRequest) request).getRequestProgressTracker(); ... I am not sure if this cast is valid in the context of a filter chain. On the other hand I am not sure wether such a use case (filter that manipulates request and response) has a chance to run in Sling. == Please note that this servlet filter needs to run as early as possible in the filter chain java.lang.ClassCastException: org.webcastellum.RequestWrapper cannot be cast to org.apache.sling.api.SlingHttpServletRequest at org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter (AbstractSlingFilterChain.java:54) at org.webcastellum.WebCastellumFilter.internalDoFilter(WebCastellumFilt er.java:2610) at org.webcastellum.WebCastellumFilter.doFilter(WebCastellumFilter.java: 1710) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
