I will second Justin in that it is a gui issue and that you should still use
the file just provide the default, clean gui separation.
We will do something about EJX, as we have discussed... any GUI gurus on the
list???
marc
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Justin Forder
Sent: Monday, May 22, 2000 7:17 AM
To: jBoss Developer
Subject: Re: [jBoss-Dev] Interceptor configurations: flexibility
vsusability
First impressions:
You discuss the difficulty and the hazards to the user of doing GUI
configuration of the interceptor chain. Being unhappy with the GUI
option, you propose to hard-code the interceptor order.
Why not define the interceptor existence and order in an XML config
file? You (or anyone) can come back to the GUI option later.
My guess is that the GUI is not intrinsically hard, it's just not a
style of interaction that is currently supported in EJX. To make it less
dangerous, there should be a "restore default settings" button (or the
user defines new configurations, and chooses between them, with the
original configuration always being available as a choice).
Rickard �berg <[EMAIL PROTECTED]> 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
>
--
Justin Forder
