I fixed the tests (to have unique archive names inside ear).
Now all JBossWS tests pass against AS trunk, see 601 jobs at:
IOW MC upgrade is ok for JBossWS, no problems since now ;)
Richard
On 01/13/2010 03:45 PM, Brian Stansberry wrote:
If you have some spare cycles to try and analyze the cause of some
of
those failures, it would be very helpful. If you find anything, the "MC
2.2.x update" thread on this list is the best place to report them.
On 01/13/2010 08:30 AM, Richard Opalka wrote:
> Yes,
>
> it's nice it boots faster.
> However there are still some issues, e.g.
>
http://jbossws.jboss.org:8180/hudson/job/NATIVE-CORE-AS-6.0.1-SUN-JDK-6/28/
> that have to be addressed/identified :(
>
> Rio
>
> On 01/13/2010 03:10 PM, 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
>>
>>
>
>
--
Richard Opalka
ropalka(a)redhat.com
JBoss, by Red Hat
Office: +420 222 365 200
Mobile: +420 731 186 942