From: Dmitriy S. <sha...@gm...> - 2011-07-03 15:58:11
|
Hello, I do want to revisit scheduler to solve problems it have, same time I do want to move configurations to /db/system/scheduler/... and convert to new configuration framework. Any objections? -- Dmitriy Shabanov |
From: Adam R. <ad...@ex...> - 2011-07-03 16:28:32
|
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. On 3 July 2011 17:58, Dmitriy Shabanov <sha...@gm...> wrote: > Hello, > > I do want to revisit scheduler to solve problems it have, same time I do > want to move configurations to /db/system/scheduler/... and convert to new > configuration framework. > Any objections? > -- > Dmitriy Shabanov > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Dmitriy S. <sha...@gm...> - 2011-07-04 07:08:00
|
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 |
From: Wolfgang M. <wol...@ex...> - 2011-07-04 07:49:41
|
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 |
From: Adam R. <ad...@ex...> - 2011-07-04 09:50:29
|
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 |
From: Dmitriy S. <sha...@gm...> - 2011-07-04 14:21:37
|
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 |
From: Dmitriy S. <sha...@gm...> - 2011-07-05 04:38:15
|
On Mon, Jul 4, 2011 at 12:49 PM, Wolfgang Meier <wol...@ex...>wrote: > 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. > How long it can take? All I need so far is runtime schedule reconfiguration and add "tries" before unscheduling. -- Dmitriy Shabanov |
From: Adam R. <ad...@ex...> - 2011-07-06 09:17:45
|
On 5 July 2011 06:38, Dmitriy Shabanov <sha...@gm...> wrote: > > > On Mon, Jul 4, 2011 at 12:49 PM, Wolfgang Meier <wol...@ex...> > wrote: >> >> 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. > > How long it can take? > All I need so far is runtime schedule reconfiguration and add "tries" before > unscheduling. So for just the Scheduler changes, I presume without moving it to Configurator yet, do you foresee any breaking changes with regards backwards compatibility? > -- > Dmitriy Shabanov > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Dmitriy S. <sha...@gm...> - 2011-07-06 11:34:47
|
Nothing, all I want is runtime reconfiguration feature. On Wed, Jul 6, 2011 at 2:17 PM, Adam Retter <ad...@ex...> wrote: > So for just the Scheduler changes, I presume without moving it to > Configurator yet, do you foresee any breaking changes with regards > backwards compatibility? > -- Dmitriy Shabanov |