JSR168 portlet packaging?

Question

From the JSR168 spec, (which is similar to how other portals seem to behave
with their proprietary APIs), a JSR168 portlet application appears to be a
WAR with a portlet.xml and web.xml conforming to the requirements of the
spec, that can then be installed in any portal.
From my superficial knowledge based on skimming the WL8.1 portal docs
recently, WL portlet development appears to be done within a Portal WAR such
that the portlet(s) are just components of the portal war itself.
How are these two supposed to work together in the WLP env? Say I develop a
couple JSR168 portlets in my own Java environment (emacs :-) and then WAR
them up and install them into Jetspeed-2 and another 168 compliant portal
when available (eg, IBM's 5.something). I believe those would accept my
portlet WAR and keep them in that WAR and just reference them from their
Portals. How would WL8.1.x handle such development (outside of Workshop/WL)
and deployment to a WL8.1.x portal? Do I have to merge my JSR168 based
portlet WAR (and thus a web.xml and portlet.xml merge) into the Portal WAR
(eg, if I want to ship a script to deploy my portlet WAR into an existing
WL8.1 portal?) or will WL8.1.x be able to reference a Portlet WAR outside of
a Portal WAR?
TIA - a confused potential portlet developer...

Answer 1

I agree with what Joe said...
BTW, I (and I assume Joe) think JSR168 is a good thing - and it's great that
WLP has the first prototype of it out there - don't get me wrong, I like it,
I'd just prefer if it were easier to deploy to given portlets coming in from
multiple sources being added into an existing portal. From Joe's case, he
probably doesn't want to have to merge the portlet.xml files. From my case
as a supplier of portlets, I'd rather not have to have to create different
install tools/docs/procedures for my customers for each portal vendor now
that I can have standard portlets based on JSR168...
"Joe C." <[email protected]> wrote in message
news:[email protected]...
You can always import any arbitrary webapp using the WLW as a portalproject
I'm not sure that solves my problem or the one ISV was talking about(which
I assume is the same).
I am not talking about importing a webapp (containing portlets or nto) and
making it be my portal.
- Assume I'm already developing a portal with some in-house developed
portlets.
- I want to get 3 JSR168 portlets from SAP (just picked a random vendorout
of the air) and add them to my portal.
- I want to get 2 JSR168 portlets from Siebel (ditto)
- And I need one Domino portlet from that other 3 letter vendor (ditto)
- Each of those vendors is likely to build JSR168 portlets that can be
installed/used in any JSR168 compliant portal, so they can stop buildingall
the various per-vendor proprietary API portlets.
- Each of those vendors needs to package up their portlets for
shipping/install.
- Given that JSR168 describes the Web App layout for packaging a portlet,
each of those vendors is likely to package their portlets up in a WAR.
- Some JSR168 compliant portals (I believe) will be able to just install
those WARs and use them as is from the Portal WAR and drop them on pages.
- WLP 8.1 appears to require that I unpack/extract those WARs and mergethe
portlet.xml and contents of each of those WARs with my existing Portal WAR
that I want to add those portlets to. Tell me why this is better?
To your earlier comments made here:
The pitfall of this approach is that webapps depend on each other towork correctly
Well yeah, I expect my portal to depend on my portlets - of course.
which is against the spirit of webapps.I disagree - EARs depend on the WARs within them. Cooperating WARs can
depend on each other too.
A deployer should be able to deploy/undeploy any webapp withoutaffecting the functionality of other
webapps - which would be case in the model you describe.Of course, if you remove a portlet that a portal depends on, I wouldexpect
it to break .
In addition, there are security issues that the deployer must be awareof.
Of course. That's the case with any J2EE deployment no matter how many
EARs/WARs you're deployiing.
"Subbu Allamaraju" <[email protected]> wrote in message
news:[email protected]...
Joe,
You can always import any arbitrary webapp using the WLW as a portal
project, and during that process you'll have the opportunity to
automatically update the descriptors (and also adding the correct jar
files). There is no need to hand-merge descriptors unless you want to.
Subbu
Joe C. wrote:
Please tell me it's going to get better.
That would make sense if one were developing all their own portlets
for
their portals.
But I (and most people I know) as a customer, that needs to aggregate
portlets from multiple (possibly many) 3rd parties, such as the big 4
application vendors, am going to need to know how those standardJSR168
portlets work and are configured so that I can hand-merge them into my
company's portal?
As an end user it doesn't really help me that much that I can developmy
own
portlets to JSR168. The whole point of JSR168 is that portlet vendorsthat
build portlets for others to install into their portals will be able
to
build one set of portlets that can then be installed in any compliant
portal. This limitation seems to prevent that from beingcommonplace/useful
(given how few people are going to know how to do such merges - theyjust
want to install 3rd party portlets and drop them on pages). I reallyhope
Workshop provides a user friendly way to integrate such 3rd party
JSR168
portlets or WLP will be missing the whole point of having such astandard in
the first place. I agree with the ISV that started this
conversation -
please provide a means for me to install 3rd party portlets withouthaving
to hand-merge XML configuration files.
"Subbu Allamaraju" <[email protected]> wrote in message
news:[email protected]...
isv wrote:
From the JSR168 spec, (which is similar to how other portals seem to
behave
with their proprietary APIs), a JSR168 portlet application appears to
be
a
WAR with a portlet.xml and web.xml conforming to the requirements of
the
spec, that can then be installed in any portal.For all practical purposes, a portal app is a web app, with the only
differece being the portlet.xml file. So, a portal app contains
portlets
in addition to things that typically exist in a webapp.
How are these two supposed to work together in the WLP env? Say I
develop a
couple JSR168 portlets in my own Java environment (emacs :-) and thenWAR
them up and install them into Jetspeed-2 and another 168 compliantportal
when available (eg, IBM's 5.something). I believe those would accept
my
portlet WAR and keep them in that WAR and just reference them fromtheir
Portals. How would WL8.1.x handle such development (outside ofWorkshop/WL)
and deployment to a WL8.1.x portal? Do I have to merge my JSR168
based
portlet WAR (and thus a web.xml and portlet.xml merge) into thePortal
>>>
WAR
(eg, if I want to ship a script to deploy my portlet WAR into anexisting
WL8.1 portal?) or will WL8.1.x be able to reference a Portlet WARoutside of
a Portal WAR?For WLP, the unit of development/deployment is a webapp. We're aware
that some implementations (including the ones you mention) follow a
model where portal deployment involves several web apps with portlets
aggregated by a portal deployed in one of those webapps. The pitfall
of
this approach is that webapps depend on each other to work correctly -
which is against the spirit of webapps. A deployer should be able to
deploy/undeploy any webapp without affecting the functionality ofother
webapps - which would be case in the model you describe. In addition,
there are security issues that the deployer must be aware of.
Having said this, if your portlets are already bundled into a WARfile,
you need to merge the portlets into the portal webapp. Or, you couldlet
WL convert your webapp into a portal webapp. We don't intend tosupport
portlet referencing from other webapps.
Subbu