[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 updated WFLY-3774:
----------------------------------
Fix Version/s: 8.2.0.CR1
{quote}Sorry I wasn't clear on that point. CDI 1.2 clearly listed what is injectable, but it also applies to CDI 1.1. This behavior is nothing changed between versions, it just got clearer definistion.{quote}
You are wrong. @Stereotypes being recognized as bean defining annotations is a new feature of CDI 1.2 - see e.g. http://www.cdi-spec.org/news/2014/04/14/CDI-1_2-released/
More precisely, in CDI 1.1, only scope annotations are considered bean defining annotations:
http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_defining_annotations
In CDI 1.2 this was extended to cover @Stereotypes and some other annotations:
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_defining_annotations
> 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
> Fix For: 8.2.0.CR1, 9.0.0.Beta1
>
> Attachments: logs.zip, 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, 3 months
[JBoss JIRA] (WFLY-1119) Assign an unique NodeID automatically
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-1119?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-1119:
------------------------------
Component/s: Transactions
(was: JMS)
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: WFLY-1119
> URL: https://issues.jboss.org/browse/WFLY-1119
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Transactions
> Reporter: Clebert Suconic
> Assignee: Jeff Mesnil
> Priority: Optional
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (WFCORE-29) IllegalStateException when patching MBeans are queried during shutdown
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-29?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFCORE-29:
-----------------------------------------------
Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1120535|https://bugzilla.redhat.com/show_bug.cgi?id=1120535] from ON_QA to VERIFIED
> IllegalStateException when patching MBeans are queried during shutdown
> ----------------------------------------------------------------------
>
> Key: WFCORE-29
> URL: https://issues.jboss.org/browse/WFCORE-29
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management, Patching
> Reporter: James Livingston
> Assignee: Emanuel Muckenhuber
> Attachments: shutdownmbeanquery.jar
>
>
> If the MBeans for the patching subsystem are queried during server shutdown, it can result in an IllegalStateException. InstallationManagerService has already had stop() called on it, so the value is null.
> This can be reproduced by the attached EJB, which does a MBeanServer.queryMBeans(null, null); from the @PreDestroy method. It's in a loop to ensure it runs after the installation manager gets de-initialised.
> java.lang.IllegalStateException
> at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:87) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:28) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.children(PatchResource.java:139) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.hasChildren(PatchResource.java:134) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.registry.AbstractModelResource.hasChildren(AbstractModelResource.java:81) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.hasChildren(AbstractModelResource.java:279) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:57) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:43) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.ModelControllerMBeanHelper.queryMBeans(ModelControllerMBeanHelper.java:125) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.queryMBeans(ModelControllerMBeanServerPlugin.java:159) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.queryMBeans(PluggableMBeanServerImpl.java:816) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at example.ShutdownMBeanQuery.destroy(ShutdownMBeanQuery.java:23)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (SECURITY-640) Jboss Negotiation fallback to login page if NTLM token is received or the user is not present in active directory.
by Hrishi Salvi (JIRA)
[ https://issues.jboss.org/browse/SECURITY-640?page=com.atlassian.jira.plug... ]
Hrishi Salvi closed SECURITY-640.
---------------------------------
Thank you..
> Jboss Negotiation fallback to login page if NTLM token is received or the user is not present in active directory.
> ------------------------------------------------------------------------------------------------------------------
>
> Key: SECURITY-640
> URL: https://issues.jboss.org/browse/SECURITY-640
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Environment: Active Directory Winwos 2003, Client Machine windows XP, Jboss Server Machine Window XP and Jboss 6.1
> Reporter: Hrishi Salvi
> Assignee: Derek Horton
> Fix For: Negotiation_2_2_8, Negotiation_2_3_0_CR2
>
>
> We are trying to configure the single sign on using jboss negotiation.
> We are able to login successfully if the user is present in active directory.
> But in case if user is not present in active directory users, it throw 401 error page.
> Instead of 401 we want user to access login form and authenticate user using different login module.
> In our case we have login page we authenticate user on that page.
> If we receive user credentials we login the user without asking for password.
> Now if the user credentials are not received then we want user to open login form present
> on login page, but before that is throws 401 error.
> We have configure the login-config.xml, web.xml and jboss-web.xml as per the documentation.
> Also defined
> <web-resource-collection>
> <web-resource-name>Restricted</web-resource-name>
> <url-pattern>/Request</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> in web.xml
> Our application is access through Request servlet.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (WFLY-3799) Wrong WildFly version when WildFly standalone is started
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-3799?page=com.atlassian.jira.plugin.... ]
Thomas Diesler updated WFLY-3799:
---------------------------------
Assignee: (was: Thomas Diesler)
Component/s: Server
(was: ConfigAdmin)
> Wrong WildFly version when WildFly standalone is started
> --------------------------------------------------------
>
> Key: WFLY-3799
> URL: https://issues.jboss.org/browse/WFLY-3799
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 9.0.0.Beta1
> Reporter: Juergen Zimmermann
>
> I compiled the WildFly snapshot from GitHub. When I start WildFly standalone, then I see this final log message with the version number from WildFly Core:
> {code}
> INFO [org.jboss.as] WFLYSRV0025: WildFly 1.0.0.Alpha5 "Kenny" started in 2454ms - Started 216 of 319 services (143 services are lazy, passive or on-demand)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (JGRP-1875) UNICAST3/UNICAST2: sync receiver table with sender table
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1875?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1875 at 9/1/14 2:22 AM:
--------------------------------------------------------
We don't need the last {{SYNC-ACK}} message: this is only used to tell the sender to accept {{ACK}} msgss again, but when a sender receives a {{SYNC}} message, it changes its {{conn-id}} which automatically drops all messages from a receiver anyway !
The complete design document is here: https://github.com/belaban/JGroups/blob/master/doc/design/UNICAST3-SYNC.txt
was (Author: belaban):
We don't need the last {{SYNC-ACK}} message: this is only used to tell the sender to accept {{ACK}} msgss again, but when a sender receives a {{SYNC}} mesage, it changes its {{conn-id}} which automatically drops all messages from a receiver anyway !
The complete design document is here: https://github.com/belaban/JGroups/blob/master/doc/design/UNICAST3-SYNC.txt
> UNICAST3/UNICAST2: sync receiver table with sender table
> --------------------------------------------------------
>
> Key: JGRP-1875
> URL: https://issues.jboss.org/browse/JGRP-1875
> Project: JGroups
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6
>
>
> If a receiver B closes its recv-table and the sender A doesn't, then (when receiving msgs from the sender) the receiver engages in a protocol using {{GET-FIRST-SEQNO}} to sync itself with the sender. This has several problems, detailed in JGRP-1873 and JGRP-1874. (Note that the other way round (sender closing send-table), there is no issue, as the sender will create a new connection with a new {{conn-id}}).
> To prevent {{STABLE}} messages interfering with {{GET-FIRST-SEQNO}} messages (JGRP-1873), we could run an additional {{SYNC}} protocol round, e.g.
> * B needs to get the lowest and highest seqno sent from A
> * B sends a {{SYNC}} message to A (instead of a {{GET-FIRST-SEQNO}} message)
> * B sets a flag that discards all {{STABLE}} or {{ACK}} messages on reception of {{SYNC}}
> * B replies with a {{SYNC-OK}} containing the _lowest_ and _highest_ sent seqnos
> * B creates an entry for A with the lowest and highest seqnos
> * B sends a {{SYNC-ACK}} to A
> * A resets the flag and starts accepting {{STABLE}} / {{ACK}} messages from B again
> * A and B now use the usual protocols to retransmit missing messages
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (JGRP-1875) UNICAST3/UNICAST2: sync receiver table with sender table
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1875?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1875 at 9/1/14 2:22 AM:
--------------------------------------------------------
We don't need the last {{SYNC-ACK}} message: this is only used to tell the sender to accept {{ACK}} msgss again, but when a sender receives a {{SYNC}} mesage, it changes its {{conn-id}} which automatically drops all messages from a receiver anyway !
The complete design document is here: https://github.com/belaban/JGroups/blob/master/doc/design/UNICAST3-SYNC.txt
was (Author: belaban):
We don't need the last {{SYNC-ACK}} message: this is only used to tell the sender to accept {{ACK}}s again, but when a sender receives a {{SYNC}} mesage, it changes its {{conn-id}} which automatically drops all messages from a receiver anyway !
The complete design document is here: https://github.com/belaban/JGroups/blob/master/doc/design/UNICAST3-SYNC.txt
> UNICAST3/UNICAST2: sync receiver table with sender table
> --------------------------------------------------------
>
> Key: JGRP-1875
> URL: https://issues.jboss.org/browse/JGRP-1875
> Project: JGroups
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6
>
>
> If a receiver B closes its recv-table and the sender A doesn't, then (when receiving msgs from the sender) the receiver engages in a protocol using {{GET-FIRST-SEQNO}} to sync itself with the sender. This has several problems, detailed in JGRP-1873 and JGRP-1874. (Note that the other way round (sender closing send-table), there is no issue, as the sender will create a new connection with a new {{conn-id}}).
> To prevent {{STABLE}} messages interfering with {{GET-FIRST-SEQNO}} messages (JGRP-1873), we could run an additional {{SYNC}} protocol round, e.g.
> * B needs to get the lowest and highest seqno sent from A
> * B sends a {{SYNC}} message to A (instead of a {{GET-FIRST-SEQNO}} message)
> * B sets a flag that discards all {{STABLE}} or {{ACK}} messages on reception of {{SYNC}}
> * B replies with a {{SYNC-OK}} containing the _lowest_ and _highest_ sent seqnos
> * B creates an entry for A with the lowest and highest seqnos
> * B sends a {{SYNC-ACK}} to A
> * A resets the flag and starts accepting {{STABLE}} / {{ACK}} messages from B again
> * A and B now use the usual protocols to retransmit missing messages
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months