Re: [Exist-development] scheduler revision

[Adam R. <ad...@ex...>]

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 <sha...@gm...> wrote:
> On Sun, Jul 3, 2011 at 9:28 PM, Adam Retter <ad...@ex...> 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 }
ad...@ex...
irc://irc.freenode.net/existdb