August 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3774) CDI bean with StereoType is not injectable in implicit bean archive

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/WFLY-3774?page=com.atlassian.jira.plugin.... ] Jozef Hartinger resolved WFLY-3774. ----------------------------------- Resolution: Cannot Reproduce Bug WildFly 8.1.0.Final only supports CDI 1.1. For CDI 1.2 support you'll have to build either the master or 8.x branch. I tried your reproducer on both and got a clean test run. Feel free to reopen if you are still able to reproduce the problem on master or 8.x > CDI bean with StereoType is not injectable in implicit bean archive > ------------------------------------------------------------------- > > Key: WFLY-3774 > URL: https://issues.jboss.org/browse/WFLY-3774 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.1.0.Final > Reporter: Takayoshi Kimura > Assignee: Jozef Hartinger > Attachments: stereotype.zip > > > CDI 1.2 defines bean defining annotations and with beans with these annotations should be injectable. However a bean with StereoType, one of bean defining annotations, is not injectable within implicit bean archive on WildFly. > Attached a simple war project to reproduce this problem. This works on GlassFish 4 but doesn't work on WildFly 8.1.0 nor WildFly 9 master at this time. Making this an explicit bean archive by adding empty beans.xml (or set bean-discovery-mode=all) fixes the problem, the container recognizes the CDI bean correctly. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-85) Suppress all warnings in generated sources

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-85?page=com.atlassian.jira.plugin... ] David Lloyd commented on LOGTOOL-85: ------------------------------------ I'd rather not do this. The warnings may indicate real bugs. The processor should be cloning generic types, avoiding this type of warnings at least. > Suppress all warnings in generated sources > ------------------------------------------ > > Key: LOGTOOL-85 > URL: https://issues.jboss.org/browse/LOGTOOL-85 > Project: Log Tool > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 1.2.0.Final > Reporter: Vlad Arkhipov > Assignee: James Perkins > > Generated logger/messages implementaions may cause the compiler to emit warnings (for example, if your interface method has generic parameters). It will be a problem if you compile with -Xlint:all -Werror flags. > I suppose there is no real reason to make the processor honour generics, and these warnings can be safely ignored? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-85) Suppress all warnings in generated sources

by Vlad Arkhipov (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-85?page=com.atlassian.jira.plugin... ] Vlad Arkhipov updated LOGTOOL-85: --------------------------------- Git Pull Request: https://github.com/jboss-logging/jboss-logging-tools/pull/18 > Suppress all warnings in generated sources > ------------------------------------------ > > Key: LOGTOOL-85 > URL: https://issues.jboss.org/browse/LOGTOOL-85 > Project: Log Tool > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 1.2.0.Final > Reporter: Vlad Arkhipov > Assignee: James Perkins > > Generated logger/messages implementaions may cause the compiler to emit warnings (for example, if your interface method has generic parameters). It will be a problem if you compile with -Xlint:all -Werror flags. > I suppose there is no real reason to make the processor honour generics, and these warnings can be safely ignored? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3774) CDI bean with StereoType is not injectable in implicit bean archive

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/WFLY-3774?page=com.atlassian.jira.plugin.... ] Jozef Hartinger reassigned WFLY-3774: ------------------------------------- Assignee: Jozef Hartinger (was: Stuart Douglas) > CDI bean with StereoType is not injectable in implicit bean archive > ------------------------------------------------------------------- > > Key: WFLY-3774 > URL: https://issues.jboss.org/browse/WFLY-3774 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.1.0.Final > Reporter: Takayoshi Kimura > Assignee: Jozef Hartinger > Attachments: stereotype.zip > > > CDI 1.2 defines bean defining annotations and with beans with these annotations should be injectable. However a bean with StereoType, one of bean defining annotations, is not injectable within implicit bean archive on WildFly. > Attached a simple war project to reproduce this problem. This works on GlassFish 4 but doesn't work on WildFly 8.1.0 nor WildFly 9 master at this time. Making this an explicit bean archive by adding empty beans.xml (or set bean-discovery-mode=all) fixes the problem, the container recognizes the CDI bean correctly. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-85) Suppress all warnings in generated sources

by Vlad Arkhipov (JIRA)

Vlad Arkhipov created LOGTOOL-85: ------------------------------------ Summary: Suppress all warnings in generated sources Key: LOGTOOL-85 URL: https://issues.jboss.org/browse/LOGTOOL-85 Project: Log Tool Issue Type: Enhancement Security Level: Public (Everyone can see) Affects Versions: 1.2.0.Final Reporter: Vlad Arkhipov Assignee: James Perkins Generated logger/messages implementaions may cause the compiler to emit warnings (for example, if your interface method has generic parameters). It will be a problem if you compile with -Xlint:all -Werror flags. I suppose there is no real reason to make the processor honour generics, and these warnings can be safely ignored? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-583) Drools WB jcr2vfs: make the migration tool work again

by Petr Široký (JIRA)

