You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2008/03/05 23:38:29 UTC
Why I think Spring + xbean is wrong ...
Hi guys,
first, I want to say that it's not a rant in any way.
Straight to the point now.
I was trying to run the Studio to open the latest version of the ADS
configuration file (server.xml). I got a blatant NPE. Of course, one can
blame the Studio code which is not defensive enough (fair enough). But :
the problem is that we are expecting a certain structure for this
server.xml file, which has changed quite a lot lately. Because we are
using a Sax parser to parse it (eh, no other way, as we don't want to
instanciate the beans).
The main issue is that one would have prefered to load the beans
directly from the Spring structured file, but there is no way to do that
(beans get instanciated as soon as they are loaded). The way the server
is built, and more important, the way the configuration is written,
leads to a real problem : the Spring configuration launch the server, as
the beans are immediatly instanciated.
So there is no other way but using a hand drafted XML parser...
Could have it been done better ? I think so.
The first thing would have to decouple the configuration from the
launch. Laoding configuration should by no mean instanciate the server
or any function. This is simply dangerous, error prone, and horribly
painfull when debugging the init process (you have to *know* what is
going on to be able to decipher the init process, which may change as
loaded beans can change).
The second thing is that I personally find xbean overly complex and
really useless. Just because it allows you to use some cool annotation
into the code, it should not lead developer to hit the wall as soon as
he tries to understand where those annotations has been added. Now, the
configuration is spread all over the code, instead of being gathered in
a single location : the configuration file.
Third, the mapping between bean names and real classes is totally
masked. If you look at the server.xml file, who is able to say that
'replicaId' is mapped to the
org.apache.directory.mitosis.common.ReplicaId class ? No one, except
those who *know* that the xbean plugin generates a 1.0 file (yes, 1.0 is
its name !) somewhere here :
apacheds/apacheds-xbean-spring/target/xbean/META-INF/services/org/apache/xbean/spring/http/apacheds.org/config/1.0
I do think that we went far too far.
wdyt ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Why I think Spring + xbean is wrong ...
Posted by Emmanuel Lecharny <el...@gmail.com>.
David Jencks wrote:
>
> On Mar 5, 2008, at 2:38 PM, Emmanuel Lecharny wrote:
>
>> Hi guys,
>>
>> first, I want to say that it's not a rant in any way.
>>
>> Straight to the point now.
>>
>> I was trying to run the Studio to open the latest version of the ADS
>> configuration file (server.xml). I got a blatant NPE. Of course, one
>> can blame the Studio code which is not defensive enough (fair
>> enough). But : the problem is that we are expecting a certain
>> structure for this server.xml file, which has changed quite a lot
>> lately. Because we are using a Sax parser to parse it (eh, no other
>> way, as we don't want to instanciate the beans).
>
> You have me at a disadvantage here as you give no clue why you are
> trying to programatically understand server.xml without starting the
> server.
Simple scenario, as explained before : The Studio tries to open the
server.xml just because as it carries ADS configuration, it is really
cool to allow users to manipulate a GUI instead of diving into a 400
lines XML file... No need to start the server ofr that, isn't it ?
> Without knowing that, its hard to discuss anything intelligently. No
> matter what the solution, its easy to come up with lots of scenarios
> that are difficult using that solution.
Is this scenario enough to justify my need for a simplier solution ?
>
>>
>> The main issue is that one would have prefered to load the beans
>> directly from the Spring structured file, but there is no way to do
>> that (beans get instanciated as soon as they are loaded). The way the
>> server is built, and more important, the way the configuration is
>> written, leads to a real problem : the Spring configuration launch
>> the server, as the beans are immediatly instanciated.
>
> How is this a problem? Seems to me like a gigantic simplification
> over having spring do its lifecycle + apacheds duplicate all the
> lifecycle work. I'm personally a believer in constructor dependency
> injection for components which means that, normally, once the
> component is instantiated, it's started. IMO this is good component
> design so there would have to be an extremely compelling reason to
> move away from this.
IMO, initialization should be a totally different phase that the
configuration loading. Coupling those two guys just leads to big problems...
>>
>> So there is no other way but using a hand drafted XML parser...
>
> Umm, there's a generated schema, so you can also use jaxb or xmlbeans
> to generate data classes that exactly represent the xml and use them.
> Hand crafted xml parsers have not been a plausible solution to
> anything for years AFAIK.
I agree on that (hand crafted XML parsers are just silly, except in
specifci cases where performance is needed), but why should we generate
new class when we already have existing classes ?
>>
>> Could have it been done better ? I think so.
>> The first thing would have to decouple the configuration from the
>> launch. Laoding configuration should by no mean instanciate the
>> server or any function. This is simply dangerous, error prone, and
>> horribly painfull when debugging the init process (you have to *know*
>> what is going on to be able to decipher the init process, which may
>> change as loaded beans can change).
>>
>> The second thing is that I personally find xbean overly complex and
>> really useless. Just because it allows you to use some cool
>> annotation into the code, it should not lead developer to hit the
>> wall as soon as he tries to understand where those annotations has
>> been added. Now, the configuration is spread all over the code,
>> instead of being gathered in a single location : the configuration file.
>
> I have no idea what you mean here. AFAIK the configuration is still
> all in server.xml, although now there is also a schema so automated
> checking of some of the plausibility of the server.xml file is possible.
everything is possible, but some are just more complex when using such a
scenario. That's my problem ...
>
>>
>> Third, the mapping between bean names and real classes is totally
>> masked. If you look at the server.xml file, who is able to say that
>> 'replicaId' is mapped to the
>> org.apache.directory.mitosis.common.ReplicaId class ? No one, except
>> those who *know* that the xbean plugin generates a 1.0 file (yes, 1.0
>> is its name !) somewhere here :
>> apacheds/apacheds-xbean-spring/target/xbean/META-INF/services/org/apache/xbean/spring/http/apacheds.org/config/1.0
>>
>
> well, it would have been a lot easier to have a separate namespace for
> each maven subproject, but I thought people would object more to that
> than having a single namespace.
That won't solve the problem. We now have three places to look at when
debugging the server :
- the server.xml file
- the 1.0 file (silly name ...)
- and the code.
When I debug a piece of software, I just hate jumping through files like
that. May be I'm just thinking a little bit too linearly. I like to step
the code, not to step the code/server.xml/1.0/code/server.xml/.... Too
complicated for me...
>>
>> I do think that we went far too far.
>>
>> wdyt ?
>>
>
> I think spring sucks in a lot of ways and look forward to the time
> when it can be replaced with an extended version of jaxb that can
> handle constructor dependency injection and factory beans. Right now
> I think spring + xbean-spring is still the best balance between
> expressive configuration and a reasonably functional container.
>
> If we were willing to abandon all constructor dependency injection and
> take over the component lifecycle code entirely then we could probably
> just use jaxb to create all the components. Dain is also working on
> some stuff that might allow a switch away from spring.
IMO, Spring is ok if it is limited to loading beans, but not instanciate
them. There is no need to initialize anything but the data. At the end
of the day, beans should be plain stupid POJO, nothing more.
If you want to go any further, then just have a simple bean which
initalize the whole stuff after having loaded all the
POJO/configuration, taht's my point. I want to be able to put a
breakpoint in the code where the POJOS are read, being able to check
that the configuration is now present in those data structures, and then
being able to step the initialization process in a debugger without
having to put breakpoinst all over the code to know what's going to be
called...
Is that an unreasonnable expectation ?
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Why I think Spring + xbean is wrong ...
Posted by David Jencks <da...@yahoo.com>.
On Mar 5, 2008, at 2:38 PM, Emmanuel Lecharny wrote:
> Hi guys,
>
> first, I want to say that it's not a rant in any way.
>
> Straight to the point now.
>
> I was trying to run the Studio to open the latest version of the
> ADS configuration file (server.xml). I got a blatant NPE. Of
> course, one can blame the Studio code which is not defensive enough
> (fair enough). But : the problem is that we are expecting a certain
> structure for this server.xml file, which has changed quite a lot
> lately. Because we are using a Sax parser to parse it (eh, no other
> way, as we don't want to instanciate the beans).
You have me at a disadvantage here as you give no clue why you are
trying to programatically understand server.xml without starting the
server. Without knowing that, its hard to discuss anything
intelligently. No matter what the solution, its easy to come up with
lots of scenarios that are difficult using that solution.
>
> The main issue is that one would have prefered to load the beans
> directly from the Spring structured file, but there is no way to do
> that (beans get instanciated as soon as they are loaded). The way
> the server is built, and more important, the way the configuration
> is written, leads to a real problem : the Spring configuration
> launch the server, as the beans are immediatly instanciated.
How is this a problem? Seems to me like a gigantic simplification
over having spring do its lifecycle + apacheds duplicate all the
lifecycle work. I'm personally a believer in constructor dependency
injection for components which means that, normally, once the
component is instantiated, it's started. IMO this is good component
design so there would have to be an extremely compelling reason to
move away from this.
>
> So there is no other way but using a hand drafted XML parser...
Umm, there's a generated schema, so you can also use jaxb or xmlbeans
to generate data classes that exactly represent the xml and use
them. Hand crafted xml parsers have not been a plausible solution to
anything for years AFAIK.
>
> Could have it been done better ? I think so.
> The first thing would have to decouple the configuration from the
> launch. Laoding configuration should by no mean instanciate the
> server or any function. This is simply dangerous, error prone, and
> horribly painfull when debugging the init process (you have to
> *know* what is going on to be able to decipher the init process,
> which may change as loaded beans can change).
>
> The second thing is that I personally find xbean overly complex and
> really useless. Just because it allows you to use some cool
> annotation into the code, it should not lead developer to hit the
> wall as soon as he tries to understand where those annotations has
> been added. Now, the configuration is spread all over the code,
> instead of being gathered in a single location : the configuration
> file.
I have no idea what you mean here. AFAIK the configuration is still
all in server.xml, although now there is also a schema so automated
checking of some of the plausibility of the server.xml file is possible.
>
> Third, the mapping between bean names and real classes is totally
> masked. If you look at the server.xml file, who is able to say that
> 'replicaId' is mapped to the
> org.apache.directory.mitosis.common.ReplicaId class ? No one,
> except those who *know* that the xbean plugin generates a 1.0 file
> (yes, 1.0 is its name !) somewhere here : apacheds/apacheds-xbean-
> spring/target/xbean/META-INF/services/org/apache/xbean/spring/http/
> apacheds.org/config/1.0
well, it would have been a lot easier to have a separate namespace
for each maven subproject, but I thought people would object more to
that than having a single namespace.
>
> I do think that we went far too far.
>
> wdyt ?
>
I think spring sucks in a lot of ways and look forward to the time
when it can be replaced with an extended version of jaxb that can
handle constructor dependency injection and factory beans. Right now
I think spring + xbean-spring is still the best balance between
expressive configuration and a reasonably functional container.
If we were willing to abandon all constructor dependency injection
and take over the component lifecycle code entirely then we could
probably just use jaxb to create all the components. Dain is also
working on some stuff that might allow a switch away from spring.
>
thanks
david jencks
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
Re: Why I think Spring + xbean is wrong ...
Posted by Ole Ersoy <ol...@gmail.com>.
Emmanuel Lecharny wrote:
> Ole Ersoy wrote:
>> Hey Emmanuel,
> hey OLE,
>
> I'm not going to comment everything you wrote, just because I don't have
> more than a 100 Kfeet vision of what EMF is and can do.
>
> You think that EMF is the ultimate solution, but I don't have time to
> read the thousands of pages I have found about EMF on the web.
Yeah - Some of the material can be simplified a great deal I think / broken down into simpler use cases.
>
> Here is what I suggest : can you just provide some working sample using
> EMF ?
>
> What we need is :
> - a file will contain ADS configuration (server.xml)
For this we just need to grab the server.xml Schema and generate the corresponding EMF beans from it. I can do this and check it into my sandbox. Anyone have a quick link to the server.xml xsd schema?
> - we should be able to read it easily on Studio (without writing a hand
> crafted XML parser)
That's easy. In addition to generating a model, EMF can generate Eclipse plugins, including an editor for the model, that Studio team could use the editor plugin as an example for how to interact with the model. The generated editor comes with undo,redo,save,etc. so most of the base functionality is already there.
> - we should be able to produce this same file on Studio
Also easy. Studio would just create a uninitialized instance of the model and serialize it. This takes about 3 lines of code...I'll make sure to point them out when it's done.
> - we should be able to read this file in ADS, validating it and tells
> explicitely where we have errors
I know this is what the EMF framework is for, so using it would be an added plus for the Studio team I think. I'm not an expert on it, but I'll do my best to find answers on how to better provide validation feedback whenever encountered. The EMF ecore editor uses this extensively, and the feedback is great. There are two tabs in the editor. If the parser encounters invalid feedback, it displays it in the feedback tab.
> - we should then be able to use the generated objects in a simple way
> (for instance, int port = config.getServerPort(); or Interceptor
> schemaInterceptor = config.getInterceptor( "schema" ); )
Yup - Works just like that. Also if you need a configuration object several layers down in the containment hierarchy, you can use XPath expression...something like resource.getObject("/rootElement/nextLevel/objectIwant);
Now I just have to find the server.xml schema. If anyone has a quick link to it, that would be great.
Cheers,
- Ole
Re: Why I think Spring + xbean is wrong ...
Posted by Emmanuel Lecharny <el...@gmail.com>.
Ole Ersoy wrote:
> Hey Emmanuel,
hey OLE,
I'm not going to comment everything you wrote, just because I don't have
more than a 100 Kfeet vision of what EMF is and can do.
You think that EMF is the ultimate solution, but I don't have time to
read the thousands of pages I have found about EMF on the web.
Here is what I suggest : can you just provide some working sample using
EMF ?
What we need is :
- a file will contain ADS configuration (server.xml)
- we should be able to read it easily on Studio (without writing a hand
crafted XML parser)
- we should be able to produce this same file on Studio
- we should be able to read this file in ADS, validating it and tells
explicitely where we have errors
- we should then be able to use the generated objects in a simple way
(for instance, int port = config.getServerPort(); or Interceptor
schemaInterceptor = config.getInterceptor( "schema" ); )
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Why I think Spring + xbean is wrong ...
Posted by Ole Ersoy <ol...@gmail.com>.
Hey Emmanuel,
I'm going to comment on how EMF solves the issues, which I've done before, but I figured plugging it in different scenarios might be helpful. I'll just throw it in as a backdrop...
Emmanuel Lecharny wrote:
> Hi guys,
>
> first, I want to say that it's not a rant in any way.
>
> Straight to the point now.
>
> I was trying to run the Studio to open the latest version of the ADS
> configuration file (server.xml). I got a blatant NPE. Of course, one can
> blame the Studio code which is not defensive enough (fair enough). But :
> the problem is that we are expecting a certain structure for this
> server.xml file, which has changed quite a lot lately. Because we are
> using a Sax parser to parse it (eh, no other way, as we don't want to
> instanciate the beans).
First EMF would give you the option to model the configuration file using java interfaces, xml schema, EMF Ecore (XMI) (I'm sure there are all sorts of other means as well now) and provides very smart tooling
for doing all of this, so that you get real time validation of the model.
The just generate the corresponding java beans for loading instances of
server.xml. They are now completely separate from the server, and should be
queried by the server components as the server is loading and needs configuration
information.
Also Studio, JUnit, or anything else could load server.xml files completely
independently of the server and it's components.
>
> The main issue is that one would have prefered to load the beans
> directly from the Spring structured file, but there is no way to do that
> (beans get instanciated as soon as they are loaded).
With EMF the beans / components would get a reference to the configuration model, thus configuration is completely decoupled from the beans / components. So there would be configuration bean (Focused only on providing configuration information, and other beans focused other concerns).
> The way the server
> is built, and more important, the way the configuration is written,
> leads to a real problem : the Spring configuration launch the server, as
> the beans are immediatly instanciated.
>
This is a good argument for using EMF I think.
> So there is no other way but using a hand drafted XML parser...
Hang on...EMF.
>
> Could have it been done better ? I think so.
> The first thing would have to decouple the configuration from the
> launch. Laoding configuration should by no mean instanciate the server
> or any function. This is simply dangerous, error prone, and horribly
> painfull when debugging the init process (you have to *know* what is
> going on to be able to decipher the init process, which may change as
> loaded beans can change).
This is what a ton of projects use EMF for. Complete separation of the
configuration model from other services. Core services should source configuration
information from the "Configuration Service", as you are saying.
>
> The second thing is that I personally find xbean overly complex and
> really useless. Just because it allows you to use some cool annotation
> into the code, it should not lead developer to hit the wall as soon as
> he tries to understand where those annotations has been added. Now, the
> configuration is spread all over the code, instead of being gathered in
> a single location : the configuration file.
With EMF the XML Schema for the configuration file is it. It reflects configuration in its entirety. Update it and everything else is updated automatically...With the exception that the components that are customers of the configuration schema change would have to be updated,....Studio could also use the EMF validation framework to provide informative messages / insight into what is wrong, in case someone introduced errors into the server.xml file.
>
> Third, the mapping between bean names and real classes is totally
> masked.
With EMF the name of the bean corresponds to the name of the XML Schema element. Also, annotations can be used to customize how the model is serialized, although the default xml serialization very intuitive and easy to read.
> If you look at the server.xml file, who is able to say that
> 'replicaId' is mapped to the
> org.apache.directory.mitosis.common.ReplicaId class ? No one, except
> those who *know* that the xbean plugin generates a 1.0 file (yes, 1.0 is
> its name !) somewhere here :
> apacheds/apacheds-xbean-spring/target/xbean/META-INF/services/org/apache/xbean/spring/http/apacheds.org/config/1.0
>
>
> I do think that we went far too far.
>
> wdyt ?
>
>
I personally like to manage configuration completely separately from everything else, so I agree. Being able to load the configuration separately also makes testing a lot easier in my opinion.
If ADS used EMF, components could be written and unit tested by themselves. Another thing that's really cool about EMF is that you can set model defaults on the XML schema, and these will be generated into the Java beans, such that if you create an instance of the server configuration, without actually loading the configuration, it's a valid configuration instance. This can now be passed to a new component being written, and the component can be unit tested using valid configuration data with minimal effort.
ADSConfiguration configuration = new ADSConfiguration();
This is a valid configuration instance. The server could run on this without ever loading server.xml. Thus the same instance can be used for unit testing all the components.
Another benefit that I've mentioned in the past is that using EMF allows a valid server.xml to always automatically generated, since it's just the new / updated model schema serialized.
Cheers,
- Ole
Re: Why I think Spring + xbean is wrong ...
Posted by Chris Custine <cc...@apache.org>.
On the subject of containers, Alex and I had a conversation quite some time
ago about Spring, OSGi, <insert shiny new container here> and I think
everyone agrees that Apache Directory is a toolkit / API / framework upon
which you can you could build a runtime for use with any container, or
deployment style be it a full fledged runtime like OSGi or yet another API
layer like Spring (or both). One of my favorite things about Spring is the
non-invasive nature of its use if you simply use it for IOC. The IOC part
is simply a convenience and if you want to wire together the parts yourself
through code (or JAXB -> POJO, or the EMF thingy), that should work too. I
hope this is all still the case. :-)
Chris
On Sat, Mar 8, 2008 at 1:38 AM, Stefan Zoerner <st...@labeo.de> wrote:
> Emmanuel Lecharny wrote:
> > Do we need a container technology ? The 0.8 version was working without
> > this IoC crap. IoC is, IMHO, hyper over hyped... But this is another
> > debate !
>
> I think a container should not be necessary, if ApacheDS is embedded. In
> this case, every additional dependency will add burden to those who plan
> to integrate it in their applications.
>
> I thought this was basically the idea of using the Spring Framework.
>
> Greetings,
> Stefan
>
>
Re: Why I think Spring + xbean is wrong ...
Posted by Emmanuel Lecharny <el...@gmail.com>.
Stefan Zoerner wrote:
> In the Spring courses for the customer I work for (a training company)
> I use ADS as an example and tell the participants that we have chosen
> it because it is not invasive.
Arf !!!
Just don't give your customers pointers to this mailing list ;)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Why I think Spring + xbean is wrong ...
Posted by Stefan Zoerner <st...@labeo.de>.
Emmanuel Lecharny wrote:
>>
>> I think a container should not be necessary, if ApacheDS is embedded.
>> In this case, every additional dependency will add burden to those who
>> plan to integrate it in their applications.
>>
>> I thought this was basically the idea of using the Spring Framework.
> Back three years ago, when Spring was injected into ADS, I think this
> was just because it was "SO COOL !!!"
In the Spring courses for the customer I work for (a training company) I
use ADS as an example and tell the participants that we have chosen it
because it is not invasive.
> Now, what is bothering me the more is different :
> - how to ease the Studio team work when dealing with the conf
> - how to stabilize the configuration to avoid rewritting the doco every
> month
> - and more important : how to help users dealing with configuration !
>
> I think that point #3 goes well with point #1. When you are a beginner,
> a good GUI helps.
I totally support your aims. All three of them.
Greetings,
Stefan
Re: Why I think Spring + xbean is wrong ...
Posted by Emmanuel Lecharny <el...@gmail.com>.
Stefan Zoerner wrote:
> Emmanuel Lecharny wrote:
>> Do we need a container technology ? The 0.8 version was working
>> without this IoC crap. IoC is, IMHO, hyper over hyped... But this is
>> another debate !
>
> I think a container should not be necessary, if ApacheDS is embedded.
> In this case, every additional dependency will add burden to those who
> plan to integrate it in their applications.
>
> I thought this was basically the idea of using the Spring Framework.
Back three years ago, when Spring was injected into ADS, I think this
was just because it was "SO COOL !!!"
Ok, I know I'm a little bit old fashionned, but this saved my life more
than once :) When you think we had AOP into the server ... ;)
Now, what is bothering me the more is different :
- how to ease the Studio team work when dealing with the conf
- how to stabilize the configuration to avoid rewritting the doco every
month
- and more important : how to help users dealing with configuration !
I think that point #3 goes well with point #1. When you are a beginner,
a good GUI helps.
Thanks Stefan !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Why I think Spring + xbean is wrong ...
Posted by Stefan Zoerner <st...@labeo.de>.
Emmanuel Lecharny wrote:
> Do we need a container technology ? The 0.8 version was working without
> this IoC crap. IoC is, IMHO, hyper over hyped... But this is another
> debate !
I think a container should not be necessary, if ApacheDS is embedded. In
this case, every additional dependency will add burden to those who plan
to integrate it in their applications.
I thought this was basically the idea of using the Spring Framework.
Greetings,
Stefan
Re: Why I think Spring + xbean is wrong ...
Posted by Emmanuel Lecharny <el...@gmail.com>.
Alex Karasulu wrote:
> <snip/>
> For now I'm pooped and will accept what we have.
So do I. I don't want to 'do it again'... No time for that.
> It works well and the configuration is a lot better than it was with
> just pure Spring. We can work with it until we find a better way.
Sure. I just wanted to point the fact that we have some problem with the
current usage of Spring + xbeans, and that we need to seriously think
twice the next time we choose to change our configuration system.
> In the end, even if we put configuration into the DIT something is
> going to have to do what Spring does: instantiate the objects and wire
> them up.
What about :
DirectoryServer ds = new DirectoryServer(); ?
Instanciating object though constructors is pretty efficient in Java ;)
> Question is how do we do that in a simple and easy to manage way
> that's as straight forward as possible while allowing us to use our
> favorite container technology?
Do we need a container technology ? The 0.8 version was working without
this IoC crap. IoC is, IMHO, hyper over hyped... But this is another
debate !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Why I think Spring + xbean is wrong ...
Posted by Ole Ersoy <ol...@gmail.com>.
> Really? I wanted to work with you on this and saw you were using some
> basis mapping technique. I was wondering if this can be combined with
> annotations somehow to drive the mapping in ways the user needs that are
> outside of the basis mapping.
It definitely could. That's the next phase of the DAS. I have not found much time to work on it lately. To get the current version going I spent 3 months full time plugging away, so my budget is pretty much spent, until I get some other projects out of the way, but it does support taking any EMF graph and storing it in the DIT, hence it will support server.xml.
Acutally the mapping technique is fairly sophisticated braw. It examines the EMF object reflectively to figure out what the corresponding ObjectClass is, and if that object class does not exist, it creates it. Then it stores the Object in the DIT using that ObjectClass. So if this were relational, the DAS would first look at an Object to see whether the table exists. Then if it did not exist, it would create it, and then store the object as a row in the table that it just created.
It also accounts for inheritance, so if the EMF instance being stored inherits from a super type, then the DAS creates the corresponding ObjectClass that inherits from the parent ObjectClass.
So right now the DAS uses 0 configuration (Except for JNDI Connection parameters). It just figures out the schema automagically, creates it if it does not already exist, and goes from there.
>
>
> Just load the generated model with server.xml, pass it to
> DAS.save(model) (model is a reference to the Object that is the root
> element of server.xml), and it's instantly in the DIT. Restoring it
> from the DIT is the same. DAS.load("DN of root server.xml
> element"); So there's all sorts of benefits like that end up being
> enabled, through use of EMF.
>
>
> Wow. Sounds easy. OK I need to find some time to pick your brain.
Pick away - You'll see there's not much up there :-). Things come to me in flashes and then their gone baby gone. Seriously, I'll be happy to answer questions, it might just take me a little time to refresh. I need to write the guide for the current release anyways, so that will be a good opportunity to get a push going.
>
> One question that probably should come up during the JPOX
> collaboration is whether it can support a similar capability.
>
>
> Right. My fear is that we're going to try to bend the LDAP access model
> to try to make it fit into the relational model and that would be a
> mistake that will limit capabilities.
The one difference that helps LDAP DAS in this case is that EMF EObject's live in an XML namespace. I therefore used this concept to create ObjectClasses that match specific java classes.
What JPOX could do, I think, is use the package namespace for the classes to generate ObjectClasses that match each JPOX class, per object in a given graph. Then just follow the same algorithm that the LDAP DAS uses to read and write graphs. Then the only difference would be that the LDAP DAS uses an XML Namesapce to create unique ObjectClasses (Corresponding to Java Classes) and the JPOX implementation uses java package namespaces instead. (SDO has a ChangeSummary that is used for updates and deletes, so we'd have to fingure out how JPOX wants to handle that.)
This would guarantee a one to one mapping between java classes and ObjectClasses. I think the JPOX guys are pretty sharp though. I'm sure they already have this stuff figured out.
One thing that has to be provided for queries like "SELCT BLAH FROM HOOOHAHHH" is that they have to be translated into JNDI Speak. In order to do this, additional context has to be provided such that the translator understands what entry(s) HOOOOHAHHH corresponds to. To be more specific, it's "What namespace does HOOOHAHHH live in?".
Anyways - Just my 2 cents. Hope it helps. I would like to do a JPA facade on the LDAP DAS later, and then I'll have a more concrete blue print of the concepts outlined above.
Cheers,
- Ole
Re: Why I think Spring + xbean is wrong ...
Posted by Alex Karasulu <ak...@apache.org>.
On Sat, Mar 8, 2008 at 1:59 PM, Ole Ersoy <ol...@gmail.com> wrote:
> Alex Karasulu wrote:
> > Oh Ole I'm trying to get this EMF stuff but I'm just not groking it -
> > still need to back up and read these long emails. Thanks for not giving
> > up on us - I know the EMF concepts you talk about are valuable
> > especially when we really trick studio out the way I dream of.
>
> Thanks for not blocking me as Spam on the mail list :-). I know when you
> are doing a big bang, and this Ole guy starts proposing a big bang on top of
> the big bang, it can be a little over the top.
No worries I appreciate your comments. I just wish I had the attention
span these days to follow up and research them.
> One thing I can do to make it simpler is just create a simple little hello
> world for it, that will demo the key capabilities that I think will be most
> valuable for the directory project. Starting with the simplest XML Schema
> possible, so that it's much easier to see what's going on and relate the
> inputs to the outputs.
Yeah that would help a lot thanks.
The XBean Schema generated something like 40 implementation classes (Impl
> posftixed classes), plus corresponding interfaces. Even though these are
> the configuration beans, it's still pretty intensive to think about how the
> graph of all of those are constructed from loading server.xml, in addition
> to general EMF design concepts, which is all pattern based.
>
> But before we invest time in general, we need to make sure we agree on an
> understanding of the process in which EMF would be used, the the general
> requirements it imposes on server components, such that everyone has a
> chance to see whether they would enjoy that type of development style.
>
That would be nice before rushing into it.
>
> One thing you mentioned was storing the configuration in the DIT. With
> the LDAP DAS that would be instant.
Really? I wanted to work with you on this and saw you were using some basis
mapping technique. I was wondering if this can be combined with annotations
somehow to drive the mapping in ways the user needs that are outside of the
basis mapping.
> Just load the generated model with server.xml, pass it to DAS.save(model)
> (model is a reference to the Object that is the root element of server.xml),
> and it's instantly in the DIT. Restoring it from the DIT is the same.
> DAS.load("DN of root server.xml element"); So there's all sorts of
> benefits like that end up being enabled, through use of EMF.
>
Wow. Sounds easy. OK I need to find some time to pick your brain.
>
> One question that probably should come up during the JPOX collaboration is
> whether it can support a similar capability.
>
Right. My fear is that we're going to try to bend the LDAP access model to
try to make it fit into the relational model and that would be a mistake
that will limit capabilities.
>
> So once the dust settle a little, I'll be glad to help further our
> understanding of ways EMF could be leveraged.
>
Thanks!
>
> Have a terrific weekend,
You too.
Alex
Re: Why I think Spring + xbean is wrong ...
Posted by Ole Ersoy <ol...@gmail.com>.
> hmmm.... I'm getting the feeling EMF and jaxb have similar goals....
Yeah I think it's a pretty even match up. This article is great for comparison:
http://www.theserverside.com/tt/articles/article.tss?l=BindingXMLJava
> jaxb only generates POJOs, not interface/impl split. This may make one
> or the other easier to deal with, I don't know which yet.
The reason EMF does this is to make it easy to follow the "Separate the Interface From Implementation" design pattern. EMF uses this pattern in the .edit and .editor plugins that it generates also. It may be worth while to take into consideration whether this pattern means anything in the context of server development. If it becomes desirable to generate the .edit and .editor plugins for Studio, then it becomes meaningful by default.
Cheers,
- Ole
Re: Why I think Spring + xbean is wrong ...
Posted by David Jencks <da...@yahoo.com>.
On Mar 8, 2008, at 10:59 AM, Ole Ersoy wrote:
> Alex Karasulu wrote:
>> Oh Ole I'm trying to get this EMF stuff but I'm just not groking
>> it - still need to back up and read these long emails. Thanks for
>> not giving up on us - I know the EMF concepts you talk about are
>> valuable especially when we really trick studio out the way I
>> dream of.
>
> Thanks for not blocking me as Spam on the mail list :-). I know
> when you are doing a big bang, and this Ole guy starts proposing a
> big bang on top of the big bang, it can be a little over the top.
> One thing I can do to make it simpler is just create a simple
> little hello world for it, that will demo the key capabilities that
> I think will be most valuable for the directory project. Starting
> with the simplest XML Schema possible, so that it's much easier to
> see what's going on and relate the inputs to the outputs. The
> XBean Schema generated something like 40 implementation classes
> (Impl posftixed classes), plus corresponding interfaces. Even
> though these are the configuration beans, it's still pretty
> intensive to think about how the graph of all of those are
> constructed from loading server.xml, in addition to general EMF
> design concepts, which is all pattern based.
hmmm.... I'm getting the feeling EMF and jaxb have similar goals....
jaxb only generates POJOs, not interface/impl split. This may make
one or the other easier to deal with, I don't know which yet.
I may try to put together a jaxb demo also
thanks
david jencks
>
> But before we invest time in general, we need to make sure we agree
> on an understanding of the process in which EMF would be used, the
> the general requirements it imposes on server components, such that
> everyone has a chance to see whether they would enjoy that type of
> development style.
>
> One thing you mentioned was storing the configuration in the DIT.
> With the LDAP DAS that would be instant. Just load the generated
> model with server.xml, pass it to DAS.save(model) (model is a
> reference to the Object that is the root element of server.xml),
> and it's instantly in the DIT. Restoring it from the DIT is the
> same. DAS.load("DN of root server.xml element"); So there's all
> sorts of benefits like that end up being enabled, through use of EMF.
>
> One question that probably should come up during the JPOX
> collaboration is whether it can support a similar capability.
>
> So once the dust settle a little, I'll be glad to help further our
> understanding of ways EMF could be leveraged.
>
> Have a terrific weekend,
> - Ole
Re: Why I think Spring + xbean is wrong ...
Posted by Ole Ersoy <ol...@gmail.com>.
Alex Karasulu wrote:
> Oh Ole I'm trying to get this EMF stuff but I'm just not groking it -
> still need to back up and read these long emails. Thanks for not giving
> up on us - I know the EMF concepts you talk about are valuable
> especially when we really trick studio out the way I dream of.
Thanks for not blocking me as Spam on the mail list :-). I know when you are doing a big bang, and this Ole guy starts proposing a big bang on top of the big bang, it can be a little over the top.
One thing I can do to make it simpler is just create a simple little hello world for it, that will demo the key capabilities that I think will be most valuable for the directory project. Starting with the simplest XML Schema possible, so that it's much easier to see what's going on and relate the inputs to the outputs. The XBean Schema generated something like 40 implementation classes (Impl posftixed classes), plus corresponding interfaces. Even though these are the configuration beans, it's still pretty intensive to think about how the graph of all of those are constructed from loading server.xml, in addition to general EMF design concepts, which is all pattern based.
But before we invest time in general, we need to make sure we agree on an understanding of the process in which EMF would be used, the the general requirements it imposes on server components, such that everyone has a chance to see whether they would enjoy that type of development style.
One thing you mentioned was storing the configuration in the DIT. With the LDAP DAS that would be instant. Just load the generated model with server.xml, pass it to DAS.save(model) (model is a reference to the Object that is the root element of server.xml), and it's instantly in the DIT. Restoring it from the DIT is the same. DAS.load("DN of root server.xml element"); So there's all sorts of benefits like that end up being enabled, through use of EMF.
One question that probably should come up during the JPOX collaboration is whether it can support a similar capability.
So once the dust settle a little, I'll be glad to help further our understanding of ways EMF could be leveraged.
Have a terrific weekend,
- Ole
Re: Why I think Spring + xbean is wrong ...
Posted by Alex Karasulu <ak...@apache.org>.
On Fri, Mar 7, 2008 at 8:51 PM, Emmanuel Lecharny <el...@gmail.com>
wrote:
> 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...
>
Ok now I'm confused. I thought XBean was built on top of Spring to utilize
it's custom namespace capabilities to make for terse, concise XML
configuration files.
Before, we had those big nasty Spring configuration files which explicitly
defined every bean without the custom tags.
I think phase I explicitly stated that one of our main efforts was to remove
(#2) the configuration beans that existed and wire the components directly
(#1). This did clean up a lot of crap but it introduced different problems
to deal with. I also thing the configuration beans we had were shabby so a
lot of the cleanup was because the config beans we used did not match well.
It could be done either way.
For now I'm pooped and will accept what we have. It works well and the
configuration is a lot better than it was with just pure Spring. We can
work with it until we find a better way. In the end, even if we put
configuration into the DIT something is going to have to do what Spring
does: instantiate the objects and wire them up. Question is how do we do
that in a simple and easy to manage way that's as straight forward as
possible while allowing us to use our favorite container technology?
Oh Ole I'm trying to get this EMF stuff but I'm just not groking it - still
need to back up and read these long emails. Thanks for not giving up on us
- I know the EMF concepts you talk about are valuable especially when we
really trick studio out the way I dream of.
Alex
Alex
Re: Why I think Spring + xbean is wrong ...
Posted by Emmanuel Lecharny <el...@gmail.com>.
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
Re: Why I think Spring + xbean is wrong ...
Posted by Ole Ersoy <ol...@gmail.com>.
> You should look at jaxb :-) The guys who are working on the eclipse
> plugin for editing geronimo plans are abandoning EMF in favor of jaxb.
> The simplest use of jaxb is to generate java objects from a schema, but
> then you can change these generated java objects quite a lot and still
> have the automatic 2 way mapping between xml and pojos still work.
> DOM4j is more like using a SAX parser :-)
Cool - I think we're starting to speak the same language now :-). One thing that would be really nice is to be able to avoid is the EMF dependency. Even with a public Maven repository, it's still of a concern to a lot of developers. For example when publishing the Directory for download, there would probably have to be some sort of notice saying it uses EMF, which is EML licensed. The other core consideration for Directory is whether it wants to generate .edit and .editor plugins for Studio. Something that should be examined, in light of everything else. Another broader consideration is that the ecosystem that EMF is a part of as immense momentum, and the number of tools / frameworks growing up around it is constantly gathering momentum. The only way to do that though is to layout a road map for Studio in terms of key capabilities that should be added over the coming years, and then match that up with what the EMF project, and corresponding Eco system offers. The amou
nt of code generation used in developing Studio should also be considered.
Thanks,
- Ole
Re: Why I think Spring + xbean is wrong ...
Posted by David Jencks <da...@yahoo.com>.
On Mar 7, 2008, at 5:28 PM, Ole Ersoy wrote:
> Just some comments on the EMF part inline:
>
>> 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 haven't grasped the EMF approach well enough to see
>> exactly where it fits into this spectrum of choices.
>
> Man - after having read this I thought "Cool - He totally gets the
> EMF approach". It's very similar, if not exactly what you just
> said. I'll just do a few lines summarizing the tutorial trace I
> sent out:
>
> - Grab the xbean xsd schema.
> - Generate the model classes (Interfaces and Implementations) from it.
> - Load server.xml binding the instances of the configuration
> classes to server.xml elements
>
> This is probably the same thing we would be doing with JAXB, except
> maybe for the implementation of the Data Object Model. With EMF we
> generated classes that match the complex types defined in the xbean
> schema. When EMF loads server.xml it creates instances of these
> classes using a generated factory. We then get instances of these
> classes from the resource used to load them and use these instances
> per their generated interfaces. So for example:
>
> AuthenticatorType authenticatorType = resource.getObject("server/
> authenticatorType");
>
> Now you can access the properties of the authenticatorType per the
> interface that was generated for it (Just getters and setters for
> the properties on the AuthenticatorType).
>
> Just a little more elaboration....AuthenticatorType is a
> ComplexType definition in the xbean schema. EMF generated the
> corresponding class implementation and interface for it,
> AuthenticatorType (Interface) and AuthenticatorTypeImpl
> (implementation).
>
> So when EMF is reading server.xml, it says "Ahh - there's an
> element in here that corresponds to AuthenticatorType. Lets create
> an instance of AuthenticatorType and bind it to the corresponding
> server.xml element, resulting in the data in that element being
> made available on the AuthenticatorType instance", and then it
> continues building the graph that way.
>
> So the difference between EMF and say just loading server.xml using
> DOM4J is that we get to retrieve instances of objects that have a
> defined type. If we were to load it using DOM4J, we would have to
> navigate the configuration model more "reflectively", using the
> DOM4J API. I think JAXB and DOM4J are similar, but I used DOM4J
> since I'm more familiar with it.
You should look at jaxb :-) The guys who are working on the eclipse
plugin for editing geronimo plans are abandoning EMF in favor of
jaxb. The simplest use of jaxb is to generate java objects from a
schema, but then you can change these generated java objects quite a
lot and still have the automatic 2 way mapping between xml and pojos
still work. DOM4j is more like using a SAX parser :-)
thanks
david jencks
>
> Hope that helps.
>
> Cheers,
> - Ole
>
>
>
>
>
>
Re: Why I think Spring + xbean is wrong ...
Posted by Ole Ersoy <ol...@gmail.com>.
Just some comments on the EMF part inline:
> 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 haven't grasped the EMF
> approach well enough to see exactly where it fits into this spectrum of
> choices.
Man - after having read this I thought "Cool - He totally gets the EMF approach". It's very similar, if not exactly what you just said. I'll just do a few lines summarizing the tutorial trace I sent out:
- Grab the xbean xsd schema.
- Generate the model classes (Interfaces and Implementations) from it.
- Load server.xml binding the instances of the configuration classes to server.xml elements
This is probably the same thing we would be doing with JAXB, except maybe for the implementation of the Data Object Model. With EMF we generated classes that match the complex types defined in the xbean schema. When EMF loads server.xml it creates instances of these classes using a generated factory. We then get instances of these classes from the resource used to load them and use these instances per their generated interfaces. So for example:
AuthenticatorType authenticatorType = resource.getObject("server/authenticatorType");
Now you can access the properties of the authenticatorType per the interface that was generated for it (Just getters and setters for the properties on the AuthenticatorType).
Just a little more elaboration....AuthenticatorType is a ComplexType definition in the xbean schema. EMF generated the corresponding class implementation and interface for it, AuthenticatorType (Interface) and AuthenticatorTypeImpl (implementation).
So when EMF is reading server.xml, it says "Ahh - there's an element in here that corresponds to AuthenticatorType. Lets create an instance of AuthenticatorType and bind it to the corresponding server.xml element, resulting in the data in that element being made available on the AuthenticatorType instance", and then it continues building the graph that way.
So the difference between EMF and say just loading server.xml using DOM4J is that we get to retrieve instances of objects that have a defined type. If we were to load it using DOM4J, we would have to navigate the configuration model more "reflectively", using the DOM4J API. I think JAXB and DOM4J are similar, but I used DOM4J since I'm more familiar with it.
Hope that helps.
Cheers,
- Ole
Re: Why I think Spring + xbean is wrong ...
Posted by David Jencks <da...@yahoo.com>.
On Mar 7, 2008, at 2:27 AM, Emmanuel Lecharny wrote:
> Stefan Zoerner wrote:
>> Emmanuel Lecharny wrote:
>>> ...
>>> I do think that we went far too far.
>>>
>>> wdyt ?
>>
>> Let me first say that I really liked the idea of making
>> configuration of ApacheDS simpler form a user (e.g. administrator)
>> perspective. The xbean approach did a good job here, the files are
>> shorter and more expressive.
> I will temper my initial mail : xbean has some advantage : it
> generates a XSD. But the indirection is still a PITA...
>> Unfortunately, some ports of the configuration are comparable
>> complicated to the 1.0 pure Spring world (or even more complex).
>>
>> For instance:
>> ...
>> <!-- The desired quality-of-protection, used by DIGEST-MD5 and
>> GSSAPI. -->
>> <saslQop>
>> <value xmlns="http://www.springframework.org/schema/
>> beans">auth</value>
>> <value xmlns="http://www.springframework.org/schema/
>> beans">auth-int</value>
>> <value xmlns="http://www.springframework.org/schema/
>> beans">auth-conf</value>
>> </saslQop>
>> ...
> It can be replaced by :
>
> <spring:beans xmlns:spring="http://xbean.apache.org/schemas/spring/
> 1.0"
> xmlns:s="http://www.springframework.org/schema/
> beans" <!-- Added NameSpace declaration -->
> xmlns="http://apacheds.org/config/1.0">
> ...
> <saslQop>
> <s:value>auth</s:value>
> <s:value>auth-int</s:value>
> <s:value>auth-conf</s:value>
> </saslQop>
>
> Much simpler ...
very true :-) why didn't I do that ??
I think I was hoping to figure out a solution all in the apacheds
namespace and never got back to looking for it.
>
>> The question I asked myself when xbean was introduced: Isn't it
>> possible to use our own namespace and use pure Spring 2.0
>> functionality for that to make configuration easier? This has been
>> done with transactions, AOP etc. in Spring itself.
>>
>> Perhaps we can obtain a comparable result with native Spring
>> features, and avoid the dependency to xbean.
>>
>> http://static.springframework.org/spring/docs/2.0.x/reference/
>> extensible-xml.html
> May be... This has to be explored.
Definitely worth looking into. I haven't :-) I've heard rumors that
it is not as capable as xbean-spring but being built-in is pretty nice.
>>
>> Whether this will conflict with Emmanuel's requirement to make
>> configuration easier to parse/edit with Studio -- I have not
>> thought about that yet.
> 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. How is this different
from having a configuration data object separate from the component?
>
> 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 haven't grasped the EMF approach well enough to see exactly where
it fits into this spectrum of choices.
>
> 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.
thanks
david jencks
>
> Thanks Stefan !
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
Re: Why I think Spring + xbean is wrong ...
Posted by Emmanuel Lecharny <el...@gmail.com>.
Stefan Zoerner wrote:
> Emmanuel Lecharny wrote:
>> ...
>> I do think that we went far too far.
>>
>> wdyt ?
>
> Let me first say that I really liked the idea of making configuration
> of ApacheDS simpler form a user (e.g. administrator) perspective. The
> xbean approach did a good job here, the files are shorter and more
> expressive.
I will temper my initial mail : xbean has some advantage : it generates
a XSD. But the indirection is still a PITA...
> Unfortunately, some ports of the configuration are comparable
> complicated to the 1.0 pure Spring world (or even more complex).
>
> For instance:
> ...
> <!-- The desired quality-of-protection, used by DIGEST-MD5 and
> GSSAPI. -->
> <saslQop>
> <value
> xmlns="http://www.springframework.org/schema/beans">auth</value>
> <value
> xmlns="http://www.springframework.org/schema/beans">auth-int</value>
> <value
> xmlns="http://www.springframework.org/schema/beans">auth-conf</value>
> </saslQop>
> ...
It can be replaced by :
<spring:beans xmlns:spring="http://xbean.apache.org/schemas/spring/1.0"
xmlns:s="http://www.springframework.org/schema/beans"
<!-- Added NameSpace declaration -->
xmlns="http://apacheds.org/config/1.0">
...
<saslQop>
<s:value>auth</s:value>
<s:value>auth-int</s:value>
<s:value>auth-conf</s:value>
</saslQop>
Much simpler ...
> The question I asked myself when xbean was introduced: Isn't it
> possible to use our own namespace and use pure Spring 2.0
> functionality for that to make configuration easier? This has been
> done with transactions, AOP etc. in Spring itself.
>
> Perhaps we can obtain a comparable result with native Spring features,
> and avoid the dependency to xbean.
>
> http://static.springframework.org/spring/docs/2.0.x/reference/extensible-xml.html
>
May be... This has to be explored.
>
> Whether this will conflict with Emmanuel's requirement to make
> configuration easier to parse/edit with Studio -- I have not thought
> about that yet.
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 ...).
Another point is that we have mixed configuration laoding and
initialization, which is, from my POV, a bad mistake.
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...
Thanks Stefan !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Why I think Spring + xbean is wrong ...
Posted by Stefan Zoerner <st...@labeo.de>.
Emmanuel Lecharny wrote:
> ...
>
> I do think that we went far too far.
>
> wdyt ?
Let me first say that I really liked the idea of making configuration of
ApacheDS simpler form a user (e.g. administrator) perspective. The xbean
approach did a good job here, the files are shorter and more expressive.
Unfortunately, some ports of the configuration are comparable
complicated to the 1.0 pure Spring world (or even more complex).
For instance:
...
<!-- The desired quality-of-protection, used by DIGEST-MD5 and
GSSAPI. -->
<saslQop>
<value
xmlns="http://www.springframework.org/schema/beans">auth</value>
<value
xmlns="http://www.springframework.org/schema/beans">auth-int</value>
<value
xmlns="http://www.springframework.org/schema/beans">auth-conf</value>
</saslQop>
...
Although it is probably easy to complete the xbean configuration and
reduce such parts. This should happen at least, because we easily loose
the simplification we achieved.
The question I asked myself when xbean was introduced: Isn't it possible
to use our own namespace and use pure Spring 2.0 functionality for
that to make configuration easier? This has been done with transactions,
AOP etc. in Spring itself.
Perhaps we can obtain a comparable result with native Spring features,
and avoid the dependency to xbean.
http://static.springframework.org/spring/docs/2.0.x/reference/extensible-xml.html
Whether this will conflict with Emmanuel's requirement to make
configuration easier to parse/edit with Studio -- I have not thought
about that yet.
Greetings from Hamburg,
Stefan