[jboss-dev-forums] [Design of JBoss Portal] - Re: Deployment architecture for 3.x
sverker
do-not-reply at jboss.com
Sat Nov 18 17:17:35 EST 2006
I would definitely vote for the approach you suggest at the end, i.e. use native integration whenever possible and fall back to hooks in web.xml for what's not possible to do natively.
The main reason is that if JBoss Portal integrates natively as a component into the app server, then I as a developer/administrator/user can use the same configurations and tools that I'm used to no matter if my app server is JBoss, JONAS, Geronimo, OracleAS or just a plain Tomcat or Jetty. Each of these have their own conventions on how to do things, which those who use them are used to. It shouldn't be necessary to have to bother with custom methods to deploy JBoss Portal apps if the necessary information already is available in the app server. Also, the integration should be as non-intrusive as possible so that I don't have to change app server config which might potentially create problems for other applications.
Take your competitor Liferay as example. Their approach is that they use a private deploy directory from where they pick up war files (and require a lot of changes to the app server config). That means that I can't create an ear which contains my application with a war file which is intended to plug into the Portal server component as that ear file will be deployed by the default deployer and the embedded war file will not be picked up by the portal-specific deployer.
When doing fallback to technique 2 all that should be necessary to do is to set up either a listener or a servlet in web.xml, whichever approach you chose, that serves as a bootstrap for the portal specific deployer.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3987111#3987111
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3987111
More information about the jboss-dev-forums
mailing list