JBoss Portal

Most impressive Javascript I've ever seen

noreply@blogger.com (Julien Viet) — Tue, 15 Jul 2008 22:10:00 +0000

When I was a kid, I spent lot of time coding on my Amiga 500 visual effects called demos. I had much fun with demos and it was a great way to learn coding. I still spend a bit of my time to look at the actual productions or read technical articles on demo effects.

It's very boring to use a technology to do what it is designed for. Abusing the browsers DOM + Javascript is also something possible but very hard to achieve. Why ? because browsers are designed to display styled boxes and text and nothing else. For instance, drawing a line or a bitmap is very hard to achieve without dirty tricks that are very expensive to perform, think of implementing the Bresenham line algorithm to draw a line using the DOM as a rendering technology.

I found in the past a few abuse of DOM+JS that went in that direction such as "Super Mario" remakes, but I was not much impressed... until today!

The demo is called Neja and it's coded by Ribon and Bomb! Even my Macbookpro finds it impressive because it really excites the laptop's fan :-) . It worked well only in Firefox and in did not work fully in Safari. You can check it online here, enjoy!

Daiwa Securities America customer reference

noreply@blogger.com (Thomas Heute) — Mon, 14 Jul 2008 13:54:00 +0000

It's pretty difficult to get large customers to talk about their usage of JBoss Portal. Luckily, Daiwa Securities America accepted, and I can't be thankful enough.

Here is the full reference.

I picked the best extracts here:

Daiwa Securities America Inc., one of Japan's largest securities brokerages with a focus on sales and trading of Japanese and U.S. Equities and fixed-income instruments, financial futures and investment banking, has migrated from proprietary solutions to JBoss Enterprise Application and Portal Platforms. As a result, Daiwa has cut application development time in half, dramatically improved application performance and saved over $300,000 in licensing and hardware costs.

With some previous experience with JBoss solutions, Daiwa first downloaded a free version of the JBoss.org Portal project. Recognizing the mission-critical nature of the DSAweb portal, Daiwa quickly purchased a subscription to the JBoss Enterprise Portal Platform to benefit from the stability and reliability of an enterprise-class platform including support, patches and updates.

With JBoss solutions, Daiwa employees are more productive with faster portal application loading time, developer productivity has increased with the ease of development on open source solutions and JBoss support from Red Hat has been fast and reliable.

If you also have success stories to share (publicly or not), please let me know (thomas.heute@jboss.com).

JBoss Portal 2.7 Alpha released

noreply@blogger.com (Julien Viet) — Tue, 08 Jul 2008 11:27:00 +0000

We have just released the alpha version of the upcoming of JBoss Portal 2.7 release that brings the Portlet 2.0 features to our mainstream product JBoss Portal.

The JBoss Portlet Container technology is included in this release and provides an out of the box support for the JSR 286 features such as:

Portlet eventing
Public pararemers
Resource serving
Portlet filters

Our admin tool has been upgraded as well to support JSR 286.

Enjoy the release, you can get the files from the download page as usual!

JSF in a portlet has never been this easy!

noreply@blogger.com (Wesley Hales) — Mon, 07 Jul 2008 13:18:00 +0000

We just released JBoss Portlet Bridge Beta3 along with some good supporting documentation and example projects. See the documentation for full details.

The majority of the code written for this release is internal to the portlet bridge project (refactoring, 301 spec updates and enhancements, bug fixes...). The next release (Beta 4 - early Sept) will be huge for the portlet bridge for the following reasons:

The EG is currently discussing a lot of significant clarifications and improvements. For example, working with the JSF 2.0 EG to allow certain needs and working on Portlet 2.0 areas of the spec.
There is currently a lot of discussion about navigation between portlet modes. Once this is nailed down in the spec, we will implement it.
The Portlet 1.0 version should be getting close to public review.

Other than the spec related reasons for release schedule, we must work in unison with the latest Seam and RichFaces relases, make sure that we squash any bugs concerning the 3 integration points, handle features/improvements/refactorings, and try to test and give feedback to the 301 EG. And, of course we can't forget about JBoss Portal 2.7+!

There are soo many cool things going on right now within the JBoss Portal project, I would like to tell you about all of them but then this post wouldn't be about JBPB anymore. Just stay tuned to this blog...

With that said, here are a few tips for JSF portlet developers that concern this release:

