You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2003/10/20 06:27:37 UTC
embedding strategies?
Based on posts over the last week or so, combined with what is in place
on the subject of kernel embedded, I'm trying to figure out a good
direction.
Context - current embedding approaches:
1. the kernel/bootstrap package (a CLI based loader)
2. the maven merlin plugin (maven project context)
3. abstract unit test in kernel/unit (maven project context)
4. Alexis Agahi' work on re. Avalon in JBoss and OpenIM
5. Timmothy Bennets work on Jetty
6. Peter Courcoux work in embedding inside a web-app for Turbine
Generally speaking these embeddors do the following:
1. provides a single boostrap jar file package
2. collects kernel arguments relative to the embedded context
3. builds the kernel context
4. deploys the kernel
5. provides environment specific controls
Generalizing again - about the only thing really common across the above
is the kernel context and the kernel itself. As things have been moving
forward - the kernel interfaces have been updated to better address
embedded requirements. At the same time things are somewhat fragmented
in the area of kernel control.
My own feeling about the current control code within the embeddors with
the CVS repository is that - it could really be improved. With a clean
controller the code needed to setup the kernel could be consolidated and
and the suite of different embeddors could be simplified and the core
code centralized – under merlin/kernel/control (for example).
What are other peoples thoughts about the current kernel loaders (I
think we can do better that the content I've written). Any ideas on what
a kernel controller would look like? Perhaps a controller would
aggregate info form the context and the runtime kernel and it would also
be the MBean point of access. Maybe taking Alexis' content as the MBean
starting point for a controller, perhaps moving this closer to the
DefaultEmbeddedKernel or perhaps recutting DefaultEmbeddedKernel to be a
DefaultKernelController that hides all of the thread stuff. With
something like that we could backport the functionality into the
plugins, abstract test case, and other related embeddors.
Ok, enough from me!
:-)
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: embedding strategies?
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
>
> Based on posts over the last week or so, combined with what is in
> place on the subject of kernel embedded, I'm trying to figure out a
> good direction.
>
> Context - current embedding approaches:
>
> 1. the kernel/bootstrap package (a CLI based loader)
> 2. the maven merlin plugin (maven project context)
> 3. abstract unit test in kernel/unit (maven project context)
> 4. Alexis Agahi' work on re. Avalon in JBoss and OpenIM
> 5. Timmothy Bennets work on Jetty
> 6. Peter Courcoux work in embedding inside a web-app for Turbine
And am I plain stupid or what? I didn't include the ldapd effort linked
to Alex Karasulu (incubator project). That's a project that is
fundimentally interested in embedding Avalon. Think contaner embedded
inside a JNI context - lots of really cool local and remote stuff. If
I've missed any other embedded scenarios - let us know!
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: embedding strategies?
Posted by Stephen McConnell <mc...@apache.org>.
Alexis Agahi wrote:
>On Monday 20 October 2003 09:07, Stephen McConnell wrote:
>
>
>
>>Super!
>>What I have in the back of my head is one controller class and a bunch
>>of different embeddors that all use the same controller.
>>
>>
>
>I'm currently reading jboss source to understand the deployer :)
>
>
>
>
>>>I'm also ready to dig the Eclipse pluging path (if required).
>>>
>>>
>>Maybe a skeleton could be interesting - i.e. the some bootstrap suff to
>>link into Eclipse - and then we add out internal spells!
>>
>>
>
>of course!
>
>if( "@author".equals( "mcconnell@nosp@m.apache.org" ) )
>{
> System.exit();
>}
>
>:)
>
ROTFL ..
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: embedding strategies?
Posted by Alexis Agahi <al...@users.sf.net>.
On Monday 20 October 2003 09:07, Stephen McConnell wrote:
> Super!
> What I have in the back of my head is one controller class and a bunch
> of different embeddors that all use the same controller.
I'm currently reading jboss source to understand the deployer :)
> >I'm also ready to dig the Eclipse pluging path (if required).
>
> Maybe a skeleton could be interesting - i.e. the some bootstrap suff to
> link into Eclipse - and then we add out internal spells!
of course!
if( "@author".equals( "mcconnell@nosp@m.apache.org" ) )
{
System.exit();
}
:)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: embedding strategies?
Posted by Stephen McConnell <mc...@apache.org>.
Alexis Agahi wrote:
>On Monday 20 October 2003 06:27, Stephen McConnell wrote:
>
>
>
>>What are other peoples thoughts about the current kernel loaders (I
>>think we can do better that the content I've written). Any ideas on what
>>a kernel controller would look like? Perhaps a controller would
>>aggregate info form the context and the runtime kernel and it would also
>>be the MBean point of access. Maybe taking Alexis' content as the MBean
>>starting point for a controller, perhaps moving this closer to the
>>DefaultEmbeddedKernel or perhaps recutting DefaultEmbeddedKernel to be a
>>DefaultKernelController that hides all of the thread stuff. With
>>something like that we could backport the functionality into the
>>plugins, abstract test case, and other related embeddors.
>>
>>
>
>the MBean/Jboss approach, provide compatibility with all current JBoss
>applications. I'm not sure this is the best solution, but this could be
>considered as A solution.
>
>I'm going to spend few hours on this to check if there are some pitfalls.
>
Super!
What I have in the back of my head is one controller class and a bunch
of different embeddors that all use the same controller.
>
>
>I'm also ready to dig the Eclipse pluging path (if required).
>
Maybe a skeleton could be interesting - i.e. the some bootstrap suff to
link into Eclipse - and then we add out internal spells!
Steve.
>---------------------------------------------------------------------
>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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: embedding strategies?
Posted by Alexis Agahi <al...@users.sf.net>.
On Monday 20 October 2003 06:27, Stephen McConnell wrote:
> What are other peoples thoughts about the current kernel loaders (I
> think we can do better that the content I've written). Any ideas on what
> a kernel controller would look like? Perhaps a controller would
> aggregate info form the context and the runtime kernel and it would also
> be the MBean point of access. Maybe taking Alexis' content as the MBean
> starting point for a controller, perhaps moving this closer to the
> DefaultEmbeddedKernel or perhaps recutting DefaultEmbeddedKernel to be a
> DefaultKernelController that hides all of the thread stuff. With
> something like that we could backport the functionality into the
> plugins, abstract test case, and other related embeddors.
the MBean/Jboss approach, provide compatibility with all current JBoss
applications. I'm not sure this is the best solution, but this could be
considered as A solution.
I'm going to spend few hours on this to check if there are some pitfalls.
I'm also ready to dig the Eclipse pluging path (if required).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org