On Feb 23, 2005, at 3:07 PM, Geir Magnusson Jr wrote:
On Feb 23, 2005, at 11:46 AM, Dain Sundstrom wrote:
That of course means that someone would have to define their own
types, and the latest changes by David Jencks make defining your own
types the norm. With his code you no longer declare an e
On Feb 23, 2005, at 1:53 PM, David Jencks wrote:
On Feb 23, 2005, at 11:53 AM, Dain Sundstrom wrote:
http://geronimo.apache.org/xml/ns/security";>
On Feb 23, 2005, at 11:46 AM, Dain Sundstrom wrote:
On Feb 23, 2005, at 10:59 AM, Geir Magnusson Jr wrote:
On Feb 23, 2005, at 10:14 AM, Dain Sundstrom wrote:
On Feb 23, 2005, at 9:24 AM, Geir Magnusson Jr wrote:
On Feb 23, 2005, at 12:23 AM, David Jencks wrote:
+1 on canonical name as internal str
On Feb 23, 2005, at 11:53 AM, Dain Sundstrom wrote:
On Feb 23, 2005, at 11:40 AM, David Blevins wrote:
On Wed, Feb 23, 2005 at 12:13:50PM -0500, Alan D. Cabrera wrote:
I don't parse the data at startup. The data gets parsed by a
tssConfigEditor and a cssConfigEditor at deployment time.
Cool. Is t
Dain Sundstrom wrote:
On Feb 23, 2005, at 11:40 AM, David Blevins wrote:
On Wed, Feb 23, 2005 at 12:13:50PM -0500, Alan D. Cabrera wrote:
I don't parse the data at startup. The data gets parsed by a
tssConfigEditor and a cssConfigEditor at deployment time.
Cool. Is this a case where you could pu
+1
Dain Sundstrom wrote:
For the record;
+1 on canonical name as internal string representation
-1 on attempting to preserve whatever string is used to construct the
gbean name
+1 on restricting characters in gbean name and assuring that gbean
name >> object name conversion always works in a non-
Jeremy Boynes wrote:
David Jencks wrote:
+1 on canonical name as internal string representation
-1 on attempting to preserve whatever string is used to construct the
gbean name
I think the usability value in getting back what you put it is greater
than having the keys rearranged on you (given t
On Feb 23, 2005, at 11:40 AM, David Blevins wrote:
On Wed, Feb 23, 2005 at 12:13:50PM -0500, Alan D. Cabrera wrote:
I don't parse the data at startup. The data gets parsed by a
tssConfigEditor and a cssConfigEditor at deployment time.
Cool. Is this a case where you could put the xml in another fi
On Feb 23, 2005, at 10:59 AM, Geir Magnusson Jr wrote:
On Feb 23, 2005, at 10:14 AM, Dain Sundstrom wrote:
On Feb 23, 2005, at 9:24 AM, Geir Magnusson Jr wrote:
On Feb 23, 2005, at 12:23 AM, David Jencks wrote:
+1 on canonical name as internal string representation
-1 on attempting to preserve what
On Wed, Feb 23, 2005 at 12:13:50PM -0500, Alan D. Cabrera wrote:
> I don't parse the data at startup. The data gets parsed by a
> tssConfigEditor and a cssConfigEditor at deployment time.
Cool. Is this a case where you could put the xml in another file in the
archive and have the attribute b
On Feb 23, 2005, at 11:03 AM, Jeremy Boynes wrote:
Dain Sundstrom wrote:
On Feb 23, 2005, at 8:45 AM, Jeremy Boynes wrote:
Dain Sundstrom wrote:
On Feb 22, 2005, at 7:23 PM, [EMAIL PROTECTED] wrote:
public Set listGBeans(ObjectName pattern) {
-return gbeanRegistry.listGBeans(pattern);
On Wed, Feb 23, 2005 at 10:30:51AM -0800, Jeremy Boynes wrote:
> Dain Sundstrom wrote:
> >On Feb 23, 2005, at 9:16 AM, Jeremy Boynes wrote:
> >
> >>David Blevins wrote:
> >>
> >>>The protocol layer in OpenEJB uses the canonical string version all
> >>>over the place. We avoided ObjectName on the
Dain Sundstrom wrote:
On Feb 23, 2005, at 8:45 AM, Jeremy Boynes wrote:
Dain Sundstrom wrote:
On Feb 22, 2005, at 7:23 PM, [EMAIL PROTECTED] wrote:
public Set listGBeans(ObjectName pattern) {
-return gbeanRegistry.listGBeans(pattern);
+String domain = (pattern == null ||
patte
On Feb 23, 2005, at 10:14 AM, Dain Sundstrom wrote:
On Feb 23, 2005, at 9:24 AM, Geir Magnusson Jr wrote:
On Feb 23, 2005, at 12:23 AM, David Jencks wrote:
+1 on canonical name as internal string representation
-1 on attempting to preserve whatever string is used to construct
the gbean name
I've b
+1 on canonical name as internal string representation
-1 on attempting to preserve whatever string is used to construct the gbean name
+1 on restricting characters in gbean name and assuring that gbean name
-David
On Wed, Feb 23, 2005 at 12:23:03AM -0800, David Jencks wrote:
> +1 on canonical n
On Feb 23, 2005, at 8:45 AM, Jeremy Boynes wrote:
Dain Sundstrom wrote:
On Feb 22, 2005, at 7:23 PM, [EMAIL PROTECTED] wrote:
public Set listGBeans(ObjectName pattern) {
-return gbeanRegistry.listGBeans(pattern);
+String domain = (pattern == null ||
pattern.isDomainPattern())
Dain Sundstrom wrote:
On Feb 23, 2005, at 9:16 AM, Jeremy Boynes wrote:
David Blevins wrote:
The protocol layer in OpenEJB uses the canonical string version all
over the place. We avoided ObjectName on the wire as String is
capable of representing an ObjectName and serializes faster and with
le
On Feb 23, 2005, at 9:35 AM, Jeremy Boynes wrote:
Dain Sundstrom wrote:
Can we be done with this bikeshed now?
This is not a bikeshead; these are important decisions that should be
discussed. Your decisions could break seamless integration with JMX,
and could require redesign of OpenEJB, ActiveM
On Feb 23, 2005, at 9:24 AM, Geir Magnusson Jr wrote:
On Feb 23, 2005, at 12:23 AM, David Jencks wrote:
+1 on canonical name as internal string representation
-1 on attempting to preserve whatever string is used to construct the
gbean name
I've been following from the peanut gallery, and like depl
On Feb 23, 2005, at 9:16 AM, Jeremy Boynes wrote:
David Blevins wrote:
The protocol layer in OpenEJB uses the canonical string version all
over the place. We avoided ObjectName on the wire as String is
capable of representing an ObjectName and serializes faster and with
less bytes as there is s
Bordet, Simone wrote:
Hi,
David Jencks wrote:
+1 on canonical name as internal string representation
-1 on attempting to preserve whatever string is used to
construct the
gbean name
I think the usability value in getting back what you put it
is greater
than having the keys rearranged on you
For the record;
+1 on canonical name as internal string representation
-1 on attempting to preserve whatever string is used to construct the
gbean name
+1 on restricting characters in gbean name and assuring that gbean name
>> object name conversion always works in a non-surprising manner.
On Fe
On Wed, Feb 23, 2005 at 09:16:58AM -0800, Jeremy Boynes wrote:
> David Blevins wrote:
> >The protocol layer in OpenEJB uses the canonical string version all over
> >the place. We avoided ObjectName on the wire as String is capable of
> >representing an ObjectName and serializes faster and with l
On Feb 23, 2005, at 9:09 AM, Jeremy Boynes wrote:
David Jencks wrote:
+1 on canonical name as internal string representation
-1 on attempting to preserve whatever string is used to construct the
gbean name
I think the usability value in getting back what you put it is greater
than having the keys
Dain Sundstrom wrote:
My point is that your argument is invalid. There is no guarantee in
java that x.equals(new SomeClass(x).toString()) is ever true.
It is for String :-)
My point here is that preserving the supplied name is useful, the order
is irrelevant to the implementation so there is no
Hi,
> David Jencks wrote:
> > +1 on canonical name as internal string representation
> > -1 on attempting to preserve whatever string is used to
> construct the
> > gbean name
>
> I think the usability value in getting back what you put it
> is greater
> than having the keys rearranged on yo
Dain Sundstrom wrote:
Can we be done with this bikeshed now?
This is not a bikeshead; these are important decisions that should be
discussed. Your decisions could break seamless integration with JMX,
and could require redesign of OpenEJB, ActiveMQ gbeans, and gbeans in
geronimo itself.
Well t
On Feb 23, 2005, at 12:23 AM, David Jencks wrote:
+1 on canonical name as internal string representation
-1 on attempting to preserve whatever string is used to construct the
gbean name
I've been following from the peanut gallery, and like deployment, this
seems to be a required topic for partici
David Blevins wrote:
The protocol layer in OpenEJB uses the canonical string version all over
the place. We avoided ObjectName on the wire as String is capable of
representing an ObjectName and serializes faster and with less bytes as
there is special logic in java.io.ObjectOutput/InputStream t
I don't parse the data at startup. The data gets parsed by a
tssConfigEditor and a cssConfigEditor at deployment time. You would
know that if you read the code. Oh, wait...
Regards,
Alan
P.S. Yes, the schema and editors are on openejb-builder, Mr. Jenks!
David Blevins wrote:
Just wondering if
David Jencks wrote:
+1 on canonical name as internal string representation
-1 on attempting to preserve whatever string is used to construct the
gbean name
I think the usability value in getting back what you put it is greater
than having the keys rearranged on you (given the order of the keys is
Hiram Chirino wrote:
Does this mean that GBeanName is going to replace more than just where
ObjectName was being used?
Not sure what you mean.
GBeanName is going to be how we identify GBean instances within a kernel
so instead of
Kernel.getAttribute(new ObjectName(instanceName), attrName)
you
Dain Sundstrom wrote:
On Feb 22, 2005, at 7:23 PM, [EMAIL PROTECTED] wrote:
public Set listGBeans(ObjectName pattern) {
-return gbeanRegistry.listGBeans(pattern);
+String domain = (pattern == null ||
pattern.isDomainPattern()) ? null : pattern.getDomain();
+Map props =
On Feb 22, 2005, at 7:23 PM, [EMAIL PROTECTED] wrote:
public Set listGBeans(ObjectName pattern) {
-return gbeanRegistry.listGBeans(pattern);
+String domain = (pattern == null ||
pattern.isDomainPattern()) ? null : pattern.getDomain();
+Map props = pattern == null ? nul
+1 on canonical name as internal string representation
-1 on attempting to preserve whatever string is used to construct the
gbean name
+1 on restricting characters in gbean name and assuring that gbean name
>> object name conversion always works in a non-surprising manner.
(although I may chang
I think that's what builders are for (e.g. openejb builder). I'm not in
favor of adding stuff to the service deployer that is not absolutely
necessary.
david jencks
On Feb 22, 2005, at 11:12 PM, David Blevins wrote:
Just wondering if we aren't side-stepping the deployment system rather
than exp
On Feb 22, 2005, at 10:06 PM, Jeremy Boynes wrote:
Dain Sundstrom wrote:
On Feb 22, 2005, at 5:38 PM, Jeremy Boynes wrote:
Dain Sundstrom wrote:
I think we will need a canonical form.
Why?
Because, you want to print two gbeans names that are equal and get
the same string. Because, you don't want
Just wondering if we aren't side-stepping the deployment system rather
than expanding it to meet our needs. The idea of gbeans parsing xml at
startup and configuring themselves creeps me out. The config data in
the xml won't always be valid and the xml won't always be well formed.
I've often
Does this mean that GBeanName is going to replace more than just where
ObjectName was being used? Right now ActiveMQ does not highly use the
Geronimo Kernel at runtime like some of the other geronimo modules do,
but if it did want to move in that direction, to for example to have the
kernel lo
On Feb 22, 2005, at 10:06 PM, Jeremy Boynes wrote:
Dain Sundstrom wrote:
On Feb 22, 2005, at 5:38 PM, Jeremy Boynes wrote:
Dain Sundstrom wrote:
I think we will need a canonical form.
Why?
Because, you want to print two gbeans names that are equal and get
the same string. Because, you don't want
Dain Sundstrom wrote:
On Feb 22, 2005, at 5:38 PM, Jeremy Boynes wrote:
Dain Sundstrom wrote:
I think we will need a canonical form.
Why?
Because, you want to print two gbeans names that are equal and get the
same string. Because, you don't want geronimo classes bleeding into your
apis.
Anyway
Make error handling in deployment plugin more user friendly
---
Key: GERONIMO-593
URL: http://issues.apache.org/jira/browse/GERONIMO-593
Project: Geronimo
Type: Improvement
Components: deployment
Reporte
In general it is both. For alan's case it is something we control, but
I think we should offer the same facility to third party GBeans.
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
On Feb 22, 2005, at 5:48 PM, David Blevins wrote:
Is this xml for a third party
On Feb 22, 2005, at 5:38 PM, Jeremy Boynes wrote:
Dain Sundstrom wrote:
I think we will need a canonical form.
Why?
Because, you want to print two gbeans names that are equal and get the
same string. Because, you don't want geronimo classes bleeding into
your apis.
Anyway, why not? ObjectName ha
Something we control. The CSIv2 configuration that I am using is very
hierarchical. Everything works w/ the CDATA.
Regards,
Alan
David Blevins wrote:
Is this xml for a third party piece of software or something that we
control?
-David
On Feb 22, 2005, at 10:59 AM, Alan D. Cabrera wrote:
I hav
Yes sir...you are indeed correct. I ripped it from Jetty.
I'll have a look at the openejb code and see what I can do.
Jeff
-Original Message-
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 22, 2005 7:11 PM
To: [EMAIL PROTECTED]
Subject: Tomcat TransactionConte
It looks like this class was cribbed from the Jetty
TransactionContextBeforeAfter class. I suggest that instead this code
be taken from org.openejb.transaction.ContainerPolicy$TxSupports. The
Jetty code is very clunky since Jetty doesn't support an interceptor
style invocation (around advice
Is this xml for a third party piece of software or something that we
control?
-David
On Feb 22, 2005, at 10:59 AM, Alan D. Cabrera wrote:
I have no problem reading in the string into XML. It just looks ugly
in the plan file.
Regards,
Alan
David Jencks wrote:
I'm not sure this is such a good id
Dain Sundstrom wrote:
I think we will need a canonical form.
Why?
There are many places that key
stuff off the string canonical form of the object name.
Isn't that fundamentally a bad idea? If you want to key off GBean name,
key off GBeanName and not the string representation.
I think that
I think we will need a canonical form. There are many places that key
stuff off the string canonical form of the object name. I think that
instead of keeping the original name around, we throw it out and
replace it with canonical name form, since the original name doesn't
really matter. Also
[ http://issues.apache.org/jira/browse/GERONIMO-568?page=history ]
John Sisson updated GERONIMO-568:
-
Attachment: SystemDatasource_patch.txt
Patch attached for review.
Notes: The JDBCTransactionalThreadPooledTimer and
JDBCNonTransactionalThreadPooledTi
51 matches
Mail list logo