Namespacing
In situations where you need to use the id of an element in your JSF/xhtml markup, you would normally see something like 'form1:myBtn' in the rendered markup. But now with the bridge namespacing you will see something similar to:
jbpns_2fdefault_2fNews_2fStories_2fStoryTemplateWindow12snpbj:_viewRoot:form1:myBtn
To overcome this, you can use the following expression in your Facelets page to prepend the namespace to your javascript code:
document.getElementById('#{facesContext.externalContext.response.namespace}the_rest_of_JSF_ID
since this uses the portletResponse, once you try to view this page on the servlet application side, you will get an exception. To avoid this, you need to check for the type of response in your backing bean and assign a new "safe" namespace variable for the UI.
Excluding Attributes from the Bridge Request Scope
When your application uses request attributes on a per request basis and you do not want that particular attribute to be managed in the extended bridge request scope, you must use the following configuration in your faces-config.xml. Below you will see that any attribute namespaced as foo.bar or any attribute beginning with foo.baz(wildcard) will be excluded from the bridge request scope and only be used per that application's request.
```
<application>
     <application-extension>
         <bridge:excluded-attributes>
             <bridge:excluded-attribute>foo.bar</bridge:excluded-attribute>
             <bridge:excluded-attribute>foo.baz.*</bridge:excluded-attribute>
         </bridge:excluded-attributes>
     </application-extension>
    </application>
```
Or you can use the javax.portlet.faces.annotation.ExcludeFromManagedRequestScope annotation to accomplish the same thing.

For more information on this release or to find out more about the project, visit the project page.

JBoss Portal on Amazon EC2

noreply@blogger.com (Prabhat Jha) — Tue, 17 Jun 2008 20:22:00 +0000

With the announcement of availability of JBoss Enterprise Application Platform (EAP) on Amazon Elastic Compute Cloud (EC2), it was logical for us to verify that JBoss Enterprise Portal Platform can also be deployed on EC2. For those who are not familiar with EC2, EC2 basically provides you a resizable compute capacity and you only pay for the resources (CPU, Memory etc) you use.

Once you have a JBoss EAP image on EC2, deploying JBoss Portal is like a walk in the park. All you have to do is to copy jboss-portal.sar and database descriptor to deploy folder of your server configuration. We successfully ran the complete JBoss Portal testsuite as well as tests that we perform as part of release testing. Only extra configuration that we had to do was to bump up the heap size for ANT otherwise it gave OOM error while generating reports. :-)

Feel free to let us know your experience with JBoss Portal on EC2. Mine was certainly good.

Note: At present, only JBoss EAP image is hosted on EC2. JBoss EAP bundled with JBoss Portal will be available in future.

JBoss Portlet Container 2.0 GA Release

noreply@blogger.com (Julien Viet) — Fri, 13 Jun 2008 17:00:00 +0000

The JBoss Portal team is very proud to announce the release of the JBoss Portlet Container 2.0 product.

The release is a fully compliant implementation of the Portlet 2 (JSR286) specification, which was released yesterday.

JBoss Portlet Container 2.0 comes with a lightweight portal based on JSP tags and comes bundled with a few demonstration portlets. The goal of that lightweight portal is to provide developers with an easy way to showcase and test their portlet applications. It should work well with other JSP taglibs and templating frameworks.

It provides advanced functionalities:

Administration application which provides an overview of the deployed applications / portlets / filters and management of their life cycle. Failed portlets or filters can be restarted or stopped when needed.
Event debugger which should prove very userful to understand complex event interactions.
Event flood detection to prevent events from running wild.
Management of life cycle dependencies between portlet filters and portlet container: if a portlet filter fails and is stopped then all the portlet containers dependent on that filter will also be stopped (otherwise it would obviously result in an incorrect application).
Optimized event payload marshalling: when an event with an object payload is fired from application A to application B, the event will be unmarshalled/marshalled between the two applications classloaders (otherwise it would result in a class cast exception) unless the event class is shared at the server level, in which case the event can be safely transported across application borders.

The next major release of our mainstream portal product JBoss Portal 2.7 will bundle the JBoss Portlet Container.

You can download the release from our project download page.

JBoss Portal @ Rotterdam JBug

noreply@blogger.com (Julien Viet) — Tue, 10 Jun 2008 21:39:00 +0000

