12:39 p.m.
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
2:53 p.m.
Eh, replied few secs too late. :-)
The answer is yes, but *if* you do it via xml config, as string, this
is then just additional "helper" string.
AOP usage is completely transparent.
Sent from my iPod
On 26.1.2010, at 21:39, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
6:06 p.m.
Thanks,
That works although I need to release AOP 2.1.7 before we can test that on Hudson. Or
shall I do an AOP 2.1.7-Beta in the morning and upgrade AS to use that? Flavia is looking
at the remaining 3 errors we get locally. She is investigating but I think the problem is
in the deployers. It seems to be the something to do with
<bean name="AOPXMLMetaDataParserDeployer"
class="org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer">
<constructor>
<parameter>org.jboss.aop.microcontainer.beans.metadata.AOPDeployment</parameter>
</constructor>
<property name="suffix">-aop.xml</property>
</bean>
not getting triggered for jboss-aop.xml if we have this structure
aop-scoped1.sar/
aop-scoped1.aop/
META-INF/
jboss-aop.xml
META-INF/
jboss-service.xml
I'm not 100% sure if this is the case, but just to check do we still support nested
deployments in sars?
jboss-aop.xml gets picked up with this structure:
aop-scoped2.sar/
jboss-aop.xml
META-INF/
jboss-service.xml
On 26 Jan 2010, at 20:53, Ales Justin wrote:
6:19 p.m.
We should still support a deployment like your aop-scoped1.sar example.
These tests were passing on Jan 10[1] so for sure we didn't decide to
change what we support since then. ;-)
[1]
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test...
On 01/26/2010 06:06 PM, Kabir Khan wrote:
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
5:10 a.m.
This is not happening at the moment, I only get one binding added for this test and that
is coming from AOP annotations on classes. I don't see SchemaResolverDeployer.parse()
getting invoked for the ones from the nested aop-scoped1.aop/META-INF/jboss-aop.xml, but I
see it working as expected for aop-scoped2/jboss-aop.xml.
On 27 Jan 2010, at 00:19, Brian Stansberry wrote:
8:18 a.m.
I think I found out why this is happening.
When AOPXMLMetaDataParserDeployer (SchemaResolverDeployer) is triggered
to process the .aop unit, there is already a metadata previously created
for the annotated binding. Take a look at the beginning of method
AbstractParsingDeployerWithOutput.createMetaData:
protected void createMetaData(DeploymentUnit unit, Set<String> names,
String suffix, String key) throws DeploymentException
{
// First see whether it already exists
T result = getMetaData(unit, key);
if (result != null && allowsReparse() == false)
return;
// Create it
....
So, result is not null (it contains the annotated binding) and
allowsReparse returns false, thus preventing the deployer from finding
META-INF/aop.xml.
I compared this with the behavior of deploying aop-scopedear1.aop. This
file contains no aspect annotations and, hence,
AOPXMLMetaDataParserDeployer gets a null result at the beginning of
createMetaData and is able to find META-INF/jboss-aop.xml file.
We are not seeing the same failure for aop-scoped2 because the aop.xml
file is outside META-INF and, for what I saw during debugging, this is
treated as a child unit. So there is no searching for
META-INF/jboss-aop.xml involved.
I just don't know how to fix it, because it looks like allowsReparse()
implementation is hardcoded "return false". Any pointers on how this
could be configured differently is appreciated, if that is the right way
to fix it, that is ;-).
On 01/27/2010 09:10 AM, Kabir Khan wrote:
--
Flavia Rainone | JBoss Core Developer
M: (+55) (+11) 8122-5466
YIM/MSNIM: flaviarnn
8:26 a.m.
Where does the previous metadata come from?
(OK, annotation binding, but where is this annotation binding?)
Either this deployer kicks in at the wrong stage,
or you're didn't consider any metadata merging.
Yes, xml/config files outside metadata locations (META-INF, ...) are
treated as subdeployments.
9:36 a.m.
On 27 Jan 2010, at 14:26, Ales Justin wrote:
The annotations are in classes in the .aop archive. They are parsed by
AOPAnnotationMetaDataParserDeployer which should come after the SchemaResolverDeployer
public class AOPAnnotationMetaDataParserDeployer extends AbstractDeployer
{
public AOPAnnotationMetaDataParserDeployer(int xmlParserOrder)
{
super.setOutput(AOPDeployment.class);
super.setStage(DeploymentStages.PARSE);
//Make this come after the AOPXMLMetaDataParserDeployer
super.setRelativeOrder(xmlParserOrder + 1);
}
public void deploy(DeploymentUnit unit) throws DeploymentException
{
....
AOPDeployment deployment = unit.getAttachment(AOPDeployment.class);
if (factories != null && factories.size() > 0)
{
if (deployment == null)
{
deployment = new AOPDeployment();
unit.addAttachment(AOPDeployment.class.getName(), deployment,
AOPDeployment.class);
}
...
}
}
deployers.xml
<bean name="AOPXMLMetaDataParserDeployer"
class="org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer">
<constructor>
<parameter>org.jboss.aop.microcontainer.beans.metadata.AOPDeployment</parameter>
</constructor>
<property name="suffix">-aop.xml</property>
</bean>
<bean name="AOPAnnotationMetaDataParserDeployer"
class="org.jboss.aop.asintegration.jboss5.AOPAnnotationMetaDataParserDeployer">
<constructor>
<parameter><inject bean="AOPXMLMetaDataParserDeployer"
property="relativeOrder"/></parameter>
</constructor>
</bean>
9:50 a.m.
Looking at the code, I don't see a reason why it cannot be at POST_PARSE.
Another thing we can notice from this issue is that deployers ordering
has changed -- it seems we (already) no longer use relative order for
ordering.
So, be alert on similar issues, as I've already found few things related
to bad/insufficient info of inputs/outputs in deployers.
(the alt-dd issue was a result of this)
Ales Justin wrote:
10:21 a.m.
That needs to be re-written to use inputs/outputs.
On a funny note:
War deployers have a long history of hacks,
so only Remy is allowed to touch them. :-)
On more serious one:
I'll have a look at them after M2 (before M3),
and communicate the changes with Remy.
Kabir Khan wrote:
10:39 a.m.
On Wed, Jan 27, 2010 at 5:21 PM, Ales Justin <ales.justin(a)gmail.com> wrote:
Yes, I was told that using an absolute order was bad. I'm aware of
that. But it works and the order is quite inflexible, so I don't see
much benefit here.
Any news on the feature additions so that I can switch to using a more
optimized annotation deployer ?
Rémy
10:33 a.m.
Moving it to POST_PARSE fixes the three failure we were seeing, but introduces a new
failure. If m2eclipse finishes updating maven dependencies before Sunday I'll try to
debug why.
Does m2eclipse take ages to do its stuff for every pom update for everybody else, or is
there something wrong with my setup? The last time it took 20 minutes
On 27 Jan 2010, at 15:50, Ales Justin wrote:
2:56 p.m.
Flavia and I have upgraded AOP in AS to 2.1.8.GA which gets rid of all the AOP errors
https://jira.jboss.org/jira/browse/JBAS-7618
On 27 Jan 2010, at 16:59, Kabir Khan wrote:
9:08 a.m.
[resent form the correct account this time]
On 01/27/2010 08:56 PM, Kabir Khan wrote:
Hmm, interesting, I upgraded my AS and
now get an error out of aopc. Or
rather I get a verify error from the code it generates:
13:04:25,428 WARN [ClassLoaderManager] Unexpected error during load
of:org.jboss.jbossts.baframework.demo.service.HotelImpl:
java.lang.ClassFormatError: Invalid length 170 in LocalVariableTable in
class file org/jboss/jbossts/baframework/demo/service/HotelImpl
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
. . .
The offending routine is HotelImpl.getHotelData()
Here's the relevant before bytecode (I'll spare you all the details but
the two versions are attached:
public java.lang.String getHotelData();
Code:
Stack=2, Locals=6, Args_size=1
0: getstatic #9; //Field log:Lorg/apache/log4j/Logger;
3: ldc #60; //String getHotelData()
. . .
153: aload_1
154: invokevirtual #66; //Method
java/lang/StringBuffer.toString:()Ljava/lang/String;
157: areturn
. . .
LocalVariableTable:
Start Length Slot Name Signature
57 24 4 customer
Lorg/jboss/jbossts/baframework/demo/service/CustomerEntityImpl;
37 47 3 i$ Ljava/util/Iterator;
119 24 5 room
Lorg/jboss/jbossts/baframework/demo/service/RoomEntityImpl;
97 49 4 i$ Ljava/util/Iterator;
0 158 0 this
Lorg/jboss/jbossts/baframework/demo/service/HotelImpl;
25 133 1 sb Ljava/lang/StringBuffer;
30 128 2 customers Ljava/util/List;
89 69 3 roomEntities Ljava/util/List;
and here is the after version:
public java.lang.String getHotelData();
Code:
Stack=2, Locals=6, Args_size=1
0: getstatic #341; //Field
org/jboss/jbossts/baframework/demo/service/HotelImpl.log:Lorg/apache/log4j/Logger;
3: ldc_w #343; //String getHotelData()
6: invokevirtual #345; //Method
org/apache/log4j/Logger.info:(Ljava/lang/Object;)V
. . .
159: aload_1
160: invokevirtual #397; //Method
java/lang/StringBuffer.toString:()Ljava/lang/String;
163: areturn
. . .
LocalVariableTable:
Start Length Slot Name Signature
63 26 4 customer
Lorg/jboss/jbossts/baframework/demo/service/CustomerEntityImpl;
41 51 3 i$ Ljava/util/Iterator;
129 26 5 room
Lorg/jboss/jbossts/baframework/demo/service/RoomEntityImpl;
105 53 4 i$ Ljava/util/Iterator;
0 170 0 this
Lorg/jboss/jbossts/baframework/demo/service/HotelImpl;
29 141 1 sb Ljava/lang/StringBuffer;
34 136 2 customers Ljava/util/List;
97 73 3 roomEntities Ljava/util/List;
So, the offending entry is the one for 'this' which has been pushed off
the end of the bytecode.
Since this AS includes javassist 3.11.0 this may relate to introduction
of my patch to 3.10 correcting a previous error in updating local
variable tables. In particular I am suspicious about all the ldc_w
instructions which replace ldc. The 170 offset for 'this' is 6 greater
than it should be and there are 6 ldc_w instructions in the method. I
notice also that the start and end positions for e.g i$ and sb which
both follow two ldc instructions are out by 2 in the new version.
Similarly, roomEmtities is 4 beyond where it should be and follows 4 ldc
instructions My fix might possibly have performed a counting error in
places where javassist is replacing ldc with ldc_w but I didn't directly
modify any of the code which counted changes in length. I think more
likely I have unmasked an existing error in counting length changes
which did not previously trip the verifier but has done so now because
my update is inserting new extents and they now go off the end of the
bytecode. I will investigate further.
regards,
Andrew Dinn
-----------
8:56 a.m.
On 01/27/2010 04:50 PM, Ales Justin wrote:
This is not true.
copy/paste from
org.jboss.deployers.plugins.sort.DependenciesTopologicalDeployerSorter.Graph.sort()
public List<Deployer> sort()
{
...
// ensure backward compatibility
Collections.sort(roots, Ordered.COMPARATOR);
...
while(!roots.isEmpty())
{
...
// ensure backward compatibility
nextLevel = new TreeSet<Vertex>(Ordered.COMPARATOR);
...
}
}
Backward compatibility is ensured with current deployers sorting
algorithm, but we should remove it IMHO.
When https://jira.jboss.org/jira/browse/JBDEPLOY-233 will be fixed we
will not support it any more.
I suggest to Kabir and everybody else relying on this fugly relative
order feature to migrate to
input/output based deployers sorting.
The problem Kabir is seeing with current wrong deployers ordering is
because someone touched inputs/outputs
of some deployers and this change affects him :(
Rio
--
Richard Opalka
ropalka(a)redhat.com
JBoss, by Red Hat
Office: +420 222 365 200
Mobile: +420 731 186 942
9:12 a.m.
You don't know that. ;-)
As DependenciesTopologicalDeployerSorter is actually currently not used,
and I have no other explanation on why that Web deployer kicked in
before AOP deployer -- their relative order was an explicit order hack:
AOP = Web + 1.
This could be either good or bad:
* good: exposed some issues; e.g. alt-dd order
* bad: it didn't expose some issues :-); e.g. we might have bad/random order
We can try switching to this sort alg,
doing it on a clean Hudson run would be best - to expose any changes.
9:18 a.m.
On 01/29/2010 04:12 PM, Ales Justin wrote:
aha, ok
It's because some input/output changed in some deployer and it caused
AOP deployer is not in the same "processing level" like Web deployer.
IOW both AOP and Web deployers are never relatively compared like before.
Believe me, there are no changes in new sorting algorithm ;)
--
Richard Opalka
ropalka(a)redhat.com
JBoss, by Red Hat
Office: +420 222 365 200
Mobile: +420 731 186 942
3:23 p.m.
I guess you meant this one?
<bean name="EARContentsDeployer"
class="org.jboss.deployment.EARContentsDeployer">
<constructor>
<parameter><inject bean="AppParsingDeployer"
property="relativeOrder"/></parameter>
</constructor>
<!-- Does the deployment have to end in .ear to process it -->
<property name="requiresEarSuffix">true</property>
</bean>
Deployers in ear-deployer-jboss-beans need revisiting,
to be more input/output based.
On Feb 1, 2010, at 10:01 PM, Jason T. Greene wrote:
5536
days inactive
5542
days old
jboss-development@lists.jboss.org
32 comments
8 participants
participants (8)
-
Ales Justin -
Andrew Dinn -
Brian Stansberry -
Flavia Rainone -
Jason T. Greene -
Kabir Khan -
Richard Opalka -
Rémy Maucherat