[JBoss JIRA] (AS7-4383) Mode to disable writing deployment outcome files to deployment scanner dir
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-4383:
-------------------------------------
Summary: Mode to disable writing deployment outcome files to deployment scanner dir
Key: AS7-4383
URL: https://issues.jboss.org/browse/AS7-4383
Project: Application Server 7
Issue Type: Feature Request
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.2.0.Alpha1
Investigate adding a config option that disables writing the .isdeploying, .deployed, .isundeploying, .undeployed files to the deployment scanner dir.
Idea is to make it possible to have multiple scanners on different nodes sharing the deployment directory, without having the markers from one interfere with another.
This may not be practical at all in reality; needs investigation.
Marker files created by the user to control deployment should still be supported.
The .failed and .pending files are a bit of a gray area that need investigation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-5576) Slave HostControllers should provide initial ignored-resource data to the master HC
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-5576:
-------------------------------------
Summary: Slave HostControllers should provide initial ignored-resource data to the master HC
Key: AS7-5576
URL: https://issues.jboss.org/browse/AS7-5576
Project: Application Server 7
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.2.0.Alpha1
When the master HC is transforming the domain-level configuration model in order to provide it to a registering slave host, it should not bother transforming resources that are going to be ignored once they arrive at the slave.
To facilitate this, the slave should include ignored-resource data as part of the "host-info" ModelNode it passes to the master when it initiates registration.
One thing this (partly) allows is registration failure on the master if it detects the presence of unignored resources that the a slave running any earlier version cannot understand. The master cannot *always* fail in this situation, since the slave may be configured to ignore the offending resource. Providing the ignored-resource data allows the master to make a more informed decision.
Note: I say "(partly) allows" above because the master cannot "eagerly fail" if the registering slave is running a version that precedes the completion of this task.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (JASSIST-175) NPE while replacing FieldAccess with an instruction
by Celestino Bellone (JIRA)
Celestino Bellone created JASSIST-175:
-----------------------------------------
Summary: NPE while replacing FieldAccess with an instruction
Key: JASSIST-175
URL: https://issues.jboss.org/browse/JASSIST-175
Project: Javassist
Issue Type: Bug
Reporter: Celestino Bellone
Assignee: Shigeru Chiba
Hi guys,
I built an application that plays with load-time instrumentation. It worked well since I tested it on java7.
I had the same problem of PowerMock people (class VerifyError) so I switched to 3.17 snapshot; then I got the followin error while replacing a field access:
{noformat}
java.lang.NullPointerException
at javassist.bytecode.stackmap.MapMaker.fixTypes(MapMaker.java:285)
at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:140)
at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:99)
at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:423)
at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:405)
at javassist.expr.ExprEditor.doit(ExprEditor.java:113)
at javassist.CtClassType.instrument(CtClassType.java:1398)
at com.ejisto.core.classloading.ClassTransformer.transform(ClassTransformer.java:182)
at com.ejisto.core.classloading.ClassTransformer.transform(ClassTransformer.java:137)
at sun.instrument.TransformerManager.transform(TransformerManager.java:188)
at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:424)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2901)
at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1170)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1678)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1556)
at org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1209)
[cut]
{noformat}
I found this issue running my application with javassist 3.17 on both java7 and java6.
here attached you can find the code that reproduces this error.
Many thanks for your help!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (JBASMP-28) deploy-artifact throws NullPointer
by James Perkins (JIRA)
James Perkins created JBASMP-28:
-----------------------------------
Summary: deploy-artifact throws NullPointer
Key: JBASMP-28
URL: https://issues.jboss.org/browse/JBASMP-28
Project: JBoss AS Maven Plugins
Issue Type: Bug
Reporter: James Perkins
Assignee: James Perkins
For some reasons, DeployArtifact class contains
{code}
@parameter(defaultValue = "${project}", readonly = true, required = true)
private MavenProject project;
{code}
which is already declated in parent class AbstractDeployment.
removing private MavenProject project; from DeployArtifact fixing this issue
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months