The Rotterdam JBug is happening June 20th, Thomas and myself will be there to talk about Portlet 2.0 and the upcoming JBoss Portal 2.7 release. We'll give also a quick overview of the future releases.

The Benelux JBoss User Group is organizing an event on Friday June 20th 2008. There will be plenty of presentations:

JBoss Portal - Julien Viet and Thomas Heute - JBoss
Hibernate Search - Emmanuel Bernard - JBoss
Woman in IT - (special guest presentation) Clara Ko and Linda van der Pal - jduchess.org
JBoss Drools - Kris Verlaenen - JBoss

Here is more information, it's free of course but you need to register.

How to get the tag name of a DOM element with GWT?

noreply@blogger.com (Julien Viet) — Tue, 10 Jun 2008 21:14:00 +0000

Surprisingly it is not possible to get the tag name value of a DOM element through the GWT API. For instance for a DOM element of a form, I would like to get the "FORM" string as a result.

Obviously it is possible to come with its own solution using the JSNI (java script native integration) and return the nodeName attribute of a DOM element, here is what I wrote:

public class Utils
{
/**
* Returns an element tag name.
*
* @param element the element to obtain the tag name from
* @return the tag name value
*/
public static native String getTagName(Element element)
/*-{
// It should work with all browsers, if it does not, replace that with more appropriate code :-)
return element.nodeName;
}-*/;
}

There is probably a good reason explaining why it is not possible to get such a value, but for now it is unknown to me.

Can the Servlet 3.0 improve the development of Portlets?

noreply@blogger.com (Julien Viet) — Sun, 01 Jun 2008 18:55:00 +0000

I recently looked at the Java 3.0 API slides for JavaOne in order to catch up with what the expert group will provide in the next release of the spec. As a portlet container architect it is important to provide feedback to the expert group.

One of the challenge of developping and maintaining a portlet container is the capability to detect deployment of portlets and create associated portlet containers. Portlet are plain java classes in a war file, the main problem is to have the portlet container to be aware of the war file deployment life cycle in order to create / destroy the associated containers.

Another challenge is to have the capability to request dispatch to a war file from another a serviced request. This can only be done if a special servlet is added to the portlet application war file. So when a portlet application is deployed, the resulting web application must contain the special portlet container servlet. It is pretty much similar to:

public void service(HttpServletRequest req, HttpServletResponse resp) throws IOException, ServletException
{
// We access the context of the portlet application foo
ServletContext fooCtx = getServletContext().getContext("/foo");

// We obtain access to a servlet that will execute the portlet container
// It is important to request dispatch in order to do important stuff such
// as using objects from the foo application such as the http session or
// to have the thread context classloader of the foo application
RequestDispatcher rd = fooCtx.getRequestDispatched("/bar");

// We do an include but it should not modify the response (of course it depends on the implementation of
// the container / portal ...)
rd.include(req, resp);
}

We are able to provide solutions with different strategies, thanks to a framework that abstracts the various operations required by the portlet container and we have a couple of implementations.

We have one strategy that contains tomcat specific code and is able to detect application life cycle and modify it in a fully transparent manner. This is great for the developer as it does not require *any* modification of the portlet application, but this comes at the price of having code depending on tomcat, which is fine because tomcat is open source and we can integrate with it.

We also have a generic strategy that requires the portlet application developer to modify its war file and update the web.xml file to add a special servlet that will do all the magic. This is fine for development but this is a bit problematic when you download a thirdparty portlet application and deploy it because this forces you to edit the war file and modify it before deployment. Here is an example of what needs to be added to the war file:

<web-app>
...
<servlet>
<servlet-name>BootstrapServlet</servlet-name>
<servlet-class>org.jboss.portal.web.impl.generic.GenericBootstrapServlet</servlet-class>
<load-on-startup>0</load-on-startup>
</servlet>
...
<servlet-mapping>
<servlet-name>BootstrapServlet</servlet-name>
<url-pattern>/jbossportlet</url-pattern>
</servlet-mapping>
...
</web-app>

The nirvana is the fully transparent deployment of a portlet appliction and we are not yet there with the Servlet 3.0 spec... But the good news is that we are not far!

First the expert groups recognizes the need of the capability to modify of servlet context by providing runtime operations that will allow the addition of new servlets and create mappings dynamically:

