portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BaTien Duong <batien.du...@dbgroups.com>
Subject Re: [J2] Service Framework Proposal
Date Sat, 03 Jan 2004 20:26:42 GMT
David Le Strat wrote:

>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.
>
Hello David:

I concur with your proposal and start to use Pico. Talking about AOP, 
since J2 is completely re-design from scratch, it is good to design J2 
with AOP right from the start for crosscutting aspects such as  
Security, Caching, Logging, Exception handling, etc.

BaTien
DBGROUPS

>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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message