Planning to revert
by Brian Stansberry
When I get back from eating in an hour or so, I'm going to revert 2
recent changes:
1) The resteasy stuff that's breaking the build due to missing
resteasy-jettison-provider 2.0-beta-1. Unless it's fixed by then. :)
2) The jboss-cl upgrade to 2.2.0.Alpha1. I'll discuss with Ales, Adrian
and Thomas how to deal w/ getting the ClassCircularityErrors we're
seeing fixed.
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
15 years, 11 months
The mysterious case of the moving target . . .
by Andrew Dinn
"So, Watson, last week we tracked down our wsdl with the aid of an
Universal Resource Locator concocted, presumably by some black art of
that arch fiend Moriarty, from the ear, bean and implementation bean name:
http://localhost:8080/bademo-hotel/HotelImpl?wsdl
This week we return from our toils debugging the mysteries of the
missing AOP annotation handler only to find that our wsdl has been
filched from under our very noses and relocated to the following address
http://localhost:8080/hotel/Hotel?wsdl
Doubtless, an improvement in simplicitly, readability and clarity, my
good Doctor, but what pray does it lead one to conclude as to the logic
of the process?"
"Damn me, Holmes, I don't have a clue what is going on?"
"Precisely, my dear Watson! And neither will our users!"
regards,
Andrew Dinn
-----------
15 years, 11 months
WarAnnotationMetaDataDeployer and AOP failures
by Kabir Khan
Flavia and I are debugging the scoped AOP test failures in AS and have found something odd going on when deploying an ear with a war with classes. Basically WarAnnotationMetaDataDeployer loads all the classes in the war [1] before the AOPDeploymentAopMetaDataDeployer has the chance to add the bindings to the aspect manager [2]. This means that the classes in the war are loaded before the bindings are added, so they do not get woven. The deployers are in the same deployer stage POST_CLASSLOADER, what is the best way to change their orders around?
[1]
Daemon System Thread [RMI TCP Connection(6)-127.0.0.1] (Suspended (breakpoint at line 69 in SuperClassesFirstWeavingStrategy))
SuperClassesFirstWeavingStrategy.translate(AspectManager, String, ClassLoader, byte[]) line: 69
ScopedVFSClassLoaderDomain(AspectManager).translate(String, ClassLoader, byte[]) line: 1071
ScopedVFSClassLoaderDomain(AspectManager).transform(ClassLoader, String, Class, ProtectionDomain, byte[]) line: 1015
AOPTransformer.aspectTransform(String, ClassLoader, Class<?>, ProtectionDomain, byte[]) line: 87
AOPTransformer.transform(ClassLoader, String, Class<?>, ProtectionDomain, byte[]) line: 75
TransformerManager.transform(ClassLoader, String, Class, ProtectionDomain, byte[]) line: 169
InstrumentationImpl.transform(ClassLoader, String, Class, ProtectionDomain, byte[], boolean) line: 365
ClassLoader.defineClass1(String, byte[], int, int, ProtectionDomain, String) line: not available [native method]
BaseClassLoader(ClassLoader).defineClass(String, byte[], int, int, ProtectionDomain) line: 698
BaseClassLoader.access$200(BaseClassLoader, String, byte[], int, int, ProtectionDomain) line: 64
BaseClassLoader$2.run() line: 577
BaseClassLoader$2.run() line: 537
AccessController.doPrivileged(PrivilegedAction<T>, AccessControlContext) line: not available [native method]
BaseClassLoader.loadClassLocally(String, boolean) line: 535
BaseClassLoader.loadClassLocally(String) line: 512
FilteredDelegateLoader(BaseDelegateLoader).loadClass(String) line: 134
FilteredDelegateLoader.loadClass(String) line: 131
ClassLoadingTask$ThreadTask.run() line: 455
ClassLoaderManager.nextTask(Thread, ClassLoadingTask) line: 267
ClassLoaderManager.process(Thread, ClassLoadingTask) line: 166
ClassLoaderDomain(BaseClassLoaderDomain).loadClass(BaseClassLoader, String, boolean) line: 265
ClassLoaderDomain(BaseClassLoaderDomain).loadClass(BaseClassLoader, String) line: 1124
BaseClassLoader.loadClassFromDomain(String, boolean) line: 805
BaseClassLoader.loadClass(String, boolean) line: 445
BaseClassLoader(ClassLoader).loadClass(String) line: 250
AnnotatedClassFilter.accepts(VirtualFile) line: 121
AnnotatedClassFilter.visit(VirtualFile) line: 102
WrappingVirtualFileHandlerVisitor.visit(VirtualFileHandler) line: 62
FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 362
FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 374
FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 374
FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 374
FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 374
FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 374
FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor, boolean, boolean, boolean, boolean, VirtualFileFilter) line: 374
FileSystemContext(AbstractVFSContext).visit(VirtualFileHandler, VirtualFileHandlerVisitor) line: 307
VFS.visit(VirtualFile, VirtualFileVisitor) line: 438
VirtualFile.visit(VirtualFileVisitor) line: 448
WarAnnotationMetaDataDeployer.getClasses(VFSDeploymentUnit, VirtualFile) line: 172
WarAnnotationMetaDataDeployer.processMetaData(VFSDeploymentUnit, List<VirtualFile>) line: 146
WarAnnotationMetaDataDeployer.deploy(VFSDeploymentUnit) line: 125
WarAnnotationMetaDataDeployer.deploy(DeploymentUnit) line: 78
DeployerWrapper.deploy(DeploymentUnit) line: 179
DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1660
DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1378
DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1431
DeployersImpl.install(ControllerContext, ControllerState, ControllerState) line: 1319
DeploymentControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 378
AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1890
AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 1019
AbstractKernelController(AbstractController).executeOrIncrementStateDirectly(ControllerContext, boolean) line: 1251
AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1175
AbstractKernelController(AbstractController).resolveContexts(boolean) line: 1073
AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 887
AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 602
DeployersImpl.process(List<DeploymentContext>, List<DeploymentContext>) line: 898
MainDeployerImpl.process() line: 677
MainDeployer.deploy(URL) line: 370
MainDeployer.redeploy(URL) line: 277
[2]
Daemon System Thread [RMI TCP Connection(6)-127.0.0.1] (Suspended (breakpoint at line 146 in AspectBinding))
AspectBinding.start() line: 146
GeneratedMethodAccessor192.invoke(Object, Object[]) line: not available
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object...) line: 597
ReflectionUtils.invoke(Method, Object, Object[]) line: 59
ReflectMethodInfoImpl.invoke(Object, Object[]) line: 151
BasicMethodJoinPoint.dispatch() line: 66
KernelControllerContextAction$JoinpointDispatchWrapper.execute() line: 257
KernelControllerContextAction$JoinpointDispatchWrapper(ExecutionWrapper).execute(AccessControlContext) line: 47
KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContext, ExecutionWrapper) line: 125
KernelControllerContextAction.dispatchJoinPoint(KernelControllerContext, Joinpoint) line: 72
StartStopLifecycleAction(LifecycleAction).installActionInternal(KernelControllerContext) line: 202
StartStopLifecycleAction(InstallsAwareAction).installAction(KernelControllerContext) line: 54
StartStopLifecycleAction(InstallsAwareAction).installAction(ControllerContext) line: 42
StartStopLifecycleAction(SimpleControllerContextAction<T>).simpleInstallAction(T) line: 62
StartStopLifecycleAction(AccessControllerContextAction<S,T>).install(ControllerContext) line: 71
KernelControllerContextActions(AbstractControllerContextActions).install(ControllerContext, ControllerState, ControllerState) line: 51
AbstractKernelControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 378
ScopedKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1890
ScopedKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 1019
ScopedKernelController(AbstractController).executeOrIncrementStateDirectly(ControllerContext, boolean) line: 1251
ScopedKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1175
ScopedKernelController(AbstractController).resolveContexts(boolean) line: 1073
AbstractKernelController(AbstractController).resolveContexts(boolean) line: 1104
AbstractKernelController(AbstractController).install(ControllerContext, boolean) line: 842
AbstractKernelController(AbstractController).install(ControllerContext) line: 589
AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer.deploy(FakeComponentUnit, BeanMetaData) line: 363
AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer.access$100(AbstractAopMetaDataDeployer$MyBeanMetaDataDeployer, FakeComponentUnit, BeanMetaData) line: 329
AOPDeploymentAopMetaDataDeployer(AbstractAopMetaDataDeployer<T>).deployBeans(VFSDeploymentUnit, AopMetaDataDeployerOutput) line: 269
AOPDeploymentAopMetaDataDeployer(AbstractAopMetaDataDeployer<T>).deploy(VFSDeploymentUnit, T) line: 133
AOPDeploymentAopMetaDataDeployer.deploy(VFSDeploymentUnit, AOPDeployment) line: 46
AOPDeploymentAopMetaDataDeployer.deploy(VFSDeploymentUnit, Object) line: 36
AOPDeploymentAopMetaDataDeployer(AbstractSimpleVFSRealDeployer<T>).deploy(DeploymentUnit, T) line: 56
AOPDeploymentAopMetaDataDeployer(AbstractSimpleRealDeployer<T>).internalDeploy(DeploymentUnit) line: 62
AOPDeploymentAopMetaDataDeployer(AbstractRealDeployer).deploy(DeploymentUnit) line: 55
DeployerWrapper.deploy(DeploymentUnit) line: 179
DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1660
DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1378
DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1431
DeployersImpl.install(ControllerContext, ControllerState, ControllerState) line: 1319
DeploymentControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 378
AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1890
AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 1019
AbstractKernelController(AbstractController).executeOrIncrementStateDirectly(ControllerContext, boolean) line: 1251
AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1175
AbstractKernelController(AbstractController).resolveContexts(boolean) line: 1073
AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 887
AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 602
DeployersImpl.process(List<DeploymentContext>, List<DeploymentContext>) line: 898
MainDeployerImpl.process() line: 677
MainDeployer.deploy(URL) line: 370
MainDeployer.redeploy(URL) line: 277
15 years, 11 months
Artifact Mismatch in M2 Repositories
by Andrew Lee Rubinger
I've configured the java.net Maven2 repository in my settings.xml. As a
result, I've been unable to build AS due to:
Missing:
----------
1) org.glassfish.gmbal:gmbal-api-only:jar:3.0.0-b023
Path to dependency:
1) org.jboss.jbossas:jboss-as-distribution:pom:6.0.0-SNAPSHOT
2) com.sun.xml.ws:jaxws-rt:jar:2.2
3) org.glassfish.gmbal:gmbal-api-only:jar:3.0.0-b023
The underlying cause is that com.sun.xml.ws:jaxws-rt:jar:2.2 is not
equal across the JBoss and java.net repos:
http://download.java.net/maven/2/com/sun/xml/ws/jaxws-rt/2.2/jaxws-rt-2.2...
http://repository.jboss.org/maven2/com/sun/xml/ws/jaxws-rt/2.2/jaxws-rt-2...
This calls into question: what else is mismatched?
Paul notes that we'll have some scripts soon checking our stuff against
Maven Central and java.net.
Hoping to save other's time chasing this down. For now I'm wiping my
entire local repo, removing all but Maven Central and JBoss from my
settings.xml.
I don't know yet how I'll deal with projects which rely upon other
repositories. Baking repo information into a POM is bad practice (it
lives forever with the release), and I'll additionally need to forward
these into a separate local repository so things don't get mixed up.
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
http://exitcondition.alrubinger.com
http://twitter.com/ALRubinger
15 years, 11 months
Fwd: Instability in AS testsuite
by Ales Justin
Fwd-ing to ml, as it was meant for all, not just Brian. :-)
Sent from my iPod
Begin forwarded message:
> From: Ales Justin <ales.justin(a)gmail.com>
> Date: 29. januar 2010 0:07:16 GMT+0100
> To: Brian Stansberry <brian.stansberry(a)redhat.com>
> Subject: Re: Instability in AS testsuite
>
> Yes and no.
>
> The right fix is that this input is added as one of the multiple
> inputs - via addInput, not as *the* input - which is what this
> proprty setting does.
>
> You can use install element to invoke this addInput.
>
> Sent from my iPod
>
> On 29.1.2010, at 0:03, Brian Stansberry
> <brian.stansberry(a)redhat.com> wrote:
>
>> I've got what I think is the answer; am testing it now. We need to
>> add this to the xml for WebAnnotationMetaDataDeployer:
>>
>> <property name="allInputs">true</property>
>>
>> Otherwise the addition of <property
>> name=
>> "input"
>> >org.jboss.aop.asintegration.jboss5.AopMetaDataDeployerOutput</
>> property> causes this to return false in DeployersImpl.isRelevant():
>>
>> if (deployer.isAllInputs() == false)
>> {
>> // No attachment for the input type
>> Class<?> input = deployer.getInput();
>> if (input != null && unit.isAttachmentPresent(input) == false)
>> return false;
>> }
>>
>>
>>
>> On 01/28/2010 03:40 PM, Brian Stansberry wrote:
>>> Have a look at the AS trunk tomcat module's
>>> o.j.web.tomcat.service.TomcatInjectionContainer class. The
>>> TomcatInjectionContainer is instantiated as part of
>>> o.j.w.t.service.deployer.TomcatDeployment's performDeployInternal(),
>>> which itself is called as part of the start() phase of the mbean
>>> representing the web module (webapp deployment is still mbean-
>>> based).
>>>
>>> And, sorry to say, that about exhausts my knowledge on the
>>> subject. :(
>>>
>>> I'll be poking around at this for the rest of the day as well.
>>>
>>> On 01/28/2010 02:23 PM, Kabir Khan wrote:
>>>> Neither Flavia (I assume) nor I know anything about resource
>>>> injection, can somebody please explain a bit what is involved?
>>>> Does it
>>>> use AOP?
>>>>
>>>> On 28 Jan 2010, at 20:20, Ales Justin wrote:
>>>>
>>>>> Looks like @Resource injection doesn't kick in.
>>>>> (running org.jboss.test.jpa.test.WebLibsJPAUnitTestCase)
>>>>>
>>>>> @Resource
>>>>> private UserTransaction ut;
>>>>>
>>>>> protected void doGet(HttpServletRequest req, HttpServletResponse
>>>>> resp) throws ServletException, IOException
>>>>> {
>>>>> try
>>>>> {
>>>>> ut.begin(); //<----- ut == null
>>>>>
>>>>>
>>>>> 21:15:28,125 ERROR
>>>>> [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].
>>>>> [/jpa-test].[TestServlet]]
>>>>> Servlet.service() for servlet TestServlet threw exception:
>>>>> java.lang.NullPointerException
>>>>> at org.jboss.test.jpa.servlet.TestServlet.doGet(TestServlet.java:
>>>>> 59)
>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>>>>> at
>>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>>>>> (ApplicationFilterChain.java:336)
>>>>>
>>>>> at
>>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>>>>> (ApplicationFilterChain.java:242)
>>>>>
>>>>> at
>>>>> org.apache.catalina.core.StandardWrapperValve.invoke
>>>>> (StandardWrapperValve.java:276)
>>>>>
>>>>> at
>>>>> org.apache.catalina.core.StandardContextValve.invoke
>>>>> (StandardContextValve.java:191)
>>>>>
>>>>> at
>>>>> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke
>>>>> (SecurityAssociationValve.java:183)
>>>>>
>>>>> at
>>>>> org.jboss.web.tomcat.security.JaccContextValve.invoke
>>>>> (JaccContextValve.java:95)
>>>>>
>>>>>
>>>>> Flavia Rainone wrote:
>>>>>> Sure, I'll take a look.
>>>>>> On 01/28/2010 05:43 PM, Kabir Khan wrote:
>>>>>>> Copying Flavia,
>>>>>>>
>>>>>>> Flavia can you please take a look? I am tied up with another
>>>>>>> problem.
>>>>>>> If there is something affecting the web stuff, a wild guess
>>>>>>> would
>>>>>>> be the changing of the order of the deployers done here
>>>>>>> http://fisheye.jboss.org/changelog/JBossAS/?cs=100000
>>>>>>> However, without this fix AOP fails, since the
>>>>>>> WarAnnotationMetaDataDeployer loads all the classes as
>>>>>>> mentioned on
>>>>>>> dev list a day or two ago
>>>>>>>
>>>>>>> On 28 Jan 2010, at 19:29, Brian Stansberry wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Copying Ales and Scott Marlow, as an FYI. You all have been
>>>>>>>> chasing WebJPA failures, so thought you might be interested.
>>>>>>>> We've
>>>>>>>> already determined that the JBW upgrade did not cause the new
>>>>>>>> failures; it was something in the #1 or #2 changesets below.
>>>>>>>>
>>>>>>>> On 01/28/2010 12:22 PM, Brian Stansberry wrote:
>>>>>>>>
>>>>>>>>> Looks like we have some new failures in the AS testsuite:
>>>>>>>>>
>>>>>>>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Changes between this run and the last run to completion are
>>>>>>>>> listed in
>>>>>>>>> the links below. Myself, Kabir, Carlo and Remy made changes;
>>>>>>>>> please have
>>>>>>>>> a look and fix ASAP. (Carlo I'm quite sure yours didn't break
>>>>>>>>> anything
>>>>>>>>> :) ).
>>>>>>>>>
>>>>>>>>> The changes:
>>>>>>>>>
>>>>>>>>> 1)
>>>>>>>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Note that before the #528 testsuite run hung and was killed, a
>>>>>>>>> lot of
>>>>>>>>> the new failures had appeared there; you'd have to scroll
>>>>>>>>> through
>>>>>>>>> the
>>>>>>>>> #528 console log to see exactly which.
>>>>>>>>>
>>>>>>>>> 2)
>>>>>>>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 3)
>>>>>>>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 4)
>>>>>>>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This was the JBW update. I'll quickly check out trunk at this
>>>>>>>>> revision
>>>>>>>>> and run some of the newly failing tests to see if any of
>>>>>>>>> them go
>>>>>>>>> back
>>>>>>>>> this far.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Brian Stansberry
>>>>>>>> Lead, AS Clustering
>>>>>>>> JBoss by Red Hat
>>>>>>>>
>>>>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss by Red Hat
15 years, 11 months