...
servletContext.addServlet("BootstrapServlet", "The bootstrap servlet", "org.jboss.portal.web.impl.generic.GenericBootstrapServlet", null, -1);
servletContext.addServletMapping("BoostrapServlet", new String[]{"/jbossportlet"});
...

That would allow to replace the bootstrap servlet with a servlet context listener, which improves a bit the generic solution but is not yet fully transparent.

The second new feature that improves the generic solution is the modularization of web.xml, a new form a pluggability that allow to define servlets outside of web.xml in XML fragments. It is designed for frameworks. That should allow the packaging of the bootstrap servlet context listener (since now the listener could inject the servlet) in an xml fragment outside of web.xml and would allow to minimize the amount of work to do. Such xml fragments are located in the META-INF directory of any jar file bundled with the web application.

So what would become our generic implementation ? It would come as a jar file that would contain only the web xml fragment (because any portlet container classes have to be shared between all web applications...) that would be bundled in the WEB-INF/lib of the portlet application.

So we have a better generic solution now but it is not yet perfect. The expert group recognize there is a need for the various frameworks out there (even if the portlet container stuff is a special kind of framework, because of its cross context nature). When the Portlet expert group will work on a new revision of the spec, it would be great to have a solution to this problem so the Portlet spec could leverage it to provide a portable universal solution.

Personally I have a couple of suggestions in mind, I will try to blog them in the near future and maybe we could work out something with the Servlet expert group.

JBoss Portal 2.6.5.GA released

noreply@blogger.com (Thomas Heute) — Tue, 13 May 2008 12:29:00 +0000

The latest minor release of JBoss Portal has just been released.
This is a bug fix release, here is the full release note.
Grab it while it's hot and don't hesitate to report issues in the forums.

Thanks for the feedbacks we got on previous releases !

When will Sun acquire Liferay ?

noreply@blogger.com (Julien Viet) — Thu, 08 May 2008 11:38:00 +0000

I have been told last night about that announcement: In a few words, Sun and Liferay are collaborating on a common set of components that will be reused by both platforms.

To me it's a perfect admission of two facts: Liferay failed at implement new technologies such as JSR286 and Sun failed at creating an ubiquitous and visible version of their portal.

Liferay benefits from Sun technologies that they were not able to implement due to the huge legacy of their code base. Brian admitted it publicly in a post ("we are not smart enough, we don't have enough man power, and we don't have enough energy to build an innovative product").

Sun on its side distributes a rebranded version of Liferay and kills its existing portal. Why ? Sun open portal is too tied to the operational environment and their identity management product (read here big fat momma). Sun realized that they wouldn't be able to increasing their product visibility while making it more adaptable to more diverse environments.

The real question on everyone's mind though is: why is Sun moving in this direction now? in my opinion most of the benefit goes to Liferay, so the hypothesis that Sun could acquire Liferay seems very valid to me even if the announcement claims it won't happen ("No, there are no plans for an acquisition.") and Sun does not yet have vested interests in Liferay. We can see this as a last attempt from Sun to revitalize their portal offering by trying to quickly leverage Liferay's community. Will this work for either side of this partnership? Only time will tell...

At least I am not wondering anymore about why our proposals submitted to JavaOne have been refused :-)

JBoss Portal presentation

noreply@blogger.com (Thomas Heute) — Mon, 05 May 2008 13:58:00 +0000

Tomorrow (May 6th) I will present JBoss Portal at the Zurich JUG, so if you are around feel free to come. It's free and it comes with some drinks (after the talks). (There will also be a presentation of WebSphere Portal just before)

Here are the details.

GWT hosted mode on Leopard tip

noreply@blogger.com (Julien Viet) — Sun, 04 May 2008 12:04:00 +0000

If you are experiencing issues when running GWT in hosted mode on Leopard it is normal.

There are a few issues in the official release of GWT and Java implementation on Leopard that prevent to execute the hosted mode runtime on Leopard (but the rest is fine). Basically the hosted mode runtime pops up and just quit a couple of seconds after.

So you need to download a patched version of GWT for Leopard, you can read more about it on this thread on GWT forums which is *the* thread to follow.

GWT in-place-editor

noreply@blogger.com (Julien Viet) — Sat, 03 May 2008 10:56:00 +0000

