Hi Ate
Deploying to Websphere Portal Server is actually not a problem. We develop
on Jetspeed (2.1.3 currently), and deploy the unmodified WAR file to WPS.
I've done some testing on Jetspeed 2.2 and no real problems have been found.
It's a while since I looked at the code, but I think the jetspeed deployment
code rips out whatever portlet.tlds are in the WAR, and repackages it with
the pluto TLDs (both _1.0 and _2.0 in the case of Jetspeed 2.2). The
modified WAR then gets deployed into the standard Tomcat deploy directory.
The only fishooks we have found are:
- IBM specific code needs to be stubbed out on Jetspeed. Some of our
production code uses the proprietary IBM clustered cache to provide JMS
message caching across servers in a cluster. But this is loaded as a JNDI
resource, and so can be cleanly replaced with a simple Hashmap for
development on Jetspeed.
- IBM implement non-standard JNDI branches (e.g. /cells/persistent.. and
/services/.... - no java:comp prefix). We fixed this by having all JNDI
access funnelled through a class that knows what the platform is, and adds
the prefix when running on Jetspeed. A better solution would be to make
Tomcat implement these branches, but that is a fairly complex job. (This is
a Tomcat problem, not a Jetspeed issue)
- On Jetspeed 2.2 the <c:url> tag behaves differently to WPS and Jetspeed
2.1.3. It requires the context="myapp" parameter set, else it defaults to
the /jetspeed context. Possibly this is a JSR168/286 change?
- Our WPS version only supports Java 1.4. Our workaround is to write 1.5
(or 1.6) code, and use JBoss weaver to produce 1.4 class files. It works
remarkably well. We run the weaved classes on both environments, but the
unweaved run fine on Jetspeed.
- Using two different containers means two sets of skins and themes -
Hacked JSPs for IBM and Velocity macros for Jetspeed. But this is a one-off
hit, as a single skin or theme is typically used across a number of
portlets.
I'm glad to help out anyone who is going down this path. Developing on
Jetspeed is far more productive than fighting with WPS.
Regards
Ron
----- Original Message -----
From: "Ate Douma" <[email protected]>
To: "Jetspeed Users List" <[email protected]>
Sent: Tuesday, September 15, 2009 7:34 PM
Subject: Re: deploy tools
blog s2o.bcn wrote:
I'm developing/deploying portlets in jetspeed with the wtp eclipse
plugin,
with an easy solution that I didn't see before, and that can integrate
closely eclipse wtp with jetspeed.
You can see here:
http://s2o-bcn.blogspot.com/2009/08/developing-portlets-using-eclipse-part.html
a detailed explanation.
May this could be helpful for someone...
Nice blog.
One thing I noticed is that you only reference the portlet 1.0 tld in your
web.xml.
As long as you only develop JSR-168 portlets that fine, but as Jetspeed
2.2 also supports JSR-286/Portlet 2.0, you might want to include the
following just to be sure:
<taglib>
<taglib-uri>http://java.sun.com/portlet_2_0</taglib-uri>
<taglib-location>/WEB-INF/tld/portlet_2_0.tld</taglib-location>
</taglib>
Note: if you do the above, you should also add the portlet_2.0.tld file to
your WTP project (just like the JSR-186 portlet.tld).
And related to that, you might want to mention in you blog that these
portlet tld(s) are portal/portlet-container specific.
If you migrate your build to another portal/portlet-container these
portlet tld(s) will have to be migrated as well.
Jetspeed 2.2 uses the Pluto portlet tld(s), which won't work if you move
to say WebSphere Portal (if you Jetspeed on plain WAS however it would be
fine though).
The Jetspeed runtime deployment (or alternatively buildtime/command-line
pre-processing) of standard portlet applications will take care of these
specifics, including injecting the JetspeedContainerServlet and portlet
tld(s) in your web.xml.
Doing that hard coded in your project is fine for sure as long as you are
aware of the above :)
Regards,
Ate
a10
Sergi
2009/9/14 Christine <[email protected]>
Ate Douma wrote:
Christine wrote:
Ate Douma wrote:
Christine wrote:
The mvn script for building my project was complaining about
deploy-tools:
>[INFO] Trace
>org.apache.maven.BuildFailureException: Compilation failure
>error: error reading
/home/christine/.m2/repository/org/apache/portals/jetspeed-2/jetspeed-deploy-tools/2.2.0/jetspeed-deploy-tools-2.2.0.jar;
error >in opening zip file
>
> at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:579)
The pom.xml says "version 2.2.0" but the file that's downloaded says
"jetspeed-deploy-tools-2.2".
Hi Christine,
What do you mean by "says"?
The pom file in the same directory as the jar file contains
<version>2.2.0</version>.
Right.
But where is the "2.2" without the ".0" mentioned, or are you saying
that
the the file in your local repository itself is named
jetspeed-deploy-tools-2.2.jar?
yes. I manually replaced the 2.2 file with a 2.2.0 file.
--
dagdag is just a two-character rotation of byebye.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
