I have an older laptop so default for me boots at 29secs. I am sure we can do better,
still
this is quite an improvement so kudos to everyone!
Bill Burke wrote:
i am seeing the same. What I saw pre-merge was that the deployer
sorting brought boot time from 30-33 to 26-28. With the changes I'm
seing 23-24. 10-20% improvement is about where I thought we'd be with
AOP changes.
Great job Ales, Kabir and company!
Jaikiran Pai wrote:
> With the recent upgrade of MC in AS trunk, the "default" config on my
> system now boots in around 23 seconds consistently. Before the upgrade
> it used to take somewhere around 30 to 33 seconds.
>
> -Jaikiran
>
> Kabir Khan wrote:
>> I forgot to mention the changes that I did for JBKERNEL-75, i.e. lifecycle:
http://community.jboss.org/message/518409#518409
>>
>> The gist of it is that <lifecycle-configure/> & friends no longer can
take an 'expr' attribute (containing a pointcut) and that the 'classes'
attribute now must take an annotation.
>>
>> On 5 Jan 2010, at 18:08, Kabir Khan wrote:
>>
>>> The work for this has been committed against
https://jira.jboss.org/jira/browse/JBKERNEL-75 and
https://jira.jboss.org/jira/browse/JBKERNEL-74. I have a few things I need to do before
the end of the week, if I have any time I'll try to see what impact this has on AS
boot time.
>>> On 4 Jan 2010, at 17:28, Kabir Khan wrote:
>>>
>>>> I tried starting AS with the updated jboss-aop-mc-int.jar, but ran into
problems with dependencies. I'll work on the @JMX stuff next, and try to see if I can
update all the dependencies locally in AS once I'm done with that if I have some time
before our release
>>>>
>>>> On 4 Jan 2010, at 15:43, Kabir Khan wrote:
>>>>
>>>>> I think I've got the bypassing proxy stuff working now both with
and without weaving. I'm re-running some tests before committing. A summary of what I
have done;
>>>>>
>>>>> -AOP proxy creation/checks is disabled by default
>>>>> -@EnableAopProxy on a bean forces it to go through the proxy checks
>>>>> -@DisableAOP is deprecated, but will stil be checked if it is present
and the new annotations are not present
>>>>>
>>>>> A few points:
>>>>> -if a bean is not woven but has constructor aspects you want invoked,
the bean needs the @EnableAopProxy annotation
>>>>> -If a bean's class is woven it can have aspects, so we will
always check the AOP dependencies for that bean. This will only happen if loadtime weaving
was turned on (or compile-time weaving was used) AND the bean matches some pointcuts, so
it should not be an issue in practice.
>>>>>
>>>>> Once I've tidied up I'll commit to MC trunk, and try putting
it into AS trunk before moving on to replacing the mechanism for AOP lifecycle.
>>>>>
>>>>> On 24 Dec 2009, at 12:29, Kabir Khan wrote:
>>>>>
>>>>>> I've made a start on this, but doubt I'll finish it
before I finish for Christmas. I am deprecating the @DisableAOP annotation. By default aop
proxies will be disabled, but can be enabled with @EnableAopProxy. Lifecycle callbacks
will be enabled by default (and I'll come up with a quicker way of determining if they
should apply), but can be disabled using the @DisableAopLifecycle annotation.
>>>>>>
>>>>>> One issue that I need to look into is that there are a bunch of
tests that run with weaving enabled, so I need to see how they fare with this new setup.
Since if they are woven, aspects will apply, and if those aspects have dependencies we
need those in AOPDependencyBuilder.
>>>>>>
>>>>>>
>>>>>> On 24 Dec 2009, at 10:47, Ales Justin wrote:
>>>>>>
>>>>>>>> +1, disable AOP wherever possible.
>>>>>>> I guess we can go the other way now, disabled by default +
make
>>>>>>> lifecycle completely OO.
>>>>>>> We should then definitely see good improvement.
>>>>>>>
>>>>>>>> And I'd even dare say if you want @JMX, why not just
>>>>>>>> implement it the old fashion with MBean interfaces?
It's simple and fast :-)
>>>>>>> You got that right, it's simple, probably too simple.
;-)
>>>>>>> I think one would still like to use the real power of POJO
and IoC and
>>>>>>> just register it to MBeanServer for some simple
admin/config.
>>>>>>>
>>>>>>> I dare to say I think you need to re-read this article :-)
>>>>>>> *
http://java.dzone.com/articles/a-look-inside-jboss-microconta-0
>>>>>>> _______________________________________________
>>>>>>> jboss-development mailing list
>>>>>>> jboss-development(a)lists.jboss.org
>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>> _______________________________________________
>>>>>> jboss-development mailing list
>>>>>> jboss-development(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-development