[JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3 buckets created in Frankfurt region
by Thorsten Hoeger (JIRA)
[ https://issues.jboss.org/browse/JGRP-1914?page=com.atlassian.jira.plugin.... ]
Thorsten Hoeger commented on JGRP-1914:
---------------------------------------
Is there any chance that IAMProfileAuth will be included as well? When running instances in AWS it is best to assign IAM roles with access to the bucket, but JGroups ignores this.
> S3_PING doesn't work with S3 buckets created in Frankfurt region
> -----------------------------------------------------------------
>
> Key: JGRP-1914
> URL: https://issues.jboss.org/browse/JGRP-1914
> Project: JGroups
> Issue Type: Bug
> Reporter: Gleb Leonov
> Assignee: Bela Ban
> Fix For: 3.6.3
>
>
> I tried to use S3_PING with access and secret key pair. However, I got 400 (Bad Request) error. After some investigation, I found that modern S3 buckets created in Frankfurt needs amazon v4 authentication, which needs hmac-sha256. But now S3_PING supports only hmac-sha1, so I see no way to use S3_PING with buckets in Frankfurt region.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 8 months
[JBoss JIRA] (WFLY-3988) Authorization denied for authenticated users when @PermitAll is used on EJB JAX-WS endpoint
by Jim Ma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3988?page=com.atlassian.jira.plugin.... ]
Jim Ma reassigned WFLY-3988:
----------------------------
Assignee: Jim Ma (was: Alessio Soldano)
> Authorization denied for authenticated users when @PermitAll is used on EJB JAX-WS endpoint
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-3988
> URL: https://issues.jboss.org/browse/WFLY-3988
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.1.0.Final
> Reporter: Kyle Lape
> Assignee: Jim Ma
>
> Given this endpoint:
> {code:java}
> @Stateless
> @WebService(endpointInterface="com.redhat.gss.SecureEndpoint")
> @DeclareRoles({"a","b"})
> @WebContext(contextRoot="/endpoint",urlPattern="/e",authMethod="BASIC")
> public class SecureEndpointE implements SecureEndpoint {
> @RolesAllowed({"a"})
> public String a() {
> return "Success";
> }
> @RolesAllowed({"b"})
> public String b() {
> return "Success";
> }
> @PermitAll
> public String c() {
> return "Success";
> }
> }
> {code}
> One would expect any authenticated user to be able to invoke {{c()}}, but only users with a role found in {{@DelareRoles}} can invoke it.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 8 months
[JBoss JIRA] (WFLY-4383) Wrong order of elements in appclient.xml
by Panagiotis Sotiropoulos (JIRA)
[ https://issues.jboss.org/browse/WFLY-4383?page=com.atlassian.jira.plugin.... ]
Panagiotis Sotiropoulos resolved WFLY-4383.
-------------------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Done
> Wrong order of elements in appclient.xml
> ------------------------------------------
>
> Key: WFLY-4383
> URL: https://issues.jboss.org/browse/WFLY-4383
> Project: WildFly
> Issue Type: Bug
> Components: Application Client
> Affects Versions: 9.0.0.Alpha1
> Reporter: Panagiotis Sotiropoulos
> Assignee: Panagiotis Sotiropoulos
> Fix For: 9.0.0.Beta1
>
>
> Description of problem:
> File appclient/configuration/appclient.xml has an incorrect order of elements. <core-environment> tag should be before <recovery-environment /> tag. These tags is in <subsystem xmlns="urn:jboss:domain:transactions:1.4"> and schema is in docs/schema/jboss-as-txn_1_4.xsd. This schema defines specific order of elements.
> Version-Release number of selected component (if applicable):
> 6.4.0.ER2
> Validate logs:
> appclient/configuration/appclient.xml:150: element recovery-environment: Schemas validity error : Element '{urn:jboss:domain:transactions:1.4}recovery-environment': This element is not expected. Expected is ( {urn:jboss:domain:transactions:1.4}core-environment ).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 8 months
[JBoss JIRA] (WFCORE-571) Upgrade Aesh to 0.58
by Joe Wertz (JIRA)
Joe Wertz created WFCORE-571:
--------------------------------
Summary: Upgrade Aesh to 0.58
Key: WFCORE-571
URL: https://issues.jboss.org/browse/WFCORE-571
Project: WildFly Core
Issue Type: Component Upgrade
Components: CLI
Reporter: Joe Wertz
Assignee: Joe Wertz
Large upgrade of AESH terminal. Minimal code changes at first with extensive refactoring expected later to utilize the new AESH command processing
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 8 months
[JBoss JIRA] (WFCORE-478) log4j ConsoleAppender won't display messages with per-deployment logging
by Arsalan Masood (JIRA)
[ https://issues.jboss.org/browse/WFCORE-478?page=com.atlassian.jira.plugin... ]
Arsalan Masood commented on WFCORE-478:
---------------------------------------
Is there a workaround for this until a proper fix is available?
> log4j ConsoleAppender won't display messages with per-deployment logging
> ------------------------------------------------------------------------
>
> Key: WFCORE-478
> URL: https://issues.jboss.org/browse/WFCORE-478
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> Add the following log4j.properties file to a deployment and try to log.
> {code}
> # Root logger option
> log4j.rootLogger=INFO, stdout
> # Direct log messages to stdout
> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
> log4j.appender.stdout.Target=System.out
> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
> log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 8 months
[JBoss JIRA] (JGRP-1908) Optional Executing protocol behavior to not attempt to repeat tasks
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1908?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1908.
----------------------------
Resolution: Won't Fix
Please reopen if this is still an issue
> Optional Executing protocol behavior to not attempt to repeat tasks
> -------------------------------------------------------------------
>
> Key: JGRP-1908
> URL: https://issues.jboss.org/browse/JGRP-1908
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Anuj Shah
> Assignee: William Burns
> Labels: executionservice
> Fix For: 3.6.3
>
>
> As discussed on forum:
> http://jgroups.1086181.n5.nabble.com/jgroups-users-ExecutionService-at-le...
> {quote}
> I've noticed that runnable tasks submitted to the ExecutionService can be run more than once!
> This would happen when a member executing the task is suspected and is removed from the cluster. The protocol handles this by resubmitting the request in Executing#handleView. I note the following JavaDoc
> // The person currently servicing our request has gone down
> // without completing so we have to keep our request alive by
> // sending ours back to the coordinator
> The problem is that there is no guarantee that the request was not completed.
> For my application a member executing the task had a absurdly long GC pause (30s) which meant it was temporarily removed from the cluster, when the pause completed it happily continued executing the task which had already been resubmitted and completed. The task in question involves modifying the database and is quite destructive, so you can imagine the fallout.
> I was hoping to get an opinion of if we think this behaviour is correct, especially since we are implementing a standard java,util.concurrent interface. (I couldn't find anything in the ExecutorService JavaDoc to say it is wrong though)
> Perhaps there could be control over the behaviour:
> * At least once - assumes task failed and resubmits
> * At most once - assumes task completed and cleans up - may not actually be complete
> * Exactly once - not sure if this is possible
> {quote}
> There is a simple change to exhibit the at least once behaviour by ignoring consumers that have left. I have the patch in my fork:
> https://github.com/anujshahwork/JGroups/commit/0f2c1f6f9ed57744841acdd192...
> Which my project is using. This can be wrapped in some simple configuration on the protocol to control the behaviour and would be a useful addition.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 8 months
[JBoss JIRA] (JGRP-1918) ConcurrentModificationException in Locking notification
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1918?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1918.
----------------------------
Resolution: Done
Using a copy-on-write set for lock listeners
> ConcurrentModificationException in Locking notification
> -------------------------------------------------------
>
> Key: JGRP-1918
> URL: https://issues.jboss.org/browse/JGRP-1918
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.2
> Environment: JUnit text running in Eclipse on Windows
> Reporter: Paul Illingworth
> Assignee: Bela Ban
> Fix For: 3.6.3
>
>
> I have code which unregisters a lock listener whilst a lock notification event is being fired leading to
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:926)
> at java.util.HashMap$KeyIterator.next(HashMap.java:960)
> at org.jgroups.protocols.Locking.notifyUnlocked(Locking.java:581)
> at org.jgroups.protocols.Locking$ServerLock.setOwner(Locking.java:767)
> at org.jgroups.protocols.Locking$ServerLock.handleRequest(Locking.java:655)
> at org.jgroups.protocols.Locking.handleLockRequest(Locking.java:393)
> at org.jgroups.protocols.Locking.up(Locking.java:226)
> at org.jgroups.stack.Protocol.up(Protocol.java:412)
> at org.jgroups.protocols.FORK.up(FORK.java:139)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:182)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
> at org.jgroups.stack.Protocol.up(Protocol.java:420)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> at org.jgroups.protocols.UNICAST3.deliverBatch(UNICAST3.java:1087)
> at org.jgroups.protocols.UNICAST3.removeAndDeliver(UNICAST3.java:886)
> at org.jgroups.protocols.UNICAST3.handleDataReceivedFromSelf(UNICAST3.java:821)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:424)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:652)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD.up(FD.java:253)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:288)
> at org.jgroups.protocols.Discovery.up(Discovery.java:291)
> at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2842)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1577)
> at org.jgroups.protocols.TP$3.run(TP.java:1511)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> The org.jgroups.protocols.Locking#lock_listeners is simple a HashSet which gets iterated over, This needs to be synchronised is some way.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 8 months
[JBoss JIRA] (WFLY-4390) restartable=false bach job can be restarted
by Takashi Nishigaya (JIRA)
[ https://issues.jboss.org/browse/WFLY-4390?page=com.atlassian.jira.plugin.... ]
Takashi Nishigaya commented on WFLY-4390:
-----------------------------------------
Thank you, Cheng.
I verified your fixed against WildFly 9 works well!
> restartable=false bach job can be restarted
> -------------------------------------------
>
> Key: WFLY-4390
> URL: https://issues.jboss.org/browse/WFLY-4390
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 8.2.0.Final
> Reporter: Takashi Nishigaya
> Assignee: Cheng Fang
> Attachments: batch-restartable.zip
>
>
> The batch job defined with restartable=false must not be restartable, after failed or stopped.
> GlassFish 4.1 results in the following:
> [2015-02-26T19:56:34.860+0900] [glassfish 4.1] [SEVERE] [] [] [tid: _ThreadID=25 _ThreadName=Thread-9] [timeMillis: 1424948194860] [levelValue: 1000] [[
> javax.batch.operations.JobRestartException: javax.batch.operations.JobRestartException: Job Restartable attribute is false, Job cannot be restarted.
> But WildFly tries to execute the stopped or failed job.
> Please check the attached test case.
> wildfly:
> $ mvn clean test -P wildfly-managed (or -P wildly-remote)
> glassfish:
> $ glassfish4/bin/asadmin start-domain
> $ mvn clean test -P glassfish-remote
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 8 months
[JBoss JIRA] (WFLY-4335) ArquillianService incorrectly sets TCCL
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4335?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4335:
--------------------------------------
It is true because the spec requires it, and we make sure we set the correct TCCL at each entry point.
> ArquillianService incorrectly sets TCCL
> ---------------------------------------
>
> Key: WFLY-4335
> URL: https://issues.jboss.org/browse/WFLY-4335
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.2.0.Final
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
>
> While integrating Camel in WildFly I noticed that @BeforeClass, @Before and @Test methods are being called with the TCCL of the test deployment.
> Camel happens to rely on TCCL, which is of course questionable in a modular environment. As a result it uses the test deployment's CL for resource discovery. Tests pass in the context of ARQ, but would not in a normal usage scenario when TCCL is not set or set to something else.
> This shadows potential problems when TCCL is not set or set to something else.
> Related: https://github.com/wildfly-extras/wildfly-camel/issues/292
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 8 months