You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Sing Li (JIRA)" <de...@geronimo.apache.org> on 2005/06/16 11:11:46 UTC
[jira] Created: (GERONIMO-680) New users "buy-in" hampered by inability to automatically rebuild sub-assemblies at runtime
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
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
Re: [jira] Created: (GERONIMO-680) New users "buy-in" hampered by
inability to automatically rebuild sub-assemblies at runtime
Posted by Dondi Imperial <di...@exist.com>.
I think adding a scripting module to geronimo would help a lot in this
area. Due to geronimo's GBean architecture adding such a module appears
to be a simple as writting the GBean wrapper(s) for whatever scripting
engine (say Jython or Groovy) you please. A simple implementation could,
for example, read a system property (say geronimo.start.script) and, if
this system property exists, run this script when the GBean starts. So
all you'll have to do to is start geronimo like so java -jar server.jar
-Dgeronimo.start.script=[path_to_script]. I think I could get a
prototype of this done in a couple of hours and submit it as a patch if
anyone is interested.
Thanks,
Sing Li (JIRA) wrote:
>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
>
>
>
[snip]
--
Dondi Imperial
Software Engineer
Exist Software Labs
Penthouse I, Prestige Tower,
F. Ortigas Jr. Ave. (formerly Emerald Ave.),
Ortigas Center, Pasig City 1605
Philippines
+632.687.7653
www.exist.com
[jira] Closed: (GERONIMO-680) New users "buy-in" hampered by inability to automatically rebuild sub-assemblies at runtime
Posted by "Dain Sundstrom (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-680?page=all ]
Dain Sundstrom closed GERONIMO-680:
-----------------------------------
> 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
> Fix For: 1.0-M5
> 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
[jira] Commented: (GERONIMO-680) New users "buy-in" hampered by inability to automatically rebuild sub-assemblies at runtime
Posted by "Dondi Imperial (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-680?page=comments#action_12313958 ]
Dondi Imperial commented on GERONIMO-680:
-----------------------------------------
The Scripting module patch is a bit primitive and there are a few methods from org.python.util.PythonInterpreter, like eval and execute, that could be added as GBean operations. This could also help in places like the DebugConsole where you might want to construct arbitratry objects and from user input (ie. when trying to cal kernel.invoke() on a GBean method with complex arguments.
> 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
[jira] Updated: (GERONIMO-680) New users "buy-in" hampered by inability to automatically rebuild sub-assemblies at runtime
Posted by "Dondi Imperial (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-680?page=all ]
Dondi Imperial updated GERONIMO-680:
------------------------------------
Attachment: ScriptingModule.patch
As promised here is a patch for an embedded Jython engine for geronimo. It includes a deployment plan and a Gbean.
> 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
Re: [jira] Commented: (GERONIMO-680) New users "buy-in" hampered
by inability to automatically rebuild sub-assemblies at runtime
Posted by Dondi Imperial <di...@exist.com>.
Sing Li (JIRA) wrote:
> [ 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...
>
>
I was thinking more along the lines of creating a property file like
syntax for configuring GBeans, at startup (sort of), via a scripting
engine. Here is one way this could work. A 'scripting' GBean is added to
geronimo. This GBean takes a Properties (or a List if possible) object
as an attribute. This object contains a list of all the files that are
to be executed by the embedded interpreted on startup. Now say that the
scripting language that is used supports operator overloading and that
the GBean also takes a 'library' file that is to be 'included' in all
the startup scripts. Say this script contains an object named 'getGBean'
that takes a GBean name as its argument and overloads the 'dot' operator
so that it calls kernel.setAttribute(...) on the gbean and it's
property. In Jython those files would look something like this (note
that this does not yet handle the case where the GBean we want to
configure is not running/loaded):
-------- header.py - Library (magic header fle) ---------
sys.add_package("org.apache.geronimo.kernel")
sys.add_package("org.apache.geronimo.gbean")
sys.add_package("javax.management")
from org.apache.geronimo.kernel import KernelRegistry
from javax.management import ObjectName
class getGBean:
def __init__(self, gbname):
self.gBeanName = ObjectName(gbname)
def __setattr__(self,name,value):
if name != 'gBeanName':
kernel = KernelRegistry.getSingleKernel()
kernel.setAttribute(self.gBeanName,name,value)
else:
self.__dict__[name]=value
-----------------------------------------------
-------- Configuration file possibly one (or more) for each
configurable module (header.py is injected into this file by the
interpreter GBean) ----
obj = getGBean('complete gbean name here'')
obj.someNumericAttribute = 10
obj.someStringAttribute = 'value'
....
-------------------------------------------------------------------------------------------------------------
The only difference from a regular properties file is the line with the
getGBean call..
I'll admit that this is indeed kludgy because it sets the attributes of
the GBean after they have been started where ideally you would want the
GBeans to start with their configured attributes. Add to that the fact
that there are some attributes that might require that the GBean be
re-started in order to have the desired effect (ie. the JettyConnector
and its port attribute). On the other hand, if module developers provide
'config files' in this format and add them to the list attribute of the
scripting gbean these can be packaged with the binary distribuition.
Users can then modify these files as they wish, restart geronimo and
have the changes take effect. No source download or compilation and no
need to look and edit at XML files.
HTH,
--
Dondi Imperial
Software Engineer
Exist Software Labs
Penthouse I, Prestige Tower,
F. Ortigas Jr. Ave. (formerly Emerald Ave.),
Ortigas Center, Pasig City 1605
Philippines
+632.687.7653
www.exist.com
[jira] Commented: (GERONIMO-680) New users "buy-in" hampered by inability to automatically rebuild sub-assemblies at runtime
Posted by "Sing Li (JIRA)" <de...@geronimo.apache.org>.
[ 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
[jira] Resolved: (GERONIMO-680) New users "buy-in" hampered by inability to automatically rebuild sub-assemblies at runtime
Posted by "Aaron Mulder (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-680?page=all ]
Aaron Mulder resolved GERONIMO-680:
-----------------------------------
Fix Version: 1.0-M5
Resolution: Fixed
New configuration database (ManageableAttributeStore) should essentially resolve this issue by allowing you to configure certain attributes using a text file (var/config/config.xml).
Also, we are planning to distribute the server plans with each release. That would mean a change above and beyond what's possible with the ManageableAttributeStore should be a matter of updating a plan file and running a deploy command with the included deploy tool.
> 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
> Fix For: 1.0-M5
> 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