Petr Široký created DROOLS-583: ---------------------------------- Summary: Drools WB jcr2vfs: make the migration tool work again Key: DROOLS-583 URL: https://issues.jboss.org/browse/DROOLS-583 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.2.0.Beta1 Reporter: Petr Široký Assignee: Petr Široký The current 6.2.0 SNAPSHOTS of the jcr2vfs tool are broken. There seems to some issue with incompatibility with between Drools 5.x and 6.x. {code} Asset [Bankruptcy history] with format [brl] is being migrated... java.lang.ClassCastException: org.drools.core.base.accumulators.BigDecimalSumAccumulateFunction cannot be cast to org.drools.runtime.rule.AccumulateFunction at org.drools.compiler.PackageBuilderConfiguration.loadAccumulateFunction(PackageBuilderConfiguration.java:530) at org.drools.compiler.PackageBuilderConfiguration.buildAccumulateFunctionsMap(PackageBuilderConfiguration.java:479) at org.drools.compiler.PackageBuilderConfiguration.init(PackageBuilderConfiguration.java:194) at org.drools.compiler.PackageBuilderConfiguration.<init>(PackageBuilderConfiguration.java:165) {code} Another very serious issue is that even when the jcr2vfs tests fail, the Jenkins drools-wb CI build succeeds. This needs to be fixed, so that when the tests fail, the build fails too. I will try to fix the tool in time for 6.2.0.Final. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2770) CDI Decorator should be enable on Websocket enpoint

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/WFLY-2770?page=com.atlassian.jira.plugin.... ] Jozef Hartinger commented on WFLY-2770: --------------------------------------- Plus if the bean is not enabled for some reason (e.g. an alternative or specialized) we should not probably be applying decorators to it? > CDI Decorator should be enable on Websocket enpoint > ---------------------------------------------------- > > Key: WFLY-2770 > URL: https://issues.jboss.org/browse/WFLY-2770 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: CDI / Weld, Web (Undertow) > Affects Versions: 8.0.0.CR1 > Reporter: Antoine Sabot-Durand > Assignee: Stuart Douglas > Attachments: websocket-decorator.zip > > > Defining a CDI decorator on Websocket Endpoint doesn't work. I know it's not strictly required by websocket spec (it only mentions interceptors) but as it's working in Glassfish 4, it could be nice and less confusing to add this feature to Wildfly -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2770) CDI Decorator should be enable on Websocket enpoint

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/WFLY-2770?page=com.atlassian.jira.plugin.... ] Jozef Hartinger commented on WFLY-2770: --------------------------------------- You may end up using Bean object for a subclass of the component class. > CDI Decorator should be enable on Websocket enpoint > ---------------------------------------------------- > > Key: WFLY-2770 > URL: https://issues.jboss.org/browse/WFLY-2770 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: CDI / Weld, Web (Undertow) > Affects Versions: 8.0.0.CR1 > Reporter: Antoine Sabot-Durand > Assignee: Stuart Douglas > Attachments: websocket-decorator.zip > > > Defining a CDI decorator on Websocket Endpoint doesn't work. I know it's not strictly required by websocket spec (it only mentions interceptors) but as it's working in Glassfish 4, it could be nice and less confusing to add this feature to Wildfly -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3779) IllegalAccessException when a built-in normal-scoped bean defines a package-private no-arg constructor

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/WFLY-3779?page=com.atlassian.jira.plugin.... ] Jozef Hartinger updated WFLY-3779: ---------------------------------- Fix Version/s: 8.2.0.CR1 9.0.0.Beta1 > IllegalAccessException when a built-in normal-scoped bean defines a package-private no-arg constructor > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-3779 > URL: https://issues.jboss.org/browse/WFLY-3779 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Reporter: Jozef Hartinger > Assignee: Jozef Hartinger > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3711) Topology updates of EJBClient ClusterContexts not being processed correctly after failover

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-3711?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on WFLY-3711: ------------------------------------------- There were three problems described here: - cluster contexts not getting closed on client - unnecessary ClusterNodeManagers being created as a result of cluster topology updates - no differentiation between cluster topology message types The first issue is addressed by the PR attached to this issue (6643) The second problem is addressed by EJBCLIENT-110. The third issue is one which requires protocol changes, and it may be that such changes are not absolutely necessary. Cluster topology updates arriving at an EJBCLient may be sent directly, and contain full cluster topologies, or via gossip, and contain only changes to the cluster topology. Direct receipt examples include when a node joins a cluster and the node immediately sends a full cluster topology update to the client, if it is connected. Another example is when a client connects to a node: a full topology update is again sent at that time to the client. On the other hand, indirect or gossip information is received from members of the same cluster who just note which (other) nodes have just joined or left the cluster; in other words, the changes or delta of the topology.. Despite the fact that delta updates and complete topology updates are not differentiated (and they almost certainly should be), it looks very much as though the current implementation will eventually end up with the same ClusterContext membership. > Topology updates of EJBClient ClusterContexts not being processed correctly after failover > ------------------------------------------------------------------------------------------ > > Key: WFLY-3711 > URL: https://issues.jboss.org/browse/WFLY-3711 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 9.0.0.Beta1 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > > ClusterContexts are used by EJBClient to keep track of the current set of nodes in a cluster, so that if an EJBClient invocation fails on one node, it may failover to another node in the same cluster. The ClusterContext is made up of ClusterNodeManagers which are responsible for setting up the connections between the EJBClient and the nodes in the cluster. > Cluster topology updates are sent to registered EJBClients whenever the cluster topology changes (nodes join, nodes leave a cluster). Thse topology updates are processed on the client side by ClusterTopologyUpdateHandler and are used to update the current contents of the associated ClusterContext held on the client. > The current implementation of the handling of topology updates does not correctly handle the addition/removal of ClusterNodeManagers from the cluster context - namely, rather than check whether or not a new ClusterNodeManager really needs to be added, ClusterNodeManagers are added for every node in the received topology update, leading to many unnecessary EJBReceivers and their channels being created. > The logs show that up to 18 cluster node manager instances may be created, have their EJBReceivers registered and channels to the remote node created, when only one node has been added to the cluster. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2014