The in place editor is one of the simplest yet powerful feature brought by Ajax.

I wrote two such editors last year, one using javascript and one leveraging Prototype as an exercise. Recently I started to study GWT more in depth and I found fun to write a GWT version of the in place editor.

I used the TextBox and Label widgets that will be used to display and edit the label.

The DeckPanel panel is used to alternate the display between the text box and the label widgets.

The interaction is performed using listeners. The ClickListener on the label copies the label value to the text box and switch the deck panel to show the text box. The KeyboadListener allows on the enter keystroke to copy the edited value to the label and switch back the deck panel to show the label.


public void onModuleLoad()
{
  final DeckPanel deck = new DeckPanel();
  final Label label = new Label("Initial Value");
  final TextBox text = new TextBox();

  // Wire the widgets
  deck.add(label);
  deck.add(text);
  deck.showWidget(0);

  //
  label.addClickListener(new ClickListener()
  {
     public void onClick(Widget widget)
     {
        String value = label.getText();
        text.setText(value);
        deck.showWidget(1);
        text.setFocus(true);
     }
  });

  //
  text.addKeyboardListener(new KeyboardListenerAdapter()
  {
     public void onKeyPress(Widget widget, char c, int i)
     {
        if (c == KEY_ENTER)
        {
           String value = text.getText();
           label.setText(value);
           deck.showWidget(0);
        }
        else if (c == KEY_ESCAPE)
        {
           deck.showWidget(0);
        }
     }
  });

  //
   VerticalPanel vp = new VerticalPanel();
   vp.add(deck);
   RootPanel.get().add(vp);
}

The demo is available here.

JBoss Maven repository mess

noreply@blogger.com (Julien Viet) — Sun, 20 Apr 2008 16:09:00 +0000

So if you want to use the JBoss Logger wrapper you need

for 2.0.2.GA or 2.0.3.GA : use jboss:jboss-logging-spi
for 2.0.4.GA : use jboss:jboss-common-logging-spi
for 2.0.5.GA : use org.jboss:jboss-logging-spi

Yes I am bitching about that :-)

I leave the location before 2.0.2.GA as an exercise to the reader.

Let's hope that for versions above 2.0.5.GA, it will remain the same.

JBoss Portal Face To Face Meeting #1

noreply@blogger.com (Julien Viet) — Fri, 18 Apr 2008 21:19:00 +0000

In May (13-15) the JBoss Portal team will be gathered for its first face to face meeting. I need to tell that I am very excited about it!

The team will be gathered for one week in Corsica where I grew up when I was a teenage and where my parent still live.

I managed to find a unique place on the island (note to my manager: that fits in the meeting budget of course) that will offer us an ideal place for our brainstorming sessions. I was in Corsica last week and I visited it and I must admit I was very impressed. The landlady is going to lend us the main room for our meetings and there is obviously WIFI access for the geeks we are.

The meeting occurs at the right moment as we have started to transition from JBoss Portal 2.6 to JBoss Portal 3.0: last year we started the modularization of the project that gave us the great JBoss Portlet Container product and the new Presentation Framework project and we are on the path to bring those new technologies in our main stream product JBoss Portal 2.7 and 2.8. The meeting will be a good occasion for me to share my view with the whole team and also to discuss about various topics such as security, identity and social aspects of portals, the JBoss Portlet Bridge project.

welcome to Corsica!

JBoss Portlet Bridge Beta2 Released

noreply@blogger.com (Wesley Hales) — Thu, 10 Apr 2008 13:04:00 +0000

Supports:

JBoss Portal 2.6.4
Seam 2.0.2.CR1
RichFaces 3.2.0.GA (with exception of upload component)
JSF 1.2

This release of the bridge has quite a few bug fixes and enhancements:

Portlet EL Variable support
New SeamIdentity Bridge Extension: instant SSO between your Seam application and your JBoss Portal server by a simple dependency in your pom
RichFaces Maven Archetype
Removal of PortalStateManager configuration
More documentation

EL Variable Support

portletConfig: object of type javax.portlet.PortletConfig

sessionPortletScope: mutable Map containing PortletSession attribute/values at PORTLET_SCOPE.

sessionApplicationScope: mutable Map containing PortletSession attribute/values at APPLICATION_SCOPE.

