Hi Jason,
I'm glad you asked!
According to the experts there are two ways of making web applications work in OSGI.
We could run the OSGI container inside an application server, or run the application server as a bundle inside a OSGI container (the recommend way by the eclipse.org people)
So, the OSGI container would bootstrap the existing bundles:
1) The application server (like tomcat, jetty, etc)
2) The Mojarra bundle (javax.faces)
3) The web application bundles
OSGI (version 4.1, April 2007) already has a HTTP Service Specifications so JSF would have to register itself in the HTTP service.
The application bundles would register themselves as resources using the Http Service or some kind of special Mojarra extension point.
I'll try to use an example to illustrate how I envision a JSF OSGI application.
Suppose we're building an application that has a core bundle called com.mycompany with the following files:
/WebContent
+ index.xhtml
/WeContent/META-INF
+ faces-config.xml
/src
+ MenuItem.java
+ MenuBean.java
/
+plugin.xml
The plugin.xml file would:
1) Register the "/WebContent" folder to the HTTP context "/myapp"
2) Register the com.mycompany.Menu extension point, that would be handled by the MenuBean.java.
The faces-config.xml would declare the MenuBean.java as a backend bean named "menu".
MenuBean would have a method "public List<MenuItem> getItems()" that would read the "com.mycompany.Menu" extension and return the list of MenuItem objects with the String properties: navigationRule and title.
Index.xtml would be something like:
<c:forEach items="#{menu.items}" var="item">
<h:commandLink action="#{item.navigationRule}" value="#{item.title}" />
</c:forEach>
If we run the OSGi container at this point, the application (http:/myhost/myapp/index.xhtml) would do nothing because no one is attaching to the com.mycompany.Menu extension.
So we add the "Clients" plugin.
The bundle called com.mycompany.clients would have the following files:
/WebContent
+ clientList.xhtml
+ clientEdit.xhtml
/WebContent/META-INF
+ faces-config.xml
/src
+ ClientMenu.java
+ ClientBean.java
/
+ plugin.xml
The plugin.xml file would
1) Register "/WebContent" folder to the Http context "/myapp/clients"
2) Attach to the com.mycompany.Menu extension point with ClientMenu.java, that would add a MenuItem object with "Clients" as title and "goToClientList" as navigation rule
The faces-config.xml would
1) Declare the ClientBean.java as a backend bean for use with clientList.xhtml and clientEdit.xhtml
2) Declare the navigation rule "goToClientList" to go to /myapp/clients/clientList.xhtml
If we run the OSGI container again we would see a page with a link named "Clients", and if we click it, we would go to "
http://myhost/myapp/clients/clientList.xhtml"
So:
1) The inner workings of JSF wouldn't change because we would continue to use faces-config.xml to define each JSF bundle (managed beans, navigation rules, etc)
2) We would have to tell JSF which resources are attached to the JSF servlet by using the Http Resource service, or by a javax.faces.resource extension point.
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.
Thanks,
José Freire
Consulting - Financial Services Industry
Deloitte & Touche, Quality Firm, S.A.
Main: +(351) 21 042 25 00
Fax: +(351) 21 042 29 50
jfreire_at_deloitte.pt
www.deloitte.com/pt
Deloitte
Edifício Atrium Saldanha
Praça Duque de Saldanha, 1 - 7º
1050-094 Lisboa
Portugal
From: Jason Lee [mailto:jason_at_steeplesoft.com]
Sent: segunda-feira, 7 de Abril de 2008 19:43
To: Dev - JSF
Subject: OSGi Support
Recently....someone :) inquired about making JSF, meaning Mojarra, I assume, OSGi compliant, a suggestion in which Ed expressed a high degree of interest. If this were done, what exactly would/should that look like? I'll admit that I'm extremely new to OSGi, so maybe my nascent knowledge is the real hindrance here. Would we, say, package the ViewHandler as an OSGi bundle, allowing it to be swapped out at runtime? Would the Servlet ContextListener (and it's counterpart in the Portlet world) be responsible for starting the OSGi container? Do my questions even make sense? :)
I'm trying to come up to speed on OSGi due to an unrelated impetus, but this user's question keeps running through my mind, so I'm wondering if anyone else has given it some concrete thought and has a better understanding of OSGi to help clear the air a bit. :)
--
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
*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.