Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 16403 invoked from network); 28 Mar 2006 13:53:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 28 Mar 2006 13:53:46 -0000 Received: (qmail 1947 invoked by uid 500); 28 Mar 2006 13:53:31 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 1902 invoked by uid 500); 28 Mar 2006 13:53:31 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 1891 invoked by uid 99); 28 Mar 2006 13:53:31 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Mar 2006 05:53:31 -0800 X-ASF-Spam-Status: No, hits=2.6 required=10.0 tests=RCVD_IN_SORBS_WEB,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [206.190.53.29] (HELO smtp104.plus.mail.re2.yahoo.com) (206.190.53.29) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 28 Mar 2006 05:53:30 -0800 Received: (qmail 52398 invoked from network); 28 Mar 2006 13:53:09 -0000 Received: from unknown (HELO ?9.37.214.127?) (spalias78@129.33.49.251 with plain) by smtp104.plus.mail.re2.yahoo.com with SMTP; 28 Mar 2006 13:53:09 -0000 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <4424AE8E.8000703@hogstrom.org> References: <74e15baa0603241524p7d2e4b9aw4cf92d919e155c08@mail.gmail.com> <4424AE8E.8000703@hogstrom.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Sachin Patel Subject: Re: New Feature: Configuration Import/Export Date: Tue, 28 Mar 2006 08:53:11 -0500 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.746.3) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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