Hi everybody!

I want to develop an extendable JSF Application. My idea is an application which can be extended by adding modules (plugins / addons) to the basic application. a module can either consist of additional Managed Beans or JSPs. It should be a coherent package like a .jar or a .war-File.

My solution idea is to create a page with an upload dialog which allows to parse the modul packe, save the different files into the deployed basic application folders and restart the application server.

What do you think about this? Does anyone know a better solution to solve my problem? Is it for example possible to access the managed beans of an application with a different web context?

best regards,

Defrian

Edited by: defrian on Feb 6, 2008 2:36 PM

Edited by: defrian on Feb 6, 2008 2:38 PM

 

 

I did a quick search on google and found this:

http://www.flexive.org/docs/website/jsf_plugin_api.html

You might be able to capture some good ideas from it. Once you figure it out you should write an article because I'm sure there are a lot of people that would be interested in this. I know I am.


Thanks,
Ryan

 

 

Hi,

One of the main themes for GlassFish v3 (https://glassfish.dev.java.net) is plugability. The entire server will allow you to add / remove predefined modules, or custom modules. The admin console in v3 is based on JSF and is also plugable. When a module is added to the system which provides UI, the admin console will dynamically pick it up and integrate it. This will include integrating new pages, as well as integrating within existing JSF pages.

The infrastructure to support this is currently being developed and is based on HK2, JSFTemplating, and some new config data / annotations. If you're interested in watching this project, feel free to get involved. All the code is open source as are our meetings (conference calls / irc).

Ryan... thanks for the link. It looks interesting. However, the requirements we have require much more functionality with less Java code. We'll be able to extend parts of the application w/o writing any Java code at all.. and our extension points including using re-usable "handlers" which can do a wide variety of tasks such as invoking JMX Mbeans, to setting UIComponent properties, all w/o writing Java or restarting the server.

To find out more, join the GlassFish project and register for the admin@glassfish email alias and watch it happen or participate.

Have fun!

Ken Paulsen
https://jsftemplating.dev.java.net

 

 

Wow this sounds very interesting. Especially since I've read that the best ideas from JSFTemplating and Facelets are being integrated and standardized in JSF 2.0. The project that I want to write won't be released until at least 2009 so I want to consider using early access JSF 2.0 once it is available. I'm already a GlassFish v2 paying customer (SJSAS 9.1) and am really looking forward to GlassFish v3. When it is time to work on this project I will definitely spend some time checking out the GlassFish v3 web admin project for ideas.

Is there a wiki page somewhere in the GlassFish wiki that talks about the plugin infrastructure?


Thanks,
Ryan

 

 

I just sent an email to the JSF 2.0 expert group suggesting they read this thread and consider adding support for plugins either based on what GlassFish v3 admin console is doing or Struts 2 plugins.

I also suggested they build in a feature for "processing screens" where the user sees a "Please wait..." screen while the server is processing. Struts 2 and WebWork have this feature.


Ryan

 

 

Many parts of JSF itself are pluggable, and although the spec itself doesn't call out how to make pages & business logic pluggable, it is possible to do this with JSF. It may be best to let a different JSR or open source project address this -- I might be willing to help out on such a JSR / project.

As for the "please wait screen" feature, I believe the scope of JSR 314 isn't going to capture that level of functionality. In general, that type of feature is left to component developers. This is because we don't want the spec to limit creativity and instead encourage component developers to create creative and exciting components. Also, it takes time to define and implement any new feature, and developing a large set of "standard" components would detract time spent on other areas of the spec. Instead we have been trying to look at how to standardize Ajax API's, how resources are defined and served, include a better templating format than JSP (i.e. Facelets), and other high-level problems that will improve JSF 2.0 as a whole.

I should note that I am a member of JSR 314 (JSF 2.0), however, the opinions above are my own opinions, not an official response. I am glad you sent the email to the EG, it is very good to get this kind of feedback so we know what is interesting to JSF users. Thank you!

As for GlassFish plugin wiki pages... I'm on the hook for providing more on this topic, however, here's what you can find today:

http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3AdminConsole -- There's an Open Office presentation on an early proposal on how this would work... much of it is the same, although we're aligning with HK2 to leverage it, so we'll be using its service implementation and annotations.

http://wiki.glassfish.java.net/Wiki.jsp?page=GUIPagesForGlassFishV3TP2 and the task list link show what and when we're supposed to be delivering features. It may not be complete, but will be updated with more detail as we develop.

If you have any comments, ideas, questions, feel free to let us know. I hope you do look into what we've done in GlassFish and that its helpful to you. I'm happy to hear that you are a GlassFish supporter, we greatly appreciate it!!

Thank you!

Ken Paulsen
https://jsftemplating.dev.java.net

 

 

Thanks for the detailed reply. I've talked to a number of developers who aren't interested in JSF because they think it is not good enough on its own until you plug in extra things to "fix" it such as Facelets and Seam. From what I've read JSF 2.0 will "fix" everything.

I think adding support for Struts 2 style processing screen is not a UI component, it is a framework level plumbing feature. It would be a shame to find that out after the spec is complete, then have to wait another three years for the spec to add it. We've already got to wait another year before Java EE 6/JSF 2.0 will be final.

I think application level plugin support is an other framework level plumbing feature. There may be less people using it, but if it was there then more people might start developing web apps that can use plugins (ex: JIRA). I honestly don't know much about this topic or even how Struts 2 does it, but I do know that I was thinking about using Struts 2 for an upcoming project that will require plugins until I found this thread. I've got a Struts 2 book in hand because it is production ready today. I can use those features today.


Thanks,
Ryan

 

 

I'm not sure JSF 2.0 will "fix everything." Which is why one of the strong features of JSF is its ability to easily customize it / extend it. If JSF waited for features like "Facelets" and "Seam" to be thought up and refined, JSF would still be in 1.0 draft. :) So I very much hope new projects will popup that address new needs and old projects will continue to evolve and add value.

That said, I do hope JSF 2.0 standardizes on as much as is helpful to ensure JSF developers are able to get their work done much more easily and that different component sets and frameworks work seamlessly together.

I will think more about the "processing screen." I suspose it could be implemented in a way other than a component. Although I could implement this with JS alone on the client-side... or I could cause the server-side to redirect to show the processing page, then redirect again when the processing is complete. Both of those scenarios could be easily implemented today as a JSF component. Although perhaps if you want to add this feature via a Navigation rule, or if you want Java api's to query the status of the processing (and you don't want to hang those off a custom component)... then perhaps it could be implemented by the framework.

