Hello David: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 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 <[EMAIL PROTECTED]> wrote:
Mestrallet benjamin wrote:---------------------------------------------------------------------
BaTien wrote :thing using singleton as a single entry point of a
"There is nothing new to this. We did the same
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 thepoint 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 nota 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 lightweightframework for your needs and an happy new year.
Regards,
Benjamin Mestrallet eXo platform® project leader eXo platform SARL manager
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
__________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
.
