You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Joe Bohn <jo...@earthlink.net> on 2006/10/05 23:59:16 UTC
micro-G modules(configs)
The following modules are currently included in micro-G.
What of these should we attempt to remove yet from micro-G?
connector-deployer
geronimo-gbean-deployer
hot-deployer
j2ee-deployer
j2ee-security
j2ee-server
j2ee-system
online-deployer
rmi-naming
sharedlib
shutdown
transaction
unavailable-client-deployer
unavailable-ejb-deployer
unavailable-webservices-deployer
I'd like to be able to remove the unavailable* deployers but at the
moment I think they are pretty tightly tied to the j2ee-deployer which
IIUC we need to keep since it is really not just for j2ee deployments.
IIRC I attempted to remove j2ee-deployer earlier and discovered that I
needed this to be able to deploy plugins into micro-G. I think the
other j2ee* modules are likewise required for more than just j2ee
content. Is this true?
I think we might be able to remove hot-deployer ... any thoughts? My
only concern is that if we get too fine grained then it gets difficult
to build up the image to be equivalent for little-G or higher. Right
now to get from micro-G to little-G you need to deploy both the tomcat
or jetty plugin and the corresponding deployer. Removing hot-deployer
will add another item to the list. Thoughts?
Joe
Re: micro-G modules(configs)
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 10/9/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> Anyway, should I put these ideas on the cwiki for discussion /
> clarification? It sounds that this is the general direction we're
> headed in and is rather unique. If we agree in concept it would be
> good to get our web page updated to reflect these goals (vision) of
> the project so people can see where we're going and get involved if
> they're interested.
Sure. Why not!? It's been a while since I marked the thread to read
when the time permits and I must admit I like the concept of
templating. I'm not sure how it's different from config.xml where you
declare your deps, but it's worth to give it a thought again and sort
it out. Or wait, do you want the templating tool to download (from a
local or remote repo) necessary modules and create an assembly? Isn't
it what car-maven-plugin and maven-assembly-plugin together are doing
now?
It's definitely worth to put the idea on the wiki. Even if it dies at
some time (which I doubt) we can move to it later or wipe it out.
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: micro-G modules(configs)
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Oct 6, 2006, at 10:37 AM, Joe Bohn wrote:
>
> I couldn't quite decide what to call it either which is why I'm
> using the term "geronimo-framework" for the assembly. But I'm
> certainly open to other opinions. I don't envision this being
> something that the casual user would pick up directly. I image
> that we would still ship the full j2ee assembly and possibly even
> the minimal assembly. Micro-G would be available for more
> sophisticated users that wanted to build a custom image and for
> vendors who might pick up Micro-G, build their own custom image,
> and then add their own software for redistribution/sale.
Framework makes sense as I think that is where people wanted to go
with Geronimo based on my recollection from many e-mails and
conversations. I'll pop in my 2c here given Joe's comments above.
What makes sense in my twisted mind is that Micro-G provides the core
wiring framework to build a server (as joe indicated). From that we
install plugins to assemble a server. The question then becomes how
would a user consume this? and perhaps we need to define the groups
of users that Geronimo would appeal to. Here is my quick hit list:
J2EE developers - these folks are interested in a server that they
can use to develop and deploy J2EE applications. They are not really
concerned about the plumbing of the server but are more interested in
consuming ready made things like Eclipse, Geronimo, etc. to build an
application.
Application Developer - May not want all the gizmos of J2EE / JEE but
is definitely interested in things like Servlets and Spring. They
would like a server that is sized for their needs and includes the
components they need for their applications to run. People that use
Tomcat + other stuff fall into this category.
System Developers - these folks are more in tune with the server and
its various pieces. They might be interested in the Geronimo Tx
Manager or other piece parts of the server. They are willing to
write GBeans and other Geronimo specific artifacts to accomplish
their goals. They probably want the ability to create custom server
configurations.
ISV's - Pretty much the same as System Developers but might have
targetted deployment environments like Kiosks or embedded devices.
They want to build and distribute Applications and will use Geronimo
as their core runtime infrastructure. They are probably more
interested in stability than innovation as their distributing
applications.
There are probably lots more user types but I think the above covers
the spectrum pretty broadly. With that said, how do we meet their
needs?
If I were in their shoes I would like to be able download either pre-
built server configurations (J2EE certified) or build a custom
assembly. In order to allow both I wonder if it makes sense to
introduce the concept of server templates. Here is what I mean:
Since every assembly we make now is hand turned we could make the
configuration simpler so a user could express their intended server
configuration through an XML file and we provide a generic assembler
that would read this template, resolve dependencies and spit out a
binary server config that could be distributed (downloaded as a
server). The template would allow for command line building of the
server such that a user would not need to interactively build it
(GShell ?)
This means that there would be a distribution of Geronimo that
included micro-G along with all the gorp we normally build. The gorp
would be in a repository format (like plugins or the same) so that a
user could use templates to build a server without being network
connected if they so chose). So we would make the following
available for distribution:
Geronimo J(2)EE certified (1.4 / 5.0, etc.) Tomcat / Jetty
Minimal Tomcat / Jetty
Micro-G (all components to build yur own custom server).
So in effect, the J(2)EE and Minimal servers would simply be
templates that happen to build server assemblies. Of these, the
Geronimo team certifies the J2EE one.
Anyway, should I put these ideas on the cwiki for discussion /
clarification? It sounds that this is the general direction we're
headed in and is rather unique. If we agree in concept it would be
good to get our web page updated to reflect these goals (vision) of
the project so people can see where we're going and get involved if
they're interested.
thoughts?
The thinking above is really a comglomeration of lots of discussion
on the list.
Matt Hogstrom
matt@hogstrom.org
Re: micro-G modules(configs)
Posted by Joe Bohn <jo...@earthlink.net>.
Jacek Laskowski wrote:
> On 10/5/06, Joe Bohn <jo...@earthlink.net> wrote:
>
>>
>> The following modules are currently included in micro-G.
>> What of these should we attempt to remove yet from micro-G?
>
>
> Where are we heading with Micro-G? Do we want to strip off all
> modules, but those that let us download plugins and enhance the
> server?
That's my goal. Just enough of the Geronimo framework to be able to
deploy plugins.
It's not a kernel and neither is it a server. Should we call
> it a container? A plugin container? Will it end up as a OSGi-like
> container that understand GBean-based bundles? Some more help required
> or my brain will melt down.
I couldn't quite decide what to call it either which is why I'm using
the term "geronimo-framework" for the assembly. But I'm certainly open
to other opinions. I don't envision this being something that the
casual user would pick up directly. I image that we would still ship
the full j2ee assembly and possibly even the minimal assembly. Micro-G
would be available for more sophisticated users that wanted to build a
custom image and for vendors who might pick up Micro-G, build their own
custom image, and then add their own software for redistribution/sale.
>
> Jacek
>
Re: micro-G modules(configs)
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 10/5/06, Joe Bohn <jo...@earthlink.net> wrote:
>
> The following modules are currently included in micro-G.
> What of these should we attempt to remove yet from micro-G?
Where are we heading with Micro-G? Do we want to strip off all
modules, but those that let us download plugins and enhance the
server? It's not a kernel and neither is it a server. Should we call
it a container? A plugin container? Will it end up as a OSGi-like
container that understand GBean-based bundles? Some more help required
or my brain will melt down.
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: micro-G modules(configs)
Posted by Joe Bohn <jo...@earthlink.net>.
Yes, we need to keep enough to be able to run the command line deployer.
When I pulled j2ee-deployer I was unable to run the command line
deploy.
more comments/questions below
David Jencks wrote:
>
> On Oct 5, 2006, at 3:52 PM, Aaron Mulder wrote:
>
>> I think we need to keep enough in there that the command-line deploy
>> tool still works. It looks like online-deployer is empty (or else I
>> would have said to keep that), but I think j2ee-security is required
>> for the JMX remoting used by the deploy tool. Without this, I think
>> you'll have to mangle the repository contents and config.xml by hand
>> in order to ever have more than "Micro G" (ick).
>>
>> Anyway, I would also be in favor of separating the specs from RMI
>> naming.
So let me see if I understand the idea here. I can pull the spec
dependencies from RMI naming and create a new config with just those
dependencies. I suspect that I will need to make rmi-naming dependent
on the new spec config but then I think that limits the ability to
easily switch between 1.4 and 1.5 specs. Are the specs not really
required for rmi-naming and currently included just as a way to get the
specs in the image?
>>
>> Thanks,
>> Aaron
>>
>> P.S. Maybe we should whack the online-deployer module and rename
>> "j2ee-security" to just "security" or something.
>
>
> Online-deployer is empty just like the rest of the configs that are
> servers. It relies on manifest classpath and the configuration it
> contains. IIRC online-deployer.car is the same file as deployer.jar.
I was under the impression that this was required for the command line
deploy as well but I'll pull it and see what happens.
> I guess you're right that a little more might be good. I was figuring
> that being able to add plugins might be enough. What connects to the
> plugin installer?
>
> thanks
> david jencks
>
>>
>> On 10/5/06, David Jencks <da...@yahoo.com> wrote:
>>
>>> I marked the ones to remove IMO with an X
>>>
>>> I seem to have a more extreme view of "micro" than you :-)
I'm all for getting micro-G as small as possible so long as we can grow
it easily. I guess if the dependencies are all correct (which is not
the case right now) then installing the higher level plugins should pull
everything else along for the ride.
>>> I'd also prefer to pull the specs out of rmi-naming into a separate
>>> config so we can swap in the jee5 ones more easily.
>>>
>>> thanks
>>> david jencks
>>>
>>> On Oct 5, 2006, at 2:59 PM, Joe Bohn wrote:
>>>
>>> >
>>> > The following modules are currently included in micro-G.
>>> > What of these should we attempt to remove yet from micro-G?
>>> >
>>> > X connector-deployer
OK, I'll attempt to pull this one.
>>> > geronimo-gbean-deployer
>>> > X hot-deployer
I'll pull this one too.
>>> > X j2ee-deployer
So I assume that we really need to keep this for plugin deployment
unless we rework that code some more.
>>> > X j2ee-security
If this isn't really j2ee specific then I can rename it but based upon
Aaron's comments it looks like this is still required in micro-G.
>>> > X j2ee-server
Is it true j2ee-server can be removed? I was under the impress that
this was necessary for some of the management capabilities.
>>> > j2ee-system
>>> > X online-deployer
Is this not necessary for command-line deployement as well?
>>> > rmi-naming
>>> > X sharedlib
Isn't sharelib of value even without the web containers? I didn't think
there was a lot of value in removing this but it's an easy one to pull.
>>> > shutdown
>>> > X transaction
I can look at removing this as well but I was under the impression that
the transaction capability was general purpose and not tied directly to
j2ee.
>>> > X unavailable-client-deployer
>>> > X unavailable-ejb-deployer
>>> > X unavailable-webservices-deployer
I think these three unavailable* configs are necessary so long as we
keep the j2ee-deployer.
>>> >
>>> > I'd like to be able to remove the unavailable* deployers but at the
>>> > moment I think they are pretty tightly tied to the j2ee-deployer
>>> > which IIUC we need to keep since it is really not just for j2ee
>>> > deployments. IIRC I attempted to remove j2ee-deployer earlier and
>>> > discovered that I needed this to be able to deploy plugins into
>>> > micro-G. I think the other j2ee* modules are likewise required for
>>> > more than just j2ee content. Is this true?
>>> >
>>> > I think we might be able to remove hot-deployer ... any thoughts?
>>> > My only concern is that if we get too fine grained then it gets
>>> > difficult to build up the image to be equivalent for little-G or
>>> > higher. Right now to get from micro-G to little-G you need to
>>> > deploy both the tomcat or jetty plugin and the corresponding
>>> > deployer. Removing hot-deployer will add another item to the
>>> > list. Thoughts?
>>> >
>>> > Joe
>>> >
>>> >
>>>
>>>
>
>
>
Re: micro-G modules(configs)
Posted by David Jencks <da...@yahoo.com>.
On Oct 9, 2006, at 12:55 PM, Aaron Mulder wrote:
> On 10/5/06, David Jencks <da...@yahoo.com> wrote:
>> Online-deployer is empty just like the rest of the configs that are
>> servers. It relies on manifest classpath and the configuration it
>> contains. IIRC online-deployer.car is the same file as
>> deployer.jar. I guess you're right that a little more might be
>> good. I was figuring that being able to add plugins might be
>> enough. What connects to the plugin installer?
>
> Ah, OK. We need the command-line deploy tool (which I gather means
> online-deployer as well as j2ee-security, and perhaps per Joe's
> comment j2ee-deployer). The actual plugin installer is located in the
> system module which I think is in rmi-naming, and IIRC the deploy tool
> just uses the remote Kernel proxy thingy to talk to the plugin
> installer, but I'd have to look to be sure.
>
> It may be that j2ee-deployer is not required in order to use the
> search-plugins and install-plugins commands but would be required in
> order to use the other commands. But it may also be that JSR-88 isn't
> in the class path without e.g. j2ee-deployer and therefore the classes
> used by the deploy tool couldn't be located and it would die. If
> that's the case, we may just be able to shift some of the JAR
> dependencies around to avoid needing the full j2ee-deployer...
We _really_ shouldn't need to start j2ee-deployer in order to do any
of this. If there really are problems and the solutions aren't
obvious please start opening jiras for them.
thanks
david jencks
>
> Thanks,
> Aaron
Re: micro-G modules(configs)
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 10/5/06, David Jencks <da...@yahoo.com> wrote:
> Online-deployer is empty just like the rest of the configs that are
> servers. It relies on manifest classpath and the configuration it
> contains. IIRC online-deployer.car is the same file as
> deployer.jar. I guess you're right that a little more might be
> good. I was figuring that being able to add plugins might be
> enough. What connects to the plugin installer?
Ah, OK. We need the command-line deploy tool (which I gather means
online-deployer as well as j2ee-security, and perhaps per Joe's
comment j2ee-deployer). The actual plugin installer is located in the
system module which I think is in rmi-naming, and IIRC the deploy tool
just uses the remote Kernel proxy thingy to talk to the plugin
installer, but I'd have to look to be sure.
It may be that j2ee-deployer is not required in order to use the
search-plugins and install-plugins commands but would be required in
order to use the other commands. But it may also be that JSR-88 isn't
in the class path without e.g. j2ee-deployer and therefore the classes
used by the deploy tool couldn't be located and it would die. If
that's the case, we may just be able to shift some of the JAR
dependencies around to avoid needing the full j2ee-deployer...
Thanks,
Aaron
Re: micro-G modules(configs)
Posted by David Jencks <da...@yahoo.com>.
On Oct 5, 2006, at 3:52 PM, Aaron Mulder wrote:
> I think we need to keep enough in there that the command-line deploy
> tool still works. It looks like online-deployer is empty (or else I
> would have said to keep that), but I think j2ee-security is required
> for the JMX remoting used by the deploy tool. Without this, I think
> you'll have to mangle the repository contents and config.xml by hand
> in order to ever have more than "Micro G" (ick).
>
> Anyway, I would also be in favor of separating the specs from RMI
> naming.
>
> Thanks,
> Aaron
>
> P.S. Maybe we should whack the online-deployer module and rename
> "j2ee-security" to just "security" or something.
Online-deployer is empty just like the rest of the configs that are
servers. It relies on manifest classpath and the configuration it
contains. IIRC online-deployer.car is the same file as
deployer.jar. I guess you're right that a little more might be
good. I was figuring that being able to add plugins might be
enough. What connects to the plugin installer?
thanks
david jencks
>
> On 10/5/06, David Jencks <da...@yahoo.com> wrote:
>> I marked the ones to remove IMO with an X
>>
>> I seem to have a more extreme view of "micro" than you :-)
>> I'd also prefer to pull the specs out of rmi-naming into a separate
>> config so we can swap in the jee5 ones more easily.
>>
>> thanks
>> david jencks
>>
>> On Oct 5, 2006, at 2:59 PM, Joe Bohn wrote:
>>
>> >
>> > The following modules are currently included in micro-G.
>> > What of these should we attempt to remove yet from micro-G?
>> >
>> > X connector-deployer
>> > geronimo-gbean-deployer
>> > X hot-deployer
>> > X j2ee-deployer
>> > X j2ee-security
>> > X j2ee-server
>> > j2ee-system
>> > X online-deployer
>> > rmi-naming
>> > X sharedlib
>> > shutdown
>> > X transaction
>> > X unavailable-client-deployer
>> > X unavailable-ejb-deployer
>> > X unavailable-webservices-deployer
>> >
>> > I'd like to be able to remove the unavailable* deployers but at the
>> > moment I think they are pretty tightly tied to the j2ee-deployer
>> > which IIUC we need to keep since it is really not just for j2ee
>> > deployments. IIRC I attempted to remove j2ee-deployer earlier and
>> > discovered that I needed this to be able to deploy plugins into
>> > micro-G. I think the other j2ee* modules are likewise required for
>> > more than just j2ee content. Is this true?
>> >
>> > I think we might be able to remove hot-deployer ... any thoughts?
>> > My only concern is that if we get too fine grained then it gets
>> > difficult to build up the image to be equivalent for little-G or
>> > higher. Right now to get from micro-G to little-G you need to
>> > deploy both the tomcat or jetty plugin and the corresponding
>> > deployer. Removing hot-deployer will add another item to the
>> > list. Thoughts?
>> >
>> > Joe
>> >
>> >
>>
>>
Re: micro-G modules(configs)
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I think we need to keep enough in there that the command-line deploy
tool still works. It looks like online-deployer is empty (or else I
would have said to keep that), but I think j2ee-security is required
for the JMX remoting used by the deploy tool. Without this, I think
you'll have to mangle the repository contents and config.xml by hand
in order to ever have more than "Micro G" (ick).
Anyway, I would also be in favor of separating the specs from RMI naming.
Thanks,
Aaron
P.S. Maybe we should whack the online-deployer module and rename
"j2ee-security" to just "security" or something.
On 10/5/06, David Jencks <da...@yahoo.com> wrote:
> I marked the ones to remove IMO with an X
>
> I seem to have a more extreme view of "micro" than you :-)
> I'd also prefer to pull the specs out of rmi-naming into a separate
> config so we can swap in the jee5 ones more easily.
>
> thanks
> david jencks
>
> On Oct 5, 2006, at 2:59 PM, Joe Bohn wrote:
>
> >
> > The following modules are currently included in micro-G.
> > What of these should we attempt to remove yet from micro-G?
> >
> > X connector-deployer
> > geronimo-gbean-deployer
> > X hot-deployer
> > X j2ee-deployer
> > X j2ee-security
> > X j2ee-server
> > j2ee-system
> > X online-deployer
> > rmi-naming
> > X sharedlib
> > shutdown
> > X transaction
> > X unavailable-client-deployer
> > X unavailable-ejb-deployer
> > X unavailable-webservices-deployer
> >
> > I'd like to be able to remove the unavailable* deployers but at the
> > moment I think they are pretty tightly tied to the j2ee-deployer
> > which IIUC we need to keep since it is really not just for j2ee
> > deployments. IIRC I attempted to remove j2ee-deployer earlier and
> > discovered that I needed this to be able to deploy plugins into
> > micro-G. I think the other j2ee* modules are likewise required for
> > more than just j2ee content. Is this true?
> >
> > I think we might be able to remove hot-deployer ... any thoughts?
> > My only concern is that if we get too fine grained then it gets
> > difficult to build up the image to be equivalent for little-G or
> > higher. Right now to get from micro-G to little-G you need to
> > deploy both the tomcat or jetty plugin and the corresponding
> > deployer. Removing hot-deployer will add another item to the
> > list. Thoughts?
> >
> > Joe
> >
> >
>
>
Re: micro-G modules(configs)
Posted by David Jencks <da...@yahoo.com>.
I marked the ones to remove IMO with an X
I seem to have a more extreme view of "micro" than you :-)
I'd also prefer to pull the specs out of rmi-naming into a separate
config so we can swap in the jee5 ones more easily.
thanks
david jencks
On Oct 5, 2006, at 2:59 PM, Joe Bohn wrote:
>
> The following modules are currently included in micro-G.
> What of these should we attempt to remove yet from micro-G?
>
> X connector-deployer
> geronimo-gbean-deployer
> X hot-deployer
> X j2ee-deployer
> X j2ee-security
> X j2ee-server
> j2ee-system
> X online-deployer
> rmi-naming
> X sharedlib
> shutdown
> X transaction
> X unavailable-client-deployer
> X unavailable-ejb-deployer
> X unavailable-webservices-deployer
>
> I'd like to be able to remove the unavailable* deployers but at the
> moment I think they are pretty tightly tied to the j2ee-deployer
> which IIUC we need to keep since it is really not just for j2ee
> deployments. IIRC I attempted to remove j2ee-deployer earlier and
> discovered that I needed this to be able to deploy plugins into
> micro-G. I think the other j2ee* modules are likewise required for
> more than just j2ee content. Is this true?
>
> I think we might be able to remove hot-deployer ... any thoughts?
> My only concern is that if we get too fine grained then it gets
> difficult to build up the image to be equivalent for little-G or
> higher. Right now to get from micro-G to little-G you need to
> deploy both the tomcat or jetty plugin and the corresponding
> deployer. Removing hot-deployer will add another item to the
> list. Thoughts?
>
> Joe
>
>