Rickard,
*Very* interesting question. In my mind you need to agonize over
something else...
Multiple personality disorder of jBoss 2.0
++++++++++++++++++++++++++++++++++++++++++
See the industry is still struggling with the dynamic approach we are
already exploring 2 steps ahead with the dynamic "a la carte" container.
The theory is simple. In group theory (mathematics) there is this
notion of the group and the manifestation of the group in projection
spaces. (don't question my rigor, working from memory here). In clear
what these beasts are is that the "main" object is something quite
abstract with well defined properties but whose "existence" is only seen
through manifestations in specific spaces. The "manifestations" are
"projections" i.e. particular embodiements of the group in a smaller
spaces. The real group, never really seen, is the underlying "pattern"
if you wish that the different projections manifest and express in
different ways.
In practice what is means is simple. EVERY bean and application that
you deploy might require a different environment to execute in and a
dynamic changing nature of the container. What this means is that
idealy the beans would see "myContainer" as a container tailored to
their configuration needs and therefore ideal. The bean is tricked in
thinking that the container is "all for himself" but the bean next to
him has a completely different configuration. A bit like the "matrix"
really where different "humans/beans" in pods (containers) see their own
projection of the "reality" around them even though it is only made by
the "server". The abstraction is this architecture we have the
projections the reality seen ('Point container') by the bean inside the
server. You and I know the server is complex, the beans don't.. and
that should be your guide in configuration.
The bottom line is kinda simple. You need to clearly separate your
target audience, there are those that will need to have access to this
"behind the mirror" container configuration
1- Telkel ;-) clearly dynamic !!! :-))))))
2- The ISV vendor that wants to customize the server to his
application.. want to take the singleton or another plugin for
persistence because you are "embedded" in a application, then these guys
need to access (granted code would do but would be odd) static OK
(developers) but dynamic better (just edit the file that deploys the
container, repackage)
3- The power DBA that wants all his db seen with different type of pools
and TX setting for the good reasons that were discussed and requested on
this list... clearly dynamic.
BOTTOM LINE: SEPARATE THE FILES, DON"T PUT CONTAINER ARCH INFORMATION IN
THE SAME GUI THAT THE BEGINNER DEVELOPER WILL SEE (did I get my point
across???). It seems to me to be beginer recommendations in GUI design
but I realize that EJB spec itself, the ejb-jar.xml and different xml
files did go through the same "splitting of audiences" and that we need
to know who this information is targeted to (the administrator and the
deployer, the developer in certain cases).
BOTTOM LINE: keep files and PROVIDE DEFAULT CONFIGURATION that the
ocntianer will read, I promised I will take a look at that (possibly
today).
So it is pretty clear to me that many people will need the high level
feature of container multiple personality and that TOOLS AND ISV vendors
will be drooling over this!!!!!!
See if you want to do that right now YOU NEED TO BUY A **MONOLITHIC***
CONTAINER THAT YOU CAN"T REALLY ADAPT OR PROJECT. BUY THE STUFF AND FIT
IT IF YOU CAN!!!! The one size fits all of the industry is PREHISTORIC.
You are flying ahead of the pack, Rickard, they are still struggling
with your dynamic proxies, stay ahead of the pack my friend, many of us
here follow you.
So again, wrong problem keep a File for configuration just realize that
it is a problem with EJX separation layout and presentation not the
architecture. You architecture is a diamond in the rough.
regards
marc
_________________________
"Bim, Bim, Bim, Bim, BIM"
--Vegas Soul, Baltram --
_________________________
Rickard �berg wrote:
>
> Hey
>
> As you all know the jBoss 2 containers have a concept called interceptor
> which is used to implement everything that should be done per call, such
> as tx checking and logging etc.
>
> Initially I wanted to be able to configure these directly through the
> EJX GUI, in a way similar to the other plugins. However, there are a few
> drawbacks to this. First of all, it is non-trivial to make a good
> interface that lets you add/remove interceptors to the chain, and move
> them around easily. Also, to the average user it won't be very intuitive
> that many very important settings such as commit options (for
> TxInterceptor) should be set there. In addition, if the interceptors are
> set in the wrong order this can lead to complete malfunction of the
> container. Being able to have complete control in the GUI is flexible; a
> little too flexible however.
>
> So, I was thinking that instead all of these settings could go in the
> main Container settings. The set of interceptors, and their respective
> order in the call chain, would be fixed in code (ContainerFactory to be
> precise). The interceptors would then ask the Container for all of the
> settings. This also makes it trivial to code the GUI (adding simple
> properties is easy!).
>
> A poweruser wanting to change the interceptors (add custom security for
> example) would have to edit the ContainerFactory source, but this isn't
> expected to be very common.
>
> So, the question is: does it seem like a good idea to do all
> configuration of interceptors in the Container, and let them be
> hardcoded in ContainerFactory? (my vote is, of course, yes).
>
> If so, here's a list of things that I would want to add to the Container
> configuration GUI: (affected interceptor given)
> * Commit options (EntitySynchronizationInterceptor). This setting
> affects which commit option that is used (A,B,C as defined in EJB spec)
> * Call logging (LogInterceptor). This setting logs all calls to a log.
> Useful for debugging and audits. Exception logging is always available
> even if this is turned off
>
> Well... that's it for now I guess..
>
> Comments please :-)
>
> /Rickard
>
> --
> Rickard �berg
>
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> http://www.telkel.com
> http://www.jboss.org
> http://www.dreambean.com
--
----------------------------------------------------------------
Visit Telkel at JavaOne(SM), Sun's 2000 Worldwide Java Developer
Conference(SM)
June 5-9, 2000 - Moscone Center - San Francisco
