�
> -----Original Message-----
> From: Tim Reilly [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 24, 2003 1:49 AM
> To: Jetspeed Developers List
> Subject: RE: J2 - Service Architecture Question
>
> I'm not familiar with CPS either?
> I too have some questions on the Service Architecture.
>
> (POJO=Plain`old`java? I think.)
>
You are correct.
> From the Jetspeed-2 cvs I might guess CPS stands for Common Portlet
> Services?
>
Wow! 2 for 2 ;)
> My question about services in J2...I was skimming the Jetspeed 2 classes
> and
> noticed most services based on implementation of Fulcrum. Would it be
> foolish to suggest bringing back PortletService as a proxy class;
> for the purpose of decoupling Avalon, Pico, Turbine/Fulcrum or which ever?
> Something like;
> interface PortletService{
> ...
> void init();
> ...
> void destroy();
> ...
> etc
> ...
> }
This is exactly what the purpose of CPS is.
>
> default implementation in the case of turbine
> abstract JetspeedService extends TurbineBaseService implements
> PortletService{
> public void shutdown() {
> destroy()
> }
> default implementation in the case of foo framework
> abstract JetspeedService extends FooService implements PortletService{
> public void initialise(){
> init();
> }
> public void dispose() {
> destroy();
> }
>
> something along these lines, hopefully the general idea comes across
> right?
> It may not be feasible, but what are some thoughts on this?
>
> I just realized JSR-168 does not address how portlets retrieve services or
> does it?
> No PortletContext.getService() or such. At least not from looking at the
> javadocs and interfaces.
> Wouldn't this be an important concern for platform portability? Is it too
> late to suggest to the expert group? Actually, I'm sure it was discussed.
> Was it simply dropped out of scope?
>
I don't know, I wasn't on the expert group. I suspect that providing services is
outside the scope of a basic portlet container and therefore was not proposed.
> One last question - whatever happen to
> org.apache.jetspeed.portlet.PortletService
> all I can find in the archives is over a year ago and it's someone asking
> same question,
> plus a reply that it is in the cvs head but not anymore. What is the
> currently (both J1 and J2) correct base class to extend in order to
> implement a service; Service, TurbineBaseService?
>
In J1, I have been using TurbineBaseService. In J2 I would suspect we will move
everything behind CPS.
> === Some reference stuff for Glenn, et al ===
> I'd been digging around the service / container topic the other week
> - here are some references I'd looked at:
> http://javangelist.snipsnap.org/space/IoC+Introduction
>
> Avalon - http://avalon.apache.org/
> Avalon on IoC - http://avalon.apache.org/framework/guide-patterns-ioc.html
> Pico site - http://picocontainer.org/
> Pico on IoC - http://picocontainer.org/ioc.html
> Hivemind - http://jakarta.apache.org/commons/sandbox/hivemind/
> Compare Avalon and Hivemind - H Ship's wiki post
> http://nagoya.apache.org/wiki/apachewiki.cgi?HiveMind/HiveMindAndAvalon
>
> Free book download:
> Component Development for the Java Platform
> http://www.develop.com/us/technology/developmentorseriesdownload.aspx?id=1
> 1
>
> Honestly I find the topic somewhat difficult... the pico examples are
> subtle. I guess the best information I come across cited that IoC allows
> for
> runtime association as opposed to design time association. Thinking about
> Eclipse's plug-in architecture - defining extension points, extensions,
> etc
> has helped give me something to frame the pattern against.
>
> Hope you find these useful.
> I look forward to Scott's insights.
>
> > -----Original Message-----
> > From: Glenn R. Golden [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, September 23, 2003 8:04 PM
> > To: Jetspeed Developers List
> > Subject: Re: J2 - Service Architecture Question
> >
> >
> > Scott -
> >
> > For those of us following with interest this issue of service
> > methodology, I'd be interested in more information such as:
> > - what is CPS
> > - what is IOC
> > - what is POJO.
> > - picocontainer?
> > - hivemind?
> >
> > I'll probably start searching, but if you have a brief definition or
> > link to more info I'd appreciate it.
> >
> > Also, I'm real interested in Avalon Framework - has this been evaluated
> > for a Service framework for jetspeed 2?
> >
> > Thanks.
> >
> > - Glenn
> >
> > On Tuesday, September 23, 2003, at 03:22 PM, Weaver, Scott wrote:
> >
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: David Le Strat [mailto:[EMAIL PROTECTED]
> > >> Sent: Tuesday, September 23, 2003 2:33 PM
> > >> To: [EMAIL PROTECTED]
> > >> Subject: J2 - Service Architecture Question
> > >>
> > >> All,
> > >>
> > >> I have been playing around with J2's code for a little
> > >> while (though without Pluto it is a bit challenging
> > >> ;o)). I am looking for the Jetspeed developers'
> > >> advice on the 2 following topics:
> > >>
> > >> - What is the recommended way to implement/expose
> > >> services in J2? Is it the purpose of the CPS base
> > >> services to provide a service framework for the rest
> > >> of the application (will this eventually use Avalon?)
> > >> or are plugins assuming this responsibility (see point
> > >> below)?
> > >
> > > CPS is the way to do it in the jetspeed 2 core. I talked to David
> > > yesterday and we are also going to evaluate picocontainer and Hivemind
> > > as possible replacements for Fulcrum, which is currently CPS'
> backbone.
> > > I really like the how picocontainer has simplified IOC and that all
> > > components are POJOs.
> > >
> > >>
> > >> - What is the recommended way to use a persistence
> > >> layer? I noticed that there is an OJB plugin. Should
> > >> all persistance leverage the plugin to persist data
> > >> through OJB? I read a little bit about the thrust
> > >> architecture in Jetspeed. To which extent should
> > >> plugins be used?
> > >
> > > The whole idea behind the plugin was to allow developers to "plug in"
> > > their own persistence mechanisms. We used OJB because I have a lot of
> > > experience with it. I had thought about Hibernate, but it was LGPL.
> > > Plus, Matthew Baird of the OJB project has been a huge help with the
> > > more esoteric aspects of OJB. He uses Jetspeed in some of his
> projects
> > > and drops into the Jetspeed IRC from time to time.
> > >
> > >> For instance, should the underlaying
> > >> profile management implementation be exposed as a
> > >> plugin? Let's say EJB profile, JDO profile, LDAP
> > >> profile, OJB profile and have a "universal" interface
> > >> in front that assembles the plugins and manages the
> > >> interaction with the various plugins?
> > >>
> > >
> > > Profile management should be exposed through a service or component.
> > > There should really be no need to touch persistence mechanism of the
> > > profile system.
> > >
> > >> Thanks for your input.
> > >>
> > >> Regards,
> > >>
> > >> David Le Strat.
> > >>
> > >> __________________________________
> > >> Do you Yahoo!?
> > >> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> > >> http://sitebuilder.yahoo.com
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >> For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > > *===================================*
> > > * Scott T Weaver *
> > > * Jakarta Jetspeed Portal Project *
> > > * [EMAIL PROTECTED] *
> > > *===================================*
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
*===================================*
* Scott T Weaver *
* Jakarta Jetspeed Portal Project *
* [EMAIL PROTECTED] *
*===================================*
