Re: micro-G modules(configs)
On 10/9/06, Matt Hogstrom <[EMAIL PROTECTED]> 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)
On Oct 9, 2006, at 12:55 PM, Aaron Mulder wrote: On 10/5/06, David Jencks <[EMAIL PROTECTED]> 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)
On 10/5/06, David Jencks <[EMAIL PROTECTED]> 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)
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 [EMAIL PROTECTED]
Re: micro-G modules(configs)
Jacek Laskowski wrote: On 10/5/06, Joe Bohn <[EMAIL PROTECTED]> 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)
On 10/5/06, Joe Bohn <[EMAIL PROTECTED]> 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)
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 <[EMAIL PROTECTED]> 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)
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 <[EMAIL PROTECTED]> 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)
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 <[EMAIL PROTECTED]> 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)
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
