On Mon, Jul 4, 2011 at 2:50 PM, Adam Retter <adam@...> wrote:
> Sorry, I have just re-read my email and I realise how negative it
> sounded, apologies.
> I guess apart from yourself, I am the only person that has spent a lot
> of time working and adapting the current Configurator implementation
> and I do have some concerns about it.
>
> ** In General I am very happy with the concept of the new
> Configurator, I think it is a good thing that has been needed for some
> time. Kudos and thanks :-)
> ** I am happy to see that the Configurator works for the Security Manager
> stuff.
>
> However, I think the Configurator itself is rather fragile and that
> the annotations used can be simplified and improved. But rather that
> the general 'it needs improving', let me explain myself in more
> detail. To be fair you have asked me for comments in the past, but I
> have never quite found the time to write them down, so here they
> are...
>
>
> a) You should only have to Annotate a concrete class with
> @ConfigurationClass, you should not need to annotate all of its Super
> abstract classes with the same annotation, this is overkill and easily
>
this should be simple to fix, I can't remember why Configurator force to
have that annotation ... that is coded at line 114, remove this and you get
what want.... I get it back, it there because of optimization, it will scan
super class only till last @ConfigurationClass.
> missable. Personally I would like to see @ConfigurationClass become
> @AutoConfigure, but thats just naming and personal preference ;-)
> As a Developer who wants his class state managed by the Configurator,
> I want to just write (or re-use my existing) POJO's and thats that.
>
What do you mean by POJO?
>
> b) You should not have to Annotate methods or fields within the class.
> If the class is AutoConfigured then it is up to the Configurator to
> load and persist the state of the class, this means all fields. For
> the edge case you could have an @AutoConfigureIgnore for fields, if
> that state is transient, but I would argue that you should not have
> global transient state in your code, unless maybe you are writing an
> event processor such as SAX.
>
Annotation mapping configuration "element" (tag or attribute) by name. How
can you reach same without that core part?
> c) You should not have to implement any Interface e.g. Configurable.
> By virtue of the @AutoConfigure Annotations alone we can scan and
> locate the classes at db startup time to configure. These classes
> should be POJO's as far as the author is concerned and the injection
> of state should be transparent, just like IoC frameworks such as
> Guice, Spring etc.
>
vice versa ... just interface is simple (and faster) to use.
> d) You should not have to tell the Annotator when to persist your
> class, the Configurator can monitor this through AOP. Again, im
> talking clean POJO's. I should be able to take any class, and just add
> @AutoConfigure to the top and im done. Simple :-p
>
IMHO, it's very close to that, is it?
> e) At the moment you have to tell the Configurator about every new
> class that you want to persist, and this has to be hardcoded into the
> code. Lines 248 through 295 of Configurator.java. IMHO this is not
> maintainable or dynamic. I think we both realise this is a workaround
> for some of the current issues. This code needs to be replaced,
> preferably by a 3rd party lib (see my notes at the end) that can
> extract and persist data from any class. If the field is completely
> unknown or binary, there is no reason why we cant base64 encode this
> before storing it in the XML serialized form.
>
There is ConfigurationFieldClassMask annotation, this used by realm instance
creation and I just implement NewClass annotation: it mapping not
Configurable instance by mapping instructions. OAuth realm implementation
use this feature.
> Ideas - perhaps we could adapt the processor from JAXB or XMLBeans to
> actually do almost all of the above for us, they already know and have
> the code to take a hierarchy of any java objects and convert them into
> XML, and go from XML back to a tree of java objects. We could probably
> just replace their serializer with our own SAX serializer. Also in
>
I did spend some time with this libs, but the way was not clear for me ...
> this manner we would not need to use the memtree document impl, which
> could get quite large, and we could just stream the persisted document
> in/out of the database.
> I think this coupled with a small amount of AOP to scan for the
> Annotations and trigger the loading/persisting of state and we would
> have a much cleaner implementation with much less code, where you
> could just add @AutoConfigure to your POJO.
>
> Anyways, something to discuss I think...
>
I'm always ready for discuss, but never for 'not' :-)
>
--
Dmitriy Shabanov

