portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Le Strat <dlest...@yahoo.com>
Subject Re: [J2] Service Framework Proposal
Date Sat, 03 Jan 2004 17:22:10 GMT
Intellectual honesty is not only a good professional
practice, it is paramount in today's world.  After
quite a few years in the research world, I am quite
sensitive to the "plagiarism" syndrome.  As you can
see most code samples have links to their sources.

So let's look at the code that was "copied" from Exo
as Mr Mestrallet likes to put it.

First the directory structure:

Services could therefore follow the structure:
MyService
    src
        api
        impl
    conf
        jetspeed-service.xml

Which would get deployed as:

MyService
    META-INF
        jetspeed-service.xml
    org.apache.jetspeed

Yes, Exo follows that pattern but many others do too. 
Before writing this proposal, I implemented services
using Merlin and played quite a bit with Hivemind and
Pico.  Separating api and impl (in api and impl
directories) is standard pattern in Avalon (check
Merlin for yourself).  Hivemind put the service xml
configuration file in META-INF, Merlin puts it in
BLOCK-INF.

Hivemind has this exact directory structure as you can
see in http://home.comcast.net/~hlship/bootstrap.html.

Now let's move to code samples for the various kinds
of IoC.  Those code samples are borrowed from the
PicoContainer.ppt presentation under
cvs.codehaus.org/sample/presentation/PicoContainer.ppt,
except for the Cornerstone code samples that come
directly from the IRC meeting we had with Jun a few
weeks ago.

The Pico code is I guess what's being referred as
"copied":

Clearly not that part, it comes from PicoContainer.ppt

public class Girl {
Kissable kissable;

public Girl(Kissable kissable) {
this.kissable = kissable;
}

public void kissYourKissable() {
kissable.kiss();
}
}

PicoContainer container = new DefaultPicoContainer();
container.registerComponentImplementation(clazz);

So I guess we are left with the singleton pattern and
the ServiceManager:

The ServiceManager provide access to the service.

Girl girl = (Girl)
ServicesManager.getInstance().getService(Girl.class);

•	Minimal metadata is required, interface are
recommended but not required.
•	The implementation dependencies on the framework are
minimized.
•	JMX and aspect integrations are provided through
Nanocontainer.

I guess nobody can claim right to the Singleton
pattern.  So we are left with the choice of the word
ServiceManager/ServicesManager.  I guess I should have
quoted Exo as a source for that word.

Now, the last code sample is:

privileged public aspect ConfigureServiceManager
{
	public pointcut createServiceManager(ServiceManager
manager) : 
		execution (protected ServiceManager.new()) 
		&& this(manager);

	after(ServiceManager manager) :
createServiceManager(manager)
	{
		final MutablePicoContainer container =
			manager._container; 

		container.registerComponentImplementation(
			Dispatcher.class,
			SMTPDispatcher.class); 
		container.registerComponentImplementation(
			MailerService.class);
	}
}


And this code sample comes from
http://wiki.codehaus.org/picocontainer/UseScriptingToWireAndConfigureComponents
which is quoted in the document.

Now, I am not a Jetspeed committer. I prepared this
document in good faith to initiate a debate on
services framework and as a result get accused of
"plagiarism". I believe that this is a little bit far
fetch by any standard.

Did I look at Exo's code? Of course I did as it was
part of the due diligence work I was trying to
perform. I even posted several links to articles about
Exo on this list.

I didn't necessarily feel that I would need to quote
Exo as the source of the Singleton pattern for one. 
Second, relevant to the conversation, I preferred to
point to framework code examples rather than specific
implementations of those framework (as Exo is). 
Apparently, this was a mistake.  I guess the debate as
taken an unexpected turn, not the one I was expecting.

By the way, the document I posted to the list a few
days ago was supposed to provide a basis for a healthy
debate on the topic, not some bickering about who uses
what.  I guess the Jetspeed community now knows what
it means to go with Pico/AOP.

I personally believe that AOP/IoC provides a good
combination for the choice of a service framework.  I
have reservations on the use of a Singleton to funnel
access to the service framework and would have liked
to see this topic discussed.  For instance, I would
rather have the option like Hivemind provides to have
to access a pool of services and not have to funnel
everything service look up through a singleton.

So, now can we go back to the initial debate before it
was hijacked by someone who does not even contribute
to the Jetspeed community and figure out what is the
best choice for J2?  I am looking forward to your
posts on the topic.

Sincerely,

David Le Strat.


--- BaTien Duong <batien.duong@dbgroups.com> wrote:
> Mestrallet benjamin wrote:
> 
> >BaTien wrote :
> >
> >"There is nothing new to this. We did the same
> thing using singleton as a single entry point of a
> specialized group of services in our Universal
> Integration Layer where all services from different
> frameworks can be plugged in."
> >
> >Yes and people before you too, this is not the
> point at all... You have to be blind not to see the
> solution presented in the doc file comes from the
> eXo platform design, which is actually a good thing
> for us ;). Even some parts of the code are taken
> from what we wrote 6 months ago.
> >  
> >
> I have not looked at eXo (or even downloaded it) 
> nor J2 code (except 
> the cornerstone) so I am not in a good position to
> say one way or the 
> other. Generally speaking, intelectual honesty is a
> good professional 
> practice.
> 
> BaTien
> DBGROUPS
> 
> >The fact that nowhere, our project is stated is not
> a good practise. Each time we use or talk of an Open
> Source project we always quote its name, even if
> those projects are in the same area :). I also think
> that most of members of your community thinks the
> same.
> >
> >Now I wish you to choose the best lightweight
> framework for your needs and an happy new year.
> >
> >Regards,
> >
> >Benjamin Mestrallet
> >eXo platform® project leader
> >eXo platform SARL manager
> >
> >  
> >
> 
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jetspeed-dev-help@jakarta.apache.org
> 


__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message