You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2006/03/25 00:24:01 UTC
New Feature: Configuration Import/Export
I've just added a new feature to the console whereby it can export an
installed configuration to a CAR file, and also install previously
uninstalled configurations (CAR files and dependency JAR files) from a
Maven repository (though at present, it depends on a properties file
being in the repository the provide some metadata on the available
CARs). It also still doesn't have any reasonable feedback during the
download process.
Anyway, I'm not really looking at this as a final definition of the
feature, more a look at what we can do so we can talk about the best
way to do it. (For example, we've talked about how it would be nice
to have command-line tools to do this, and while some of the code
could be extracted, we'd potentially need a separate file upload
solution, if we can't reuse the remote-deploy web app. Also, it can
only install from a Maven repo [vs a direct file upload] so it can
fetch needed dependencies. Also, it doesn't take advantage of the
soon-to-be-on-iBiblio Maven repository manager.)
As a conversation starter, it would be nice to distribute Geronimo
without any sample applications to make it a little leaner and faster
to start -- just have the screen in the console that lets you download
and install any of them that you want. I also think it would be nice
to distribute without Directory and some of the other add-ons, and
provide the ability to download and install those, ServiceMix, Quartz,
and other packages we know of integration for.
If you want to take a look at this, there's an Import/Export entry in
the application part of the console navigation bar (in HEAD). You
need to set up some Maven repo to point it to (though for a REAL quick
start you can just use a file URL like
file:///home/ammulder/.maven/repository). And then you need a file in
the root of the Maven repo called geronimo-configurations.properties
with entries like this:
Category.ConfigId=Description
Then enter the URL to your Maven repo in the screen in the console,
and it'll list all the configurations from the properties file,
grouped by the categories you specified, and let you install anything
that's not already available in the local server. I've attached a
sample that exposes some of the Geronimo web apps if you want a real,
real quick start.
Thanks,
Aaron
Re: New Feature: Configuration Import/Export
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Right now the console lets you view the dependencies before deciding
whether to proceed (though it has to at least download the CAR to get
that information), and likewise gives you a button you have to click
to start the configuration you just installed. The command-line tool
is so far a bit more primitive. It gives you a list of available
configurations, and if you select one, it's installed with all its
dependencies and started.
I'm not sure it's worth going much further with this before we define
an external format to hold the dependency information (such as an XML
file per artifact). I would hope to wait for the Maven 2 conversion
for that, since Maven 2 already has metadata in the repository, though
it's not strictly necessary.
As far as the file that lists all the available artifacts for
Geronimo, I'm not sure we need to make it corespond to a Geronimo
release. I was thinking more that it would list all the artifacts and
each one would say which Geronimo release(s) it works with. I
certainly don't want to have to provide a new file for every dot
release of Geronimo. Let's just try to get it right and use a parsing
routine that will be forgiving of future enhancements.
I'd like to learn a little more about how Maven 2 maintains the
metadata in the repository -- it seems like it already has per
artifact/version, per artifact, and per repository metadata support,
though I don't know what handles the updates and merges to those
metadata files.
Thanks,
Aaron
On 3/27/06, Donald Woods <dr...@yahoo.com> wrote:
> What are you thoughts on dependencies within a selected CAR?
> It would be nice to see that by choosing Daytrader, you would also be
> install the Corba, Axis and ActiveMQ plans while selecting the LDAP demo
> would pull in the ApacheDS configuration. Users will probably want a
> way to see/list what prerequisites are required for each configuration
> along with the estimated diskspace required before they deploy it, via
> something like a 'deploy list-configs' option.
>
> I think going with an XML format similar to the project.xml files for
> the current geronimo-configuration.properties file is a good way to go.
> It gives us and end-users a way to provide more than just CAR files
> (like WAR/EAR applications and JDBC drivers), apply validation to the
> file during the build and potentially use Maven or the Eclipse Maven
> plug-in for building server instances from scratch.
>
> I assume we would have a configuration file per release? Something like
> geronimo-configs-1.2.xml, which would allow us to change our configs
> package structure and available packages between releases.
>
>
>
> -Donald
>
>
> Aaron Mulder wrote:
> > This now works from the command line too:
> >
> > java -jar bin/deployer.jar install-configs http://localhost/maven/
> >
> > But you still need the geronimo-configurations.properties in the root
> > of the Maven repo. I'm thinking of changing that to an XML format
> > since there's at least one more piece of information that it would be
> > nice to fit in there -- namely, the version of Geronimo that this
> > particular CAR is expected to work in. We may even consider
> > explicitly breaking out the web container for web app configurations
> > so we don't bother listing all the Tomcat apps if you have a Jetty
> > server and vice versa.
> >
> > Thanks,
> > Aaron
> >
> > On 3/24/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> >
> >>I've just added a new feature to the console whereby it can export an
> >>installed configuration to a CAR file, and also install previously
> >>uninstalled configurations (CAR files and dependency JAR files) from a
> >>Maven repository (though at present, it depends on a properties file
> >>being in the repository the provide some metadata on the available
> >>CARs). It also still doesn't have any reasonable feedback during the
> >>download process.
> >>
> >>Anyway, I'm not really looking at this as a final definition of the
> >>feature, more a look at what we can do so we can talk about the best
> >>way to do it. (For example, we've talked about how it would be nice
> >>to have command-line tools to do this, and while some of the code
> >>could be extracted, we'd potentially need a separate file upload
> >>solution, if we can't reuse the remote-deploy web app. Also, it can
> >>only install from a Maven repo [vs a direct file upload] so it can
> >>fetch needed dependencies. Also, it doesn't take advantage of the
> >>soon-to-be-on-iBiblio Maven repository manager.)
> >>
> >>As a conversation starter, it would be nice to distribute Geronimo
> >>without any sample applications to make it a little leaner and faster
> >>to start -- just have the screen in the console that lets you download
> >>and install any of them that you want. I also think it would be nice
> >>to distribute without Directory and some of the other add-ons, and
> >>provide the ability to download and install those, ServiceMix, Quartz,
> >>and other packages we know of integration for.
> >>
> >>If you want to take a look at this, there's an Import/Export entry in
> >>the application part of the console navigation bar (in HEAD). You
> >>need to set up some Maven repo to point it to (though for a REAL quick
> >>start you can just use a file URL like
> >>file:///home/ammulder/.maven/repository). And then you need a file in
> >>the root of the Maven repo called geronimo-configurations.properties
> >>with entries like this:
> >>
> >>Category.ConfigId=Description
> >>
> >>Then enter the URL to your Maven repo in the screen in the console,
> >>and it'll list all the configurations from the properties file,
> >>grouped by the categories you specified, and let you install anything
> >>that's not already available in the local server. I've attached a
> >>sample that exposes some of the Geronimo web apps if you want a real,
> >>real quick start.
> >>
> >>Thanks,
> >> Aaron
> >>
> >>
> >>
> >
> >
> >
>
>
>
Re: New Feature: Configuration Import/Export
Posted by Donald Woods <dr...@yahoo.com>.
What are you thoughts on dependencies within a selected CAR?
It would be nice to see that by choosing Daytrader, you would also be
install the Corba, Axis and ActiveMQ plans while selecting the LDAP demo
would pull in the ApacheDS configuration. Users will probably want a
way to see/list what prerequisites are required for each configuration
along with the estimated diskspace required before they deploy it, via
something like a 'deploy list-configs' option.
I think going with an XML format similar to the project.xml files for
the current geronimo-configuration.properties file is a good way to go.
It gives us and end-users a way to provide more than just CAR files
(like WAR/EAR applications and JDBC drivers), apply validation to the
file during the build and potentially use Maven or the Eclipse Maven
plug-in for building server instances from scratch.
I assume we would have a configuration file per release? Something like
geronimo-configs-1.2.xml, which would allow us to change our configs
package structure and available packages between releases.
-Donald
Aaron Mulder wrote:
> This now works from the command line too:
>
> java -jar bin/deployer.jar install-configs http://localhost/maven/
>
> But you still need the geronimo-configurations.properties in the root
> of the Maven repo. I'm thinking of changing that to an XML format
> since there's at least one more piece of information that it would be
> nice to fit in there -- namely, the version of Geronimo that this
> particular CAR is expected to work in. We may even consider
> explicitly breaking out the web container for web app configurations
> so we don't bother listing all the Tomcat apps if you have a Jetty
> server and vice versa.
>
> Thanks,
> Aaron
>
> On 3/24/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
>
>>I've just added a new feature to the console whereby it can export an
>>installed configuration to a CAR file, and also install previously
>>uninstalled configurations (CAR files and dependency JAR files) from a
>>Maven repository (though at present, it depends on a properties file
>>being in the repository the provide some metadata on the available
>>CARs). It also still doesn't have any reasonable feedback during the
>>download process.
>>
>>Anyway, I'm not really looking at this as a final definition of the
>>feature, more a look at what we can do so we can talk about the best
>>way to do it. (For example, we've talked about how it would be nice
>>to have command-line tools to do this, and while some of the code
>>could be extracted, we'd potentially need a separate file upload
>>solution, if we can't reuse the remote-deploy web app. Also, it can
>>only install from a Maven repo [vs a direct file upload] so it can
>>fetch needed dependencies. Also, it doesn't take advantage of the
>>soon-to-be-on-iBiblio Maven repository manager.)
>>
>>As a conversation starter, it would be nice to distribute Geronimo
>>without any sample applications to make it a little leaner and faster
>>to start -- just have the screen in the console that lets you download
>>and install any of them that you want. I also think it would be nice
>>to distribute without Directory and some of the other add-ons, and
>>provide the ability to download and install those, ServiceMix, Quartz,
>>and other packages we know of integration for.
>>
>>If you want to take a look at this, there's an Import/Export entry in
>>the application part of the console navigation bar (in HEAD). You
>>need to set up some Maven repo to point it to (though for a REAL quick
>>start you can just use a file URL like
>>file:///home/ammulder/.maven/repository). And then you need a file in
>>the root of the Maven repo called geronimo-configurations.properties
>>with entries like this:
>>
>>Category.ConfigId=Description
>>
>>Then enter the URL to your Maven repo in the screen in the console,
>>and it'll list all the configurations from the properties file,
>>grouped by the categories you specified, and let you install anything
>>that's not already available in the local server. I've attached a
>>sample that exposes some of the Geronimo web apps if you want a real,
>>real quick start.
>>
>>Thanks,
>> Aaron
>>
>>
>>
>
>
>
Re: New Feature: Configuration Import/Export
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
This now works from the command line too:
java -jar bin/deployer.jar install-configs http://localhost/maven/
But you still need the geronimo-configurations.properties in the root
of the Maven repo. I'm thinking of changing that to an XML format
since there's at least one more piece of information that it would be
nice to fit in there -- namely, the version of Geronimo that this
particular CAR is expected to work in. We may even consider
explicitly breaking out the web container for web app configurations
so we don't bother listing all the Tomcat apps if you have a Jetty
server and vice versa.
Thanks,
Aaron
On 3/24/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> I've just added a new feature to the console whereby it can export an
> installed configuration to a CAR file, and also install previously
> uninstalled configurations (CAR files and dependency JAR files) from a
> Maven repository (though at present, it depends on a properties file
> being in the repository the provide some metadata on the available
> CARs). It also still doesn't have any reasonable feedback during the
> download process.
>
> Anyway, I'm not really looking at this as a final definition of the
> feature, more a look at what we can do so we can talk about the best
> way to do it. (For example, we've talked about how it would be nice
> to have command-line tools to do this, and while some of the code
> could be extracted, we'd potentially need a separate file upload
> solution, if we can't reuse the remote-deploy web app. Also, it can
> only install from a Maven repo [vs a direct file upload] so it can
> fetch needed dependencies. Also, it doesn't take advantage of the
> soon-to-be-on-iBiblio Maven repository manager.)
>
> As a conversation starter, it would be nice to distribute Geronimo
> without any sample applications to make it a little leaner and faster
> to start -- just have the screen in the console that lets you download
> and install any of them that you want. I also think it would be nice
> to distribute without Directory and some of the other add-ons, and
> provide the ability to download and install those, ServiceMix, Quartz,
> and other packages we know of integration for.
>
> If you want to take a look at this, there's an Import/Export entry in
> the application part of the console navigation bar (in HEAD). You
> need to set up some Maven repo to point it to (though for a REAL quick
> start you can just use a file URL like
> file:///home/ammulder/.maven/repository). And then you need a file in
> the root of the Maven repo called geronimo-configurations.properties
> with entries like this:
>
> Category.ConfigId=Description
>
> Then enter the URL to your Maven repo in the screen in the console,
> and it'll list all the configurations from the properties file,
> grouped by the categories you specified, and let you install anything
> that's not already available in the local server. I've attached a
> sample that exposes some of the Geronimo web apps if you want a real,
> real quick start.
>
> Thanks,
> Aaron
>
>
>
Re: New Feature: Configuration Import/Export
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
OK, I've put some more work into this feature.
Now you can have one Geronimo server download and install
configurations from another Geronimo server. In other words, the
console has a servlet that behaves as a Maven repository, and the
configuration import process now supports repositories that use HTTP
Basic auth (for the console anyway; not the command-line tool yet).
I also changed the configuration list format to XML. If you want a
sample, look at
http://localhost:8080/console-standard/maven-repo/geronimo-configs.xml
(in HEAD) and use the admin username and password (in this case it
generates the XML on the fly from the contents of your config store).
Finally, you'll no longer be prompted for Tomcat apps if you're
running Jetty and vice versa, and each configuration can say which
versions of Geronimo it supports and you'll only be prompted for
configurations where either no version was listed or there was a
version match.
Thanks,
Aaron
On 3/24/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> I've just added a new feature to the console whereby it can export an
> installed configuration to a CAR file, and also install previously
> uninstalled configurations (CAR files and dependency JAR files) from a
> Maven repository (though at present, it depends on a properties file
> being in the repository the provide some metadata on the available
> CARs). It also still doesn't have any reasonable feedback during the
> download process.
>
> Anyway, I'm not really looking at this as a final definition of the
> feature, more a look at what we can do so we can talk about the best
> way to do it. (For example, we've talked about how it would be nice
> to have command-line tools to do this, and while some of the code
> could be extracted, we'd potentially need a separate file upload
> solution, if we can't reuse the remote-deploy web app. Also, it can
> only install from a Maven repo [vs a direct file upload] so it can
> fetch needed dependencies. Also, it doesn't take advantage of the
> soon-to-be-on-iBiblio Maven repository manager.)
>
> As a conversation starter, it would be nice to distribute Geronimo
> without any sample applications to make it a little leaner and faster
> to start -- just have the screen in the console that lets you download
> and install any of them that you want. I also think it would be nice
> to distribute without Directory and some of the other add-ons, and
> provide the ability to download and install those, ServiceMix, Quartz,
> and other packages we know of integration for.
>
> If you want to take a look at this, there's an Import/Export entry in
> the application part of the console navigation bar (in HEAD). You
> need to set up some Maven repo to point it to (though for a REAL quick
> start you can just use a file URL like
> file:///home/ammulder/.maven/repository). And then you need a file in
> the root of the Maven repo called geronimo-configurations.properties
> with entries like this:
>
> Category.ConfigId=Description
>
> Then enter the URL to your Maven repo in the screen in the console,
> and it'll list all the configurations from the properties file,
> grouped by the categories you specified, and let you install anything
> that's not already available in the local server. I've attached a
> sample that exposes some of the Geronimo web apps if you want a real,
> real quick start.
>
> Thanks,
> Aaron
>
>
>
Re: New Feature: Configuration Import/Export
Posted by Dain Sundstrom <da...@iq80.com>.
On Mar 27, 2006, at 6:39 AM, Donald Woods wrote:
> For #4, would requiring Eclipse or just the Eclipse RCP client
> package (about 5MB) be okay as the base UI? Seems that we could
> extend the current Eclipse plug-in (or create a second one) to
> allow users to create an installed server from a Maven repo as
> Aaron has demonstrated and then setup a server instance in Eclipse
> if they wish for development usage....
Why not just use a zip or tar.gz?
> One thing I would like to see as part of whatever solution we
> create, is to start using the Apache maven repository and always
> push nightly, milestone and released builds to that sevrer in
> addition to ibiblio server (which in the past several months has
> become very unresponsive during the day due to high traffic - at
> least on the US East coast.)
FWIU, we don't publish directly to ibiblio, but instead publish to
the Apache maven repository and this is mirrored to ibiblio.
-dain
Re: New Feature: Configuration Import/Export
Posted by Donald Woods <dr...@yahoo.com>.
For #3, do you imagine a website that would dynamically generate the
download package for the user, or require them to have Java and possibly
other developer tools (like Cygwin, Ant or Maven)? One thought, would
be to reuse the Izpack work to create an "Installer" front-end, but I'm
worried about the slow download times during the day for ibiblio and
planetmirror....
For #4, would requiring Eclipse or just the Eclipse RCP client package
(about 5MB) be okay as the base UI? Seems that we could extend the
current Eclipse plug-in (or create a second one) to allow users to
create an installed server from a Maven repo as Aaron has demonstrated
and then setup a server instance in Eclipse if they wish for development
usage....
One thing I would like to see as part of whatever solution we create, is
to start using the Apache maven repository and always push nightly,
milestone and released builds to that sevrer in addition to ibiblio
server (which in the past several months has become very unresponsive
during the day due to high traffic - at least on the US East coast.)
-Donald
Matt Hogstrom wrote:
> Aaron,
>
> I'll set this up later and give it a spin. I think everyone has been
> considering how to get to the pluggable server so I'll throw in my 2c
> about what I think would be useful from a user perspective. I don't
> know enough about the internals of G to know how to implement it though.
>
> AppServers that I'm aware of all operate under the paradigm of
> installing the AppServer and then iteratively defining resources
> (DataSources, JMS Queues, etc.) and then installing and maintainging the
> applications that run in the containers. Of course they are all
> monolithic monsters that have everything in them that most people don't
> want or need.
>
> I think Little-G and now the work your doing are the right direction and
> are a new paradigm for the industry. Here are tyhe scenarios that I
> think make sense as being useful.
>
> 1. User downloads a full Geronimo instance and does initial
> customization using the installer. Pretty much like the paradigm
> described above.
>
> 2. User downloads a bootstrap agent (much like Cygwin) and then chooses
> either the pacakges they want (specific OSS projects) or the features
> they want (JMS, Servlet 2.4, EJB 1.1, Spring, etc.) The downloaded
> agent would resolve the required dependencies and suck down the
> appropriate parts and configure the runtime.
>
> 3. Similar paradigm to above but rather than running a single server
> instance they would specify a target location to export a server image
> that would be bootable. The instance they operate from is an AppServer
> factory and not an AppServer instance. The interfaces would include a
> GUI (nice user interface, dynamic resolution of dependencies, etc.) as
> well as a command line utility that could build the instances required
> for a specific set of applications.
>
>
> 4. A variation on the above would also install the application artifacts
> and create disposable runtimes. Users could then take these images and
> distribute them in a cluster and they would be fully functional
> containers but are designed to be disposed of after use. The paradigm
> of defining and iterating a server instance doesn't exist in this mode.
> The "disposable" instances would be able to federate into a managable
> cluster from an operations perspective but would be limited to starting
> and stopping the servers and pulling runtime statistics.
>
> Anyway, personally I'm interested in options 3 and 4. I think its a
> fresh approach to managed runtimes and provides all the functionality of
> J2EE and other programming models without much of the fuss.
>
> The term I use fo rthe above is Geronimo MTO (Made to Order). Kind of
> like Burger King where you can have it your way.
>
> I'd appreciate comments on the above.
>
> Matt
>
> Aaron Mulder wrote:
>
>> I've just added a new feature to the console whereby it can export an
>> installed configuration to a CAR file, and also install previously
>> uninstalled configurations (CAR files and dependency JAR files) from a
>> Maven repository (though at present, it depends on a properties file
>> being in the repository the provide some metadata on the available
>> CARs). It also still doesn't have any reasonable feedback during the
>> download process.
>>
>> Anyway, I'm not really looking at this as a final definition of the
>> feature, more a look at what we can do so we can talk about the best
>> way to do it. (For example, we've talked about how it would be nice
>> to have command-line tools to do this, and while some of the code
>> could be extracted, we'd potentially need a separate file upload
>> solution, if we can't reuse the remote-deploy web app. Also, it can
>> only install from a Maven repo [vs a direct file upload] so it can
>> fetch needed dependencies. Also, it doesn't take advantage of the
>> soon-to-be-on-iBiblio Maven repository manager.)
>>
>> As a conversation starter, it would be nice to distribute Geronimo
>> without any sample applications to make it a little leaner and faster
>> to start -- just have the screen in the console that lets you download
>> and install any of them that you want. I also think it would be nice
>> to distribute without Directory and some of the other add-ons, and
>> provide the ability to download and install those, ServiceMix, Quartz,
>> and other packages we know of integration for.
>>
>> If you want to take a look at this, there's an Import/Export entry in
>> the application part of the console navigation bar (in HEAD). You
>> need to set up some Maven repo to point it to (though for a REAL quick
>> start you can just use a file URL like
>> file:///home/ammulder/.maven/repository). And then you need a file in
>> the root of the Maven repo called geronimo-configurations.properties
>> with entries like this:
>>
>> Category.ConfigId=Description
>>
>> Then enter the URL to your Maven repo in the screen in the console,
>> and it'll list all the configurations from the properties file,
>> grouped by the categories you specified, and let you install anything
>> that's not already available in the local server. I've attached a
>> sample that exposes some of the Geronimo web apps if you want a real,
>> real quick start.
>>
>> Thanks,
>> Aaron
>
>
>
Re: New Feature: Configuration Import/Export
Posted by Sachin Patel <sp...@gmail.com>.
2,3,4 This definitely is the direction I see the tooling support
going. We are discussing changes in the WTP Server Tools Framework
to allow adopters to extend and provide similar functionality for
their servers/runtimes. So these are good usage scenarios I can
bring up during my discussions with them.
- sachin
On Mar 24, 2006, at 9:44 PM, Matt Hogstrom wrote:
> Aaron,
>
> I'll set this up later and give it a spin. I think everyone has
> been considering how to get to the pluggable server so I'll throw
> in my 2c about what I think would be useful from a user
> perspective. I don't know enough about the internals of G to know
> how to implement it though.
>
> AppServers that I'm aware of all operate under the paradigm of
> installing the AppServer and then iteratively defining resources
> (DataSources, JMS Queues, etc.) and then installing and
> maintainging the applications that run in the containers. Of
> course they are all monolithic monsters that have everything in
> them that most people don't want or need.
>
> I think Little-G and now the work your doing are the right
> direction and are a new paradigm for the industry. Here are tyhe
> scenarios that I think make sense as being useful.
>
> 1. User downloads a full Geronimo instance and does initial
> customization using the installer. Pretty much like the paradigm
> described above.
>
> 2. User downloads a bootstrap agent (much like Cygwin) and then
> chooses either the pacakges they want (specific OSS projects) or
> the features they want (JMS, Servlet 2.4, EJB 1.1, Spring, etc.)
> The downloaded agent would resolve the required dependencies and
> suck down the appropriate parts and configure the runtime.
>
> 3. Similar paradigm to above but rather than running a single
> server instance they would specify a target location to export a
> server image that would be bootable. The instance they operate
> from is an AppServer factory and not an AppServer instance. The
> interfaces would include a GUI (nice user interface, dynamic
> resolution of dependencies, etc.) as well as a command line utility
> that could build the instances required for a specific set of
> applications.
>
>
> 4. A variation on the above would also install the application
> artifacts and create disposable runtimes. Users could then take
> these images and distribute them in a cluster and they would be
> fully functional containers but are designed to be disposed of
> after use. The paradigm of defining and iterating a server
> instance doesn't exist in this mode. The "disposable" instances
> would be able to federate into a managable cluster from an
> operations perspective but would be limited to starting and
> stopping the servers and pulling runtime statistics.
>
> Anyway, personally I'm interested in options 3 and 4. I think its
> a fresh approach to managed runtimes and provides all the
> functionality of J2EE and other programming models without much of
> the fuss.
>
> The term I use fo rthe above is Geronimo MTO (Made to Order). Kind
> of like Burger King where you can have it your way.
>
> I'd appreciate comments on the above.
>
> Matt
>
> Aaron Mulder wrote:
>> I've just added a new feature to the console whereby it can export an
>> installed configuration to a CAR file, and also install previously
>> uninstalled configurations (CAR files and dependency JAR files)
>> from a
>> Maven repository (though at present, it depends on a properties file
>> being in the repository the provide some metadata on the available
>> CARs). It also still doesn't have any reasonable feedback during the
>> download process.
>> Anyway, I'm not really looking at this as a final definition of the
>> feature, more a look at what we can do so we can talk about the best
>> way to do it. (For example, we've talked about how it would be nice
>> to have command-line tools to do this, and while some of the code
>> could be extracted, we'd potentially need a separate file upload
>> solution, if we can't reuse the remote-deploy web app. Also, it can
>> only install from a Maven repo [vs a direct file upload] so it can
>> fetch needed dependencies. Also, it doesn't take advantage of the
>> soon-to-be-on-iBiblio Maven repository manager.)
>> As a conversation starter, it would be nice to distribute Geronimo
>> without any sample applications to make it a little leaner and faster
>> to start -- just have the screen in the console that lets you
>> download
>> and install any of them that you want. I also think it would be nice
>> to distribute without Directory and some of the other add-ons, and
>> provide the ability to download and install those, ServiceMix,
>> Quartz,
>> and other packages we know of integration for.
>> If you want to take a look at this, there's an Import/Export entry in
>> the application part of the console navigation bar (in HEAD). You
>> need to set up some Maven repo to point it to (though for a REAL
>> quick
>> start you can just use a file URL like
>> file:///home/ammulder/.maven/repository). And then you need a
>> file in
>> the root of the Maven repo called geronimo-configurations.properties
>> with entries like this:
>> Category.ConfigId=Description
>> Then enter the URL to your Maven repo in the screen in the console,
>> and it'll list all the configurations from the properties file,
>> grouped by the categories you specified, and let you install anything
>> that's not already available in the local server. I've attached a
>> sample that exposes some of the Geronimo web apps if you want a real,
>> real quick start.
>> Thanks,
>> Aaron
Re: New Feature: Configuration Import/Export
Posted by Joe Bohn <jo...@earthlink.net>.
This is a good summary of the possibilities Matt. I've got some
questions/comments.
>
> 2. User downloads a bootstrap agent (much like Cygwin) and then chooses
> either the pacakges they want (specific OSS projects) or the features
> they want (JMS, Servlet 2.4, EJB 1.1, Spring, etc.) The downloaded
> agent would resolve the required dependencies and suck down the
> appropriate parts and configure the runtime.
>
> 3. Similar paradigm to above but rather than running a single server
> instance they would specify a target location to export a server image
> that would be bootable. The instance they operate from is an AppServer
> factory and not an AppServer instance.
But they aren't interacting with an AppServer in #2 either ... right?
Isn't the bootstrap in #2 really just an AppServer Factory as well?
> The interfaces would include a
> GUI (nice user interface, dynamic resolution of dependencies, etc.) as
> well as a command line utility that could build the instances required
> for a specific set of applications.
Can you clarify the command line utility? Do you envision a command
line that accepts all of the configuration choices as parameters or are
you thinking of a response/properties/XML/whatever file that would be
created to specify the particulars of a configuration and then the
factory uses this information to generate an executable instance? I
assume that's what you mean but I may be missing some other aspect of
the proposal.
>
>
> 4. A variation on the above would also install the application artifacts
> and create disposable runtimes. Users could then take these images and
> distribute them in a cluster and they would be fully functional
> containers but are designed to be disposed of after use. The paradigm
> of defining and iterating a server instance doesn't exist in this mode.
> The "disposable" instances would be able to federate into a managable
> cluster from an operations perspective but would be limited to starting
> and stopping the servers and pulling runtime statistics.
I think that we may need to provide some capability for iteration and
updates ... but I agree that we should limit this. For example, I can
see why it might be desirable to change ports, users, passwords, queues,
drivers, etc... in a configuration without requiring the creation of a
new image. The problem is that there isn't necessarily a clear cut
distinction between normal maintenance and what would require a new
configuration.
Perhaps you're correct that we should prevent any updates and always
require a new image .... but I'm not sure how that will be perceived by
the user. Replacing the image typically requires an interruption of
service while an update such as installing a new service or application
doesn't impact other applications on the server. I guess I'm thinking
that we might need to give the user the choice. Basically let the
resultant server image be no different than other images which can be
incrementally enhanced if the user chooses to do so. However, the
creation of the complete runtime image gives them the choice to maintain
the template or the individual instances.
Joe
--
Joe Bohn
joe.bohn at earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
Re: New Feature: Configuration Import/Export
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Aaron,
I'll set this up later and give it a spin. I think everyone has been
considering how to get to the pluggable server so I'll throw in my 2c about what
I think would be useful from a user perspective. I don't know enough about the
internals of G to know how to implement it though.
AppServers that I'm aware of all operate under the paradigm of installing the
AppServer and then iteratively defining resources (DataSources, JMS Queues,
etc.) and then installing and maintainging the applications that run in the
containers. Of course they are all monolithic monsters that have everything in
them that most people don't want or need.
I think Little-G and now the work your doing are the right direction and are a
new paradigm for the industry. Here are tyhe scenarios that I think make sense
as being useful.
1. User downloads a full Geronimo instance and does initial customization using
the installer. Pretty much like the paradigm described above.
2. User downloads a bootstrap agent (much like Cygwin) and then chooses either
the pacakges they want (specific OSS projects) or the features they want (JMS,
Servlet 2.4, EJB 1.1, Spring, etc.) The downloaded agent would resolve the
required dependencies and suck down the appropriate parts and configure the runtime.
3. Similar paradigm to above but rather than running a single server instance
they would specify a target location to export a server image that would be
bootable. The instance they operate from is an AppServer factory and not an
AppServer instance. The interfaces would include a GUI (nice user interface,
dynamic resolution of dependencies, etc.) as well as a command line utility that
could build the instances required for a specific set of applications.
4. A variation on the above would also install the application artifacts and
create disposable runtimes. Users could then take these images and distribute
them in a cluster and they would be fully functional containers but are designed
to be disposed of after use. The paradigm of defining and iterating a server
instance doesn't exist in this mode. The "disposable" instances would be able
to federate into a managable cluster from an operations perspective but would be
limited to starting and stopping the servers and pulling runtime statistics.
Anyway, personally I'm interested in options 3 and 4. I think its a fresh
approach to managed runtimes and provides all the functionality of J2EE and
other programming models without much of the fuss.
The term I use fo rthe above is Geronimo MTO (Made to Order). Kind of like
Burger King where you can have it your way.
I'd appreciate comments on the above.
Matt
Aaron Mulder wrote:
> I've just added a new feature to the console whereby it can export an
> installed configuration to a CAR file, and also install previously
> uninstalled configurations (CAR files and dependency JAR files) from a
> Maven repository (though at present, it depends on a properties file
> being in the repository the provide some metadata on the available
> CARs). It also still doesn't have any reasonable feedback during the
> download process.
>
> Anyway, I'm not really looking at this as a final definition of the
> feature, more a look at what we can do so we can talk about the best
> way to do it. (For example, we've talked about how it would be nice
> to have command-line tools to do this, and while some of the code
> could be extracted, we'd potentially need a separate file upload
> solution, if we can't reuse the remote-deploy web app. Also, it can
> only install from a Maven repo [vs a direct file upload] so it can
> fetch needed dependencies. Also, it doesn't take advantage of the
> soon-to-be-on-iBiblio Maven repository manager.)
>
> As a conversation starter, it would be nice to distribute Geronimo
> without any sample applications to make it a little leaner and faster
> to start -- just have the screen in the console that lets you download
> and install any of them that you want. I also think it would be nice
> to distribute without Directory and some of the other add-ons, and
> provide the ability to download and install those, ServiceMix, Quartz,
> and other packages we know of integration for.
>
> If you want to take a look at this, there's an Import/Export entry in
> the application part of the console navigation bar (in HEAD). You
> need to set up some Maven repo to point it to (though for a REAL quick
> start you can just use a file URL like
> file:///home/ammulder/.maven/repository). And then you need a file in
> the root of the Maven repo called geronimo-configurations.properties
> with entries like this:
>
> Category.ConfigId=Description
>
> Then enter the URL to your Maven repo in the screen in the console,
> and it'll list all the configurations from the properties file,
> grouped by the categories you specified, and let you install anything
> that's not already available in the local server. I've attached a
> sample that exposes some of the Geronimo web apps if you want a real,
> real quick start.
>
> Thanks,
> Aaron