Showing posts with label dev. Show all posts
Showing posts with label dev. Show all posts

Tuesday, August 26, 2008

How to monitor portal session data and replication?

Lately we have been working a lot on improving JBoss Portal's performance and scalability. In this blog, I want to talk about how you can inspect what's in your session and how much data is getting replicated when a request is made to your portal deployment.

You can not get hold of HttpSession object in your portlet. To get hold of HttpSession object, either you write your custom interceptor or a filter. What you have is access to PortletSession object through getPortletSession method of request object where request could be a RenderRequest or ActionRequest. Unfortunately, there is no session.getSize() method which would tell you how big exactly your portlet session is. You would have to enumerate through attributes in session in both PORTLET_SCOPE and APPLICATION_SCOPE, get their values then obtain their size as follow:

Enumeration portletAttribs = session.getAttributeNames();
Enumeration applicationAttribs = session.getAttributeNames(PortletSession.APPLICATION_SCOPE);
ByteArrayOutputStream bs = new ByteArrayOutputStream();
ObjectOutputStream os = new ObjectOutputStream(bs);

while(portletAttribs.hasMoreElements())
{
Object obj = session.getAttribute(portletAttribs.nextElement());
os.writeObject(obj);
}

Similarly you enumerate through attributes in applicationAttribs and add write them to ObjectOuputStream. Then you get the size using:

System.out.println("PortletSession Size is " + bs.size());


The value you get is a close approximation to how big your portlet session is. HttpSession size will be bigger because portal needs to store the navigational state of your portlet/s as well.

Now, let's talk about how much data is getting replicated across your portal cluster. We will find this using JGroups MBean and JConsole which is the Java Monitoring and Management Console graphical tool shipped in J2SE JDK 5.0 and up.

First we need to prep up JBoss so that mbeans are available to JConsole. You can find the details at
JBoss-JConsole wiki. In a nutshell, you need to modiify $JBOSS_HOME/bin/run.conf. Your JAVA_OPTS should look more or less like

JAVA_OPTS="-Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dcom.sun.management.jmxremote -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanSe
rverBuilderImpl -Djboss.platform.mbeanserver"


Start JBoss Portal + JBoss AS bundle. In a separate terminal launch jconsole. You should automatically pick up PID of JBoss instance as shown here. Click Connect.


Now under MBeans tag, select Tree->jboss.jgroups -> protocol->Tomcat-Cluster->UDP as shown below. Here you will see total number of bytes sent and received by a node in cluster.



These Bytes Sent and Received value are for data related to session replication. To see replication data related to the second level cache used by Hibernate in Portal, you need to select
Tree->jboss.jgroups -> protocol->portal.hibernate->UDP

With those tools, you can now make sure that your sessions are not getting too large for the costly session replication on a cluster. You can use and abuse.

Monday, August 18, 2008

Julien Viet's Blog

I just want to signal people reading the JBoss Portal developer's blog that I just opened my official blog. I will share with you topics like portal, portlet, java, lot of cool stuff and my rants.

Wednesday, July 16, 2008

Most impressive Javascript I've ever seen

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!

Tuesday, June 10, 2008

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

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.

Sunday, May 4, 2008

GWT hosted mode on Leopard tip

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.

Saturday, May 3, 2008

GWT in-place-editor

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.

Friday, April 18, 2008

JBoss Portal Face To Face Meeting #1



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!

Monday, March 31, 2008

JBoss Portlet Container 2.0 Candidate Release 2

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.

Friday, March 28, 2008

JBoss Portal 2.7 status

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!!!!



Thursday, March 27, 2008

JBoss Portal Summer of Contribution

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!


Tuesday, February 19, 2008

JBoss Microcontainer usage in JBoss Portlet Container

