David Jencks wrote:
The thing is that we have one major problem with Spring + xbean :
when you want to debug the server, from the initialization point,
it's a real PITA, as the flow is not know unless you have the
server.xml and the 1.0 mapping file open on the same screen (and I
don't have a 40" screen on my laptop ...).
I'm not sure yet why this is a problem. I'd expect you'd put
breakpoints in the constructors of all the components and you'd see in
your debugger what all the parameters are.
This is the (break)point : to do that, you have to know which
constructor to add a breakpoint to. So you have to open
1) The server.xml file
2) The 1.0 containing the mapping between bean names and class names
3) All the constructors
How is this different from having a configuration data object separate
from the component?
You will have to put one single breakpoint, and then step into the code.
Another point is that we have mixed configuration laoding and
initialization, which is, from my POV, a bad mistake.
OK, I think this might be the big question here that could determine
how to proceed. I think there are kinda 2 extremes of points of view
as to what is "good":
1. we just have components that do stuff, and the framework directly
wires them up and then they are the running server. As far as
complexity of the working components this is obviously (at least to me
:-) the simplest possible solution and good design. However, there's
no way to look at a java model of the configuration without having a
running server, and there may be a mismatch between the way you want
to configure the components and the structure of the components.
2. we have a java data-object model of the configuration, and some way
of taking such a model and pushing the info into components and
starting the components. This has lots more objects than (1) but may
possibly result in easier configuration of the "important stuff"
Then there are lots of ways of mixing these up. I don't think there's
any right answer. I do think (1) tends to be simpler code but harder
configuration. IMO Spring is definitely oriented towards supporting
(1). With the xbean-spring generated schema we could easily do a
version of (2) where we generate data objects from the schema using
jaxb and add a lifecycle "start" method to create the component. This
could eliminate spring entirely. Then we could tweak the schema to
make it easier to configure stuff if we wanted.
I think that you sum up pretty well what I wanted to express... I
personally favor (2) because it separates the concerns :
- the way we describe the configuration
- the way we load the configuration
- the way the server use the configuration
I know that some will disagree with me, and it's fine, as soon as I
just express some frsutration I have. That does not mean I'm right !
But I want to make it clear that if I'm frustrated with what we have,
then there is some chance that new committers will find it
frustrating too...
I wish I understood better what you are frustrated with..... trying to
configure the server in studio is certainly something that is not well
supported, but I don't quite get the other stuff yet.
Yeah, may be I was not explicit enough... I can see that there are some
good approach, like modello (seems simple), EMF (way too complex for me,
but seems to solve my problem too), and even xbean alone.
If I were to repost my initial mail, I would change the tittle to "Why I
think that Spring is too much when xbean could be enough".
What happened is that I trried to load the latest version of server.xml
in Studio, and got a NPE (we are using a hand crafted XML parser).
Obviously, as xbean generates a XSD, we could use Jaxb to do the work.
There are still some remaining issues : either xbeans or modello are
documentation-free (but when I look at ADS, I would tell myself : "read
the code, dude" ;). Also modello seems more intuitive, but you have to
write the model by hand, while xbean is based on annotations.
Anyway, I think that either Spring or xbeans is just bringing some
confusion, and we could do better. If I had to vote, I would go straight
for xbeans alone, and leave spring on the side of the road...
Thanks David for the clarifications!
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
