[JBoss JIRA] (WFLY-3726) Filesystem deployment scanner deployment failure removes unrelated deployments
by Jess Holle (JIRA)
[ https://issues.jboss.org/browse/WFLY-3726?page=com.atlassian.jira.plugin.... ]
Jess Holle commented on WFLY-3726:
----------------------------------
Until this is fixed, I have 2 options:
1) Move my explicit <deployment> elements to filesystem deployment scanner directories.
2) Move all applications from filesystem deployment scanner directories to <deployment> elements.
Any recommendations as to which is more solid/supported/accepted would be appreciated.
> Filesystem deployment scanner deployment failure removes unrelated deployments
> ------------------------------------------------------------------------------
>
> Key: WFLY-3726
> URL: https://issues.jboss.org/browse/WFLY-3726
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Environment: WIndows and Linux platforms both exhibit the issue
> Reporter: Jess Holle
> Assignee: Emmanuel Hugonnet
>
> If one's standalone-full.xml configuration contains something like:
> <deployments>
> <deployment name="MyWebApp.war" runtime-name="MyWebApp.war" enabled="true">
> <fs-exploded path="../../SomeDir/MyWebApp.war" relative-to="jboss.home.dir"/>
> </deployment>
> </deployments>
> whether manually inserted (while the server is not running) or installed via the CLI via
> /deployment=ServiceCenter.war/:add(runtime-name=ServiceCenter.war,content=[{archive=false,path="../../Windchill/ServiceCenter.war",relative-to="jboss.home.dir"}])
> and a deployment scanner like:
> <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
> <deployment-scanner name="1" path="../../../Applications" relative-to="jboss.server.base.dir" scan-interval="5000" auto-deploy-exploded="true"/>
> </subsystem>
> a failure by a deployment-scanner to deploy an application (exploded in my case, though I'm not sure this makes a difference) will cause the explicitly listed <deployments> to be removed from the configuration!
> This occurs irrespective of the value used for auto-deploy-exploded and to <deployment> elements that had already successfully been deployed and started.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (AS7-3050) RESTEasy: Boolean configuration parameters don't reject non-sense content
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-3050?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-3050:
----------------------------------------------
Weinan Li <weli(a)redhat.com> changed the Status of [bug 1121661|https://bugzilla.redhat.com/show_bug.cgi?id=1121661] from NEW to MODIFIED
> RESTEasy: Boolean configuration parameters don't reject non-sense content
> -------------------------------------------------------------------------
>
> Key: AS7-3050
> URL: https://issues.jboss.org/browse/AS7-3050
> Project: Application Server 7
> Issue Type: Bug
> Components: REST
> Affects Versions: 7.1.0.Beta1b
> Reporter: Pavel Janousek
> Assignee: Weinan Li
> Fix For: Awaiting Volunteers
>
>
> RESTEasy can be configured through several configuration options in WAR application deployment file WEB-INF/web.xml. These options which are type of Boolean (= true, false; maybe we should do support for 0 and 1 too), other invalid or non-sense setting should be rejected as invalid deployment description and a such application should not be deployed at all.
> Affected options are:
> - resteasy.scan
> - resteasy.scan.providers
> - resteasy.scan.resources
> - resteasy.use.builtin.providers
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JASSIST-232) BadBytecode when trying access localVariable using insertAfter and asFinally = true
by Marvin Herman Froeder (JIRA)
[ https://issues.jboss.org/browse/JASSIST-232?page=com.atlassian.jira.plugi... ]
Marvin Herman Froeder commented on JASSIST-232:
-----------------------------------------------
Tried that too.
still: Caused by: javassist.bytecode.BadBytecode: conflict: *top* and java.lang.String
> BadBytecode when trying access localVariable using insertAfter and asFinally = true
> -----------------------------------------------------------------------------------
>
> Key: JASSIST-232
> URL: https://issues.jboss.org/browse/JASSIST-232
> Project: Javassist
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.18.2-GA
> Reporter: Marvin Herman Froeder
> Assignee: Shigeru Chiba
>
> What I was trying to do:
> I wanna init a variable calling a method and then I wanna run a cleanup on
> finally.
> {code:java}
> private void originalMethod() {
> String aVar = null; // ctMethod.addLocalVariable()
> try{
> aVar = initVar(); // routine to create something ctMethod.insertBefore()
> runOriginalCode();
> }finally {
> dismiss(aVar); //cleanup routine ctMethod.insertAfter(,true)
> }
> }
> {code}
> I tried that by doing:
> {code:java}
> ctMethod.addLocalVariable("aVar", StringCtClass));
> ctMethod.insertBefore("aVar = initVar();");
> ctMethod.insertAfter(" dismiss( aVar );" , true);
> {code}
> But I got:
> {quote}
> javassist.CannotCompileException: by javassist.bytecode.BadBytecode: success ()Ljava/lang/Boolean; in com.contaazul.Sample: conflict: *top* and java.lang.String
> at javassist.CtBehavior.insertAfter(CtBehavior.java:880)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformer.trackThread(DbAdvisorClassFileTransformer.java:127)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformer.trackThread(DbAdvisorClassFileTransformer.java:120)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformer.instrumentContaAzul(DbAdvisorClassFileTransformer.java:66)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformer.transform(DbAdvisorClassFileTransformer.java:38)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformerTest$1.loadClass(DbAdvisorClassFileTransformerTest.java:39)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformerTest.contaazulish(DbAdvisorClassFileTransformerTest.java:93)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
> at org.testng.SuiteRunner.run(SuiteRunner.java:240)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
> at org.testng.TestNG.run(TestNG.java:1057)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
> at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
> Caused by: javassist.bytecode.BadBytecode: success ()Ljava/lang/Boolean; in com.contaazul.Sample: conflict: *top* and java.lang.String
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:111)
> at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:423)
> at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:405)
> at javassist.CtBehavior.insertAfter(CtBehavior.java:871)
> ... 31 more
> Caused by: javassist.bytecode.BadBytecode: conflict: *top* and java.lang.String
> at javassist.bytecode.stackmap.TypeData$BasicType.setType(TypeData.java:134)
> at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:930)
> at javassist.bytecode.stackmap.Tracer.doInvokeMethod(Tracer.java:801)
> at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:597)
> at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:81)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:187)
> at javassist.bytecode.stackmap.MapMaker.traceException(MapMaker.java:221)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:182)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:164)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:108)
> ... 34 more
> {quote}
> and I also tried the other way around (insertAfter first and insertBefore later):
> {code:java}
> ctMethod.addLocalVariable("aVar", StringCtClass));
> ctMethod.insertAfter(" dismiss( aVar );" , true);
> ctMethod.insertBefore("aVar = initVar();");
> {code}
> still, same error
> {quote}
> javassist.CannotCompileException: by javassist.bytecode.BadBytecode: success ()Ljava/lang/Boolean; in com.contaazul.Sample: conflict: *top* and java.lang.String
> at javassist.CtBehavior.insertAfter(CtBehavior.java:880)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformer.trackThread(DbAdvisorClassFileTransformer.java:126)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformer.trackThread(DbAdvisorClassFileTransformer.java:120)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformer.instrumentContaAzul(DbAdvisorClassFileTransformer.java:66)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformer.transform(DbAdvisorClassFileTransformer.java:38)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformerTest$1.loadClass(DbAdvisorClassFileTransformerTest.java:39)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at com.marvinformatics.dbadvisor.agent.DbAdvisorClassFileTransformerTest.contaazulish(DbAdvisorClassFileTransformerTest.java:93)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
> at org.testng.SuiteRunner.run(SuiteRunner.java:240)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
> at org.testng.TestNG.run(TestNG.java:1057)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
> at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
> Caused by: javassist.bytecode.BadBytecode: success ()Ljava/lang/Boolean; in com.contaazul.Sample: conflict: *top* and java.lang.String
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:111)
> at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:423)
> at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:405)
> at javassist.CtBehavior.insertAfter(CtBehavior.java:871)
> ... 31 more
> Caused by: javassist.bytecode.BadBytecode: conflict: *top* and java.lang.String
> at javassist.bytecode.stackmap.TypeData$BasicType.setType(TypeData.java:134)
> at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:930)
> at javassist.bytecode.stackmap.Tracer.doInvokeMethod(Tracer.java:801)
> at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:597)
> at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:81)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:187)
> at javassist.bytecode.stackmap.MapMaker.traceException(MapMaker.java:221)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:182)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:164)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:108)
> ... 34 more
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3705) read-resource recursive-depth has no effect when recursive=true
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3705?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3705:
----------------------------------------
Agreed, it should be
{code}
T | 0 | No recursion
{code}
The GlobalOperationAttributes.RECURSIVE_DEPTH field should be fixed to remove the ".setDefaultValue(new ModelNode(0))" call to the builder. There really is no default value here if '0' behaves differently from 'U'.
That requires changes to how GlobalOperationAttributes.RECURSIVE_DEPTH is used though. If an attribute has no default value, you can't do this as it is done in ReadResourceDescriptionHandler:
{code}
final int recursiveDepth = RECURSIVE_DEPTH.resolveModelAttribute(context, operation).asInt();
{code}
It needs to be more like
{code}
ModelNode depthNode = RECURSIVE_DEPTH.resolveModelAttribute(context, operation);
final Integer recursiveDepth = depthNode.isDefined() ? depthNode.asInt(): null;
{code}
And then null checks wherever recursiveDepth is used. Or the code could use an int with -1 representing undefined. That would be simpler:
{code}
final int recursiveDepth = RECURSIVE_DEPTH.resolveModelAttribute(context, operation).asInt(-1);
{code}
ReadResourceHandler uses an older idiom to read the data from the operation that isn't affected by removing the default value from the RECURSIVE_DEPTH definition.
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFLY-3705
> URL: https://issues.jboss.org/browse/WFLY-3705
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Documentation, Domain Management
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.7-200.fc20.x86_64 #1 SMP Mon Jul 28 18:50:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Brian Stansberry
>
> The code inside ReadResourceHandler.doExecuteInternal(OperationContext context, ModelNode operation) goes as follows:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = recursiveDepth > 0 || operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false);
> {noformat}
> The [documentation|https://docs.jboss.org/author/display/WFLY8/Global+operations] states:
> recursive-depth – (int) – The depth to which information about child resources should be included *if recursive is {{true}*. If not set, the depth will be unlimited; i.e. all descendant resources will be included.
> The logic, however, as implemented goes - either recursive-depth is greater than zero OR recursive is true.
> The proper implementation should be:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false) &&
> (!operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).isDefined() || recursiveDepth > 0);
> {noformat}
> The above snippet works as follows: recurs IF recursive is set AND (either recursive-depth is not defined OR recursive-depth is greater than 0).
>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3728) Upgrade JGroups to 3.4.5.Final
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-3728:
----------------------------------
Summary: Upgrade JGroups to 3.4.5.Final
Key: WFLY-3728
URL: https://issues.jboss.org/browse/WFLY-3728
Project: WildFly
Issue Type: Component Upgrade
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 8.1.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 8.2.0.CR1, 9.0.0.Beta1
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3726) Filesystem deployment scanner deployment failure removes unrelated deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3726?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3726:
----------------------------------------
Agreed; the success or failure of a particular workaround doesn't impact whether a bug is valid.
> Filesystem deployment scanner deployment failure removes unrelated deployments
> ------------------------------------------------------------------------------
>
> Key: WFLY-3726
> URL: https://issues.jboss.org/browse/WFLY-3726
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Environment: WIndows and Linux platforms both exhibit the issue
> Reporter: Jess Holle
> Assignee: Emmanuel Hugonnet
>
> If one's standalone-full.xml configuration contains something like:
> <deployments>
> <deployment name="MyWebApp.war" runtime-name="MyWebApp.war" enabled="true">
> <fs-exploded path="../../SomeDir/MyWebApp.war" relative-to="jboss.home.dir"/>
> </deployment>
> </deployments>
> whether manually inserted (while the server is not running) or installed via the CLI via
> /deployment=ServiceCenter.war/:add(runtime-name=ServiceCenter.war,content=[{archive=false,path="../../Windchill/ServiceCenter.war",relative-to="jboss.home.dir"}])
> and a deployment scanner like:
> <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
> <deployment-scanner name="1" path="../../../Applications" relative-to="jboss.server.base.dir" scan-interval="5000" auto-deploy-exploded="true"/>
> </subsystem>
> a failure by a deployment-scanner to deploy an application (exploded in my case, though I'm not sure this makes a difference) will cause the explicitly listed <deployments> to be removed from the configuration!
> This occurs irrespective of the value used for auto-deploy-exploded and to <deployment> elements that had already successfully been deployed and started.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months