portletPreferenceValue: immutable Map containing the set of portlet preferences where the key is the name of the preference and the value is the first portlet preference value from the (potential) set of values.

portletPreferenceValues: immutable Map containing the set portlet preferences where the key is the name of the preference and the values are the set of this portlet preference's values.

SeamIdentity Bridge ExtensionJust add the following dependency to your JBoss Seam (Maven) project for SSO between JBoss Portal and Seam applications.

<dependency>
<groupid>org.jboss.portletbridge.extension.seam</groupid>
<artifactid>PortalIdentity</artifactid>
<version>1.0.0.B2</version>
</dependency>

RichFaces Maven Archetype
This is the new Beta2 release of the RichFaces archetype - only a few settings are different from the previous snapshot release.

mvn archetype:create
-DarchetypeGroupId=org.jboss.portletbridge.archetypes
-DarchetypeArtifactId=richfaces-basic
-DarchetypeVersion=1.0.0.B2
-DgroupId=org.whatever.project
-DartifactId=myprojectname
-DremoteRepositories=http://repository.jboss.org/maven2/

Removal of PortalStateManager configuration
The following is no longer needed in the faces-config.xml

 <state-manager>
org.jboss.portletbridge.application.PortalStateManager
</state-manager>

Visit the Portlet Bridge project page for more details.

JBoss Portlet Container 2.0 Candidate Release 2

noreply@blogger.com (Julien Viet) — Mon, 31 Mar 2008 13:45:00 +0000

We have just released the candidate release 2 of the JBoss Portlet Container project.

Since the candidate release 1 we added an administration portlet that can manage the life cycle of the deployed applications and containers.

We have also added a very useful event debugger that can help developers to understand the event flow distributed among the different portlets during the interactions an event phase.

You can download the release from our project download page.

JBoss Portal 2.7 status

noreply@blogger.com (Julien Viet) — Fri, 28 Mar 2008 21:27:00 +0000

I want to give our community an overview of the JBoss Portal 2.7 development status.

The good news is that the JBoss Portal 2.7 branch reached what I call the Milestone 1 which consist in the integration of the JBoss Portlet Container 2.0 with the same level of functionality than the current 2.6 product. Thomas and Chris were the main drivers in that effort and did a very good job.

We are heading now toward the Milestone 2 with the following simple goals:

Integrate the controller module of the JBoss Portlet Container: it allows to perform complex event interactions between portlets. Actually this is the integration point that the JBoss Portlet Container provides to the portal in order to integrate its event routing and transforming logic. There is a very simple implementation in the JBoss Portlet Container simple portal that uses a matching event routing algorithm, simple yet sufficient for the simple portal, right?

Provide JSR 286 Portlet runtime meta data overview through the administration portlet. The administrator is able to know about the coordination capabilities offered by a portlet such as the event it produces and the event it consumes.

I will talk briefly about the Milestone 3 and will probably give more update about it when Milestone 2 will be reached:

Define the coordination feature support, the event routing models and the portlet parameter sharing model
Support for new JSR 286 state in portal URLs, mostly about support of public navigational state changes in the URLs
Resource serving support

That's it for now, the entire team is focusing on reaching Milestone 2 very soon!!!!

JBoss Portal Summer of Contribution

noreply@blogger.com (Julien Viet) — Thu, 27 Mar 2008 10:13:00 +0000

Thanks to Bob, JBoss is a mentoring organization for the Google Summer of Code 2008.

We have created a few JBoss Portal related subprojects for that matter:

Content Clipper: Thomas started a few weeks ago a prototype of a web clipping engine that is able to integrate with different kind of content providers such as a remote web page, or a request dispatch into another application deployed in the same server. The goal is to transform the prototype into a project consumed by JBoss Portal.
Web SPI implementations: we have developed a Web Service Provider Interface (SPI) that allow our latest product JBoss Portlet Container to be executed in any servlet container in a reliable manner. The student would develop implementations of the Web SPI implementations in order to integrate with additional servers.
Dashboard system improvement: that project is focused on upgrading the portal object implementations (portal, pages, portlet windows system) in order to support additional page models that would allow to mix shared portlets with dashboard portlets.
OpenID integration: extend the current portal SSO integration (CAS, JOSSO, OpenSSO) by providing an OpenID authentication implementation.

The different items are also described in our GSoC page here. If you are a student and you want to be involved in the JBoss Portal project, this is a very good opportunity for you to contribute to the project and join us!

