Re: [Exist-development] scheduler revision

[Dmitriy S. <sha...@gm...>]

On Mon, Jul 4, 2011 at 2:50 PM, Adam Retter <ad...@ex...> 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