December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JASSIST-239) javassist.CannotCompileException: [source error] Method m is private

by Eric Nielsen (JIRA)

Eric Nielsen created JASSIST-239: ------------------------------------ Summary: javassist.CannotCompileException: [source error] Method m is private Key: JASSIST-239 URL: https://issues.jboss.org/browse/JASSIST-239 Project: Javassist Issue Type: Enhancement Affects Versions: 3.18.2-GA Reporter: Eric Nielsen Assignee: Shigeru Chiba Given these classes: {code} public abstract class A { public static void m() { return m(aClass()); } private static void m(Class<? extends A> aClass) { // some logic here } private static Class<? extends A> aClass() { // some logic here, subclasses will have own implementation } } public class B extends A { } {code} I'm writing instrumentation for subclasses of {{A}} (like {{B}} above). The code is something like: {code} // source is class A, target is subclass of A private void instrument(CtClass source, CtClass target) throws NotFoundException, CannotCompileException { CtMethod[] sourceMethods = source.getDeclaredMethods(); for (CtMethod method : sourceMethods) { int modifiers = method.getModifiers(); if (Modifier.isStatic(modifiers)) { CtMethod newMethod; if (Modifier.isPublic(modifiers) || Modifier.isProtected(modifiers)) { newMethod = CtNewMethod.copy(method, target, null); StringBuilder body = new StringBuilder().append("{ "); if (!CtClass.voidType.equals(method.getReturnType())) { body.append("return "); } body.append(method.getName()).append("(aClass()"); if (method.getParameterTypes().length > 0) { body.append(", $$"); } body.append("); }"); newMethod.setBody(body.toString()); } else if ("aClass".equals(method.getName())) { newMethod = CtNewMethod.copy(method, target, null); newMethod.setBody("{ return " + target.getName() + ".class; }"); } else { newMethod = CtNewMethod.delegator(method, target); } // include the generic signature for (Object attr : method.getMethodInfo().getAttributes()) { if (attr instanceof SignatureAttribute) { newMethod.getMethodInfo().addAttribute( (SignatureAttribute) attr); } } target.addMethod(newMethod); } } } {code} I want to achieve the result below with the instrumentation: {code} public class B extends A { public static void m() { return m(aClass()); // a copy of superclass code } private static void m(Class<? extends A> aClass) { super.m(aClass); // delegates to superclass } private static Class<? extends A> aClass() { return B.class; // returns this class } } {code} So when calling {{B.m()}}, the logic in the {{m(Class)}} superclass method will run receiving {{B.class}} as parameter. When running instrumentation, I get the following error message: {code} javassist.CannotCompileException: [source error] Method m is private {code} What's wrong? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-470) support patching through the http mgmt API

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-470?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-2629 to WFCORE-470: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-470 (was: WFLY-2629) Affects Version/s: 1.0.0.Alpha1 (was: 8.0.0.Final) Component/s: Patching (was: Patching) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > support patching through the http mgmt API > ------------------------------------------ > > Key: WFCORE-470 > URL: https://issues.jboss.org/browse/WFCORE-470 > Project: WildFly Core > Issue Type: Feature Request > Components: Patching > Affects Versions: 1.0.0.Alpha1 > Reporter: Emanuel Muckenhuber > Fix For: 1.0.0.Beta1 > > > The patch operation requires an input stream attachment of the patch content, which is not generally supported for all operations of the http API. We probably need to do something similar to the deployment add-content handler. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-471) pre/post cli-scripts for AS patching feature

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-471?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-347 to WFCORE-471: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-471 (was: WFLY-347) Component/s: Patching Scripts (was: Scripts) (was: Patching) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > pre/post cli-scripts for AS patching feature > -------------------------------------------- > > Key: WFCORE-471 > URL: https://issues.jboss.org/browse/WFCORE-471 > Project: WildFly Core > Issue Type: Feature Request > Components: Patching , Scripts > Reporter: Nicklas Karlsson > Assignee: Emanuel Muckenhuber > Fix For: 1.0.0.Beta1 > > > It would be handy to be able to attach pre/post CLI scripts to be applied for an AS patch. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-502) ClasspathKieProject fails vfs: try to unzip exploded jar

by Nicolas-Xavier Vanderlinden (JIRA)

