I'm listening to this discussion and trying to make sense of it so that
I can understand how it will affect our users. Keep in mind that I'm
still grasping at the fundamentals of Geronimo and G-beans so this may
be off in the weeds (and for which I will apologize for right now).
As I think
Joe Bohn wrote:
One final question I'll toss out (and possibly show my ignorance ... but
at least I'll learn the answer :-) ) ... Aren't the applications that
are deployed themselves represented by Gbeans in the bundle and
therefore the bundle is already mutable in that sense? I read an
Aaron Mulder wrote:
Of the two, I like option 5 more -- and more than all the
UUID-based options. I'm not sure the mutability needs to be reflected in
the configuration name, though -- couldn't we have non-name properties for
the version and mutability? That way the start/stop command
Thanks Jeremy. That helps a lot. I think it also helps me understand
how potentially different types of configuration data might be organized
and managed (which I'd also like to hear some thoughts on too).
IIUC then, any configuration that changes a GBean's persistent state in
the server
I really like this model and explanation and wonder just how soon we
can make it a reality.
Last fall I thought we needed the ability to add gbeans to running
configurations so you could add datasources, queues, etc to the server
while you were getting ready to deploy an app, using an admin
I don't understand why Jeremy's vision is incompatible with
altering configurations on the fly. That is to say, you change and change
and change, and when it's right, you (sign and) export
myconfig-1.3.1.jar. Perhaps that includes a single configuration (web
container). Perhaps it
Aaron Mulder wrote:
I don't understand why Jeremy's vision is incompatible with
altering configurations on the fly. That is to say, you change and change
and change, and when it's right, you (sign and) export
myconfig-1.3.1.jar. Perhaps that includes a single configuration (web
FYI, I'm considering this a discussion on our long-term policy.
In the immediate future, I'm planning to go ahead with mutable
configurations to support the desired functionality in the web console.
I'm definitely open to revising that when the time comes and we have a
more
there are at least 2 aspects to mutable configurations.
1. adding/ removing gbeans. I don't think there is a valid use case
for this and don't think we should support it, ever. I don't think we
should allow changing reference patterns either for essentially the
same reasons.
2. changing
On Tue, 26 Jul 2005, David Jencks wrote:
there are at least 2 aspects to mutable configurations.
1. adding/ removing gbeans. I don't think there is a valid use case
for this and don't think we should support it, ever. I don't think we
should allow changing reference patterns either for
Aaron Mulder wrote:
Use case: Server ships with HTTPS or AJP disabled. You want to enable it.
You go to the console, fill in a form, click a button, it is now running.
Implementation: you set the magic enabled attribute causing the
disabled bean to be started. New value of the property is
+1 for adding support for adding services to and removing services
from a configuration
On Jul 26, 2005, at 2:40 PM, David Jencks wrote:
IMO both of these are much better done as part of the offline
deployment process well before the configuration gets anywhere near
a running server.
David,
I believe we need to be able to make this kind of change to a
running server. The commercial products we're (at least in theory)
competing with all support making this kind of change through their
management console, though for certain types of changes a server restart
is required.
BTW this is already has a JIRA entry GERONIMO-400. I added this
almost a year ago.
-dain
On Jul 26, 2005, at 3:05 PM, Aaron Mulder wrote:
David,
I believe we need to be able to make this kind of change to a
running server. The commercial products we're (at least in theory)
competing
On Jul 26, 2005, at 3:06 PM, Dain Sundstrom wrote:
BTW this is already has a JIRA entry GERONIMO-400. I added this
almost a year ago.
No wonder I couldn't find it. I thought I added it :-)
Now that how saving configuration works has been explained so even I
can understand it, I don't have
On Tue, 26 Jul 2005, David Jencks wrote:
Now that how saving configuration works has been explained so even I
can understand it, I don't have any problem in saving configuration
locally. I can even imagine a tool to merge a local state with a
configuration to produce a new configuration
Aaron Mulder wrote:
Maybe I've been casting this entire discussion in the wrong way.
Both changes to GBean properties and adds/removes of GBeans can be
accomplished by adjusting the current state saved *in addition to* the
original state -- so at the end of the day, we're not really
How is enabling and subsequently configuring a service is
substantially different then just adding a new one? Simmilary, why
is disabling a service substantially different then removing it?
-dain
On Jul 26, 2005, at 3:23 PM, David Jencks wrote:
On Jul 26, 2005, at 3:06 PM, Dain
Dain Sundstrom wrote:
How is enabling and subsequently configuring a service is substantially
different then just adding a new one? Simmilary, why is disabling a
service substantially different then removing it?
I'm not a great fan of the disabled component option either - I just
used
FYI, I don't think this is a technical issue, I think this is a
scope issue. You're talking about how to support build the bundle on a
master node in a cluster and then automatically push it to worker nodes
and how to support features that no other app server has. I'm talking
about how
On Jul 26, 2005, at 3:36 PM, Jeremy Boynes wrote:
If it uses the original then the new configuration may not run
with the current one; if it uses the current then it may not
run on a server using the original one.
We have this problem regardless. Any mutation in the environment or
On Jul 26, 2005, at 3:43 PM, Aaron Mulder wrote:
On Tue, 26 Jul 2005, David Jencks wrote:
Now that how saving configuration works has been explained so even I
can understand it, I don't have any problem in saving configuration
locally. I can even imagine a tool to merge a local state with a
On Jul 26, 2005, at 3:36 PM, Dain Sundstrom wrote:
How is enabling and subsequently configuring a service is
substantially different then just adding a new one? Simmilary, why is
disabling a service substantially different then removing it?
My idea is that live changes should only affect
Aaron Mulder wrote:
FYI, I don't think this is a technical issue, I think this is a
scope issue. You're talking about how to support build the bundle on a
master node in a cluster and then automatically push it to worker nodes
and how to support features that no other app server has.
Dain Sundstrom wrote:
On Jul 26, 2005, at 3:36 PM, Jeremy Boynes wrote:
If it uses the original then the new configuration may not run with
the current one; if it uses the current then it may not run on a
server using the original one.
We have this problem regardless. Any mutation in
On Tue, 26 Jul 2005, David Jencks wrote:
I think this is a prime example of where you should use app-centric
deployment, i.e. put the security gbeans in the application.
What if your developers are not trusted with the production
database or LDAP accounts? Are you arguing that your
Okay, I think we're getting to the root of this. You believe I am
proposing breaking a current feature. I believe I am proposing only
adding new features without breaking anything.
If we add the ability to add/remove GBeans to a configuration at
runtime, then based on the
Aaron Mulder wrote:
Okay, I think we're getting to the root of this. You believe I am
proposing breaking a current feature. I believe I am proposing only
adding new features without breaking anything.
If we add the ability to add/remove GBeans to a configuration at
runtime, then
All of those are broken today if you change the properties of the
GBeans using the setAttribute calls, right?
Aaron
On Tue, 26 Jul 2005, Jeremy Boynes wrote:
The ability to build a configuration on one machine and have it run
reliably on another.
The ability for the packaging
well...
If the runtime deployer works off of the original configurations,
ignoring any local modifications, it won't break anything, but it also
will be pretty much useless (I think).
If the runtime deployer works off of the locally modified
configuration, then the runtime deployer should
Aaron Mulder wrote:
Let me try to propose some alternatives for us to consider. Assume you
want to make a change to the server configuration, and for whatever
reason, NOT bundle that with your application. This change involves
adding or removing a GBean, which is naturally related to the
Starting a new sub-thread...
One of the examples we use all the time when talking about bundles is
that of a web connector. However, this is bad example to take because it
is too simple to highlight some of the issues.
* it only contains one GBean
* that bean has a couple of fairly simple
There is a mechanism to save out he current state of GBeans on a
clean shutdown of the configuration (i.e., when you stop the
configuration). If it is not running, then there is a bug. The code
is in org.apache.geronimo.kernel.config.Configuration.doStop();
-dain
On Jul 24, 2005, at
Aaron Mulder wrote:
I thought we had a mechanism in place to store the state of a
GBean after a change at runtime -- which I assume would include storing
new values for persistent attributes as well as storing the data for new
GBeans added to a Configuration at runtime (for example, if you
For my part, I'm not convinced that it makes sense for
configurations to be immutable. I think the export/import feature would
be nice -- I finally got my web container configured 'just right', now
let me export it and load it into my cluster of 30 boxes. I wouldn't
even mind giving
I have been thinking about this issue for months now and haven't come
to any good solutions. I think it would be cool to have imutable
configuration, but just think it is practical at this point. The
console and the tomcat/jetty selection issues really show off where
our current design
As far as the Tomcat/Jetty thing goes, that will be interesting to
explore as we think over how we should deal with interfaces in some
future release. I mean, I think our dependencies should ideally be
expressed as I require a servlet 2.4-compatible web container not I
require the
I'd ask you to set aside traditional thinking and try this out for a bit.
When you write code, you edit a couple of source files, compile it, fix
the typos, build a jar, test it, decide its good enough and commit the
change. After doing this a few times you decide its good enough and do a
So the console can write to persistent attributes of GBeans -- and
I think they're taking effect (you can log out and log back in and see the
changed value, at any rate). However, if you restart the server, the
values reset to their initially generated values.
I thought we had a
39 matches
Mail list logo
