You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Mestrallet benjamin <be...@exoplatform.com> on 2004/01/03 01:03:20 UTC
Re: [J2] Service Framework Proposal
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.
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
Re: [J2] Service Framework Proposal
Posted by BaTien Duong <ba...@dbgroups.com>.
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 <ba...@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
>
>.
>
>
>
Re: [J2] Service Framework Proposal
Posted by David Le Strat <dl...@yahoo.com>.
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 <ba...@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
Re: [J2] Service Framework Proposal
Posted by BaTien Duong <ba...@dbgroups.com>.
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