Anybody want to take this on? Could be an interesting project. I think the
idea has merit Dain. Great thought.
Bill Burke
Chief Architect
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
Burke
Sent: Tuesday, January 14, 2003 3:32 PM
To: [EMAIL PROTECTED]
Subject: JBossScript was RE: [JBoss-dev] JNuke dev
Anybody want to take this on? Could be an
interesting
project. I think the idea has merit Dain. Great
thought.
Bill Burke
forget it, somebody just forgot to comment out JPDA settings.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
Burke
Sent: Tuesday, January 14, 2003 10:16 PM
To: Jboss-Dev
Subject: [JBoss-dev] any reason for -classic
Just saw -classic mode
Just saw -classic mode in jboss-head. Why are we running in -classic mode?
Another thing. Seems like JBoss is starting up much much slower than usual.
Has somebody thrown in some crazy in?
Bill
---
This SF.NET email is sponsored by: Take
- announcements
www.jboss.org
Bill Burke
Chief Architect
JBoss Group, LLC
---
This SF.NET email is sponsored by: Take your first step towards giving
your online business a competitive advantage. Test-drive
please exmplain what is the purpose of the 'name' attribute
in class-metadata element?
In the forum or here.
Thanks,
alex
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of Bill Burke
Sent: Wednesday, January 15, 2003 4:23 PM
To: [EMAIL
Ok, I was doing some coding and found that my ThreadLocal variable was the
same even between remote MBean invocations. Is there some ThreadPooling
going on that is not releasing the ThreadLocal variables?
TESTCASE:
1. remotely invoke on method test1 - this sets testit ThreadLocal variable
to
to
write/find/incorporate a JMS benchmark. Somebody to benchmark using ECPERF,
RICE/Rubis, and new JMS benchmarking. This is interesting work since you
must leverage your knowledge on clustering, caching, and configuration.
Touches all parts of JBoss.
Bill Burke
Chief Architect
JBoss
]]On Behalf Of Bill Burke
Sent: Wednesday, January 15, 2003 9:37 AM
To: Jboss-Dev; JBoss 2
Subject: [JBoss-user] WANTED: Lead JBoss Developers
We're looking for Lead Developer volunteers. Please, no emails if you've
never contributed to JBoss. If you've never contributed to JBoss you'll
need
{...} of the JRMPInvoker has
to clear the thread locals if it wants to limit the context to
the invocation
lifetime.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: Juha
In fact we could TOTALLY do that on the new AOP framework. If you
define with an xdoclet tag that a given method is @jboss:one-way then
we put an interceptor that takes fresh thread and returns immediately.
Me likes.
Please check out the metadata stuff I've been doing for the AOP
Certainly not and there should not be. The content of the thread
local has to
be controlled in the scope in which it exists.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Bill Burke
thread pool thread, and then the thread pool thread could
remove them upon exiting?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Bill
Burke
Sent: Thursday, January 16, 2003 12:51 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] ThreadPooling
ThreadPoolLocal for the
semantics your talking about.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 16, 2003 9:50 AM
Subject
Each thread holds an implicit reference to its copy of a thread-local
variable as long as the thread is alive and the ThreadLocal instance is
accessible; after a thread goes away, all of its copies of thread-local
instances are subject to garbage collection (unless other references to
these copies
.
That says that you have pools who just limit the number of threads out
there and block for other but associate a new thread for new
invocations.
marcf
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On
Behalf Of Bill Burke
Sent: Thursday, January 16
?
It is already in the JBoss 4.0 task list.
http://sourceforge.net/pm/
task.php?func=detailtaskproject_task_id=68960group_id=22866group_proj
ect_id=15043
-dain
On Friday, January 17, 2003, at 12:23 PM, Bill Burke wrote:
Please archive this on the Persistence forum. Thanks guys.
Bill
.
Bill Burke
Chief Architect
JBoss Group, LLC
---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use
Somebody really screwed up jboss-head. Can the butt-head who did fix it?
This is ridiculous
MBeans waiting for other MBeans:
[org.jboss.system.ServiceContext@17342155 {
objectName: jboss.ejb:service=EJBDeployer
state: CONFIGURED
dependencies: [jboss.tm:service=TransactionManagerService,
] Survey: JDK 1.4 versus JDK
1.3
Bill Burke wrote:
Not a good idea. JBoss clustering depends on Javagroups as you know and
there are tons of customers/those in production that use JDK
1.3.x. If you
do this, JBoss will probably be stuck with Javagroups 2.0.x for some
time to
come. JBoss
Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
Burke
Sent: Monday, January 20, 2003 1:57 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] jboss-3.2.0RC1: farming problem
can you log a bug and assign it to me?
-Original Message
I am doing some things around MetaData and centralized configuration and
configuration chains in AOP that I'd like to merge with the rest of JBoss.
Please see the topic configuration and metadata in the AOP forum.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
We only retry on connection exceptions.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Matt
Cleveland
Sent: Thursday, January 23, 2003 9:28 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [JBoss-dev] HA Retrying a Transaction? (was
know and we'll
get somebody to help you out. We really appreciate this work.
Bill
On Thursday, Jan 23, 2003, at 19:11 US/Pacific, Bill Burke wrote:
Are you getting decent results? I heard from Scott that you've made
some
improvements. Need me to merge your changes at all? Just want
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of marc
fleury
Sent: Monday, January 27, 2003 11:17 AM
To: [EMAIL PROTECTED]; 'Stefan Reich'
Subject: RE: [JBoss-dev] RE: how's ecperf going?
yes, if you take a look at the code, before the switch
the tests on PowerPC Macs and the Apple VM it is
hard to compare the results with other platforms.
Stefan
On Thursday, Jan 23, 2003, at 19:11 US/Pacific, Bill Burke wrote:
Are you getting decent results? I heard from Scott that you've
made
some
improvements. Need me to merge your
Roger that. Check5622.
The
condor is moving, I repeat the condor is moving
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Rolando MorejonSent: Tuesday, January 28, 2003 12:32
PMTo: [EMAIL PROTECTED]Subject:
[JBoss-dev] is ok
improvements and bug
fixes. Maybe you can view bug fixes by date to get a better idea.
Bill Burke
Chief Architect
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Meyer-Willner, Bernhard
Sent: Tuesday
Great work hans! Come on JBoss community! Try it out! Bang on it!
Many thanks,
Bill Burke
Chief Architect
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Hans
Dockter
Sent: Wednesday, January
forward to your contributions. Let us know.
Best Regards,
Bill Burke
Chief Architect
JBoss Group, LLC
-Original Message-
From: Tomas Lapienis [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 30, 2003 7:58 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED
I have put in a single logical name for the jetty and tomcat services.
Please tell me the changes to make and I will commit on all branches since I
am responsible.
Apologies,
Bill Burke
Chief Architect
JBoss Group, LLC
-Original Message-
From
JBG has a number of support clients using JBossMQ in production 2.4 and 3.x.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Aaron
Lindsey
Sent: Sunday, February 02, 2003 3:13 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JMS reliability (?)
Yes, I will accept $10 per change note. Please send me your credit card
information so that I can bill you directly.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Mike
Savage
Sent: Tuesday, February 04, 2003 9:17 AM
To: '[EMAIL PROTECTED]'
What if you don't have java on the client side? What if you're CORBA with
OTS? You're making it harder for Non-JBoss/Java clients to integrated with
us. I think this split should be undone.
BTW, why the split besides code readability? Is the DTM dependent on this
at all? Is the TM even
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Hiram
Chirino
Sent: Wednesday, February 12, 2003 5:09 PM
To: [EMAIL PROTECTED]; David Jencks
Subject: Re: [JBoss-dev] TxInterceptor split is bad
--- Bill Burke [EMAIL PROTECTED] wrote:
What
Of Bill
Burke
Sent: Wednesday, February 12, 2003 5:36 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] TxInterceptor split is bad
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Hiram
Chirino
Sent: Wednesday, February 12, 2003 5:09 PM
-
From: Bill Burke [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 12, 2003 5:51 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] TxInterceptor split is bad
Another thing David,
I don't see you always stuffing the Transaction into the
invocation object. A few interceptors rely
Ok, I see where the Transaction gets stuffed into the invocation object.
Still no tm.resume though for user transactions.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
Burke
Sent: Wednesday, February 12, 2003 6:06 PM
To: [EMAIL
looked at your code!
Regards,
Hiram
--- Bill Burke [EMAIL PROTECTED] wrote:
Ok, I'm looking at the code further and I'm pretty
confused on how a
Transaction get propagated across the wire now. Can
you explain? I don't
see any code anywhere that is doing a tm.resume from
-
From: Bill Burke [EMAIL PROTECTED]
To: David Jencks [EMAIL PROTECTED]; Jboss-Dev
[EMAIL PROTECTED]
Sent: Wednesday, February 12, 2003 1:31 PM
Subject: [JBoss-dev] TxInterceptor split is bad
What if you don't have java on the client side? What if you're CORBA
with
OTS? You're
be advantageous to have something analogous to the
InvokerXAResource in the client making this call rather than requiring a
call back from jboss.
david jencks
On 2003.02.12 16:31 Bill Burke wrote:
What if you don't have java on the client side? What if you're CORBA
with
OTS? You're making
The design goal is to produce a working dtm that does not make
unnecesary
inter-vm calls. The functionality of the client side tx interceptor
appears to be unavailable with the CORBA OTS if we do not write
some client
side stuff.
Here is the sequence of events for a
This is great stuff David, I will capture this on the forums for
historical
and referencial purposes. David, this whole email thread needed to
happen.
Yes, I was being abrasive somewhat, but I did it to get your attention.
Sometimes questions get ignored if you're nice
Is anybody seeing a million errors just booting run -c all? How bad is the
testsuite failing? I'm in the process of getting a clean checkout, but
would appreciate if anybody has any info right now.
Thanks,
Bill
---
This SF.NET email is
For better or for worse I've changed all Interceptors and Invokers to pass
back an InvocationResponse object. This will allow us to piggy back
information back to the client from the server for Interceptors that need
it.
I ran the testsuite and it looks about as good as it was before.
If
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Sacha
Labourey
Sent: Friday, February 14, 2003 2:17 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] TxInterceptor split is really really good
Why is this unfortunate? I thought it was a great
Please put these tests in the testsuite. We need nightly reports on the
stability of JBoss. Plus, if they aren't integrated with testsuite you risk
somebody breaking your code with a new change to the core.
Again, put these tests in testuiste
Thanks,
Bill Burke
Chief
for this purpose. We need a definition in
buildfragments/defaults.ent and to include it in the
_default:tests target.
david jencks
On 2003.02.14 11:26 Bill Burke wrote:
Please put these tests in the testsuite. We need nightly reports on the
stability of JBoss. Plus, if they aren't
stephan reich has been working
on this. Its not Branch_3_0_0 BTW, its Branch_3_0, maybe that is your
problem.
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Finn, MichaelSent: Friday, February 14, 2003 12:16
PMTo: Jboss-Development-List
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Sonnek, Ryan
Sent: Monday, February 17, 2003 4:42 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-dev] jbosscx rfe 677512
thank you all for your reply, i'll try and clear some things up for all
I think this deserves CVS access. James, can you send me your sourceforge
id? Then you can commit this yourself.
Regards,
Bill
p.s. [EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of James
Cooley
Sent: Monday, February 17, 2003
http://www.jboss.org/developers/projects/jboss/aop.jsp
Kinda crappy, but I'll be updating/editing/rewriting as time goes by.
Regards,
Bill Burke
Chief Architect
JBoss Group, LLC
---
This sf.net email
What you implemented is fine. My only problem with it is that I
think it is more logical to let the server decide if it needs the
tx, and that I think the registration callback could be avoided
(with minimal redundant client side bookkeeping) even if the
decision is made on the server side.
jmx/build.xml probably needs to reference dom4j.jar. I just check
out last night at 10 pm with no problems. Did you do an update instead of
a clean checkout? I don't think update grabs thirdparty jars for some
reason.
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David
Jencks
Sent: Wednesday, February 19, 2003 11:02 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] TxInterceptor split is really really good
On 2003.02.19 09:37 Bill Burke wrote:
What you
are you going to be remoting POJO with AOP?? With a
proxy? Who will create the proxy objet?
Regards,
Hiram
--- Bill Burke [EMAIL PROTECTED] wrote:
Ok, maybe I shouldn't have said fatally flawed.
But again, my gut tells
me that it is bad to have a dependency between
server and client
pointcuts
and such.
Bill
Regards,
Hiram
--- Bill Burke [EMAIL PROTECTED] wrote:
Ok, maybe I shouldn't have said fatally flawed.
But again, my gut tells
me that it is bad to have a dependency between
server and client
interceptors if it is not absolutely needed.
-Original Message
Whoops, forgot to send this too.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David
Jencks
Sent: Friday, February 21, 2003 5:02 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] TxInterceptor split is really really bad
I'm getting kind of tired
I would like to note that my future plans for this involve method specific
interceptor chains with a variety of client side and server side tx
interceptors, each one performing half of the TxSupport work. No maps,
just different specialized interceptors, with different interceptors per
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Ole
Husgaard
Sent: Wednesday, February 19, 2003 9:11 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] TxInterceptor split is really really good
The OTS policy only supports the equivalents of never,
Thanks. Sorry for this. +1 Guiness for me ;-)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Jeremy Boynes
Sent: Sunday, February 16, 2003 8:14 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] (no subject)
This should be fixed now.
rewriting everything. My
bet David gets there first since I've got A.D.D.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill
Burke
Sent: Friday, February 21, 2003 6:09 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] TxInterceptor split
with multiple invokers.
This is the approach I will take. I hope to iterate better and cleaner this
time around though.
Bill
Regards,
Hiram
Bill
Regards,
Hiram
--- Bill Burke [EMAIL PROTECTED] wrote:
Ok, maybe I shouldn't have said fatally
flawed.
But again, my gut tells
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Hiram
Chirino
Sent: Friday, February 21, 2003 6:44 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] TxInterceptor split is really really bad
--- Bill Burke [EMAIL PROTECTED] wrote:
I would
and/or I will end up
rewriting everything. My bet David gets there first since I've got
A.D.D.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Bill Burke
Sent: Friday, February 21, 2003 6:09 PM
To: [EMAIL PROTECTED]
Subject: RE
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David
Jencks
Sent: Friday, February 21, 2003 9:26 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing
since sliced bread
On 2003.02.21 18:58 Bill Burke
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David
Jencks
Sent: Saturday, February 22, 2003 1:43 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] org.jboss.aop.MethodMetaData
public Object resolve(Invocation invocation, String group, String
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David
Jencks
Sent: Monday, February 24, 2003 9:48 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData
On 2003.02.24 09:14 Bill Burke wrote:
-Original Message
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Bill
Burke
Sent: Monday, February 24, 2003 10:06 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData
-Original Message-
From: [EMAIL PROTECTED]
[mailto
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David
Jencks
Sent: Saturday, February 22, 2003 11:48 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing
since sliced bread
This is really boring and
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David
Jencks
Sent: Monday, February 24, 2003 10:37 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData
big snip
I also want to add that the current interface for
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Sacha
Labourey
Sent: Monday, February 24, 2003 10:33 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData
When an
Interceptor wants metadata, it walks the chain. Each
One more thing
We really need a way to generically define metadata and a generic way for an
interceptor to obtain class/ejb metadata. Currently, if somebody wants to
define a custom interceptor, the only way define class/ejb metadata is to
modify and recompile JBoss code. Interceptors
it looks like you are the one invent the perfect design/API.
So can you present you invocation chain as did and show us the error in
our logic?
-dain
On Monday, February 24, 2003, at 09:39 AM, Bill Burke wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David
Jencks
Sent: Monday, February 24, 2003 1:54 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData
On 2003.02.24 13:17 Bill Burke wrote:
-Original Message
the same argument from you again.
Please implement your idea for how dtm will work so we can discuss
something concrete.
I think I already have (see below), but will reread your posts to make sure.
Bill
thanks
david
On 2003.02.24 13:37 Bill Burke wrote:
Sure. The TxSupport class is a nice
your idea for how dtm will work so we can discuss
something concrete.
I think I already have (see below), but will reread your posts to
make sure.
Bill
thanks
david
On 2003.02.24 13:37 Bill Burke wrote:
Sure. The TxSupport class is a nice change and makes the
code much more
Aha! At least there's something we can agree on!
I may be too dense in my understanding of the TX stuff right now so have
patience. I may/may not have a point.
As far as remoting goes. The SimpleMetaData class does have the means
now
to define whether data should be serialized across
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David
Jencks
Sent: Monday, February 24, 2003 3:02 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing
since sliced bread
On 2003.02.24 14:35 Bill Burke
right? I think david just needs to
avoid duplicating the code that is in the trunk invoker all over the place.
Bill, how doable is that?
Regards,Hiram
Bill Burke [EMAIL PROTECTED] wrote:
IMHO,
CORE client interceptors such as security and tx should be writtensuch
that is in the trunk invoker over to all ther
other java based transports. But that seems more
error prone to me.
Regards,
Hiram
--- Bill Burke [EMAIL PROTECTED] wrote:
What I'm saying is, why add this complication? Do
we really need it? KISS.
-Original Message-
From
This is one of the very reasons I avoid IDEs. If you don't live in them,
you die by them.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Hiram
Chirino
Sent: Wednesday, February 26, 2003 3:42 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Eclipse
We will eventually be forced to work with non-java clients. The world is
not Java centric. We will eventually work with companies that required a
lot of non-java integration. I've already worked at 2 before JBG.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
There have been a lot of build breakages lately because people are using JDK
1.4 features and they break in JDK 1.3 builds. WE STILL SUPPORT JDK 1.3.
My suggestion? Stop developing JBOss with jdk 1.4 and develop with 1.3.
Please stop the sloppiness.
Bill
:
[EMAIL PROTECTED]Subject: RE: [JBoss-dev]
stop using JDK 1.4 for development
Bill,
I thought JBoss was going to support 1.4. Is this not the
case?
- Matt
-Original Message- From: Bill Burke
[mailto:[EMAIL PROTECTED] Sent: Fri 2/28/2003 8:42 AM
To: Jboss
: [JBoss-dev] stop using JDK 1.4 for development
There's a big difference between supporting 1.4 and _not_ supporting
1.3
Matt Munz wrote:
Bill,
I thought JBoss was going to support 1.4. Is this not the case?
- Matt
-Original Message-
From: Bill Burke
as much as we
could
find of the jca and jta frameworks use this with good results. How
could
we make this better known and popularize it?
thanks
david jencks
On 2003.02.28 08:42 Bill Burke wrote:
There have been a lot of build breakages lately because people are
using JDK 1.4
I meant to say not perfect.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Bill
Burke
Sent: Friday, February 28, 2003 11:27 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] stop using JDK 1.4 for development
chris kimptons builds are perfect
I hope we're not going to have pre-compile directives everywhere just so
that people can use nested Runtime, Remote, and regular Exceptions.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Scott
M Stark
Sent: Friday, February 28, 2003 6:49 PM
To:
what
version of jboss are you running. I thought this was fixed in 3.0.5 or
3.0.6.
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]On Behalf Of
Bijoy Sivan .KSent: Monday, March 04, 2002 7:53
AMTo: [EMAIL PROTECTED]Subject:
[JBoss-dev] removing
Is this an XDoclet thing again?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, March 02, 2003 8:41 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
If you guys are going to do this, do it soon. Eventually I need to touch a
butt load of files in EJB land.
Thanks,
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Dain
Sundstrom
Sent: Monday, March 03, 2003 1:32 AM
To: [EMAIL PROTECTED]
The AOP framework really right now is only for POJO interception. I do have
the beginnings of DynamicProxies though. The AOP POJO framework can
intercept static and member methods, constructors, and fields. YOu can
define metadata on a class via xml, as well as interceptor stacks at the
Class
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Monday, March 03, 2003 2:17 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
On
persistence is not realistic for a prototype. The rest is.
, #2, and #3a if I can focus solely on this for 5 days with no interuptions.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Scott
M Stark
Sent: Monday, March 03, 2003 3:50 PM
To: [EMAIL
Hey all,
I can see why David was so excited about the new JBoss Remoting framework
that Jeff Haynie and Tom Elrod wrote. I had dinner with Jeff in Boston last
night and over a few beers he discussed in detail their design and features
the framework provides. Jeff/Tom, please correct me where
the RMIClassLoader will automatically pull down all classes
from remote. If we can somehow compose an object dependency graph when
a class is required, we could further optimize this even more.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill
Burke
Sent
What are the advantages of it? It would require a client container. I
wonder if any other vendor supports it.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Igor
Fedorenko
Sent: Tuesday, March 04, 2003 11:24 AM
To: [EMAIL PROTECTED] Sourceforge. Net
I'm begging people not to do any large scale changes to EJB land. I'm about
to undertake converting all the EJB interceptors and invokers to use the AOP
Invocation object and Interceptor interface. This my first step on
integrating the AOP DP framework.
I'm asking you to please notify me before
The solution would probably be to cut the XDoclet building into 2 separate
bundles. I get this same error every time I build head from scratch and
always with XDoclet.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Chris
Kimpton
Sent: Wednesday,
401 - 500 of 1981 matches
Mail list logo
