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
|