+1 on making Lift work with OSGi +1 on ripping the logic out of both the Servlet and ServletFilter implementations and moving them elsewhere. This will be necessary to do portlets anyway.
On Thu, Mar 19, 2009 at 1:45 PM, marius d. <marius.dan...@gmail.com> wrote: > > Hi Chad, > > On Mar 19, 9:45 pm, chad skinner <chadwskin...@gmail.com> wrote: > > I am trying to redesign our web applications into a more services / > > component based system that would allow us to add features without > > having to worry about breaking other components. I have been > > investigating OSGi as a framework utilizing EJB3 and JPA. So far I > > have (at least I believe) all of my EJBs and Entities deploying in the > > OSGi container. The primary issue I have to address now is how to > > handle authentication and the User Interface (we are currently using > > JSF, but it has not been a good fit for our applications) and during > > some reading I ran across the Lift Framework and am impressed so far, > > but was wondering if anyone has any ideas on how it could be > > integrated into OSGi applications? > > Personally I'm not experienced with OSGi but Lift is exposed to the > JEE web container using a Servlet filter, not a servlet per se and > AFAIK to the OSGi HttpService one can only register a > servlet.LiftServlet class is A HttpServlet but I don;t think that this > would help you much as critical operations are done in the LiftFilter > class. > > > > > Would it be possible to create a servlet that would register itself > > with OSGi as handling all http requests. Then have a bundle that > > implements a service interface containing methods that determine if > > the bundle can handle a requested URI, and a method that the > > controller can call to delegate the request. This delegation process I > > believe to be entirely possible however I am not certain how this > > would play well with the Lift Framework. > > Well Lit's controllers are essentially functions and partial > functions.I think that in order to have a Lift Servlet usable in this > context would require a bit of changes in Lift. In fact OSGi > integration has been discussed before if I remember correctly but > never materialized mostly due to other priorities. > > >For this to work, I would > > need to have an OSGi activator that could initialize and destroy the > > Lift configuration when the bundle is activated or deactivated (I > > believe this would be similar to the initialization and destruction > > processes in the Lift Filter. > > > > One issue is whether or not it is possible to have multiple lift > > instances running as you will have multiple bundles each with its own > > snippets and templates and these may need to be able to access the > > templates from other services. > > If and only if each registered servlet is loaded by a separate class- > loader (unrelated in the delegation chain) that should be possible > otherwise because Lift is using Scala objects such as LiftRules there > are no boundaries so there can not be separate LiftRules etc.AFAIK > each OSGi bundle is loaded by its own classloader. Am I wrong ? > > > > > Our system uses a series of nested services and I am trying to figure > > out how I can register the servlets in a hierarchal fashion without > > knowing what context the parent bundle’s servlets are registered. For > > example, The profile may register is servlets under /profile, but the > > blog that adds functionality to the profile would register itself with > > the profile under /blog. The issue is that profile injects a couple of > > elements into the path so that /profile/private/blog shows the owner/ > > administrator view of the blog, but /profile/<username>/blog shows the > > public representation of the blog. The only way I can figure out how > > to make this work is to use delegation. > > > > Does anyone know if it is possible to setup lift in an OSGi bundle > > activator and then have another servlet delegate the calls to the Lift > > framework? Also, does anyone have any thoughts on how security could > > be implemented in a dynamic situation like this? Lastly, if this is > > possible, is this a good approach or if there are better solutions? > > IMHO Lift's integration in OSGi needs some work that is definitely > worthwhile. > > > > > I have been trying to get my thoughts down in words for a few days and > > am not certain that I have done a good job of explaining what I am > > thinking, but any thoughts or questions would be appreciated. > > All these are very interested things but to make it happen I think: > > 1. Make proper isolation for Lift to be properly initialized without a > Lift Filter (not sure if OSGi will support registering filters any > time soon). Thus one can have different context paths ... essentially > different Lift apps registered > 2. Test, test, test ... > > One thought though .. you mentioned that you'd want to use different > context /profile, /blog etc. For that you don't actually need > different LiftServlet .. just a single Lift servlet registered to the > ROOT "/" context and let Lift manage the other paths /profile, / > blog, ... etc. > > > > > Thanks, > > Chad > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
