[JBoss JIRA] (JASSIST-210) MethodCall.replace() throws inconsistent stack height in certain scenarios
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-210?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-210:
---------------------------------------
For the same reason I mentioned in This is similar to https://issues.jboss.org/browse/JASSIST-52
substituting a try-catch block for an argument or an operand in an expression is not possible (as far as I know).
The only workaround is to throw an exception again (or return a value) at the end of the catch clause.
If you execute ref.testMethod1(ref.testMethod2), then
1: ref is pushed onto the stack
2: ref is pushed onto the stack (for calling testMethod2)
3: invoke testMethod2, which push a return value onto the stack
4: pop the two values from the stack and invoke testMethod1
After the translation, 2 and 3 are replaced with a try-catch statement.
If an exception is thrown in the try block, then *all* the values in the stack are popped out.
So the value of ref stored in 1 is also popped out.
That's why even if the catch block pushed some value onto the stack, the JVM reports a verification error.
The value of ref is missing.
> MethodCall.replace() throws inconsistent stack height in certain scenarios
> --------------------------------------------------------------------------
>
> Key: JASSIST-210
> URL: https://issues.jboss.org/browse/JASSIST-210
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.16.1-GA, 3.18.1-GA
> Reporter: Patson Luk
> Assignee: Shigeru Chiba
>
> Tested on 3.16.1-GA
> This is similar to https://issues.jboss.org/browse/JASSIST-52, but the try-catch block usage is different (not wrapping the $proceed($$))
> Based on the javassist tutorial, the substituted code for MethodCall.replace():
> {{Note that the substituted code is not an expression but a statement or a block. It cannot be or contain a try-catch statement.}}
> However in the case that try-catch does not wrap the $_=$proceed($$);
> It seems to work properly. For example:
> ctClass.instrument(new ExprEditor() {
> public void edit(MethodCall m) throws CannotCompileException {
> if (m.getMethodName().equals("testMethod2")) {
> String newBlock = "{ try { System.out.println(\"injected\"); } catch (Exception e) { e.printStackTrace(); } $_ = $proceed($$); }";
> m.replace(newBlock);
> }
> }
> });
> {{which ctClass is class TestReplace, which has code as below:}}
> public class TestReplace {
> public static void main(String[] args) {
> RefClass ref = new RefClass();
> ref.testMethod2();
> }
> }
> class RefClass {
> public void testMethod1(Object o) {}
> public Object testMethod2() { return null; }
> }
> {{running TestReplace with the modified bytecode correctly prints "injected" to the screen. However if I add one more line to the TestReplace's main() method}}
> ref.testMethod1(ref.testMethod2());
> {{It throws exception as below}}
> javassist.bytecode.BadBytecode: inconsistent stack height -1
> javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:106)
> *So is try-catch acceptable if it does not wrap the $_=$proceed($$)? If so, is it a bug if it does not work properly for method invocation within another method invocation?*
> Many thanks in advance!
--
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
12 years, 7 months
[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka commented on WFLY-2426:
------------------------------------
It's in a profile, which can be disabled by -DnoVersion.properties
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Ondrej Zizka
> Labels: build, integration, jbds, layers, version
> Fix For: 8.0.0.CR1
>
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
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
12 years, 7 months
[JBoss JIRA] (JASSIST-210) MethodCall.replace() throws inconsistent stack height in certain scenarios
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-210?page=com.atlassian.jira.plugi... ]
Shigeru Chiba resolved JASSIST-210.
-----------------------------------
Resolution: Unresolved
> MethodCall.replace() throws inconsistent stack height in certain scenarios
> --------------------------------------------------------------------------
>
> Key: JASSIST-210
> URL: https://issues.jboss.org/browse/JASSIST-210
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.16.1-GA, 3.18.1-GA
> Reporter: Patson Luk
> Assignee: Shigeru Chiba
>
> Tested on 3.16.1-GA
> This is similar to https://issues.jboss.org/browse/JASSIST-52, but the try-catch block usage is different (not wrapping the $proceed($$))
> Based on the javassist tutorial, the substituted code for MethodCall.replace():
> {{Note that the substituted code is not an expression but a statement or a block. It cannot be or contain a try-catch statement.}}
> However in the case that try-catch does not wrap the $_=$proceed($$);
> It seems to work properly. For example:
> ctClass.instrument(new ExprEditor() {
> public void edit(MethodCall m) throws CannotCompileException {
> if (m.getMethodName().equals("testMethod2")) {
> String newBlock = "{ try { System.out.println(\"injected\"); } catch (Exception e) { e.printStackTrace(); } $_ = $proceed($$); }";
> m.replace(newBlock);
> }
> }
> });
> {{which ctClass is class TestReplace, which has code as below:}}
> public class TestReplace {
> public static void main(String[] args) {
> RefClass ref = new RefClass();
> ref.testMethod2();
> }
> }
> class RefClass {
> public void testMethod1(Object o) {}
> public Object testMethod2() { return null; }
> }
> {{running TestReplace with the modified bytecode correctly prints "injected" to the screen. However if I add one more line to the TestReplace's main() method}}
> ref.testMethod1(ref.testMethod2());
> {{It throws exception as below}}
> javassist.bytecode.BadBytecode: inconsistent stack height -1
> javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:106)
> *So is try-catch acceptable if it does not wrap the $_=$proceed($$)? If so, is it a bug if it does not work properly for method invocation within another method invocation?*
> Many thanks in advance!
--
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
12 years, 7 months
[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka resolved WFLY-2426.
--------------------------------
Labels: build integration jbds layers version (was: )
Fix Version/s: 8.0.0.CR1
Resolution: Done
Resolving this and expecting some feedback.
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Ondrej Zizka
> Labels: version, layers, jbds, integration, build
> Fix For: 8.0.0.CR1
>
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
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
12 years, 7 months
[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka commented on WFLY-2426:
------------------------------------
I don't like the solution with file buried somewhere in the dir structure which is not even guaranteed to remain as is for future releases.
I've created the two PR's - 5551 and 5552, two impls of the same - adding version-base.txt.
Currently it uses ${project.version}. Is maitaining the version string manually necessary? IMO we should rely on the version from POM.
The name is version-base.properties.
1) it clearly declares the file format,
2) it declares that it's for the "base" layer.
Ad 2) - for other layers, another file would be added. This ensures that tools only looking for AS will find it, and it's version. Tools looking for all layers may simply check for version-*.properties, just like they would check for "modules/system/layers/" + layer + ...
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Ondrej Zizka
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
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
12 years, 7 months
[JBoss JIRA] (WFLY-2228) EJB and web module cannot have the same name in an ear
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-2228?page=com.atlassian.jira.plugin.... ]
Eduardo Martins commented on WFLY-2228:
---------------------------------------
This issue was marked as duplicate of WFLY-2223 , which is already resolved. If you are still suffering from this on a Wildfly build made from current sources then please let us know in WFLY-2223.
> EJB and web module cannot have the same name in an ear
> ------------------------------------------------------
>
> Key: WFLY-2228
> URL: https://issues.jboss.org/browse/WFLY-2228
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Beta1
> Reporter: Jozef Hartinger
> Assignee: Eduardo Martins
> Fix For: 8.0.0.CR1
>
> Attachments: weld-translator.ear
>
>
> Having an ear project like this:
> {code}
> weld.translator.ear
> +--weld-translator.war
> +--weld-translator.jar
> {code}
> I am no longer able to deploy it to WildFly. This is a regression caused by the following commit: https://github.com/wildfly/wildfly/commit/d4aecbe5d2b241befa5da43b19c2d07...
> The deployment exception:
> {noformat}
> 10:45:56,835 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Beta1 "WildFly" started in 3433ms - Started 180 of 217 services (62 services are lazy, passive or on-demand)
> 10:46:22,816 INFO [org.jboss.as.repository] (management-handler-thread - 1) JBAS014900: Content added at location /home/jharting/jboss/Weld/wildfly-8.0.0.Beta1/standalone/data/content/41/4cdfd11cd5283d5356778f396c618ca2477c6b/content
> 10:46:22,842 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "weld-translator.ear" (runtime-name: "weld-translator.ear")
> 10:46:22,912 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "null" (runtime-name: "weld-jsf-translator-war-2.1.0-SNAPSHOT.war")
> 10:46:22,912 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "null" (runtime-name: "weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar")
> 10:46:23,147 INFO [org.jboss.weld.deployer] (MSC service thread 1-8) JBAS016002: Processing weld deployment weld-translator.ear
> 10:46:23,192 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-8) HV000001: Hibernate Validator 5.0.1.Final
> 10:46:23,340 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment weld-jsf-translator-war-2.1.0-SNAPSHOT.war
> 10:46:23,353 INFO [org.jboss.weld.deployer] (MSC service thread 1-6) JBAS016002: Processing weld deployment weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar
> 10:46:23,366 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-6) JNDI bindings for session bean named TranslatorControllerBean in deployment unit subdeployment "weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar" of deployment "weld-translator.ear" are as follows:
> java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
> java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
> java:module/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
> java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean
> java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean
> java:module/TranslatorControllerBean
> 10:46:23,369 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-6) JNDI bindings for session bean named SentenceTranslator in deployment unit subdeployment "weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar" of deployment "weld-translator.ear" are as follows:
> java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator!org.jboss.weld.examples.translator.Translator
> java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator!org.jboss.weld.examples.translator.Translator
> java:module/SentenceTranslator!org.jboss.weld.examples.translator.Translator
> java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator
> java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator
> java:module/SentenceTranslator
> 10:46:23,392 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016005: Starting Services for CDI deployment: weld-translator.ear
> 10:46:23,430 INFO [org.jboss.weld.Version] (MSC service thread 1-1) WELD-000900: 2.1.0 (2013-10-07 08:46)
> 10:46:23,448 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016008: Starting weld service for deployment weld-translator.ear
> 10:46:24,654 INFO [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-8) Initializing Mojarra 2.2.3-jbossorg-1 20130910-1739 for context '/weld-translator'
> 10:46:25,490 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS018210: Register web context: /weld-translator
> 10:46:25,569 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "weld-translator.ear" (runtime-name : "weld-translator.ear")
> 10:46:43,715 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS018224: Unregister web context: /weld-translator
> 10:46:43,731 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) JBAS016009: Stopping weld service for deployment weld-translator.ear
> 10:46:43,775 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment null (runtime-name: weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar) in 65ms
> 10:46:43,777 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015877: Stopped deployment null (runtime-name: weld-jsf-translator-war-2.1.0-SNAPSHOT.war) in 68ms
> 10:46:43,779 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015877: Stopped deployment weld-translator.ear (runtime-name: weld-translator.ear) in 70ms
> 10:46:43,820 INFO [org.jboss.as.repository] (management-handler-thread - 2) JBAS014901: Content removed from location /home/jharting/jboss/Weld/wildfly-8.0.0.Beta1/standalone/data/content/41/4cdfd11cd5283d5356778f396c618ca2477c6b/content
> 10:46:43,821 INFO [org.jboss.as.server] (management-handler-thread - 2) JBAS018558: Undeployed "weld-translator.ear" (runtime-name: "weld-translator.ear")
> 10:47:10,201 INFO [org.jboss.as.repository] (management-handler-thread - 3) JBAS014900: Content added at location /home/jharting/jboss/Weld/wildfly-8.0.0.Beta1/standalone/data/content/d9/22ca6b33304b2cccc227cdf8f6aadeedad88f9/content
> 10:47:10,203 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "weld-translator.ear" (runtime-name: "weld-translator.ear")
> 10:47:10,223 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "null" (runtime-name: "weld-translator.jar")
> 10:47:10,223 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "null" (runtime-name: "weld-translator.war")
> 10:47:10,297 INFO [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016002: Processing weld deployment weld-translator.ear
> 10:47:10,310 INFO [org.jboss.weld.deployer] (MSC service thread 1-6) JBAS016002: Processing weld deployment weld-translator.war
> 10:47:10,311 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016002: Processing weld deployment weld-translator.jar
> 10:47:10,314 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named TranslatorControllerBean in deployment unit subdeployment "weld-translator.jar" of deployment "weld-translator.ear" are as follows:
> java:global/weld-translator/weld-translator.jar/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
> java:app/weld-translator.jar/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
> java:module/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
> java:global/weld-translator/weld-translator.jar/TranslatorControllerBean
> java:app/weld-translator.jar/TranslatorControllerBean
> java:module/TranslatorControllerBean
> 10:47:10,314 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named SentenceTranslator in deployment unit subdeployment "weld-translator.jar" of deployment "weld-translator.ear" are as follows:
> java:global/weld-translator/weld-translator.jar/SentenceTranslator!org.jboss.weld.examples.translator.Translator
> java:app/weld-translator.jar/SentenceTranslator!org.jboss.weld.examples.translator.Translator
> java:module/SentenceTranslator!org.jboss.weld.examples.translator.Translator
> java:global/weld-translator/weld-translator.jar/SentenceTranslator
> java:app/weld-translator.jar/SentenceTranslator
> java:module/SentenceTranslator
> 10:47:10,318 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."weld-translator.ear"."weld-translator.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."weld-translator.ear"."weld-translator.jar".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "weld-translator.jar" of deployment "weld-translator.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.weld-translator.weld-translator is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.setupConcurrentContext(EEConcurrentContextProcessor.java:110)
> at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.processModuleDescription(EEConcurrentContextProcessor.java:71)
> at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.deploy(EEConcurrentContextProcessor.java:54)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> ... 5 more
> 10:47:10,329 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "weld-translator.ear")]) - failure description: {
> "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"weld-translator.jar\" of deployment \"weld-translator.ear\"
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.weld-translator.weld-translator is already registered"},
> "JBAS014771: Services with missing/unavailable dependencies" => [
> "jboss.deployment.unit.\"weld-translator.ear\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"weld-translator.ear\".beanmanager]",
> "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".batch is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]",
> "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".weld.weldClassIntrospector is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]"
> ]
> }
> 10:47:10,338 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "weld-translator.ear" was rolled back with the following failure message:
> {
> "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"weld-translator.jar\" of deployment \"weld-translator.ear\"
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.weld-translator.weld-translator is already registered"},
> "JBAS014771: Services with missing/unavailable dependencies" => [
> "jboss.deployment.unit.\"weld-translator.ear\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"weld-translator.ear\".beanmanager]",
> "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".batch is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]",
> "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".weld.weldClassIntrospector is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]"
> ]
> }
> 10:47:10,351 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment null (runtime-name: weld-translator.jar) in 18ms
> 10:47:10,354 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment null (runtime-name: weld-translator.war) in 21ms
> 10:47:10,356 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment weld-translator.ear (runtime-name: weld-translator.ear) in 23ms
> 10:47:10,358 INFO [org.jboss.as.controller] (management-handler-thread - 3) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".beanmanager (missing) dependents: [service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".weld.weldClassIntrospector, service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".batch]
> service jboss.deployment.unit."weld-translator.ear".beanmanager (missing) dependents: [service jboss.deployment.unit."weld-translator.ear".weld.weldClassIntrospector]
> service jboss.naming.context.java.module.weld-translator."weld-translator.war" (missing) dependents: [service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".INSTALL]
> JBAS014777: Services which failed to start: service jboss.deployment.subunit."weld-translator.ear"."weld-translator.jar".POST_MODULE
> {noformat}
--
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
12 years, 7 months
[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka updated WFLY-2426:
-------------------------------
Assignee: Ondrej Zizka
Git Pull Request: https://github.com/wildfly/wildfly/pull/5551, https://github.com/wildfly/wildfly/pull/5552
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Ondrej Zizka
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
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
12 years, 7 months
[JBoss JIRA] (JBMETA-369) Compilation error in AbstractWebServiceRefProcessor with JDK7
by Chao Wang (JIRA)
Chao Wang created JBMETA-369:
--------------------------------
Summary: Compilation error in AbstractWebServiceRefProcessor with JDK7
Key: JBMETA-369
URL: https://issues.jboss.org/browse/JBMETA-369
Project: JBoss Metadata
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.0.6.GA
Environment: Java version: 1.7.0_40, vendor: Oracle Corporation
Reporter: Chao Wang
Assignee: Chao Wang
When I built jboss metadata on https://svn.jboss.org/repos/jbossas/projects/metadata/trunk
I received a compilation error in AbstractWebServiceRefProcessor with JDK7, but I can build without this error with JDK6.
{noformat}
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7.340s
[INFO] Finished at: Mon Dec 02 17:20:37 CST 2013
[INFO] Final Memory: 13M/211M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile) on project jboss-metadata: Compilation failure
[ERROR] /home/wangchao/work/jbossas/EAP5/metadata/trunk/src/main/java/org/jboss/metadata/annotation/creator/ws/AbstractWebServiceRefProcessor.java:[116,28] error: incomparable types: Class<CAP#1> and Class<Object>
{noformat}
the error indicates to AbstractWebServiceRefProcessor.java:
{code:title=AbstractWebServiceRefProcessor.java|borderStyle=solid}
if(annotation.value() != Object.class && annotation.value() != Service.class)
ref.setServiceInterface(annotation.value().getName());
{code}
>From JAX-WS 2.1 to 2.2 API, the value type and default value have been changed from Object.class to Service.class.
{code:title=WebServiceRef.java|borderStyle=solid}
/**
* The service class, alwiays a type extending
* <code>javax.xml.ws.Service</code>. This element MUST be specified
* whenever the type of the reference is a service endpoint interface.
*/
// 2.1 has Class value() default Object.class;
// Fixing this raw Class type correctly in 2.2 API. This shouldn't cause
// any compatibility issues for applications.
Class<? extends Service> value() default Service.class;
{code}
--
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
12 years, 7 months
[JBoss JIRA] (WFLY-409) JPA should allow for a bean validator factory per persistence unit or per application deployment
by Hardy Ferentschik (JIRA)
[ https://issues.jboss.org/browse/WFLY-409?page=com.atlassian.jira.plugin.s... ]
Hardy Ferentschik commented on WFLY-409:
----------------------------------------
{quote}
Is this to say that in applications with multiple persistence units a validator factory is created for each PU? If so, I don't think that's neccessary as I'm not aware of any PU-specific configuration related to validation.
{quote}
That's right. Maybe I am just not sure what this issue stands for.
{quote}
Instead the same VF can be used for all the PUs of one application which will save memory.
{quote}
Right
{quote}
But with WFLY-1705 done, this should actually be the case, i.e. JPA consistently uses the one and only (in the context of one application) LazyValidatorFacotry (I think that's what Scott is saying).
{quote}
If this is the case, I am fine. Then I just need to find out why my test case ( see [HV-837|https://hibernate.atlassian.net/browse/HV-837]) is not working.
> JPA should allow for a bean validator factory per persistence unit or per application deployment
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-409
> URL: https://issues.jboss.org/browse/WFLY-409
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Labels: open_to_community
> Fix For: 8.0.0.Beta1
>
>
> Currently, a new bean validator factory instance is associated with each deployed persistence unit. This jira calls for adding a new PU property that specifies that a 'per app bean validator factory' should be used for a persistence unit (via a persistence unit property).
> This can be controlled by a new persistence unit property (see existing ones [here|https://docs.jboss.org/author/display/AS71/JPA+Reference+Guide#JPARe...]).
> The new property can be something like "org.jboss.as.jpa.shareValidatorFactory" which defaults to false.
> Look at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deployPersistenceUnit() to make this change.
--
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
12 years, 7 months
[JBoss JIRA] (JGRP-1751) State transfer: views installed during state transfer are never installed at the state requester
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1751?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1751 at 12/2/13 4:08 AM:
---------------------------------------------------------
SOLUTIONS:
# Ship current view with state and digest
#* This is unnecessary as the above case is an edge case and we'd ship a view that the state requester already has
# Serialize view installation and state transfer
#* Not good as joins would be delayed by ongoing state transfers (which might take a long time)
# After the state has been transferred, let the state requester ask the coordinator for the current view
#* The state requests ships its current view id
#* The coordinator checks if the view id equals the current view-id
#* If the view-ids don't match, the coordinator sends the *full view* (not delta view) to the state requester
#* Else: no-op
#* This requires 2 new messages: a GET_CURRENT_VIEW(view-id) request and a SET_CURRENT_VIEW(full-view) response
#* This could also be used when we receive a delta-view, but don't have the required view-id (investigate this later)
was (Author: belaban):
SOLUTIONS:
# Ship current view with state and digest
#* This is unnecessary as the above case is an edge case and we'd ship a view that the state requester already has
# After the state has been transferred, let the state requester ask the coordinator for the current view
#* The state requests ships its current view id
#* The coordinator checks if the view id equals the current view-id
#* If the view-ids don't match, the coordinator sends the *full view* (not delta view) to the state requester
#* Else: no-op
#* This requires 2 new messages: a GET_CURRENT_VIEW(view-id) request and a SET_CURRENT_VIEW(full-view) response
#* This could also be used when we receive a delta-view, but don't have the required view-id (investigate this later)
> State transfer: views installed during state transfer are never installed at the state requester
> ------------------------------------------------------------------------------------------------
>
> Key: JGRP-1751
> URL: https://issues.jboss.org/browse/JGRP-1751
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> If a state requester requests state and BARRIER drops all messages at the state requester, then a view V dispatched by the coordinator during the state transfer will never be installed at the state requester:
> * The current view is V1=\{A,B\}
> * B requests the state from A
> * A gets a JOIN from C
> * A mcasts the new view V2=\{A,B,C\}, seqno=6
> * A sends back a unicast state response to B including the state and a digest with A:6 (*including* V2)
> * B receives the unicast state response and installs the state and digest
> ** B's digest for A is 6
> * B receives V2 (A:6), but *drops it as message 6 is already in its digest for A !*
> --> B will never install V2 !
> This applies to all state transfer protocols which use BARRIER (STATE_TRANSFER, STATE, STATE_SOCK).
--
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
12 years, 7 months