Re: Access Log as OSGi Events
Hi Carl, On Wed, Mar 2, 2011 at 10:37 PM, Carl Hall c...@hallwaytech.com wrote: Looks like I have bought some cycles to work on this. I am familiarizing myself with the code now. I'll plan to first replace the homegrown impl with logback. Any suggestions on direction or features are most welcomed Cool - one thing that I tried to do a while ago and wasn't possible is to selectively intercept log messages in order to log them as application logs, for example to record important user or system operations. I wanted to use the OSGi LogReaderService for this, but as Felix explained in [1] that only works for logs that use the OSGi LogService directly, not for slf4j logs. If you redesign our logging system, it would be nice to remove this limitation, with a capture mechanism that gets both LogService and slf4j logs. -Bertrand
Re: sharing http session between sling servlets and other web applications in an EAR
Hi, Am Donnerstag, den 03.03.2011, 08:29 + schrieb Sarwar Bhuiyan: Hi felix, how does it work in the sling jsps then? Grabbing the object from the session and casting it works in the JSP but not in a sling servlet. (This is with us using the embedded dependencies bundle with the same jar in the ear classpath.) What makes it work in the JSP? What JSPs does it work in ? JSPs runing inside Sling or JSPs running in the other web application ? If it for JSPs in other Web Applications, it is such that the other web application just sees the ear classpath provided classes while in the OSGi framework this is not automatically the case ... Regards Felix Sarwar On Thursday, March 3, 2011, Felix Meschberger fmesc...@adobe.com wrote: Hi, Am Mittwoch, den 02.03.2011, 23:02 + schrieb Sarwar Bhuiyan: Ah, so it is not enough to have a bundle with embedded libs( the dependencies) and in another jar weblogicwith the same dependencies or the EAR's classpath? No, this is the Java classloading 101. An object has a reference to is Class object (see Object.getClass()). For two parts of Java to access the same object the have to have visibility to the same Class object. Both parts need to have access to the same class objects thus the requirement of loading the classes from a shared class loader. It is not enough for them to see the same class bytes. Regards Felix Sarwar On Wed, Mar 2, 2011 at 10:51 PM, Felix Meschberger fmesc...@adobe.comwrote: Hi, In CQ/Sling we use HttpSession objects created by the servlet container used. In your case this would be the weblogic server. The problem with the objects in the session is that the same classes (class objects) must be used in the OSGi framework as well as in the other parts of the EAR. So the classes must be loaded from a shared class loader. To do this in the OSGi framework you will want to use a feature call system package exports. The easiest way to get this done is creating a framework extension fragment which attaches to the system bundle and enhances the exports of that system bundle. Refer to [1] for how this could be done. Regards Felix [1] http://blog.meschberger.ch/2008/10/osgi-framework-extension-as-maven.html Am Mittwoch, den 02.03.2011, 22:10 + schrieb Unmesh Joshi: Hi, In our current project, we have a mix of sling servlets (as part of CQ) and an old spring mvc application. The migration is planned to move completely to sling/CQ. But till the complete migration happens, these two need to coexist in the same web container (weblogic in this case). We have a successful POC working where JSPs, which are CQ components, can access session objects set by other web applications. (Made possible by session sharing facility in weblogic). For refering to the Java classes in JSP, they need to be packaged and exported as an OSGI bundle. I am trying to understand how http session handling happens in OSGI container (felix) and other web applications in same web container. Because, if I try to use the same class in sling servlet (which is packaged as OSGI bundle), I get ClassCastException (as expected). Are there any pointers which explain how class loading works in HTTP service in Felix? Thanks, Unmesh
Re: sharing http session between sling servlets and other web applications in an EAR
On 03.03.11 07:01, Unmesh Joshi unmeshjo...@gmail.com wrote: 1. Why would the classes be resolved in JSP components when exported from a OSGI bundle which includes all the shared jars. Here they are not getting loaded by shared ear class loader. If these are JSPs running inside Sling, I would guess: it might be that the classloader used by the JSP scripting engine actually directly uses the shared classloader from the servlet container, without the need for the special framework extension fragment in the OSGi container. But not sure. Some colleagues told me that session objects are actually getting serialized and then deserialized in OSGI container, so the behaviour is similar to how remote calls work with serialization. No, there is no serialization going on. AFAIK this only happens in servlet containers that cache sessions on disk and/or move the session across instances and hence need to serialize/deserialize them. This statefulness (and complexity) you get here from using http sessions is the central point why they are considered a bad idea (tm). OSGi itself doesn't do anything here (since it is about classloading and a general framework) and Sling also doesn't do anything with HttpSessions, so they use them as they are provided by the underlying servlet container. 2. How does OSGI framework know about Ear classloader as its parent classloader (and not go to Java system classloader)? In the OSGI bundles, if I try to get parent classloader by calling getClassLoader().getParent(), I get null, which I suppose means bootstrap classloader. I think the OSGi class loader prevents you from going to the parent class loader, in order to make sure its class loading mechanism is not mitigated. Internally it still has access to the parent class loader that it gets from the servlet container (if the OSGi framework is running inside a webapp, as it is the case with Sling), but here you need the framework extension fragment being present so that OSGi can properly pass those classes through (again, not 100% sure, Felix probably knows it much better than me). Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
Re: sharing http session between sling servlets and other web applications in an EAR
On Thu, Mar 3, 2011 at 10:27 AM, Alexander Klimetschek aklim...@adobe.com wrote: On 03.03.11 07:01, Unmesh Joshi unmeshjo...@gmail.com wrote: If these are JSPs running inside Sling, I would guess: it might be that the classloader used by the JSP scripting engine actually directly uses the shared classloader from the servlet container, without the need for the special framework extension fragment in the OSGi container. But not sure. When JSP running inside sling is trying to get session objects, it is ALWAYS getting deserialized by weblogic. See the following stack trace. This does not happen when Sling servlet is trying to get session data. Is something special happens when JSP is processed by sling? at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:546) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at weblogic.common.internal.PassivationUtils.toObject(PassivationUtils.java:54) at weblogic.common.internal.PassivationUtils.toObject(PassivationUtils.java:46) at weblogic.common.internal.PassivationUtils.copy(PassivationUtils.java:64) at weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java:100) at weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java:44) at weblogic.servlet.internal.session.SessionData.getAttribute(SessionData.java:395) at weblogic.servlet.internal.session.SharedSessionData.getAttribute(SharedSessionData.java:59) at org.apache.jsp.apps.myapp.components.Login.Login_jsp._jspService(Login_jsp.java:145) at org.apache.sling.scripting.jsp.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at org.apache.sling.scripting.jsp.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:394) at org.apache.sling.scripting.jsp.JspServletWrapperAdapter.service(JspServletWrapperAdapter.java:59) at org.apache.sling.scripting.jsp.JspScriptEngineFactory.callJsp(JspScriptEngineFactory.java:142) at org.apache.sling.scripting.jsp.JspScriptEngineFactory.access$100(JspScriptEngineFactory.java:73) at org.apache.sling.scripting.jsp.JspScriptEngineFactory$JspScriptEngine.eval(JspScriptEngineFactory.java:344) at org.apache.sling.scripting.core.impl.DefaultSlingScript.call(DefaultSlingScript.java:224) at org.apache.sling.scripting.core.impl.DefaultSlingScript.eval(DefaultSlingScript.java:161) at org.apache.sling.scripting.core.impl.DefaultSlingScript.service(DefaultSlingScript.java:320) at org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:525) at org.apache.sling.engine.impl.filter.SlingComponentFilterChain.render(SlingComponentFilterChain.java:45) at org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:64) at com.day.cq.wcm.core.impl.WCMDebugFilter.doFilterWithErrorHandling(WCMDebugFilter.java:183) at com.day.cq.wcm.core.impl.WCMDebugFilter.doFilter(WCMDebugFilter.java:150) at org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60) at com.day.cq.wcm.core.impl.WCMRequestFilter.doFilter(WCMRequestFilter.java:239) at org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60) at org.apache.sling.engine.impl.SlingMainServlet.processRequest(SlingMainServlet.java:427) at org.apache.sling.engine.impl.SlingMainServlet.includeContent(SlingMainServlet.java:408) at org.apache.sling.engine.impl.request.SlingRequestDispatcher.dispatch(SlingRequestDispatcher.java:175) at org.apache.sling.engine.impl.request.SlingRequestDispatcher.include(SlingRequestDispatcher.java:69) at com.day.cq.wcm.core.impl.WCMRequestFilter$ForwardRequestDispatcher.include(WCMRequestFilter.java:457) at org.apache.sling.scripting.jsp.taglib.IncludeTagHandler.dispatch(IncludeTagHandler.java:47) at org.apache.sling.scripting.jsp.taglib.AbstractDispatcherTagHandler.doEndTag(AbstractDispatcherTagHandler.java:129) at org.apache.jsp.libs.foundation.components.parsys.parsys_jsp._jspService(parsys_jsp.java:308) at org.apache.sling.scripting.jsp.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at org.apache.sling.scripting.jsp.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:394) at
Re: sharing http session between sling servlets and other web applications in an EAR
On 03.03.11 14:44, Unmesh Joshi unmeshjo...@gmail.com wrote: When JSP running inside sling is trying to get session objects, it is ALWAYS getting deserialized by weblogic. See the following stack trace. This does not happen when Sling servlet is trying to get session data. Is something special happens when JSP is processed by sling? at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:546) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at weblogic.common.internal.PassivationUtils.toObject(PassivationUtils.java:5 4) at weblogic.common.internal.PassivationUtils.toObject(PassivationUtils.java:4 6) at weblogic.common.internal.PassivationUtils.copy(PassivationUtils.java:64) at weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java :100) at weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java :44) at weblogic.servlet.internal.session.SessionData.getAttribute(SessionData.jav a:395) at weblogic.servlet.internal.session.SharedSessionData.getAttribute(SharedSes sionData.java:59) at org.apache.jsp.apps.myapp.components.Login.Login_jsp._jspService(Login_jsp .java:145) Well, not sure from the stacktrace if there is an actual deserialization going on. Weblogic could also just try to read from some cache. Maybe you could disable that serialization in Weblogic - I don't really see the reason why you want that overhead between two webapps on the same web application server. (Except persisting the sessions on disk is important) In any case, this is all happening inside Weblogic, not Sling. The JSP just calls session.getAttribute() here. Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
Re: sharing http session between sling servlets and other web applications in an EAR
The actual deserialization is going on and it happens only when session.getAttribute is called from JSP in sling. If its called from SlingServlet, which is in OSGI bundle, this doesn't happen. We do not need serialization at all, but not sure why this kind of thing is happening only when called from JSP running in sling. On Thu, Mar 3, 2011 at 11:01 PM, Alexander Klimetschek aklim...@adobe.com wrote: On 03.03.11 14:44, Unmesh Joshi unmeshjo...@gmail.com wrote: When JSP running inside sling is trying to get session objects, it is ALWAYS getting deserialized by weblogic. See the following stack trace. This does not happen when Sling servlet is trying to get session data. Is something special happens when JSP is processed by sling? at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:546) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at weblogic.common.internal.PassivationUtils.toObject(PassivationUtils.java:5 4) at weblogic.common.internal.PassivationUtils.toObject(PassivationUtils.java:4 6) at weblogic.common.internal.PassivationUtils.copy(PassivationUtils.java:64) at weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java :100) at weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java :44) at weblogic.servlet.internal.session.SessionData.getAttribute(SessionData.jav a:395) at weblogic.servlet.internal.session.SharedSessionData.getAttribute(SharedSes sionData.java:59) at org.apache.jsp.apps.myapp.components.Login.Login_jsp._jspService(Login_jsp .java:145) Well, not sure from the stacktrace if there is an actual deserialization going on. Weblogic could also just try to read from some cache. Maybe you could disable that serialization in Weblogic - I don't really see the reason why you want that overhead between two webapps on the same web application server. (Except persisting the sessions on disk is important) In any case, this is all happening inside Weblogic, not Sling. The JSP just calls session.getAttribute() here. Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
implicit sling:resourceType?
Hey, I have a node: /content/page whose sling:resourceType = /apps/foo/bar So, GET /content/page.html will be handled by /apps/foo/bar/html.jsp I cannot modify sling:resourceType of /content/page. However, I would like GET /content/page.edit.html to be handled by /apps/foo/bar2/edit.html.jsp Is this possible? I cannot modify /apps/foo/bar and /content/page. But I want .edit.html to be handled by /apps/foo/bar2. Should I add a servlet with: sling.servlet.resourceTypes = sling/servlet/default sling.servlet.selectors = edit to capture all .edit.html and somehow call /apps/foo/bar2/edit.html.jsp ? (maybe a redirect?)
Re: implicit sling:resourceType?
Hi Sam I think the RequestDispatcherOptions[0] might be what you're looking for. It allows you to control certain aspects of re-dispatching (forwarding and including) a request, including forcing a different resource type. You could use this API in a servlet registered for the edit selector, as you suggested. Regards Julian [0] http://sling.apache.org/apidocs/sling5/org/apache/sling/api/request/RequestDispatcherOptions.html On Thu, Mar 3, 2011 at 8:17 PM, sam lee skyn...@gmail.com wrote: Hey, I have a node: /content/page whose sling:resourceType = /apps/foo/bar So, GET /content/page.html will be handled by /apps/foo/bar/html.jsp I cannot modify sling:resourceType of /content/page. However, I would like GET /content/page.edit.html to be handled by /apps/foo/bar2/edit.html.jsp Is this possible? I cannot modify /apps/foo/bar and /content/page. But I want .edit.html to be handled by /apps/foo/bar2. Should I add a servlet with: sling.servlet.resourceTypes = sling/servlet/default sling.servlet.selectors = edit to capture all .edit.html and somehow call /apps/foo/bar2/edit.html.jsp ? (maybe a redirect?)
Re: Access Log as OSGi Events
Hi, Am Donnerstag, den 03.03.2011, 17:07 + schrieb Carl Hall: There seem to be 3 things to accomplish here: * Change logging order to have slf4j write into the LogService then have a LogListener that will handle writing to logback, etc. I would not do that. Rather keep the structure as it is now. Maybe we can just provide a custom logback appender which emits the OSGi events requested by Bertrand ? * Replace homegrown log mechanism with logback (or something comparable) * maintaining all current functionality. +1 to both. And while I'm buying cycles I might as well try to accomplish everything. :) I feel decently comfortable in the code as I spent last night getting a map of the terrain. I have started a local git branch for performing these changes. I'll file 2 JIRAs to cover this (change to logback, change processing order). Felix, is this [1] the whiteboard sanbox you speak of? Exactly. But you might also use the Apache Review Board, if you like. Let me know if I sound crazy on any of this. All things said, except: Thanks a lot for taking this over ! Regards Felix 1 http://svn.apache.org/repos/asf/sling/whiteboard/ On Thu, Mar 3, 2011 at 8:56 AM, Justin Edelson jus...@justinedelson.comwrote: Go Carl!!! On Mar 3, 2011, at 2:58 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi Carl, Am Mittwoch, den 02.03.2011, 21:37 + schrieb Carl Hall: Looks like I have bought some cycles to work on this. I am familiarizing myself with the code now. I'll plan to first replace the homegrown impl with logback. Any suggestions on direction or features are most welcomed. The most important point is, that existing configurations and configuration mechanisms (factory configurations for writers and loggers) must still be supported. Further points would then probably be extending the current configuration mechanisms to support more logback features: - different Appenders - Appender extension Definitely in favor of these two conceptually, but I would prefer we didn't expose the implementation detail that we're using logback. Possible? - add Sling to the list of open-source projects using it (see http://logback.qos.ch) I think this will be a major rework. How about starting this in a whiteboard sandbox ? Regards Felix On Fri, Feb 18, 2011 at 10:09 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi, Am Donnerstag, den 17.02.2011, 08:58 + schrieb Bertrand Delacretaz: Hi, On Wed, Feb 16, 2011 at 10:49 PM, Carl Hall c...@hallwaytech.com wrote: Is it possible to send the access log entries as OSGi events? I see the use of RequestLogger which doesn't have such capabilities. To send access log entries to as events, would a patch be required for SlingMainServlet et al? In theory the LogReaderService might help for that, but the way our logging is implemented does not allow us to use it currently, see http://markmail.org/message/dlx5yvbjr74d46mh I think improving this would be useful, if someone has the cycles... As I already mentioned in the reference mail thread, using LogReader does not work. I thought about reverting the LogService-SLF4J interconnection in that SLF4J would log to LogService. But this turns out to not be practical -- mostly because LogService does not allow the same level of flexibility regarding log categories I really think the correct solution going forward (and needing cycles here) would be to replace our home-grown SLF4J implementation with an existing implementation (logback comes to mind) which would allows us for better extensibility and reuse. Regards Felix -Bertrand [1] http://www.osgi.org/javadoc/r4v42/org/osgi/service/log/LogReaderService.html
Re: Access Log as OSGi Events
Hi, One last word ;-) Lets move this discussion to dev@ ;-) Regards Felix Am Donnerstag, den 03.03.2011, 17:07 + schrieb Carl Hall: There seem to be 3 things to accomplish here: * Change logging order to have slf4j write into the LogService then have a LogListener that will handle writing to logback, etc. * Replace homegrown log mechanism with logback (or something comparable) * maintaining all current functionality. And while I'm buying cycles I might as well try to accomplish everything. :) I feel decently comfortable in the code as I spent last night getting a map of the terrain. I have started a local git branch for performing these changes. I'll file 2 JIRAs to cover this (change to logback, change processing order). Felix, is this [1] the whiteboard sanbox you speak of? Let me know if I sound crazy on any of this. 1 http://svn.apache.org/repos/asf/sling/whiteboard/ On Thu, Mar 3, 2011 at 8:56 AM, Justin Edelson jus...@justinedelson.comwrote: Go Carl!!! On Mar 3, 2011, at 2:58 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi Carl, Am Mittwoch, den 02.03.2011, 21:37 + schrieb Carl Hall: Looks like I have bought some cycles to work on this. I am familiarizing myself with the code now. I'll plan to first replace the homegrown impl with logback. Any suggestions on direction or features are most welcomed. The most important point is, that existing configurations and configuration mechanisms (factory configurations for writers and loggers) must still be supported. Further points would then probably be extending the current configuration mechanisms to support more logback features: - different Appenders - Appender extension Definitely in favor of these two conceptually, but I would prefer we didn't expose the implementation detail that we're using logback. Possible? - add Sling to the list of open-source projects using it (see http://logback.qos.ch) I think this will be a major rework. How about starting this in a whiteboard sandbox ? Regards Felix On Fri, Feb 18, 2011 at 10:09 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi, Am Donnerstag, den 17.02.2011, 08:58 + schrieb Bertrand Delacretaz: Hi, On Wed, Feb 16, 2011 at 10:49 PM, Carl Hall c...@hallwaytech.com wrote: Is it possible to send the access log entries as OSGi events? I see the use of RequestLogger which doesn't have such capabilities. To send access log entries to as events, would a patch be required for SlingMainServlet et al? In theory the LogReaderService might help for that, but the way our logging is implemented does not allow us to use it currently, see http://markmail.org/message/dlx5yvbjr74d46mh I think improving this would be useful, if someone has the cycles... As I already mentioned in the reference mail thread, using LogReader does not work. I thought about reverting the LogService-SLF4J interconnection in that SLF4J would log to LogService. But this turns out to not be practical -- mostly because LogService does not allow the same level of flexibility regarding log categories I really think the correct solution going forward (and needing cycles here) would be to replace our home-grown SLF4J implementation with an existing implementation (logback comes to mind) which would allows us for better extensibility and reuse. Regards Felix -Bertrand [1] http://www.osgi.org/javadoc/r4v42/org/osgi/service/log/LogReaderService.html
