geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sing Li (JIRA)" <>
Subject [jira] Commented: (GERONIMO-680) New users "buy-in" hampered by inability to automatically rebuild sub-assemblies at runtime
Date Mon, 20 Jun 2005 05:12:18 GMT
    [ ] 

Sing Li commented on GERONIMO-680:

Thanks for the patch. The thought of being able to 
eventually write GBeans entirely in a scripting 
language is eerie; just picturing a REXX
script with an EJB fascade right now... hmmm...

Anyways, back to the problem @ hand.
I was hoping that, playing the role of a user, 
I'd only have to pose the problem  ;-)

Parameterizing the solution:
  it must not
   - require source code download
   - require maven
   - require CVS
   - require SVN
   - require source code change in the G
      machinery due to its interim nature

Our hands are tied, we must tinker only with the
binary distribution, and only have one thing to work 
   - the runtime deployer 

So, the interim kludge solution may be a script that:

   - waits until the server has started completely
   - check the plans directory for *any* changed plan
   - if a changed plan is detected, undeploy everything,
       the whole J2EE kitten kaboodle, down to only the 
       core + system + kernel, and the runtime deployer
   - redeploy all the modules again

This *does* imply that the plan directory has to cloned,
from its current privileged location, to a location
under target... ie. var/config/plan

Build the script into a org/apache/geronimo/RestartJ2EEServer 
configuration that starts up and ends in STOPPED state

as David J. pointed out, while theoretically
feasible - this kludge is not possible with Geronimo
today because the RuntimeDeployer config depends on 
the Server config! Taking down the Server config will
elimitate all possibilities of runtime deployment :-(

In the longer term, the following is desirable:

 - have a plan directory in the assembly module that
    contains only core and system and kernel plans,
    so the J2EE and other plans are optional
 - have all the other "user" plans located in 
    var/config/plan of target 
 - have configuration loader optionally operate in a 
    'cached mode' where it treats the serialized "user"
    configurations as a cached copy of the plans located 
    in var/config/plan; and will flush plus redeploy 
    if necessary


> New users "buy-in" hampered by inability to automatically rebuild sub-assemblies at runtime
> -------------------------------------------------------------------------------------------
>          Key: GERONIMO-680
>          URL:
>      Project: Geronimo
>         Type: Improvement
>     Reporter: Sing Li
>  Attachments: ScriptingModule.patch
> Sizable population of current Tomcat, Jetty, 
> OpenEJB, and ActiveMQ users will soon take a look at
> Geronimo.
> Unfortunately, they are very likely to walk away out of 
> pure frustration :-(
> The current usage model for these products are very similar 
> to that of the Apache web server.  A user can:
> 1. change the config file, for example httpd.conf
> 2. restart the server, for example ... via apachectl
> 3. immediately try the new server in action
> This model allows for rapid revision/iteration 
> during experimentation, debugging, and on-the-fly 
> config rewrites.
> Unfortunately, attempting to do the same with 
> their favourite server INSIDE Geronimo will 
> (today) require:
> 1. download of the entire Geronimo source base
> 2. research and understand Maven
> 3. research and understand SVN and CVS
> 4. understand the Geronimo build process
> 5. crossed digits during assorted build failures -
> out-of-sync repository, server lock-ups, etc
> 6. days on end searching mailing list archives (if
> the search feature isn't still broken)
> 7. endless hours lurking on the IRC
> 8. days and days of wondering why he/she is doing it
> All of this is required to make a simple change
> that formerly equates to a text file edit
> and server restart.
> Somewhere between step 1 and 8 above, most sane
> user would have quit, disappointed.  
> Not every server user aspires to become a 
> server-system developer :-(
> Even though this problems will likely go away once 
> GUI admin/deployment/configuration tools 
> and GUI assemblies-construction-kits become available,
> there is an obvious need to address the usability 
> issue in the interim.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message