I think I've lost the thread and level-of-reply info
due to having to use the web interface for mail,
sorry copying the message I'm replying to...
--original message thread...
On May 24, 2006, at 12:47 PM, Dain Sundstrom wrote:
On May 23, 2006, at 11:26 PM, David Jencks wrote:
On May 23,
This may be no surprise, but I think including it is reasonable. :)
Thanks,
Aaron
On 5/26/06, David Jencks [EMAIL PROTECTED] wrote:
I think I've lost the thread and level-of-reply info
due to having to use the web interface for mail,
sorry copying the message I'm replying to...
I concur with Aaron that including it is reasonable.
Aaron Mulder wrote:
This may be no surprise, but I think including it is reasonable. :)
Thanks,
Aaron
On 5/26/06, David Jencks [EMAIL PROTECTED] wrote:
I think I've lost the thread and level-of-reply info
due to having to use the web
+1 on excluding this from 1.1. I agree it's not a blocker.
I think client-corba needs a dependency on client-security, I thought
it was there. I'll try to investigate on the plane tomorrow.
I expected you to fix this by modifying the ServiceConfigBuilder to
check that the gbean reference
On May 23, 2006, at 11:04 PM, David Jencks wrote:
+1 on excluding this from 1.1. I agree it's not a blocker.
I think client-corba needs a dependency on client-security, I
thought it was there. I'll try to investigate on the plane tomorrow.
I expected you to fix this by modifying the
On May 23, 2006, at 11:26 PM, David Jencks wrote:
On May 23, 2006, at 11:04 PM, David Jencks wrote:
+1 on excluding this from 1.1. I agree it's not a blocker.
I think client-corba needs a dependency on client-security, I
thought it was there. I'll try to investigate on the plane
Well, I do feel that it's a pretty serious issue... Mainly because
it's a hard-to-interpret error at an unfortunate time... The thing is
distributed but not started so it seems kind of like it worked (e.g.
the new thing appears in the console, etc.) but really it didn't. (I
expect users to be
I agree that we should address this in 1.1.1. Another problem I ran into today is when a deployment
fails and the artifacts are left in the repo but are unusable requiring a manual removal of the
items. I need to see if there is an existing JIRA.
Matt
Aaron Mulder wrote:
Well, I do feel
Don't most people just use the one step deploy instead of
distribute then start. If I am correct, there should be very
little difference in the user experience.
-dain
On May 24, 2006, at 11:21 AM, Aaron Mulder wrote:
Well, I do feel that it's a pretty serious issue... Mainly because
Deploy reduces to distribute+start. If the distribute fails, the
whole thing fails. If distribute works but start fails, it's left
distributed but not started. We could try to undeploy if start fails,
which should be a trivial change -- that's probably at least better
than what we do now.
I finished the patch for GERONIMO-1960 (http://issues.apache.org/jira/
browse/GERONIMO-1960), but I think it may be destabilizing and should
be move to 1.1.1.
I added a verify method to Deployment context which is called from
getConfigurationData(). This method verifies the references and
11 matches
Mail list logo
