Hi Chad, On Mar 19, 9:45 pm, chad skinner <[email protected]> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
