Agreed. FWIW already AspectWerkz can dynamically weave aspects into
Java code at deployment time using a special ClassLoader which performs
the necessary bytecode swizzling to insert the aspects.
http://aspectwerkz.codehaus.org
On Sunday, August 10, 2003, at 05:10 pm, Jules Gosnell wrote:
let me subvert this thread a little...
for the future...
If you step back a little and look again at the precompiled and
dynamically aggregated containers, I think you would find that they
could both be decomposed into aspects in a pretty similar way. The
difference is simply in the choice of how to implement those aspects.
The thing that I find exciting is that from only a little bit of
reading around aspects it looks as if it will soon be possible (if it
is not already) to weave the same set of aspects at either compile or
deploy/run time. Whether the aspect guys will be able to be as
efficient at deploy-time weaving as they can at compile-time is a
matter for an aspect list, but I suspect that compile time weaved
aspects will not be any slower than a custom compiled container and
deploy-time weaving will be considerable more efficient than existing
run time interceptor frameworks.
So, in short, I think that the gap between compile time and deploy
time container composition is probably shrinking into irrelevance,
which is good news as it means that both teams can concentrate on a
single impl - competition is good, but right now I think it should be
all hands on deck to get something out there...
Jules
Greg Wilkins wrote:
Even if we are able to support two or more EJB containers, I would
never recommend using different ones for development and deployment.
That, as you say, is just asking for inconsistencies to cause grief.
But some users may choose to give up the benefits of the dynamics
during development for a compiled container - because either they
really want/need every nano seconds of latency reduced or because
their culture is opposed to dynamics on production machines.
If there are really several diametrically opposed ways of doing
EJBs - then it would be great if geronimo could support them all.
But then I have little idea of the amount of work required to
come up with AbstractEJBContainer.
cheers
Test Account wrote:
Greg,
Absolutely, that was the gist of what I was trying to say,
albeit,
somewhat poorly. You want the fast dynamic development deployment
capabilities while banging out endless refactorings. But when it
comes time
to deploy in a scalable environment you may need to eek every last
drop of
performance, so may need the compiled skeletons. It would be great
to have
both. The problem would be in guaranteeing consistency between the
two
paths. I wouldn't want to get differing behavior when running in
development from when running in production.
Enjoy,
Craig
----- Original Message ----- From: "Greg Wilkins" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, August 10, 2003 1:07 AM
Subject: Re: Reflection Bad, OO and direct Method invocation Good...
I don't know if this falls into the "too much choice is a bad thing"
arena, but would it not be good if we could have both a dynamic
jboss
inspired EJB container and a compiled EJB container (perhaps from
or inspired by the JOnAS folks??).
--
Greg Wilkins<[EMAIL PROTECTED]> Phone/fax: +44
7092063462
Mort Bay Consulting Australia and UK.
http://www.mortbay.com
--
/*************************************
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
* http://www.coredevelopers.net
*************************************/
James
-------
http://radio.weblogs.com/0112098/
