You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2003/03/08 10:34:14 UTC
Re: cvs commit: avalon-sandbox/merlin-jndi/
what does this do?
I would like to change (or set up) informal sandbox policy: before you
put a new subproject in sandbox, write up a short proposal for the
subproject, so everyone knows the project is there and what it does. And
you'll have to lobby against a -1 of course.
cheers,
- Leo
mcconnell@apache.org wrote:
> Log:
> Initial commit of a Merlin to JNDI connector.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: restructuring Merlin
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jason van Zyl wrote, On 08/03/2003 17.30:
> On Sat, 2003-03-08 at 09:37, Leo Simons wrote:
>
>>Stephen McConnell wrote:
>>
>>> if its also
>>>acceptable that I move these projects to Maven.
>>>
>>>Any opinions?
>>
>>+1
These projects are sandbox projects.
The issues I had with using Maven for Avalon *now* are not applicable
IMO in the sandbox; on the contrary I welcome any experimentation there
that can make us understand more things.
NOTE: Centipede has now been proposed to Ant, and we are in the process
of friutfully discussing on how to better serve Ant.
...
> A road map for Maven will be released on Monday part of
> which will be an outline Maven being turned into an Avalon component.
Avalon should use as much things that relate to its codebase as
possible. This is one of the reasons why I strongly favor using Cocoon
(Forrest) for the doc generation. And the reason why I personally
encourage Stephen to make Merlin use Maven.
Add to this that I am a Forrest developer, and that I can't wait to have
Forrest work nicely with Maven (yes, I do want to get to a single HTML2
DTD), you have my
+1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: restructuring Merlin
Posted by Jason van Zyl <ja...@zenplex.com>.
On Sat, 2003-03-08 at 11:35, Leo Simons wrote:
>
> can we congratulate on going top-level yet?
Not just yet. But I think the issue will be resolved in the next couple
of days.
> cheers!
>
> - Leo
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: restructuring Merlin
Posted by Leo Simons <le...@apache.org>.
Jason van Zyl wrote:
> On Sat, 2003-03-08 at 09:37, Leo Simons wrote:
>
>>Stephen McConnell wrote:
>>
>>> if its also
>>>acceptable that I move these projects to Maven.
>>>
>>>Any opinions?
>>
>>+1
>
>
> I would be glad to help if you're having any troubles. Most of nasty
> problems will go away in beta-9 as I finally have ClassWorlds integrated
> so that each plugin gets it's own separate classloader which makes life
> much easier. A road map for Maven will be released on Monday part of
can we congratulate on going top-level yet?
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: restructuring Merlin
Posted by Jason van Zyl <ja...@zenplex.com>.
On Sat, 2003-03-08 at 09:37, Leo Simons wrote:
> Stephen McConnell wrote:
> > if its also
> > acceptable that I move these projects to Maven.
> >
> > Any opinions?
>
> +1
I would be glad to help if you're having any troubles. Most of nasty
problems will go away in beta-9 as I finally have ClassWorlds integrated
so that each plugin gets it's own separate classloader which makes life
much easier. A road map for Maven will be released on Monday part of
which will be an outline Maven being turned into an Avalon component.
Soon after I hope that beta-9 will be released and with the classloader
isolation Maven should be _much_ easier to live with.
> - Leo
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: restructuring Merlin
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> if its also
> acceptable that I move these projects to Maven.
>
> Any opinions?
+1
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
restructuring Merlin
Posted by Stephen McConnell <mc...@apache.org>.
Taking into account the amount of work implied by the following two
emails (avalon jar repository + Merlin restructuring), I'm would like to
put forward a proposal which would set the groundwork for justifying this.
http://marc.theaimsgroup.com/?l=avalon-dev&m=104712140011322&w=2
http://marc.theaimsgroup.com/?l=avalon-dev&m=104712113711184&w=2
I'm currently spending too much time maintaining two build environments
- Ant and Maven. The Ant environment is maintained only to support the
content over on Avalon. On my local machine I'm using Maven builds for
everything (and as a result my internal processes are much more reliable
and better structured). I'm willing to migrate the current Merlin,
Assembly, Meta content under an umbrella Merlin project if its also
acceptable that I move these projects to Maven.
Any opinions?
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-sandbox/merlin-jndi/
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
>> what does this do?
>
> It a JNDI ObjectFactory that lets you access a new instance of the
> Merlin Kernel from a JNDI context.
so IIUC it is of no real use outside merlin?
>> I would like to change (or set up) informal sandbox policy: before
>> you put a new subproject in sandbox, write up a short proposal for
>> the subproject, so everyone knows the project is there and what it
>> does. And you'll have to lobby against a -1 of course.
>
> I agree that new projects should be discussed before launching of on
> a sandbox commit. However, I do think that the notion of "project"
> should be qualified.
you have a suggestion? :D
> If the structural breakout is problematic it could be repackage but
> this would be nothing more that moving deck-chairs.
yes please :D
Makes things clearer.
it'd be my preference to keep all code used by one container inside a
single base directory until it actually becomes used in another
container. Like moving the phoenix dependencies into avalon-phoenix,
merlin-jndi classes into avalon-sandbox/merlin, assembly classes into
avalon-sandbox/merlin and container/lifecycle out of avalon-fortress
(because it is in use in merlin).
This makes it clearer at a glance what the actual organisation of a
project is. Another way to put it: consider the (hypothetical) case
where we decide we're going to base "spearhead" on merlin/assembly. We
might want an avalon-spearhead repository. Content of that as it stands
now would be sandbox/assembly, sandbox/merlin-*, and I believe also
sandbox/meta or sandbox/info.
All those packages are in fact a single "project". The fact they could
be used independently of each other in theory doesn't change that. I can
point at many packages in phoenix that are completely independent of
everything else, for example.
The single thing that looks to be an exception (besides the merlin stuff
in sandbox), instrument-*, is not! Just look at the gump dependency tree
to see why :D
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-sandbox/merlin-jndi/
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>Stephen,
>
>
>
>>It a JNDI ObjectFactory that lets you access a new instance of the
>>Merlin Kernel from a JNDI context.
>>
>>
>
>
>
>> Context initCtx = new InitialContext();
>> Context envCtx = (Context) initCtx.lookup("java:comp/env");
>> Kenel kernel = envCtx.lookup("merlin/ServiceFactory");
>>
>>
>
>
>
>>Naturally this needs to be backed by a JNDI resource declaration as
>>per the Servlet 2.3 spec (or alternative JNDI configuration). That's
>>where parameters such as the Merlin system and block definition URLs
>>are declared.
>>
>>
>
>Do you have any interest in seeing org.apache.naming moved out of Tomcat
>into a common project for others, e.g., Avalon, James, and others, to use?
>
>
Yes.
I spend some time going over the Tomcat code partly to get a validation
of the Merlin/JNDI connection up and running inside tomcat but also
because of the related discussions on this topic over on the James list.
While I don't have a real deep grip on the content of the
org.apche.naming package - I do have the impression that this may be a
starting point for the addition of handlers support service URLs.
Cheers, Steve.
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: cvs commit: avalon-sandbox/merlin-jndi/
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stephen,
> It a JNDI ObjectFactory that lets you access a new instance of the
> Merlin Kernel from a JNDI context.
> Context initCtx = new InitialContext();
> Context envCtx = (Context) initCtx.lookup("java:comp/env");
> Kenel kernel = envCtx.lookup("merlin/ServiceFactory");
> Naturally this needs to be backed by a JNDI resource declaration as
> per the Servlet 2.3 spec (or alternative JNDI configuration). That's
> where parameters such as the Merlin system and block definition URLs
> are declared.
Do you have any interest in seeing org.apache.naming moved out of Tomcat
into a common project for others, e.g., Avalon, James, and others, to use?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-sandbox/merlin-jndi/
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> what does this do?
It a JNDI ObjectFactory that lets you access a new instance of the
Merlin Kernel from a JNDI context.
For example, a servlet could do the following:
Context initCtx = new InitialContext();
Context envCtx = (Context) initCtx.lookup("java:comp/env");
Kenel kernel = envCtx.lookup("merlin/ServiceFactory");
Naturally this needs to be backed by a JNDI resource declaration as
per the Servlet 2.3 spec (or alternative JNDI configuration). That's
where parameters such as the Merlin system and block definition URLs
are declared.
>
> I would like to change (or set up) informal sandbox policy: before
> you put a new subproject in sandbox, write up a short proposal for
> the subproject, so everyone knows the project is there and what it
> does. And you'll have to lobby against a -1 of course.
I agree that new projects should be discussed before launching of on
a sandbox commit. However, I do think that the notion of "project"
should be qualified. For example, the merlin-jndi package reflects
good structuring and separation of concerns within and across the
Merlin system. It's all part of the Merlin "project" (from a
functional perspective).
If the structural breakout is problematic it could be repackage but
this would be nothing more that moving deck-chairs. The current
Merlin suite presently includes:
merlin core merlin implementation
merlin-spi Merlin Service Provider Interface API
merlin-jndi Merlin JNDI Connector
merlin-bootstrap Merlin CLI loader
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.orghttp://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org