[JBoss JIRA] (LOGTOOL-110) Log Tool generates incorrect annotations
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-110?page=com.atlassian.jira.plugi... ]
James Perkins closed LOGTOOL-110.
---------------------------------
Resolution: Out of Date
I don't believe this is an issue. If there is still an issue please feel free to reopen.
> Log Tool generates incorrect annotations
> ----------------------------------------
>
> Key: LOGTOOL-110
> URL: https://issues.jboss.org/browse/LOGTOOL-110
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Environment: openjdk version "1.8.0_91"
> OpenJDK Runtime Environment (build 1.8.0_91-b14)
> OpenJDK Server VM (build 25.91-b14, mixed mode)
> Apache Maven 3.3.3
> javax.enterprise:cdi-api:jar:1.2
> javax.inject:javax.inject:jar:1
> org.jboss.weld:weld-api:jar:2.3.Final
> org.jboss.weld:weld-spi:jar:2.3.Final
> org.jboss.classfilewriter:jboss-classfilewriter:jar:1.1.2.Final
> org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:jar:1.0.0.Final
> org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final
> org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.0.Final
> org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:1.0.0.Final
> org.hibernate.javax.persistence:hibernate-jpa-2.1-api:jar:1.0.0.Final
> com.google.guava:guava:jar:18.0
> org.jboss.spec.javax.el:jboss-el-api_3.0_spec:jar:1.0.5.Final
> org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.2_spec:jar:1.0.0.Final
> org.jboss.logging:jboss-logging-processor:jar:2.0.1.Final
> org.jboss.logging:jboss-logging-annotations:jar:2.0.1.Final
> org.jboss.jdeparser:jdeparser:jar:2.0.0.Final
> org.jboss.logging:jboss-logging:jar:3.3.0.Final
> net.sourceforge.findbugs:annotations:jar:1.3.2
> Reporter: gil cattaneo
> Attachments: ReflectionLogger.i18n_locale_COUNTRY_VARIANT.properties, ReflectionLogger.java, ReflectionLogger_$logger.java, ReflectionLogger_logger.java, ResolutionLogger.i18n.properties, weld-core-build.log
>
>
> Hi
> i catch:
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.5.1:compile (default-compile) on project weld-core-impl: Compilation failure: Compilation failure:
> [ERROR] /builddir/build/BUILD/core-2.3.4.Final/impl/target/generated-sources/annotations/org/jboss/weld/logging/ReflectionLogger_$logger.java:[25,8] org.jboss.weld.logging.ReflectionLogger_$logger is not abstract and does not override abstract method illegalArgumentExceptionOnReflectionInvocation(java.lang.Class<?>,java.lang.Object,java.lang.reflect.Method,java.lang.String,java.lang.IllegalArgumentException) in org.jboss.weld.logging.ReflectionLogger
> [ERROR] /builddir/build/BUILD/core-2.3.4.Final/impl/target/generated-sources/annotations/org/jboss/weld/logging/ReflectionLogger_$logger.java:[198,5] method does not override or implement a method from a supertype
> [ERROR] -> [Help 1]
> any ideas?
> thanks in advance
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (LOGTOOL-84) Provide mechanism for preparing string representations of logged objects
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-84?page=com.atlassian.jira.plugin... ]
James Perkins closed LOGTOOL-84.
--------------------------------
Resolution: Out of Date
Cleaning up old JIRA's and this sounds like there is a solution for it.
> Provide mechanism for preparing string representations of logged objects
> ------------------------------------------------------------------------
>
> Key: LOGTOOL-84
> URL: https://issues.jboss.org/browse/LOGTOOL-84
> Project: Log Tool
> Issue Type: Feature Request
> Reporter: Gunnar Morling
> Assignee: David Lloyd
>
> There are cases where a fine-grained control of the string representation of logged objects in log messages would be useful.
> When logging {{Class}} objects for instance, we would like to see the fully-qualified name of the given class in the log message. Currently we get _(class|interface) com.acme.Foo_, though, as per the implementation of {{j.l.Class#toString()}}, which prepends the type of the given class object.
> As workaround, we currently define the log method to accept a String parameter and pass {{myClass.getName()}} to it. Having a strongly typed log method which takes the "real" object as parameter seems preferable, though.
> A possible solution could be a mechanism which allows to register to-string converters for given types with a logger:
> {code}
> //Provided by JBoss Logging API
> public interface StringConverter<T> {
> String createString(T object);
> }
> //A project-specific implementation
> public class ClassStringConverter implements StringConverter<Class<?>> {
> public String createString(Class<?> object) {
> return object.getName();
> }
> }
> //Project-specific logger, references 1..n converters
> @MessageLogger(projectCode = "HV", converters=ClassStringConverter.class)
> public interface Log extends BasicLogger {
> //implementation uses converter to create string representation of given class
> @LogMessage(level = INFO)
> @Message(id = 1, value = "Illegal class %s")
> void illegalClass(Class<?> clazz);
> }
> {code}
> Would such a feature make sense to you?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-9070) Request Scope is not active during Batchlet
by James Perkins (JIRA)
James Perkins created WFLY-9070:
-----------------------------------
Summary: Request Scope is not active during Batchlet
Key: WFLY-9070
URL: https://issues.jboss.org/browse/WFLY-9070
Project: WildFly
Issue Type: Bug
Components: Batch, CDI / Weld
Affects Versions: 10.1.0.Final
Environment: Wildfly 10.1.0 Final
Reporter: Cody Lerum
Assignee: James Perkins
When executing a Java EE 7 batchlet if an injection of an @RequestScoped bean is attempted.
Example
{noformat}
20:57:13,995 WARN [org.jberet] (Batch Thread - 13) JBERET000001: Failed to run batchlet org.jberet.job.model.RefArtifact@b5b6a97: org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:689)
at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90)
at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:165)
at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8942) Request Scope is not active during Batchlet
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-8942?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-8942:
-------------------------------------
Thanks [~mkouba]. I got it to work locally. I was missing the {{@Unboud}} before.
> Request Scope is not active during Batchlet
> -------------------------------------------
>
> Key: WFLY-8942
> URL: https://issues.jboss.org/browse/WFLY-8942
> Project: WildFly
> Issue Type: Bug
> Components: Batch, CDI / Weld
> Affects Versions: 10.1.0.Final
> Environment: Wildfly 10.1.0 Final
> Reporter: Cody Lerum
> Assignee: James Perkins
> Attachments: batch-chunk.war
>
>
> When executing a Java EE 7 batchlet if an injection of an @RequestScoped bean is attempted.
> Example
> {noformat}
> 20:57:13,995 WARN [org.jberet] (Batch Thread - 13) JBERET000001: Failed to run batchlet org.jberet.job.model.RefArtifact@b5b6a97: org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:689)
> at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90)
> at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:165)
> at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-8954:
------------------------------------
# Please look at [https://community.jboss.org/wiki/HackingOnWildFly]
# after you git clone [https://github.com/wildfly/wildfly], do a "git checkout -b WFLY-8954"
# In your local wildfly folder, change into the wildfly folder and run "build.sh clean install" (or build.bat) to build the app server.
# change into the testsuite/compat folder and run "mvn clean install" (you need Apache Maven installed for this step) and that will run a minimal EclipseLink test.
# start making changes of your local copy of the [https://github.com/wildfly/wildfly/tree/master/testsuite/compat/src/test/...] folder, to reproduce the failure with EclipseLink
# Run "mvn clean install" again with your test changes and verify that your seeing the same error.
# Do a "git push origin WFLY-8954" to push your test code changes to github.
After that, we can discuss further how to try code changes to address the failure.
One more thing, you need to agree that your code contributions be made under the terms of the MIT License, [http://www.opensource.org/licenses/mit-license.php]. Comment in response if you agree to these terms?
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-9069) EJBClientContext could not initialize class org.jboss.ejb.client.DeploymentNodeSelector when building with JDK-9
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-9069?page=com.atlassian.jira.plugin.... ]
Amos Feng reassigned WFLY-9069:
-------------------------------
Assignee: Tomaz Cerar
> EJBClientContext could not initialize class org.jboss.ejb.client.DeploymentNodeSelector when building with JDK-9
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9069
> URL: https://issues.jboss.org/browse/WFLY-9069
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Amos Feng
> Assignee: Tomaz Cerar
>
> {noformat}
> testRejectionsEAP620(org.jboss.as.ejb3.subsystem.Ejb3TransformersTestCase) Time elapsed: 2.786 sec <<< ERROR!
> java.lang.IncompatibleClassChangeError: Inconsistent constant pool data in classfile for class org/jboss/ejb/client/DeploymentNodeSelector. Method lambda$static$1([Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; at index 109 is CONSTANT_MethodRef and should be CONSTANT_InterfaceMethodRef
> at org.jboss.ejb.client.DeploymentNodeSelector.<clinit>(DeploymentNodeSelector.java:83)
> at org.jboss.ejb.client.EJBClientContext$Builder.<init>(EJBClientContext.java:538)
> at org.jboss.as.ejb3.subsystem.EJB3Subsystem50Parser.parseProfile(EJB3Subsystem50Parser.java:218)
> at org.jboss.as.ejb3.subsystem.EJB3Subsystem30Parser.parseProfiles(EJB3Subsystem30Parser.java:215)
> at org.jboss.as.ejb3.subsystem.EJB3Subsystem40Parser.parseRemote(EJB3Subsystem40Parser.java:116)
> at org.jboss.as.ejb3.subsystem.EJB3Subsystem12Parser.readElement(EJB3Subsystem12Parser.java:135)
> at org.jboss.as.ejb3.subsystem.EJB3Subsystem13Parser.readElement(EJB3Subsystem13Parser.java:66)
> at org.jboss.as.ejb3.subsystem.EJB3Subsystem14Parser.readElement(EJB3Subsystem14Parser.java:58)
> at org.jboss.as.ejb3.subsystem.EJB3Subsystem20Parser.readElement(EJB3Subsystem20Parser.java:69)
> at org.jboss.as.ejb3.subsystem.EJB3Subsystem30Parser.readElement(EJB3Subsystem30Parser.java:77)
> at org.jboss.as.ejb3.subsystem.EJB3Subsystem50Parser.readElement(EJB3Subsystem50Parser.java:88)
> at org.jboss.as.ejb3.subsystem.EJB3Subsystem12Parser.readElement(EJB3Subsystem12Parser.java:104)
> at org.jboss.as.ejb3.subsystem.EJB3Subsystem12Parser.readElement(EJB3Subsystem12Parser.java:71)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:122)
> at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
> at org.jboss.as.subsystem.test.TestParser.readElement(TestParser.java:103)
> at org.jboss.as.subsystem.test.TestParser.readElement(TestParser.java:51)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:122)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:76)
> at org.jboss.as.subsystem.test.SubsystemTestDelegate.parse(SubsystemTestDelegate.java:223)
> at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.parse(SubsystemTestDelegate.java:611)
> at org.jboss.as.model.test.ModelTestBootOperationsBuilder.internalSetSubsystemXml(ModelTestBootOperationsBuilder.java:76)
> at org.jboss.as.model.test.ModelTestBootOperationsBuilder.setXmlResource(ModelTestBootOperationsBuilder.java:55)
> at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.parseXmlResource(SubsystemTestDelegate.java:624)
> at org.jboss.as.ejb3.subsystem.Ejb3TransformersTestCase.testRejections(Ejb3TransformersTestCase.java:174)
> at org.jboss.as.ejb3.subsystem.Ejb3TransformersTestCase.testRejectionsEAP620(Ejb3TransformersTestCase.java:138)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-9069) EJBClientContext could not initialize class org.jboss.ejb.client.DeploymentNodeSelector when building with JDK-9
by Amos Feng (JIRA)
Amos Feng created WFLY-9069:
-------------------------------
Summary: EJBClientContext could not initialize class org.jboss.ejb.client.DeploymentNodeSelector when building with JDK-9
Key: WFLY-9069
URL: https://issues.jboss.org/browse/WFLY-9069
Project: WildFly
Issue Type: Bug
Components: EJB
Reporter: Amos Feng
{noformat}
testRejectionsEAP620(org.jboss.as.ejb3.subsystem.Ejb3TransformersTestCase) Time elapsed: 2.786 sec <<< ERROR!
java.lang.IncompatibleClassChangeError: Inconsistent constant pool data in classfile for class org/jboss/ejb/client/DeploymentNodeSelector. Method lambda$static$1([Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; at index 109 is CONSTANT_MethodRef and should be CONSTANT_InterfaceMethodRef
at org.jboss.ejb.client.DeploymentNodeSelector.<clinit>(DeploymentNodeSelector.java:83)
at org.jboss.ejb.client.EJBClientContext$Builder.<init>(EJBClientContext.java:538)
at org.jboss.as.ejb3.subsystem.EJB3Subsystem50Parser.parseProfile(EJB3Subsystem50Parser.java:218)
at org.jboss.as.ejb3.subsystem.EJB3Subsystem30Parser.parseProfiles(EJB3Subsystem30Parser.java:215)
at org.jboss.as.ejb3.subsystem.EJB3Subsystem40Parser.parseRemote(EJB3Subsystem40Parser.java:116)
at org.jboss.as.ejb3.subsystem.EJB3Subsystem12Parser.readElement(EJB3Subsystem12Parser.java:135)
at org.jboss.as.ejb3.subsystem.EJB3Subsystem13Parser.readElement(EJB3Subsystem13Parser.java:66)
at org.jboss.as.ejb3.subsystem.EJB3Subsystem14Parser.readElement(EJB3Subsystem14Parser.java:58)
at org.jboss.as.ejb3.subsystem.EJB3Subsystem20Parser.readElement(EJB3Subsystem20Parser.java:69)
at org.jboss.as.ejb3.subsystem.EJB3Subsystem30Parser.readElement(EJB3Subsystem30Parser.java:77)
at org.jboss.as.ejb3.subsystem.EJB3Subsystem50Parser.readElement(EJB3Subsystem50Parser.java:88)
at org.jboss.as.ejb3.subsystem.EJB3Subsystem12Parser.readElement(EJB3Subsystem12Parser.java:104)
at org.jboss.as.ejb3.subsystem.EJB3Subsystem12Parser.readElement(EJB3Subsystem12Parser.java:71)
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:122)
at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
at org.jboss.as.subsystem.test.TestParser.readElement(TestParser.java:103)
at org.jboss.as.subsystem.test.TestParser.readElement(TestParser.java:51)
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:122)
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:76)
at org.jboss.as.subsystem.test.SubsystemTestDelegate.parse(SubsystemTestDelegate.java:223)
at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.parse(SubsystemTestDelegate.java:611)
at org.jboss.as.model.test.ModelTestBootOperationsBuilder.internalSetSubsystemXml(ModelTestBootOperationsBuilder.java:76)
at org.jboss.as.model.test.ModelTestBootOperationsBuilder.setXmlResource(ModelTestBootOperationsBuilder.java:55)
at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.parseXmlResource(SubsystemTestDelegate.java:624)
at org.jboss.as.ejb3.subsystem.Ejb3TransformersTestCase.testRejections(Ejb3TransformersTestCase.java:174)
at org.jboss.as.ejb3.subsystem.Ejb3TransformersTestCase.testRejectionsEAP620(Ejb3TransformersTestCase.java:138)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months