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 21:30:08 GMT
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 <novotny@aei.mpg.de> 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
>>>
>>>
>>>
>>>
>>>      
>>>
>>    
>>
>
>
>  
>


Mime
View raw message