As for application-level plugin support. I agree, this is a framework feature. I'm not opposed to adding it (as I'm obviously doing this type of work today), but I'm not sure if it will make it into the spec in time, unless we rushed it in which might hurt its quality. I think type of feature might best be developed as its own JSR, or open source project... perhaps not even specifically tied to JSF. Then it could be used with any version of JSF, and perhaps non-JSF applications, and could be considered for a future version of JSF. Although I do agree with you... it would be nice if it were there available as a standard JSF feature today.

Thanks again for all your input!

Ken Paulsen
https://jsftemplating.dev.java.net

 

 

Thanks, I'm happy to hear you open to these suggestions. For some ideas on the processing screen, have a look at WebWork's Execute and Wait Interceptor:

http://www.opensymphony.com/webwork/wikidocs/Execute%20and%20Wait%20Interceptor.html



Thanks,
Ryan

 

 

Hi Defrian,

I developed the JSF plugin API of flexive (mentioned in the first reply).

As Ken Paulsen said, JSF is already well suited for plugins - once you place a faces-config.xml in a JAR file, it will be autodetected by the JSF runtime. This means you can add managed beans, components, validators, and renderers to an application simply by adding a JAR file to its classpath (which is how JSF component libraries like Tomahawk work).

However, for full plugins which also include HTML pages and templates, as well as other resources like stylesheets and scripts, plain JSF won't suffice.

In flexive, we use two additional frameworks to enable plugins that can contain JSF components, actual web pages, and web resources: Facelets and Weblets.

Facelets is well-known as a XHTML view building technology, but it has a second advantage: it is possible to load XHTML pages (and component templates) from the classpath, i.e. a JAR file, through a minor extension of the resource resolver [1]. This also enables you to use these pages in JSF navigation rules declared in your plugin's faces-config.xml. Facelets' .taglib.xml files are used to declare tags based on templates served from the JAR file.

Weblets [2] serves static resources like images, scripts and stylesheets from the classpath. You store the files anywhere in your JAR file, add a weblets-config.xml to your JAR file (which will be autodetected as well), and then reference resources through a weblet:// URI which will be resolved by the Weblets view handler. Weblets also generates version-based URIs: the software version is automatically encoded in the resource URL, which greatly simplifies caching of those files.

Overall, while there are some major obstacles in building "configuration-free" plugins with JSF, it is certainly possible and works quite well. One thing we haven't been able to solve is hot deployment, since it would require a reset of the JSF runtime environment.

If you have additional questions, feel free to ask.

Regards,
Daniel Lichtenberger
\[fleXive] core developer
http://www.flexive.org
--
UCS - unique computing solutions gmbh
http://www.ucs.at