I planned to rewrite the life cycle support in our JBoss Portlet Container product a couple of months ago, I have started that task for a couple of days. The main reason is the addition of portlet filters which introduce a life cycle of the different container objects a bit more complex than what it used to be in the past.

 The current code only manages the portlet application and portlet container with a trivial one to many relationships between application and container.

 The rewrite will introduce the portlet filter object having a one to many relationship with the application and also a one to many relationship with a subset of the containers according to what the application developer describes in the portlet descriptor file.

 So far we have not used directly any state machine framework to manage that. The main reason is that we use JBoss MC in the JBoss Portlet Container product and we use the good old JBoss Microkernel in JBoss AS 4.2.

 One could argue that I should write my own stuff to manage that. Indeed even if it is not very hard to do and that a set of good test cases would help to achieve something reliable it would miss one crucial feature which is the interaction with the environment. Indeed we need to be able to make a portlet container or a portlet application able to depend on some service for instance and have that dependency managed by the hosting environment.

 Another motivation for the rewrite is to expose outside of the container a set of managed object that represent the applications, the containers exposing only a subset of the concerns:
  • Life cycle management wired to the MC and not directly to the container obviously
  • Expose runtime meta data like portlet info
 In the implementation using JBoss MC, I have been able to simplify a couple of stuff thanks to an interesting feature called deployment callback. It allows to install/uninstall (a special kind of injection but with no managed dependency) all the beans (that's how JBoss MC names its POJO citizens) having a certain class. So this feature allowed me to remove a bunch of wiring code and simplify my stuff.

 The documentation is very good although it is missing some parts, but it's ok as I don't need those part (yet... Mark and Ales if you read me :-) ).

 The integration of our build with Maven improves also a lot about my understanding of JBoss MC, since Idea is able to download sources which helps to understand the kernel API stuff.

 Once I am done with that, I should work on getting the CC/PP portlet feature implemented and than I'll try to upgrade the JBoss MC version to the one matching JBoss AS 5 Beta 4. I'll try to keep you informed about that.

Wednesday, January 23, 2008

Would Eclipse do that ?

I am a big fan of Intellij Idea.

I am using it since version 1.5 back in 2000. At this time I was using JBuilder Community Edition which was a decent IDE (compared to Notepad). When I tried Intellij the switch was obvious and I did it. At this time it was already offering to do a lot of refactorings when other IDE had no a clue of what a refactoring was.

Since then I never used anything else. I am glad that Jetbrains provides to the JBoss Portal project licenses for this great tool (as they do for a lot of other open source projects) and would like to thank them for supporting us.

Anyway, today I refactored a class name from PortalNavigationalState to PageNavigationalState. I had a few other classes that were using that class as a member called portalNS.

When I asked Idea to make the refactoring it asked me if I would like to rename the fields portalNS to pageNS. I don't know how they manage to do that (and I don't care), what matters is that I accepted it.

Would other IDE (like Eclipse) do that ?

Friday, January 11, 2008

How to access the Portlet Mode from a JSF Portlet

We at JBoss a division of Red Hat use Hudson as a Continuous Integration tool. So I thought why not write a portlet that integrates with Hudson. The portlet can be downloaded from Portlet Swap. I ended up using the RI JSF implementation and JSF-Portlet bridge. It took me a while to figure out how to access some portal/portlet related objects in managed bean so I thought I should share what I found out.

To get the portlet mode in JSF's managed bean, you need to do
Object reqObj = FacesContext.getCurrentInstance().getExternalContext().getRequest();
if  (reqObj instanceof PortletRequest)
{
request = (PortletRequest)reqObj;
return request.getPortletMode();
}


You can get PortletPreferences similary by using request.getPreferences().

To get init parameters that you have specified in portlet.xml, you use
Map applicationMap = FacesContext.getCurrentInstance().getExternalContext().getApplicationMap();
if (null != applicationMap)
{
PortletConfig config = (PortletConfig)applicationMap.get("javax.portlet.PortletConfig");
return config.getInitParameter(param);
}


Thursday, November 1, 2007

JSFUnit is born

Well or at least it has its official blog!

I encourage you to have a look at it because it's a real progress in web UI unit testing which allow to test your web UI without relying on the underlying layer (CSS/HTML/HTTP) and make sure that your application behaves correctly when a user interacts with it.

Wednesday, October 24, 2007

JBoss Portal Development Status

We started a few weeks ago big changes in the project codebase with several goals:
  1. Decouple the services consumed by the portal and the portal (life cycle, coupling)
  2. Improve the QA processes
  3. Improve the build system
I chosed to do it at this time because it was just after the 2.6 release and we started to reach some limitations due to the ageing of the build system and the cost of maintaining multiple branches.

We also decided to split the development of the project into 2 directions.

We continue the development of 2.6.x releases with additional features. JBoss Portal 2.x reached its maturity with the 2.6 version and we are going to continue to invest efforts in it. The goal is to deliver time boxed versions of 2.6.x with time frames between 2 and 4 months with emphasis on improving the integration footprint of the portal and the usability. We already provided 2.6.1 and 2.6.2, I can tell you that 2.6.3 is on the rails for December 2007

I asked Thomas Heute (who joined the project a few month after it started, in November 2004 as far as I remember) to lead the JBoss Portal 2.6.x effort and he is doing a great job.

