I know _nothing_ about OSGi, but I do know that Glassfish v3 is redoing
their architecture to be OSGi, so I _think_ that we're going to get some
level of OSGi integration at some point in the future (but maybe just
via the servlet container... as I said, I know nothing about this).
Prehaps Ryan knows more?
Anyway, if you're really into OSGi, the new V3 stuff may have some
attraction for you. I think we're past the early alpha level on the
code there (i.e., mostly stable for most things).
Jim
Jason Lee wrote:
> Those are all very good questions, answers to which I'd like to hear
> myself. :)
>
> In terms of implementing these changes (whatever they turn out to be), I
> really have no idea when and where that would happen. Of course, I'm
> willing to help, but, as I've noted, I'm still an OSGi noob, so it will
> take me some time to get up to speed. If we can decide on how this
> should look/work, I'll think along those lines as I study OSGi, and
> we'll see what happens (assuming the entire idea isn't scrapped. Either
> way, I have to learn OSGi, though :)
>
> On Tue, Apr 8, 2008 at 6:16 AM, Freire, Jose Luis (PT - Lisbon)
> <jfreire_at_deloitte.pt <mailto:jfreire_at_deloitte.pt>> wrote:
>
> I also don't think it would be very difficult to make JSF as a bundle.
> It would be great if we could downgrade some advanced JSF internals to
> bypass some potencial OSGI limitations/constraints. Would any work on
> JSF-OSGI be done on 1.2, or would it start on 2.0?
>
> The first thing we need is a configure() method that we could call on
> plugin activation. And then see where it breaks next.
>
> The eclipse.org <http://eclipse.org> team has JSP working
> (http://www.eclipse.org/equinox/server/jsp_support.php) and on the same
> page they have links to examples of JSTL and Struts.
>
> For JSP they do it with a bundle (org.eclipse.equinox.jsp.jasper) they
> describe as "Provides an OSGi friendly JSPServlet based on the use of
> the Jasper 2 compiler and runtime."
>
> So how would JSF+JSP work? Would the JSF-OSGI implementation use it's
> own Jasper implementation? Or would it be simpler to start with
> JSF+Facelets?
>
> I am curious about what Ed Burns meant by "It makes perfect sense to me
> to have the JSF impl sit on top of an OSGI stack."
>
> Does he mean to have an JSF-OSGI extension spec so we could define
> extension points to configure PhaseListeners, Navigation Handlers, etc?
> Or does he mean to actually refactor the JSF Implementation to be OSGI
> native? OSGI Service Layer has a lot of interesting stuff that the
> JSF-OSGI implementation could use, like the Log Service for example.
>
>
> -----Original Message-----
> From: Jason Lee [mailto:jason_at_steeplesoft.com
> <mailto:jason_at_steeplesoft.com>]
> Sent: segunda-feira, 7 de Abril de 2008 22:03
> To: dev_at_javaserverfaces.dev.java.net
> <mailto:dev_at_javaserverfaces.dev.java.net>
> Subject: Re: OSGi Support
>
> Freire, Jose Luis (PT - Lisbon) wrote:
> > I'm glad you asked!
>
> So that was you! I was too lazy to search. :)
>
> > We could go crazy and have some other extensions points like
> > javax.faces.validator to declare validators, but I don't think it
> would
> > bring any immediate benefit.
>
> So what you're mainly interested in, then, is a way to register JSF
> itself with an OSGi container as a whole, and not necessarily parts of
> the JSF impl itself, right? If that's so, that doesn't seem like it
> would be all that difficult, but my inexperience with the technology may
>
> be glaring at this point. :)
>
> --
> Jason Lee, SCJP
> Software Architect -- Objectstream, Inc.
> Mojarra and Mojarra Scales Dev Team
> https://mojarra.dev.java.net
> https://scales.dev.java.net
> http://blogs.steeplesoft.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> <mailto:dev-unsubscribe_at_javaserverfaces.dev.java.net>
> For additional commands, e-mail:
> dev-help_at_javaserverfaces.dev.java.net
> <mailto:dev-help_at_javaserverfaces.dev.java.net>
>
> *Disclaimer:*
> Deloitte refers to one or more of Deloitte Touche Tohmatsu, a Swiss
> Verein, its member firms, and their respective subsidiaries and
> affiliates. As a Swiss Verein (association), neither Deloitte
> Touche Tohmatsu nor any of its member firms has any liability for
> each other's acts or omissions. Each of the member firms is a
> separate and independent legal entity operating under the names
> "Deloitte," "Deloitte & Touche," "Deloitte Touche Tohmatsu," or
> other related names. Services are provided by the member firms or
> their subsidiaries or affiliates and not by the Deloitte Touche
> Tohmatsu Verein.
> Privileged/Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message (or
> responsible for delivery of the message to such person), you may not
> copy or deliver this message to anyone. In such case, you should
> destroy this message and kindly notify the sender by reply email.
> Please advise immediately if you or your employer do not consent to
> Internet email for messages of this kind. Opinions, conclusions and
> other information in this message that do not relate to the official
> business of my firm shall be understood as neither given nor
> endorsed by it.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> <mailto:dev-unsubscribe_at_javaserverfaces.dev.java.net>
> For additional commands, e-mail:
> dev-help_at_javaserverfaces.dev.java.net
> <mailto:dev-help_at_javaserverfaces.dev.java.net>
>
>
>
>
> --
> Jason Lee, SCJP
> Software Architect -- Objectstream, Inc.
> Mojarra and Mojarra Scales Dev Team
> https://mojarra.dev.java.net
> https://scales.dev.java.net
> http://blogs.steeplesoft.com