Improvements (general and performances) : next steps

[Emmanuel Venisse-2]

Hi,

In next days, I'll work on some improvements.

Notification:
I started to refactor the notification part. I'm removing
plexus-notification and simplify APIs. In this refactoring, I remove the
context HashMap and use a "real" object (MessageContext) so it is more easy
to know what can be used from the context. This refactoring is a first step
for the notification part because I want in the future to allow a user to
develop a new notifier without to modify some Continuum code or existing
JSPs, a notifier will be a plugin but not in 1.2
I'll remove plexus-mail-sender too and will replace it by the Spring mail
component
I'll change the library used by the MSN notifier.

Performance:
During a build, we won't do DB access, it is a performance issue actually.
All will be done in memory and the result will be stored at the end.
I want to remove all HashMap context used actually in the build controller
and build actions,  they aren't developer friendly.
To reduce DB access and improve performance a lot, I'd like to use ehcache
for all major objects (all objects without build results and associated)

What do you think?
Emmanuel

[brettporter]

On 30/06/2008, at 11:42 PM, Emmanuel Venisse wrote:

> Hi,
>
> In next days, I'll work on some improvements.
>
> Notification:
> I started to refactor the notification part. I'm removing
> plexus-notification and simplify APIs. In this refactoring, I remove  
> the
> context HashMap and use a "real" object (MessageContext) so it is  
> more easy
> to know what can be used from the context. This refactoring is a  
> first step
> for the notification part because I want in the future to allow a  
> user to
> develop a new notifier without to modify some Continuum code or  
> existing
> JSPs, a notifier will be a plugin but not in 1.2
> I'll remove plexus-mail-sender too and will replace it by the Spring  
> mail
> component
> I'll change the library used by the MSN notifier.

Seems to make sense to me.

>
>
> Performance:
> During a build, we won't do DB access, it is a performance issue  
> actually.
> All will be done in memory and the result will be stored at the end.
> I want to remove all HashMap context used actually in the build  
> controller
> and build actions,  they aren't developer friendly.
> To reduce DB access and improve performance a lot, I'd like to use  
> ehcache
> for all major objects (all objects without build results and  
> associated)

Certainly what I want to see, but sounds like a big, scary,  
destabilising change :)

Can we continue with this step by step, or on a feature branch or for  
1.3 or something like that?

Cheers,
Brett

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/

[Emmanuel Venisse-2]

On Mon, Jun 30, 2008 at 4:02 PM, Brett Porter <brett@...> wrote:

>
> On 30/06/2008, at 11:42 PM, Emmanuel Venisse wrote:
>
>  Hi,
>>
>> In next days, I'll work on some improvements.
>>
>> Notification:
>> I started to refactor the notification part. I'm removing
>> plexus-notification and simplify APIs. In this refactoring, I remove the
>> context HashMap and use a "real" object (MessageContext) so it is more
>> easy
>> to know what can be used from the context. This refactoring is a first
>> step
>> for the notification part because I want in the future to allow a user to
>> develop a new notifier without to modify some Continuum code or existing
>> JSPs, a notifier will be a plugin but not in 1.2
>> I'll remove plexus-mail-sender too and will replace it by the Spring mail
>> component
>> I'll change the library used by the MSN notifier.
>>
>
> Seems to make sense to me.

spring mail and msn lib changes won't be in the global notification change.
We don't need a branch for notification changes.

>
>
>>
>> Performance:
>> During a build, we won't do DB access, it is a performance issue actually.
>> All will be done in memory and the result will be stored at the end.
>> I want to remove all HashMap context used actually in the build controller
>> and build actions,  they aren't developer friendly.
>> To reduce DB access and improve performance a lot, I'd like to use ehcache
>> for all major objects (all objects without build results and associated)
>>
>
> Certainly what I want to see, but sounds like a big, scary, destabilising
> change :)
>
> Can we continue with this step by step, or on a feature branch or for 1.3
> or something like that?

Sure, I won't work on it on trunk :) it will be first on a branch.
I don't know yet if all will be in 1.2 or not but it will be done step by
step, I don't want to break all ;)

Emmanuel

[olamy]

2008/6/30 Emmanuel Venisse <emmanuel.venisse@...>:
> Hi,
>
> In next days, I'll work on some improvements.
>
> Notification:
> I started to refactor the notification part. I'm removing
> plexus-notification and simplify APIs. In this refactoring, I remove the
> context HashMap and use a "real" object (MessageContext) so it is more easy

BuildContext with some methods like getProjectId ?

> to know what can be used from the context. This refactoring is a first step
> for the notification part because I want in the future to allow a user to
> develop a new notifier without to modify some Continuum code or existing
> JSPs, a notifier will be a plugin but not in 1.2

Cool  (olamy like the plugin idea ;-) )

> I'll remove plexus-mail-sender too and will replace it by the Spring mail
> component
> I'll change the library used by the MSN notifier.
>
> Performance:
> During a build, we won't do DB access, it is a performance issue actually.
> All will be done in memory and the result will be stored at the end.
> I want to remove all HashMap context used actually in the build controller
> and build actions,  they aren't developer friendly.
> To reduce DB access and improve performance a lot, I'd like to use ehcache
> for all major objects (all objects without build results and associated)

Sure (not ok getProjectId but getProject :-) )

>
> What do you think?

Sounds great !


> Emmanuel
>

Thanks,
--
Olivier

[Emmanuel Venisse-2]

On Mon, Jun 30, 2008 at 5:14 PM, Olivier Lamy <olamy@...> wrote:

> 2008/6/30 Emmanuel Venisse <emmanuel.venisse@...>:
> > Hi,
> >
> > In next days, I'll work on some improvements.
> >
> > Notification:
> > I started to refactor the notification part. I'm removing
> > plexus-notification and simplify APIs. In this refactoring, I remove the
> > context HashMap and use a "real" object (MessageContext) so it is more
> easy
>
> BuildContext with some methods like getProjectId ?

no, but getProject. If we use getProjectId, we'll need to get the project
from the DB ;)

>
>
> > to know what can be used from the context. This refactoring is a first
> step
> > for the notification part because I want in the future to allow a user to
> > develop a new notifier without to modify some Continuum code or existing
> > JSPs, a notifier will be a plugin but not in 1.2
>
> Cool  (olamy like the plugin idea ;-) )
>
> > I'll remove plexus-mail-sender too and will replace it by the Spring mail
> > component
> > I'll change the library used by the MSN notifier.
> >
> > Performance:
> > During a build, we won't do DB access, it is a performance issue
> actually.
> > All will be done in memory and the result will be stored at the end.
> > I want to remove all HashMap context used actually in the build
> controller
> > and build actions,  they aren't developer friendly.
> > To reduce DB access and improve performance a lot, I'd like to use
> ehcache
> > for all major objects (all objects without build results and associated)
>
> Sure (not ok getProjectId but getProject :-) )
>
> >
> > What do you think?
>
> Sounds great !
>
>
> > Emmanuel
> >
>
> Thanks,
> --
> Olivier
>