Sorry, I have just re-read my email and I realise how negative it
sounded, apologies.
I guess apart from yourself, I am the only person that has spent a lot
of time working and adapting the current Configurator implementation
and I do have some concerns about it.
** In General I am very happy with the concept of the new
Configurator, I think it is a good thing that has been needed for some
time. Kudos and thanks :-)
** I am happy to see that the Configurator works for the Security Manager stuff.
However, I think the Configurator itself is rather fragile and that
the annotations used can be simplified and improved. But rather that
the general 'it needs improving', let me explain myself in more
detail. To be fair you have asked me for comments in the past, but I
have never quite found the time to write them down, so here they
are...
a) You should only have to Annotate a concrete class with
@ConfigurationClass, you should not need to annotate all of its Super
abstract classes with the same annotation, this is overkill and easily
missable. Personally I would like to see @ConfigurationClass become
@AutoConfigure, but thats just naming and personal preference ;-)
As a Developer who wants his class state managed by the Configurator,
I want to just write (or re-use my existing) POJO's and thats that.
b) You should not have to Annotate methods or fields within the class.
If the class is AutoConfigured then it is up to the Configurator to
load and persist the state of the class, this means all fields. For
the edge case you could have an @AutoConfigureIgnore for fields, if
that state is transient, but I would argue that you should not have
global transient state in your code, unless maybe you are writing an
event processor such as SAX.
c) You should not have to implement any Interface e.g. Configurable.
By virtue of the @AutoConfigure Annotations alone we can scan and
locate the classes at db startup time to configure. These classes
should be POJO's as far as the author is concerned and the injection
of state should be transparent, just like IoC frameworks such as
Guice, Spring etc.
d) You should not have to tell the Annotator when to persist your
class, the Configurator can monitor this through AOP. Again, im
talking clean POJO's. I should be able to take any class, and just add
@AutoConfigure to the top and im done. Simple :-p
e) At the moment you have to tell the Configurator about every new
class that you want to persist, and this has to be hardcoded into the
code. Lines 248 through 295 of Configurator.java. IMHO this is not
maintainable or dynamic. I think we both realise this is a workaround
for some of the current issues. This code needs to be replaced,
preferably by a 3rd party lib (see my notes at the end) that can
extract and persist data from any class. If the field is completely
unknown or binary, there is no reason why we cant base64 encode this
before storing it in the XML serialized form.
Ideas - perhaps we could adapt the processor from JAXB or XMLBeans to
actually do almost all of the above for us, they already know and have
the code to take a hierarchy of any java objects and convert them into
XML, and go from XML back to a tree of java objects. We could probably
just replace their serializer with our own SAX serializer. Also in
this manner we would not need to use the memtree document impl, which
could get quite large, and we could just stream the persisted document
in/out of the database.
I think this coupled with a small amount of AOP to scan for the
Annotations and trigger the loading/persisting of state and we would
have a much cleaner implementation with much less code, where you
could just add @AutoConfigure to your POJO.
Anyways, something to discuss I think...
On 4 July 2011 09:07, Dmitriy Shabanov <shabanovd@...> wrote:
> On Sun, Jul 3, 2011 at 9:28 PM, Adam Retter <adam@...> wrote:
>>
>> I am not against changes to the Scheduler, but what are the problems?
>>
>> I AM against converting anything to the new Configuration framework.
>> IMHO it is a good first proof of concept but there is lots about it
>> that needs revising, it feels like a mess at the moment.
>>
>
> Do you have any problem with configurator now? eXist itself looks like a
> mess, so what? should we stop coding it?
>
> --
> Dmitriy Shabanov
>
--
Adam Retter
eXist Developer
{ United Kingdom }
adam@...
irc://irc.freenode.net/existdb

Hi Dmitryi,
I know it's difficult, but the goal right now still is to get trunk
into a releasable state. After several months, we just managed to get
the major new features in trunk stable. Now it's time to wrap up. I
would rather not start yet another redesign effort which affects the
very core. Instead, we should test and work on those issues users will
have when upgrading from 1.4.x to trunk. For example, backups are not
compatible between 1.4.x and trunk.
There are also a lot of things on the surface which need to be fixed
and cleaned up (demo apps, app repository). We should concentrate on
those things first before moving on to new core redesigns.
Wolfgang

On Sun, Jul 3, 2011 at 9:28 PM, Adam Retter <adam@...> wrote:
> I am not against changes to the Scheduler, but what are the problems?
>
> I AM against converting anything to the new Configuration framework.
> IMHO it is a good first proof of concept but there is lots about it
> that needs revising, it feels like a mess at the moment.
>
>
Do you have any problem with configurator now? eXist itself looks like a
mess, so what? should we stop coding it?
--
Dmitriy Shabanov

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details