We have started the inception phase of the next generation JBoss Portal 3.0. For now we are focusing on delivering the services that will be used by the platform, it naturally started with the modularization of the existing services (portlet container, identity, etc...) and development of new services such as the presentation framework that will be the next portal front end layer.

The status as of today is that we modularized pretty much everything we wanted (except WSRP and Widget) and we have started the presentation framework development. The portlet container is now agnostic of JBoss AS (thanks to the web SPI module) and can be used in Tomcat or JBoss AS (we are looking forward to support other containers, contributions are welcome here). The mavenization process of the build has started and should be finished soon.

For now we cannot commit to a precise delivery date for 3.0 and I would certainly lie if I would give a precise date. We always have been good at reaching our goals (all the portal releases were done on time or with a couple of weeks of delay, 2.0 June 2005, 2.2 December 2005, 2.4 July 2006, 2.6 June 2007) but for now we are focusing on gathering the necessary components for the 3.0 (presentation framework, security, management, etc...). It comes also from the fact that today 2.6.x has became an integration platform of the different services and 3.0 will follow the same path.

We agreed with our product manager that there will be a JBoss Portal 2.8 release in Q4 2008 that will contain the same feature as 2.6 + the new presentation framework and the implementation of Portlet 2.0 specification (it does not mean that the Portlet 2.0 implementation will not be in JBoss Portal 2.6.x of course!!!).

As usual you can follow our development in the portal development forums.

Friday, June 22, 2007

JSF is great but...

that kind of code does not help to find out why the value was wrong. It is part of the class org.apache.myfaces.renderkit.RendererUtils (1.1.1)


public static Boolean getBooleanValue(UIComponent component)
{
Object value = getObjectValue(component);
if (value==null || value instanceof Boolean)
{
return (Boolean) value;
}
else
{
throw new IllegalArgumentException("Expected submitted value of type Boolean for Component : "+
getPathToComponent(component));
}
}



It's so trivial that I will not submit a patch (perhaps it is already improved now).

It's an half rant, Thomas will do a full JSF rant next week when he will tell you how trivial it is to make a JSF application executed in a portlet container and a target environment that is MyFaces or Sun RI (or why we had to develop the JSFMetaBridge).

JIRA missing basic features

We are in June 2007, JIRA still does not have the notion of branches (a mere relationship between versions) and the capability to resolve an issue for a given release.

Tuesday, June 19, 2007

An implementation of partial portal page refresh

JBoss Portal 2.6 has partial page refresh for portlets feature.

The feature allows a page to be partially refreshed when a portlet link is clicked using ajax technology. The goal is not only to refresh the portlet markup but also ensure that the markup of the entire page is correct. And this of course should be totally transparent to the portlet code, i.e the portlet developer should not use an API other than JSR-168.

There is a lot of challenge when it comes to the implementation of that feature, both on the server side and on the client side. On the client side, it is to my opinion not trivial to come up with a universal solution. I built an implementation based on DOM events which allows to react on portlet clicks. I think also there are several other solutions and I have not investigated them all yet.

I choosed the DOM event based solution since it is the less intrusive because it does not require modifications of the portlet markup. It really helps to provide a solution which offers nice degradation when the client side has javascript disabled. It also works nicely with a portlet that would modify the DOM of their markup at runtime.

However I think there are some limitations that could always trigger a full refresh of the page. For instance the main limitation I see today is the programmatic submit of a form that never create events and therefore will force a full page refresh. It is possible to bypass that limitation in some browsers (Firefox, Safari and IE, I haven't yet tested other browsers).


<form id="my_form" action="/portal/...." method="post">

<select onclick="document.getElementById('my_form').submit()">
...
</select>

There is a workaround for this on browsers that allow to modify the prototype of DOM elements such as Firefox of Safari. It consist in modifying the prototype of the HTMLFormElement and replace the submit() method to perform the partial page refresh at this place.


var oldSubmit = HTMLFormElement.prototype.submit;
var newSubmit = function()
{
// Perform AJAX request and update here
}
HTMLFormElement.prototype.submit = newSubmit;

This technique does not work in IE (of course!!!), however it is possible to achieve the same result using a technique that emulates prototype behavior described below.


//This applies an IE "behavior" to the form elements

<style type="text/css">
form
{
behavior: url(test.htc);
}
</style>

And the IE behavior is


<method name="submit" internalname="_submit" />
<script type="text/javascript">
function _submit()
{
// Perform AJAX request and update here
}
</script>