Christophe Lombart wrote:
Hi Jason,
I think others project have the same problem. portlet portability is
possible for simple portlets but it becomes more complex when thoses
portlets have to use some portal services (eg. the security
components).
This is certainly a problem-- we have our own "Authentication
Module" approach
http://www.gridsphere.org/gridsphere/docs/ReferenceGuide/ReferenceGuide.html#portlet-auth
and I understand every other portal has their own propietary classes for
handling security. However the basic role, group stuff is a part of the
J2ee specs.
Just one question : can you point me to an open source project that
provide portal and strong CMS features (in java) ? I didn't find one.
That's certainly the big problem in the java community. We are not
working on the same foundation. this problem is less present in the
python/zope plateform.
Not really unfortunately :-( which is why I've been turned on to
Graffito. There are a few other projects:
xWiki, also has some level of portlet integration but only works with
exo platform
JBoss xwiki, another wiki portlet solution which I would be interested
in using but is tied to JBoss
We've chatted with the guys that have created SnipSnap snipsnap.org
and they have prototyped some gridsphere/snipsnap integration which has
been exciting, but so far nothing represents itself as a vendor agnostic
solution.
Cheers, Jason
Anyway, I'm agree to add more abstraction in the Graffito code.
Thanks,
Christophe
On 11/28/05, Jason Novotny <[EMAIL PROTECTED]> wrote:
Hi Christophe,
Thanks very much for your summary-- I'm glad I stepped in when I did
to hopefully inspire you to make graffito a lot more useful than it is
destined to be now. IMHO, an ongoing problem with many jakarta projects
is their implicit dependencies on other Jakarta projects. It sort of
makes a mockery to say "JSR 168 compliant portlets" if it's pretty much
glued to Jetspeed. Furthermore, it prevents this project from having any
practical applicability outside the world of Jakarta since Jetspeed2
represents only a very small user community compared to JBoss, Liferay,
Exo and vendor portals, which pretty much also limits the extent that
this codebase can get better over time.
I think it's fine if you're using jetspeed 2 security, but you need
to provide a way to either deploy those components to any portal as part
of the portlet.war file possibly or simply rely on standard j2ee
security as dictated by the servlet and portlet specs.
Cheers, Jason
Supporting different portal servers requires more complexity and abstraction.
Let me resume how Graffito is designed. Than, we can see if it fits to
Gridsphere and see together how we can change the Graffito project
structure, deployment scripts, ... .
If there are too many J2 dependencies, I'm agree to review them.
1. Grafftito contains some demo portlets but also some components.
Thoses components can be executed in any IOC container (in theory :-)
). We are currently supporting Spring. If you need another IOC
container, you have to check the differencies in term of component
lifecycle, tx management, ... In the case of J2 integration, the
Graffito components are running inside the portal container and can be
used by other portal services (eg. the portal page manager).
Futhermore, the Graffito scope is not limited to build portlets. It
should be possible to run Graffito components in other kind of
applications. That's why those components are important.
2. The security depends on the J2 security components which are very
good. Maybe more abstraction is required here. We are using JAAS. Are
you supporting JAAS in Gridsphere ?
3. The demo portlet (browser) depends also on the j2 API and some J2 services.
In my opinion, supporting different portal container is possible but
it will take times.
Personnally, I have no time to do it now but of course I can help you
to modify all subprojects. Let me know if you are interesting to do
it. We can make the following plan :
1. Review the API and commons subproject : see how to drop the J2 dependencies.
2. Review the components subproject wich will be the big job.
3. See if the engine is needed.
3. Review the portlets.
Kind regards,
Christophe