[1] http://source.flexive.org/browse/~raw,r=271/fleXive/trunk/src/ui/jsf-components/src/java/com/flexive/faces/ClasspathResourceResolver.java
[2] https://weblets.dev.java.net/

 

 

Thanks Defrian for the interesting information. We know that JSF 2.0 will have a Facelets-like view technology built in. Would you say that the new Resource feature in JSF 2.0 [1][2] is like Weblets? If yes, it sounds like a lot of what we need to build an application plugin will be built-into JSF in the future.


Thanks,
Ryan

[1] http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature5
[2] http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature

 

 

Ryan,

JSF 2 will allow you to serve arbitrary resources from the classpath. I'm not familiar with all the features of Weblets, but what Daniel described sounds very similar to what will be supported. JSF 2's resource handling will not only serve resources, but will help generate the html necessary to request them, including placing it at the appropriate place within the page (head, or end of the body, etc). I will ensure the same JS resource isn't requested multiple times, etc. Weblets may do a lot of this today, not sure. There are other frameworks besides weblets available that also support some of these features for serving resources like: Shale Remoting, JSFTemplating (FileStreamer), Mojarra Scales, and probably most component libraries (I know Woodstock has its own). This is why this issue was a priority to standardize in JSF 2.0.

Daniel,

I just looked a the fleXive web site -- I'm impressed. I like fleXive's overall approach to building an application, it looks like it solves a lot of the infrastructure that many applications need to get going quickly. I also like that you have documentation on how to get started with fleXive using GlassFish. ;) In fact your documentation in general was very good.

The plugin API was good for a generic Java API-level plugin infrastructure. However, unlike most other parts of fleXive, it didn't seem to have higher-level concepts. What we're working on in GlassFish is to provide page-fragement types of integrations, where you will be able to add a new Tab using a page fragment. Our plugin API will reflect this. We also have meta data associated with our plugin that will help the plugin consumer prioritize the different plugins and know more about how to deal with it. I know your plugin api can do all of these things, but its left up to the interface creator and implementor to work out the details. It would be nice to see some of this specified and infrastructure to support it built up around it.

Also, you might want to consider taking a look at what HK2 has done wrt to defining a generic API (@Contract) and providing an implemenation to it (@Service) (https://hk2.dev.java.net/components.html). This is very similar to what you've done, however, I think what HK2 has done simplifies it and is very innovative. To get a list of "plugins" that implement a particular interface, in an HK2 environment you'd do:

@Inject MyPluginInterface [] plugins;

That's all. I think this type of system is very doable within fleXive and might be a nice addition.

Daniel, if you're interested in added JSFT support to fleXive, let me know and I can help you test and/or integrate it.

And finally, I should mention that JSFTemplating provides loading resources (JS, Images, css, anything) out of a jar file, it also allows pages (its own format or Facelets) out of an jar file. This would give you the ability to add pages w/ resources simply by dropping a jar file into the app. It also supports a dynamic include feature (based on <ui:include>) which tags a flag to make it fail silently if the content doesn't exist... this allows you to look for pages fragments that might be "plugged-in" to your application so you can extend a page to reference additional content in the future. All this is included in JSFTemplating virtually out-of-the-box. Even with all of these features, I don't consider this a complete plugin solution -- not like what we'll provide in GF v2 anyway.

Good luck!

Ken Paulsen
https://jsftemplating.dev.java.net

 

 

Hi Ken,

thanks for the encouraging words! We'd be definitely interested in adding JSFTemplating support to flexive. The "JSF Plugin API" linked in the first reply was meant to be exactly what you said: a rather low-level API for extending code through extension points. It's not vital to building what we call "flexive components", since most of the functionality is already provided by JSF, Facelets and Weblets. Currently the plugin API is used for adding menu items and buttons to the flexive backend application. HK2 seems to solve the same problem in a more sophisticated way. It just never popped up on our radar when we looked for a generic plugin API, and other solutions seemed to be too heavy-weight. Would be a nice extension as well.

I'm off to a skiing holiday next week, but I'd really like to take you up on your offer when I'm back.

Kind regards,
Daniel Lichtenberger
\[fleXive] core developer
http://www.flexive.org
--
UCS - unique computing solutions gmbh
http://www.ucs.at

 

 

HI Daniel,

I hope you had a great ski trip! Please feel free to get in contact with me. I can be found on IRC at irc.freenode.net, #jsftemplating. Or you can send me an email.

Thanks!

Ken Paulsen
https://jsftemplating.dev.java.net