David H. DeWolf wrote:
5) Ability to have a portable solution which can be packaged as a
single war (not built differently for different environments) and
deployed on any compliant servlet container.
If its a single war file, then how will standard portlet applications
be deployed to a single war file solution? Will all portlet
applications run inside the same class loader, same session space as
the portal? What about resource collisions?
Great question. When I say "single war", I'm referring to the
aggregation server - not necessarily the portlets. My instinct says
that to meet this requirement a cross context dispatch must be used and
portlets must be deployed to the app server seperately (which is
acceptable). If anyone has a better idea - I'd LOVE to hear it.
We've had some success in this area.
Jetspeed has a "local" portal invoker.
We deploy portlet applications to WEB-INF/apps and run the Java portlet
code from there, each having its own class loader.
This seems to work fine, under certain 'conventions', mainly that you
put the resources (JSPs, images, HTML...) in a common area under the
portal's web application. We still keep a separate class loader for each
portlet application, however the resources are shared and the big
problem with this is collisions. Perhaps we could enforce a name space
for resources...
For one of the solutions, this is for an admin console which is embedded
in a device. Think of a generic linksys router and the web console that
comes with it and then imagine that more than one entity is providing
different aspects of the management console. B/C it's embeded,
resources are limited and we'd like to keep it as small as possible.
That seems like a valid use case.
Because of these use cases, this isn't a traditional portal so I don't
see "users" wanting more. That said, that is always a temptation, but
one that we've purposely decided to shun.
I keep repeating myself here, I think a light-weight portal is
questionable as its the natural progression of the portal space to
integrate with technologies and "grow". The end result will be two
portal solutions for Apache Portals. Maybe we should ask ourselves the
question first before going on:
Do we want to have more than one portal solution at Apache Portals?
I think that's a very fair question. I have no problem if the answer is
no. *If* we can maintain scope and keep this solution light weight, I
do believe that a second "light weight" portal may help jetspeed. The
reason is that it *may* attract more users to the portal world (perhaps
because it lowers the cost of entry - and no, that's not being critical
of jetspeed, just something we should think about and evaluate). Once
this attraction occurs and users begin to ask for more, we simply say -
hey - look at jetspeed and hopefully provide them an upgrade path.
At the same time, *If* we allow this light solution to grow outside of
the original scope, there is no doubt that it will detract from
jetspeed. If we as a community believe that my use cases and
requirements are unique enough that they don't warrent a solution within
apache portals, I take no offense.
Frankly, we don't even have enough committers for any of our projects
right now. That is a concern to me, even without the additional
maintenance of 4th portal solution here.
Fair enough. We at Pluto know all about lack of committers :)
I know and you have a great point there.
We need more Jetspeed committers getting involved in Pluto.
We all need to review Pluto 1.1 over the next few weeks.
IF any of you out there have not reviewed 1.1, please do so !
David has refactored Pluto to a much more manageable codebase.
We should all give it a thorough code review.
I believe that would be a more "synergized" and community building,
rather than community splintering approach. Now this implies that your
solution is community-splintering. And frankly, that is not fair at
all, to simply imply it. So please, tell us how Jetspeed Components
and the Jetspeed team of developers and contributors fit in with this
solution, and how we won't feel that we are being ignored and stepped
over and splintered?
On one hand, I'm not sure how this affects the current make up of
portals at all. If the jetspeed team has no interest, either nothing
changes or the pluto portal driver moves outside of pluto and jetspeed
still isn't affected since none of the active pluto developers are
active in jetspeed anyways.
On the other hand, I'd very much like to see this be the bridge between
the two projects. *If* we can find a way for the two teams to
collaborate I would absolutely love it. I'm very willing to dump the
pluto portal driver and use jetspeed components instead (though I do
have a strong preference to the pluto 1.1 container). If that approach
was chosen, I would think it would be natural for jetspeed to be an
extension of "the aggregation server". That said, I definately
understand how that comment may ruffle some feathers - especially
considering that I have similar feelings regarding "dumping" pluto and
am only putting that on the table since I know it may be best for the
community.
Well, Im willing to consider creating a Jetspeed Components subproject.
Also, if you don't like the Jetspeed solution, just say so.
Gawd knows we are not perfect. There are problems.
Just speak your mind and tell us why its just unusable for a
lightweight portal solution.
Perhaps any responses to these comments should go in another thread so
that we don't get off track. . .
I can't say I don't like jetspeed. From what I can tell, it simply does
not meet my requirements. That said, there are two things that are not
ideal IMHO (and perhaps my understanding is wrong and these really
aren't issues):
I don't really like is the repo layout and build -- I don't think that
they lend themselves to easily discovering the core components of
jetspeed. I found I had to research and look around quite a bit to feel
like I had any clue what lived where.
Fair enough. Perhaps a re-org of Jetspeed would help, as I mentioned
above, moving the components to a Jetspeed Components subproject.
The other thing I don't like is the setup required. I'd like to be able
to take a jetspeed war, deploy it, and go. . .I don't want to have to
create db schemas, build for specific app servers, etc. . .before
running. IMHO, either an installer should do that work for me, jetspeed
should initialize itself at startup, or the default build should not
require this prep work.
The new installer does all of that.
Beside those minor things, I really have no problem with jetspeed.
I agree with you. I find the Jetspeed plugin and build to be lacking
Finally, are you willing to base your portal on the Jetspeed API?
Yes, as long as it doesn't have a whole ton of dependencies, a lot of
service interfaces that the core is dependent upon but I don't need, and
the concept of pages and page layouts (PSML) are seperated from each other.
The API is pretty lightly coupled, we hope.
I think it would be worth trying
Im on vacation this week, but I'll be back Friday and can start helping then