[ https://issues.jboss.org/browse/DROOLS-502?page=com.atlassian.jira.plugin... ] Nicolas-Xavier Vanderlinden updated DROOLS-502: ----------------------------------------------- Affects Version/s: 6.2.0.CR3 > ClasspathKieProject fails vfs: try to unzip exploded jar > -------------------------------------------------------- > > Key: DROOLS-502 > URL: https://issues.jboss.org/browse/DROOLS-502 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Beta4, 6.2.0.CR3 > Reporter: Nicolas-Xavier Vanderlinden > Assignee: Mark Proctor > > Drools is not able to load kmodule.xml from an exploded jar inside an exploded ear. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-502) ClasspathKieProject fails vfs: try to unzip exploded jar

by Nicolas-Xavier Vanderlinden (JIRA)

[ https://issues.jboss.org/browse/DROOLS-502?page=com.atlassian.jira.plugin... ] Nicolas-Xavier Vanderlinden commented on DROOLS-502: ---------------------------------------------------- Would it be possible to resolve this bug in the next release ? The fix seems to be simple to apply. > ClasspathKieProject fails vfs: try to unzip exploded jar > -------------------------------------------------------- > > Key: DROOLS-502 > URL: https://issues.jboss.org/browse/DROOLS-502 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Beta4, 6.2.0.CR3 > Reporter: Nicolas-Xavier Vanderlinden > Assignee: Mark Proctor > > Drools is not able to load kmodule.xml from an exploded jar inside an exploded ear. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4139) Batch module dependencies not configured for valid deployments

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4139?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-4139: -------------------------------------- Assignee: Brent Douglas (was: James Perkins) > Batch module dependencies not configured for valid deployments > -------------------------------------------------------------- > > Key: WFLY-4139 > URL: https://issues.jboss.org/browse/WFLY-4139 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 8.2.0.Final, 9.0.0.Alpha1 > Environment: Fedora 19, JDK 8u25, wildfly-dist:9.0.0.Alpha1 > Reporter: Brent Douglas > Assignee: Brent Douglas > Fix For: 9.0.0.Beta1 > > > In BatchEnvironmentProcessor the Batch subsystem only adds a dependency on wildfly's transaction manager and bean manager if some marker files are detected. (See here) > https://github.com/wildfly/wildfly/blob/bfc41360196f5183a005101bf7ac2d7bf... > If they are not detected an unhelpful exception is thrown when instantiating the JobOperator: > {noformat} > 01:18:25,442 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0009: Undeployed "test.war" (runtime-name: "test.war") > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 248.119 sec <<< FAILURE! - in io.machinecode.chainlink.ee.wildfly.WildFlyTest > testGlassfish(io.machinecode.chainlink.ee.wildfly.WildFlyTest) Time elapsed: 0.336 sec <<< ERROR! > java.util.ServiceConfigurationError: javax.batch.operations.JobOperator: Provider org.jberet.operations.JobOperatorImpl could not be instantiated > at org.wildfly.jberet.services.BatchEnvironmentService$WildFlyBatchEnvironment.getArtifactFactory(BatchEnvironmentService.java:123) > at org.wildfly.jberet.DelegatingBatchEnvironment.getArtifactFactory(DelegatingBatchEnvironment.java:52) > at org.jberet.operations.JobOperatorImpl.<init>(JobOperatorImpl.java:89) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:408) > at java.lang.Class.newInstance(Class.java:438) > at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380) > at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) > at java.util.ServiceLoader$1.next(ServiceLoader.java:480) > at javax.batch.runtime.BatchRuntime.getJobOperator(BatchRuntime.java:57) > at io.machinecode.chainlink.ee.wildfly.WildFlyTest.testGlassfish(WildFlyTest.java:36) > {noformat} > There are valid reasons that these marker files may not be in the deployment, an example being that the deployment might only read metadata from jobs started by other deployments from the configured repository. This check also does not take into account jars in a war's lib dir (for example if you try and run a test using arquillian) or in an ear, which should be allowed. > I think there should be two changes. Firstly, those dependencies should be added unconditionally as there are cases where these marker will not be present and they will still be required. Secondly, the exception thrown because the beanManager has not been configured should be thrown earlier in the lifecycle where it will generate a real error message (perhaps in BatchEnvironmentService#start before creating the WildFlyBatchEnvironment where it can first be detected): > https://github.com/wildfly/wildfly/blob/bfc41360196f5183a005101bf7ac2d7bf... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4181) Incorrect program name set in appclient.bat

by James Perkins (JIRA)

James Perkins created WFLY-4181: ----------------------------------- Summary: Incorrect program name set in appclient.bat Key: WFLY-4181 URL: https://issues.jboss.org/browse/WFLY-4181 Project: WildFly Issue Type: Bug Components: Application Client Reporter: James Perkins Assignee: James Perkins The change for WFLY-4130 introduced processing the incoming parameters. During this process parameters are shifted which evaluates an incorrect {{PROGNAME}}. The evaluation of the {{PROGNAME}} needs to happen before the parameters are shifted. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4179) Three web integration test failures with security manager enabled

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-4179?page=com.atlassian.jira.plugin.... ] James Perkins commented on WFLY-4179: ------------------------------------- Running with a build of that PR did not seem to work locally. It's possible I had something wrong though. > Three web integration test failures with security manager enabled > ----------------------------------------------------------------- > > Key: WFLY-4179 > URL: https://issues.jboss.org/browse/WFLY-4179 > Project: WildFly > Issue Type: Bug > Components: Security Manager, Test Suite > Reporter: James Perkins > Assignee: Stuart Douglas > Attachments: org.jboss.as.test.integration.jsp.JspTagTestCase-output.txt, org.jboss.as.test.integration.web.customerrors.CustomErrorsUnitTestCase-output.txt, org.jboss.as.test.integration.web.servlet.lifecycle.ServletLifecycleMethodDescriptorTestCase.txt > > > The following 3 tests fail when the security manager is enabled for the {{testsuite/integration/web}} tests. > * org.jboss.as.test.integration.jsp.JspTagTestCase > * org.jboss.as.test.integration.web.servlet.lifecycle.ServletLifecycleMethodDescriptorTestCase > * org.jboss.as.test.integration.web.customerrors.CustomErrorsUnitTestCase > The tests are set to be ignored if the {{-Dsecurity.manager}} property is enabled. Once resolved the profile in the pom.xml for the web integration tests should be removed. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-57) Deprecated resource is present in r-r-d of /subsystem=security/security-domain=*

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-57?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFCORE-57: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1070214|https://bugzilla.redhat.com/show_bug.cgi?id=1070214] from POST to MODIFIED > Deprecated resource is present in r-r-d of /subsystem=security/security-domain=* > -------------------------------------------------------------------------------- > > Key: WFCORE-57 > URL: https://issues.jboss.org/browse/WFCORE-57 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha4 > Reporter: Harald Pehl > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Alpha9 > > > When executing > {code} > /subsystem=security/security-domain=*:read-resource-description(recursive-depth=2) > {code} > the acl subresource contains both the deprecated child-resource {{login-module}} and the new one called {{acl-module}}: > {code} > ... > "acl" => { > "description" => "Access control list configuration. Configures a list of ACL modules to be used.", > "model-description" => {"classic" => { > "description" => "Access control list configuration. Configures a list of ACL modules to be used.", > ... > "operations" => undefined, > "children" => { > "acl-module" => { > "description" => "ACL module", > "model-description" => {"*" => { > "description" => "List of authentication modules", > ... > "operations" => undefined, > "children" => {} > }} > }, > "login-module" => { > "description" => "Login module", > "model-description" => {"*" => undefined} > } > } > }} > }, > ... > {code} > However the deprecated subresource {{login-modules}} should only appear if setting {{include-aliases=true}} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-281) Unable to check result "undefined" in cli

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-281?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-281: ------------------------------------------------ Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1158602|https://bugzilla.redhat.com/show_bug.cgi?id=1158602] from ASSIGNED to MODIFIED > Unable to check result "undefined" in cli > ----------------------------------------- > > Key: WFCORE-281 > URL: https://issues.jboss.org/browse/WFCORE-281 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha13 > Reporter: Joe Wertz > Assignee: Joe Wertz > Priority: Minor > Fix For: 1.0.0.Alpha14 > > > if-else constructs in the CLI can't compare against undefined attribute results. > Attempt to create any 'if (result == undefined)' algorithms will always return false. The value-comparison can't handle undefined attributes. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2014