incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Novotny <novo...@aei.mpg.de>
Subject Re: Graffito & Jetspeed 2 dev
Date Mon, 28 Nov 2005 20:13:08 GMT

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
>
>
>  
>


Mime
View raw message