JBoss Portal talk at Austin JUG

noreply@blogger.com (Prabhat Jha) — Wed, 19 Mar 2008 15:23:00 +0000

I will be giving a presentation and demo of JBoss Portal at Austin JUG on March 25.

The talk starts at 7:00 PM. It's free to everybody so if you are in the neighborhood, please feel free to stop by. See you there.

RichFaces Portlet Archetype

noreply@blogger.com (Wesley Hales) — Wed, 12 Mar 2008 10:30:00 +0000

I just finished creating a Maven archetype for the RichFaces portlet using the JBoss Portlet Bridge. An archetype basically gives you a empty project shell with all of the proper config files and package names that are custom to your project. It comes packaged with a simple demo of the RichFaces ajax repeater code.

From the command line run:

mvn archetype:create -DarchetypeGroupId=org.jboss.portletbridge.archetypes -DarchetypeArtifactId=richfaces-basic
-DarchetypeVersion=1.0.0-SNAPSHOT -DgroupId=org.whatever.project -DartifactId=myprojectname
-DremoteRepositories=http://snapshots.jboss.org/maven2/

Navigate to the newly created project folder and run mvn install - now you are ready to deploy the war file located in the target directory.

The Rise of the Portlet Containers

noreply@blogger.com (Julien Viet) — Mon, 10 Mar 2008 09:20:00 +0000

So now that the Portlet 2.0 spec is approved, it is very interesting to watch the evolution of the OSS market since the Portlet 1.0 spec.

The most noticeable change is the projectization of the portlet container technology. (I will not use the word productization because some of the projects release a complete product and some just make a dump of the source code of the project). 4 years ago the only standalone portlet container was Pluto (the Reference Implementation) and today there is an avalanche of at least 4 portlet container projects (including our JBoss Portlet Container product).

So the question is why do we have so many open source portlet container projects ? because a portlet container is an important piece of a portal and every one wants to develop its own portlet container ?

I think it answers partially the question. If you look a bit more closer at the portlet container technology, then you will see that there is an obvious lack of standard for embedding a portlet container in a portal, i.e a portal needs to chose a portlet container and use its proprietary API to interact with the container. Indeed the portlet specification does not specify that contract because this is the scope of the WSRP spec. As of today if a portal wants to reuse a portlet container in a portable manner, that portal needs to talk WSRP and nobody wants to do that!

So the rationalization of the market could drive to the adoption of a portal spec. It would provide the minimum basis to create a "Portal" profile in Java EE (which is today an hot topic!). Without a portal spec, I don't see any chance to have the portlet container technology part of Java EE.

JBoss Portlet Container 2.0 Candidate Release 1

noreply@blogger.com (Julien Viet) — Wed, 05 Mar 2008 23:54:00 +0000

I just released the first candidate release of our portlet container product with a few additional features since the beta:

documentation : a product would not be a product without a documentation. The documentation has improved since the beta and now we have a complete section on the portal taglib and much more.
optimized event payload marshalling : when an event with an object payload is fired from application A to application B, the event will be unmarshalled/marshalled between the 2 applications classloaders (otherwise it would result in a class cast exception) unless the event class is shared at the server level (optimization).
life cycle dependencies between portlet filter and portlet container : if a portlet filter fails and is stopped then all the portlet container dependent on that filter will also be stopped (otherwise it would result obviously in an incorrect application).
administration application which provides an overview of the deployed applications / portlets / filters and management of their life cycle. So it is possible to restart a failed filter or portlet, or stop them when necessary.
event flood detection : in order to prevent event flood situations

The next release candidate release will probably be done once the public final draft of the spec is available on the JCP site and it should be a certified release.

We should add an event debugger that would help portlet developers to get the reporting of the event phase for debugging purpose. What a great addition to the product!

We'll blog soon about the integration roadmap of the portlet container product in our next release of the mainstream branch: JBoss Portal 2.7!!!!

Portlet 2.0 specification is approved

noreply@blogger.com (Julien Viet) — Wed, 05 Mar 2008 10:55:00 +0000

The spec has been approved on Monday, congratulations to the Expert Group led by Stefan Hepper!!!

You can expect the public final draft to follow soon and we'll do a release of our new product JBoss Portlet Container very soon!!!