[
http://issues.apache.org/jira/browse/GERONIMO-680?page=comments#action_12314022
]
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
with:
- 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
[NOTE:
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
Comments?
> New users "buy-in" hampered by inability to automatically rebuild
> sub-assemblies at runtime
> -------------------------------------------------------------------------------------------
>
> Key: GERONIMO-680
> URL: http://issues.apache.org/jira/browse/GERONIMO-680
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
