-Original Message-
From: [EMAIL PROTECTED]
[mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of David
Jencks
Sent: Monday, October 21, 2002 4:52 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JBoss 4.0 Entity Redesign
On 2002.10.21 10:50:45 -0400 Bill Burke
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign
-Original Message-
From: [EMAIL PROTECTED]
[mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of
David Jencks
Sent: Monday, October 21, 2002 4:52 PM
To: [EMAIL PROTECTED]
Subject: Re
See my responses online at www.jboss.org we need to start breaking down
the development and letting people get in our development in a more
transparent fashion.
1. Interceptors do not belong in the JMX layer. JMX should
stay simple. If you want interceptors in front of an MBean,
you
Good point, answered online
marc f
-Original Message-
From: [EMAIL PROTECTED]
[mailto:jboss-development-admin;lists.sourceforge.net] On
Behalf Of Bill Burke
Sent: Monday, October 21, 2002 10:54 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign
I
Of
Hiram Chirino
Sent: Sunday, October 20, 2002 11:41 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign
Previously we were on opposite sides of this debate:-)
I think for simplicity we should have only stateless
interceptors,
any interceptor can store per-stack state
marc fleury wrote:
One more request: stateless vs stateful interceptors. It is clear to me
that both are needed. For example: stateful are easy to code you just
have your variable in there and it is easy. A good example of stateless
(taken from invocation) is the read-ahead interceptor. The
Of Dain
Sundstrom
Sent: Tuesday, October 22, 2002 10:22 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JBoss 4.0 Entity Redesign
marc fleury wrote:
One more request: stateless vs stateful interceptors. It is clear to me
that both are needed. For example: stateful are easy to code you
:22 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JBoss 4.0 Entity Redesign
marc fleury wrote:
One more request: stateless vs stateful interceptors. It is clear to me
that both are needed. For example: stateful are easy to code you just
have your variable in there and it is easy
]
[mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of
Hiram
Chirino
Sent: Sunday, October 20, 2002 11:25 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign
I think for simplicity we should have only stateless
interceptors, any interceptor can
Sent: Sunday, October 20, 2002 7:47 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign
Sounds good,
When are we planing on converting the interceptor to having only a
single invoke method? I can easily do this with a new abstract
interceptor that breaks
On 2002.10.20 19:46:52 -0400 marc fleury wrote:
Sounds good,
When are we planing on converting the interceptor to having only a
single invoke method? I can easily do this with a new abstract
interceptor that breaks into the two methods based on
invocation type.
Any objections?
I think for simplicity we should have only stateless
interceptors, any interceptor can store per-stack state in a
the stack top in a hashmap.
I rewrote the mbean interceptors this way, it works fine, but
then juha committed a completely different reimplementation.
David there is no
Previously we were on opposite sides of this debate:-)
I think for simplicity we should have only stateless interceptors, any
interceptor can store per-stack state in a the stack top in a hashmap.
This was the way I created the aspect stuff initially. The interceptors
were tottaly statless.
On 2002.10.19 13:55:07 -0400 Dain Sundstrom wrote:
While I was off line for the last two and a half weeks I worked on a
redesign of entities from EntityContainer down. The most important part
of the redesign is the replacement of the EntityPersistentManager with
some new interceptors.
David Jencks wrote:
On 2002.10.19 13:55:07 -0400 Dain Sundstrom wrote:
When are we planing on converting the interceptor to having only a
single invoke method? I can easily do this with a new abstract
interceptor that breaks into the two methods based on invocation type.
Any objections?
I
On 2002.10.19 16:07:29 -0400 Dain Sundstrom wrote:
David Jencks wrote:
On 2002.10.19 13:55:07 -0400 Dain Sundstrom wrote:
When are we planing on converting the interceptor to having only a
single invoke method? I can easily do this with a new abstract
interceptor that breaks into the two
David Jencks wrote:
On 2002.10.19 16:07:29 -0400 Dain Sundstrom wrote:
Will this be, like, today? If not can you send me a diff or something?
Yes, once I figure out this build error:
$ ./build.sh
build.sh: *WARNING* Ignoring environment value for $ANT_HOME
build.sh: Executing:
Looks like thirdparty/xdoclet/xdoclet is not checked out.
Where did you get your jboss-head from?
to fix, you can:
cd thirdparty
cvs get _thirdparty_xdoclet_xdoclet
--jason
On Sat, 19 Oct 2002, Dain Sundstrom wrote:
David Jencks wrote:
On 2002.10.19 16:07:29 -0400 Dain Sundstrom wrote:
On 2002.10.19 17:39:13 -0400 Dain Sundstrom wrote:
David Jencks wrote:
On 2002.10.19 16:07:29 -0400 Dain Sundstrom wrote:
Will this be, like, today? If not can you send me a diff or something?
Yes, once I figure out this build error:
$ ./build.sh
build.sh: *WARNING* Ignoring
You did miss the build system fun.
Check out
cvs ... co -r HEAD jboss-head
Each branch now has its own set of module definitiions:
jboss-all == jboss-3.0
jboss-3.2
jboss-head
david jencks
On 2002.10.19 19:25:14 -0400 Dain Sundstrom wrote:
Jason Dillon wrote:
Looks like
David Jencks wrote:
You did miss the build system fun.
Check out
cvs ... co -r HEAD jboss-head
Do I really have to put the -r HEAD?
I'm glad I wasn't around for this one, but this solution seems like a
huge hack.
Anyway it will take me a while to move my changes from my old tree to
the
On 2002.10.19 20:41:32 -0400 Dain Sundstrom wrote:
David Jencks wrote:
You did miss the build system fun.
Check out
cvs ... co -r HEAD jboss-head
Do I really have to put the -r HEAD?
no, that's just for [misplaced] emphasis, sorry.
cvs ... co jboss-head
works fine.
You should
]
Sent: Saturday, October 19, 2002 5:41 PM
Subject: Re: [JBoss-dev] JBoss 4.0 Entity Redesign
Do I really have to put the -r HEAD?
I'm glad I wasn't around for this one, but this solution seems like a
huge hack.
Anyway it will take me a while to move my changes from my old tree to
the new
23 matches
Mail list logo
