Order of -object.xml is not guaranteed

[syllant]

Hi,

When you have to define lots of pages using -object.xml descriptor, you'll probably want to use several -object.xml files.

But this approach has a severe limitation : loading order is not guaranteed ! So portal node may be loaded after pages nodes !

Problem is that although descriptors URL are sorted before parsing, their parsing results are put in a non-sorted Map (cf. org.jboss.portal.server.deployment.jboss.PortalDeploymentInfoContext).

I've made a temporary patch, but is there any chance to see this resolved for next release ?

Thanks

PS : seems like there's a bug in class org.jboss.portal.common.util.SetMap, it doesn't apply sort when passing a comparator in constructor. Whereas ListMap does...

[go4nishu]

looking for the solution to same problem. any one got the solution?

[go4nishu]

i have got a solution for this issue
check out the jira
https://jira.jboss.org/jira/browse/JBPORTAL-1832

thanks
narinder

[syllant]

Hi narinder,

It's a simple but limited solution, I've posted a note in JIRAabout ;-)

However, if you are satisfied with it, others surely will be, that's the main point :-)

Sylvain

[antoine_h]

Hello,

I did a Wiki about a way to do that.
see : http://wiki.jboss.org/auth/wiki/PortletandPageDeploymentOrder

the way I do it is to package the parts of the portal (main default portal, portal x, portal y, ...) in different Sar (or War) with all their code things related to it.
This is a convenient architecture to both develop and deploy parts of the whole portal(s) independently.

you can look at the way Sar are used for the portal itself, to organise your code and portal artifacts.

by the way : I thaught of including files... but that is not really nice, is it ?
using the packaging of JBoss, and architecture of the developed code looks better to me.
This also allow to have your own JXM services, EJB, etc... being deployed in the proper order.
If a portlet needs a JXM service (configuration ?) in it's initialization phase... it must be deployed before the portlet... etc...
It is also more clean for production side of the portal management.

Antoine

[syllant]

Hello Antoine,

I find this idea relevant for some cases but it has a major impact on project architecture (several web.xml declarations, several HTTP sessions, class dependencies between webapps, multiple deliveries, ...).

We had splitted our -object.xml files according to our web pages tree : each branch was declared in its own -object.xml file. It wouldn't have been relevant to make a webapp for each branch.

So I think this kind of architecture must not be driven by -object.xml separation but by real architecture needs. However it's interesting since some users will see that through -object.xml files :-)

Sylvain

[antoine_h]

Hello,

Yes ! exactly !
it is the real question : the architecture of the whole portal and inner application aggregated by the portal.

Here some few things, that may be usefull.

for what you say, about technical thing (multiple web.xml, sessions, class depencies)... this is main questions.
there are solutions :
- several HTTP sessions : yes... but you don't use them... and would have them anyway without a portal... so... that the cost of aggregating things.
- several : web.xml : you can put the common thing in the model of web.xml of jboss... and the specific thing in each package. more clean, no ?
- class dependencies : use libs... organise thing with SAR,... this is more clean architecture...
- multiple delivery : if you want independant delivery and deployement, you have multiple delivery. If you don't need it, you can put every thing in the same package, ... and in the same -object.xml

but this requiere some study... and defining things for each portal project.

mainly, as you conclued it, I am saying that doing the architecture based on the web page tree may not be enough for agregating inner applications.

It is better (and may be requiered) to organize the architecture of a portal, with a focus on the aggregation of inner application.
This is important, as defining the page is only one part of it : there are always some more, as java, JSP, JSF, ... JMX services involved in the aggregated applications.

for what I see in several companies (as a consultant), many of them wants to take a portal plateform, ... just to have a tool to build web pages.

one of them took the portal just to give to a webmaster a tool to build it's pages.
and that is not the best tool for that...
and they end with developper headhache... or when the developer reach to deliver something, ... they have with some big big production troubles.
That is not the portal plateform responsability. It is what they have done with it.

So... yes, some user will see that through -object.xml and admin GUI cool prototyping feature... but I want to warn : think of architecture of the whole packages also... for a successfull development and portal in production...
(whatever JSR-168 portal plateform you work with...)

hope it helps...
Antoine