[JBoss JIRA] (WFCORE-3183) Unable to connect jboss-cli.sh using GS2-KRB5-PLUS
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3183?page=com.atlassian.jira.plugi... ]
Jan Kalina reopened WFCORE-3183:
--------------------------------
> Unable to connect jboss-cli.sh using GS2-KRB5-PLUS
> --------------------------------------------------
>
> Key: WFCORE-3183
> URL: https://issues.jboss.org/browse/WFCORE-3183
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta31
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> I am unable to connect with jboss-cli.sh using GS2-KRB5-PLUS. This is not duplicity to JBEAP-12688. In this case even SASL client is not created.
> In server.log I see
> {code}
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Initialized connection from /127.0.0.1:37230 to /127.0.0.1:9993 with options {org.jboss.remoting3.RemotingOptions.SASL_PROTOCOL=>remote}
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Accepted connection from /127.0.0.1:37230 to localhost.localdomain/127.0.0.1:9993
> 17:25:10,564 TRACE [org.jboss.remoting.remote] (management I/O-2) Setting read listener to org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@2cb6a081
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,565 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 28 bytes
> 17:25:10,565 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 17:25:10,576 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,577 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,577 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 56 bytes
> 17:25:10,577 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=52 cap=8192]
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=52 cap=8192]
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "cli-client"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.0.CR5-redhat-1"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service
> 17:25:10,580 TRACE [org.jboss.remoting.remote.server] (management I/O-2) No EXTERNAL mechanism due to unverified SSL peer
> 17:25:10,583 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism GS2-KRB5-PLUS
> 17:25:10,583 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism PLAIN
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 88 bytes
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,638 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,638 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,638 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received EOF
> 17:25:10,638 TRACE [org.jboss.remoting.remote] (management I/O-2) Received connection end-of-stream
> 17:25:10,971 INFO [org.jboss.eapqe.krbldap.utils.CustomCLIExecutor] (main) CLI executor output:
> 17:25:10,971 INFO [org.jboss.eapqe.krbldap.utils.CustomCLIExecutor] (main) Failed to connect to the controller: Unable to authenticate against controller at localhost.localdomain:9993: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> {code}
> In jboss-cli.log I see.
> {code}
> 17:14:21,557 TRACE [org.wildfly.security] Created SaslClient [null] for mechanisms [GS2-KRB5-PLUS]
> 17:14:21,557 TRACE [org.jboss.remoting.remote.connection] Connection error detail: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:438)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> 17:14:21,558 DEBUG [org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> 17:14:21,559 TRACE [org.jboss.remoting.endpoint] Registered exception result: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:438)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (DROOLS-1704) NPE when updating container with java class
by Karel Suta (JIRA)
Karel Suta created DROOLS-1704:
----------------------------------
Summary: NPE when updating container with java class
Key: DROOLS-1704
URL: https://issues.jboss.org/browse/DROOLS-1704
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 7.2.0.Final
Reporter: Karel Suta
Assignee: Edson Tirelli
Attachments: stacktrace.txt
User has Kie server with deployed container with java class.
If user updates the container to new version with kjar without java class then it is updated correctly. However if user then tries to update the container again, this time to version which contains same java class then NullPointerException is thrown. See attachment.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JGRP-2061) TYPE_STRING does not handle unicode
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2061?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2061:
--------------------------------
I think this has been fixed (but I forgot to close the issue):
{code:java}
case TYPE_STRING:
String str=(String)obj;
if(Util.isAsciiString(str)) {
int len=str.length();
ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING);
for(int i=0; i < len; i++)
retval.put((byte)str.charAt(i));
return retval.array();
}
else {
ByteArrayDataOutputStream out=new ByteArrayDataOutputStream(str.length()*2 +3);
out.write(TYPE_UTF_STRING);
out.writeUTF(str);
byte[] ret=new byte[out.position()];
System.arraycopy(out.buffer(), 0, ret, 0, ret.length);
return ret;
}
{code}
Can you confirm this?
> TYPE_STRING does not handle unicode
> -----------------------------------
>
> Key: JGRP-2061
> URL: https://issues.jboss.org/browse/JGRP-2061
> Project: JGroups
> Issue Type: Bug
> Reporter: Cody Ebberson
> Assignee: Bela Ban
> Fix For: 4.0.6
>
>
> In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character.
> For example, see objectToByteBuffer lines 561-567:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util....
> {{
> case TYPE_STRING:
> String str=(String)obj;
> int len=str.length();
> ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING);
> for(int i=0; i < len; i++)
> retval.put((byte)str.charAt(i));
> return retval.array();
> }}
> This code will incorrectly encode any String with non ASCII encoding.
> There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JGRP-2211) UUID not serializable
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2211?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-2211.
--------------------------
Fix Version/s: 4.0.6
Resolution: Won't Do
As discussed, I removed Serializable from addresses. The attached program shows how to use addresses as keys in user data.
> UUID not serializable
> ---------------------
>
> Key: JGRP-2211
> URL: https://issues.jboss.org/browse/JGRP-2211
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.5
> Reporter: Chris LastName
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0.6
>
>
> Caused by: java.lang.RuntimeException: java.io.NotSerializableException: org.jgroups.util.UUID
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:574)
> at org.jgroups.JChannel.up(JChannel.java:797)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:891)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.getStateFromApplication(STATE_TRANSFER.java:328)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.handleStateReq(STATE_TRANSFER.java:313)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.handle(STATE_TRANSFER.java:284)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.handle(STATE_TRANSFER.java:31)
> at org.jgroups.util.ProcessingQueue.process(ProcessingQueue.java:54)
> at org.jgroups.util.ProcessingQueue.add(ProcessingQueue.java:35)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:132)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:177)
> ...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JGRP-2209) Members leaving the cluster
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2209?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-2209.
--------------------------
Resolution: Out of Date
Hi Swathi,
as discussed on the call, the findings/suggestions were:
* UNICAST3 was missing from the config, use FD_ALL/FD_SOCK
* Old config: use the XML config {{tcp.xml}} shipped with the version of JGroups you use and make modifications to it
* Switch to XML-style config
* Upgrade to the latest 3.4.x, certainly not an alpha version!
* Even better: switch to 3.6.x if you can
I'm closing this issue. We can always create an issue if a bug is found.
Cheers
> Members leaving the cluster
> ---------------------------
>
> Key: JGRP-2209
> URL: https://issues.jboss.org/browse/JGRP-2209
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.0
> Environment: Linux
> Reporter: Swathi Kumar
> Assignee: Bela Ban
>
> We recently upgraded the jgroups jars from version 2_5_2/jgroups-all.jar to 3_4_0/jgroups-3.4.0.Alpha2.jar.
> With the upgrade we see our clusters are not stable.
> The members leave the cluster for short duration of time (say around 5-6m) and join back on their own.
> We initially suspected it to be a network issue and we involved the network team to investiate further.
> But after reviewing the network logs, it is very much evident that the network has no role to play in members leaving the cluster. The boxes on which the nodes/members are running are healthy and fine and the network is very fast and healthy too.
> We are not able to determine the root cause for the members leaving the clusters.
> Please note, we have multiple clusters configured (round about 5-6) and we are experiencing the same problem on all the clusters.
> We request you to kindly help us in resolving this issue.
> We have the below jgroups config properties in our application to create 3 channels (for security reasons have used a dummy host name here) :-
> jgroups_cluster.property_string=TCP(bind_addr=host_name_A;bind_port=34061):TCPPING(initial_hosts=host_name_A[34061],host_name_A[44061],host_name_A[54061];port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_ALL(interval=5000;timeout=20000):FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=100,200,300,600,1200,2400,4800;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(print_local_addr=true;join_timeout=5000)
> jgroups_cluster.distribution_property_string=TCP(bind_port= 34060;thread_pool_rejection_policy=run):TCPPING(initial_hosts=host_name_A[34060],host_name_A[44060],host_name_A[54060];port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_SOCK:FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=3000;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(join_timeout=5000;print_local_addr=true)
> jgroups_cluster.lock.protocolStack=TCP(bind_addr=host_name_A;bind_port=34062:TCPPING(initial_hosts=host_name_A[34062],host_name_A[44062],host_name_A[54062];port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_ALL(interval=5000;timeout=20000):FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=100,200,300,600,1200,2400,4800;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(print_local_addr=true;join_timeout=5000)
> Please let us know if you need any logs from our end.
> Kindly consider this on priority as our business is at stake with this issue happening on a daily basis.
> Many thanks in advance.
> Regards
> Swathi BN
> (IBM)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JGRP-2197) Merge doesn't work properly
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2197?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-2197.
--------------------------
Resolution: Won't Fix
Please re-open if you can reproduce this with the latest stable 3.6.x release
> Merge doesn't work properly
> ---------------------------
>
> Key: JGRP-2197
> URL: https://issues.jboss.org/browse/JGRP-2197
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Allen Zhao
> Assignee: Bela Ban
> Priority: Critical
> Attachments: MergeTest.java, jgroups.log, jgroupsConfig.xml
>
>
> Using the attached jGroups configuration file and sample code based on the Draw example, run two MergeTest instances alanz-dev-54589 and alanz-dev-53593 on one machine, and another instance , AllenMAC-4773 on the second machine; both machines are in the same network connected by a cable.
> Initially all three instances are in the same group, then unplug the cable from the second machine, two groups formed as expected:
> group1: alanz-dev-54589 and alanz-dev-53593
> group2: AllenMAC-4773
> Then plug the cable into the second machine again, the groups merged into one group with all the three members.
> These are good as expected. Keeping doing these by unplug/plug the cable into the second machine, it took around 5 times until the following happened, which is unexpected:
> when AllenMAC-4773 merged into the group composed by alanz-dev-54589 and alanz-dev-53593, it kicked alanz-dev-54589 out, and the two groups formed: MergeView::[alanz-dev-53593|14] (2) [alanz-dev-53593, AllenMAC-4773], and alanz-dev-54589 formed a group by itself.
> Please see the sample code output from the two instances run on the first machine as follows:
> ==============alanz-dev-54589===================
> -------------------------------------------------------------------
> GMS: address=alanz-dev-54589, cluster=draw-cluster, physical address=fe80:0:0:0:1c97:64f4:50a0:20b0%11:63608
> -------------------------------------------------------------------
> ** View=[alanz-dev-54589|0] (1) [alanz-dev-54589]
> ** View=[alanz-dev-54589|1] (2) [alanz-dev-54589, AllenMAC-4773]
> ** View=[alanz-dev-54589|2] (3) [alanz-dev-54589, AllenMAC-4773, alanz-dev-53593]
> ** View=[alanz-dev-54589|3] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|4] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|3] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|3] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|5] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|6] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|5] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|5] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|7] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|8] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|7] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|7] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|9] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|10] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|9] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|9] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|11] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|12] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|11] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|11] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|13] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-53593|15] (3) [alanz-dev-53593, AllenMAC-4773, alanz-dev-54589], 2 subgroups: [alanz-dev-53593|14] (2) [alanz-dev-53593, AllenMAC-4773], [alanz-dev-54589|13] (1) [alanz-dev-54589]
> ================alanz-dev-53593=======================
> ---------------------------------------------------------------------
> GMS: address=alanz-dev-53593, cluster=draw-cluster, physical address=fe80:0:0:0:1c97:64f4:50a0:20b0%11:63610
> -------------------------------------------------------------------
> ** View=[alanz-dev-54589|2] (3) [alanz-dev-54589, AllenMAC-4773, alanz-dev-53593]
> ** View=[alanz-dev-54589|3] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|4] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|3] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|3] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|5] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|6] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|5] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|5] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|7] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|8] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|7] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|7] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|9] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|10] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|9] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|9] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|11] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-54589|12] (3) [alanz-dev-54589, alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|11] (2) [alanz-dev-54589, alanz-dev-53593], [AllenMAC-4773|11] (1) [AllenMAC-4773]
> ** View=[alanz-dev-54589|13] (2) [alanz-dev-54589, alanz-dev-53593]
> ** MergeView::[alanz-dev-53593|14] (2) [alanz-dev-53593, AllenMAC-4773], 2 subgroups: [alanz-dev-54589|13] (1) [alanz-dev-53593], [AllenMAC-4773|13] (1) [AllenMAC-4773]
> ** MergeView::[alanz-dev-53593|15] (3) [alanz-dev-53593, AllenMAC-4773, alanz-dev-54589], 2 subgroups: [alanz-dev-53593|14] (2) [alanz-dev-53593, AllenMAC-4773], [alanz-dev-54589|13] (1) [alanz-dev-54589]
> The issue happened in our system which uses jGroups for data replication. I turned on all jGroups log, and got some useful log information as the attached. It seems that at some point, a merge request from AllenMAC-4773 was received by alanz-dev-53593, and in that message, mbrs only contained alanz-dev-53593.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9235) @Resource injection does not fail in a servlet when the resource is missing
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9235?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-9235.
----------------------------------
Resolution: Rejected
This is allowed for simple env entries:
EE.5.4.1.3
....
It’s often convenient to declare a field or method as an injection target, but
specify a default value in the code, as illustrated in the following example.
// The maximum number of tax exemptions, configured by the Deployer.
@Resource int maxExemptions = 4; // defaults to 4
To support this case, the container must only inject a value for this resource if
the deployer has specified a value to override the default value.
.....
> @Resource injection does not fail in a servlet when the resource is missing
> ---------------------------------------------------------------------------
>
> Key: WFLY-9235
> URL: https://issues.jboss.org/browse/WFLY-9235
> Project: WildFly
> Issue Type: Bug
> Components: Naming, Web (Undertow)
> Reporter: Stephen Coy
> Assignee: Stuart Douglas
> Attachments: web45709634.jira.zip
>
>
> The attached web application builds, deploys and runs perfectly.
> However, if you remove one of the <env-entry> elements from the web.xml it will still deploy and run.
> The associated injection point is left as null instead of having the deployment fail as required by the Java EE 7 Spec in "EE.5.2.5 Annotations and Injection", where it states:
> {quote} If the container fails to find a resource needed for injection, initialization of the class must fail, and the class must not be put into service.{quote}
> Also see StackOverflow question https://stackoverflow.com/questions/45716813/glassfish-wildfly-not-failin...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months