[JBoss JIRA] (WFLY-5536) Recovery manager is not able to recover MDB and shows warnings on each run.
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5536?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-5536:
-----------------------------------
[~mwessendorf] I don't think it's been backported to EAP 6.4 with HornetQ. Artemis uses ServiceLoader to load resources related to recovery. I don't think that HornetQ had a similar feature though...
> Recovery manager is not able to recover MDB and shows warnings on each run.
> ---------------------------------------------------------------------------
>
> Key: WFLY-5536
> URL: https://issues.jboss.org/browse/WFLY-5536
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR2
> Reporter: Hayk Hovsepyan
> Assignee: Jeff Mesnil
> Priority: Blocker
> Fix For: 10.0.0.CR5
>
> Attachments: MDB_JMS_XA.log, TEST-org.jboss.as.test.jbossts.crashrec.test.JMSMdbCrashRecoveryTestCase-jta.xml
>
>
> Recovery manager is not able to recover MDB and shows warnings.
> This causes to see the same warning log in server each time recovery is run.
> This happens when server is crashed before transaction state is saved.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-1367) Test framework for CLI-based tests can be very slow
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1367?page=com.atlassian.jira.plugi... ]
Tomaz Cerar closed WFCORE-1367.
-------------------------------
Fix Version/s: 3.0.0.Beta9
Resolution: Done
Looking at code, there are no timeouts involved anymore.
And it looks like tests run quite fast.
> Test framework for CLI-based tests can be very slow
> ---------------------------------------------------
>
> Key: WFCORE-1367
> URL: https://issues.jboss.org/browse/WFCORE-1367
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Test Suite
> Reporter: David Bosschaert
> Priority: Minor
> Fix For: 3.0.0.Beta9
>
>
> The org.jboss.as.test.integration.management.base.AbstractCliTestBase provides a suitable API for testing CLI-based operations. However, running tests with a relatively large number of CLI operations can take a *long* time, seemingly much longer than necessary. This is probably related to the fact that CLIWrapper.readAllAsOpResult() method always seems to wait until the lineTimeout has expired.
> Typically the WAIT_LINETIMEOUT value is used for this argument. Shortening the timeout is not an option as I have seen cases where a test would fail when run on a slow machine, but this only happens occasionally.
> It would be *much* better if a timeout was not needed for this and the test would wait until a certain operation was finished.
> This can be observed in org.jboss.as.test.integration.management.cli.JmsTestCase and I also experienced it when writing the org.jboss.as.test.integration.osgi.management.OSGiManagementTestCase.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2564) Customize resolve-path handle to handle absolute paths
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2564?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2564:
-------------------------------------
Comment: was deleted
(was: I've unassigned this so it's free for anyone to pick up, but I stuck a 3.0.0 Fix Version on it because it seems like something we could get done fairly easily. The Fix Version is just to help attract attention to it if people have time; it's not a commitment.)
> Customize resolve-path handle to handle absolute paths
> ------------------------------------------------------
>
> Key: WFCORE-2564
> URL: https://issues.jboss.org/browse/WFCORE-2564
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Beta9
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 3.0.0.Beta11
>
>
> The :resolve-path operation will always resolve the path based on the relative-to attribute.
> In the messaging subsystem, we have a different behaviour where the relative-to attribute is *ignored* (whether it is defined or not) when the path value correponds to an absolute path.
> To be consistent with this behaviour, the :resolve-path operation builder would need customization and specify that the relative-to attribute must be ignored when the path is absolute.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2564) Customize resolve-path handle to handle absolute paths
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2564?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2564:
-------------------------------------
Comment: was deleted
(was: Whoever picks this up please ping [~jmesnil] about picking up JBEAP-9717 at the same time since that's the actual immediate use case for the change to core. Actually using the core change is a good way to make sure it's right. ;))
> Customize resolve-path handle to handle absolute paths
> ------------------------------------------------------
>
> Key: WFCORE-2564
> URL: https://issues.jboss.org/browse/WFCORE-2564
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Beta9
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 3.0.0.Beta11
>
>
> The :resolve-path operation will always resolve the path based on the relative-to attribute.
> In the messaging subsystem, we have a different behaviour where the relative-to attribute is *ignored* (whether it is defined or not) when the path value correponds to an absolute path.
> To be consistent with this behaviour, the :resolve-path operation builder would need customization and specify that the relative-to attribute must be ignored when the path is absolute.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2564) Customize resolve-path handle to handle absolute paths
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2564?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2564:
----------------------------------------
Assignee: Jeff Mesnil
The bit I mentioned about changing PathManager doesn't have to be part of this; the immediate issue can be resolved solely within ResolvePathHandler and its Builder.
> Customize resolve-path handle to handle absolute paths
> ------------------------------------------------------
>
> Key: WFCORE-2564
> URL: https://issues.jboss.org/browse/WFCORE-2564
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Beta9
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 3.0.0.Beta11
>
>
> The :resolve-path operation will always resolve the path based on the relative-to attribute.
> In the messaging subsystem, we have a different behaviour where the relative-to attribute is *ignored* (whether it is defined or not) when the path value correponds to an absolute path.
> To be consistent with this behaviour, the :resolve-path operation builder would need customization and specify that the relative-to attribute must be ignored when the path is absolute.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8414) EJBContext.getCallerPrincipal behaves differently in Elytron and legacy security
by Josef Cacek (JIRA)
Josef Cacek created WFLY-8414:
---------------------------------
Summary: EJBContext.getCallerPrincipal behaves differently in Elytron and legacy security
Key: WFLY-8414
URL: https://issues.jboss.org/browse/WFLY-8414
Project: WildFly
Issue Type: Bug
Components: EJB, Security
Reporter: Josef Cacek
Assignee: Darran Lofthouse
The {{EJBContext.getCallerPrincipal()}} used in unsecured EJB method returns "anonymous" (i.e. unauthenticatedIdentity) in legacy security and it returns authenticated user-name when the default security domain ("other") is mapped to Elytron.
This could complicate users migration from legacy security to Elytron.
I'm not sure if this behavior was intended or if it's just a problem of how the Elytron default domain mapping works in ejb3 subsystem.
If the current {{getCallerPrincipal}} behavior is correct, then we should either reuse this JIRA for Documentation changes (especially Migration guide) or close this and create a new Documentation one.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2564) Customize resolve-path handle to handle absolute paths
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2564?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2564:
------------------------------------------
Whoever picks this up please ping [~jmesnil] about picking up JBEAP-9717 at the same time since that's the actual immediate use case for the change to core. Actually using the core change is a good way to make sure it's right. ;)
> Customize resolve-path handle to handle absolute paths
> ------------------------------------------------------
>
> Key: WFCORE-2564
> URL: https://issues.jboss.org/browse/WFCORE-2564
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Beta9
> Reporter: Jeff Mesnil
> Fix For: 3.0.0.Beta11
>
>
> The :resolve-path operation will always resolve the path based on the relative-to attribute.
> In the messaging subsystem, we have a different behaviour where the relative-to attribute is *ignored* (whether it is defined or not) when the path value correponds to an absolute path.
> To be consistent with this behaviour, the :resolve-path operation builder would need customization and specify that the relative-to attribute must be ignored when the path is absolute.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2564) Customize resolve-path handle to handle absolute paths
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2564?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2564:
----------------------------------------
Assignee: (was: Brian Stansberry)
> Customize resolve-path handle to handle absolute paths
> ------------------------------------------------------
>
> Key: WFCORE-2564
> URL: https://issues.jboss.org/browse/WFCORE-2564
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Beta9
> Reporter: Jeff Mesnil
> Fix For: 3.0.0.Beta11
>
>
> The :resolve-path operation will always resolve the path based on the relative-to attribute.
> In the messaging subsystem, we have a different behaviour where the relative-to attribute is *ignored* (whether it is defined or not) when the path value correponds to an absolute path.
> To be consistent with this behaviour, the :resolve-path operation builder would need customization and specify that the relative-to attribute must be ignored when the path is absolute.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2564) Customize resolve-path handle to handle absolute paths
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2564?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2564:
-------------------------------------
Fix Version/s: 3.0.0.Beta11
I've unassigned this so it's free for anyone to pick up, but I stuck a 3.0.0 Fix Version on it because it seems like something we could get done fairly easily. The Fix Version is just to help attract attention to it if people have time; it's not a commitment.
> Customize resolve-path handle to handle absolute paths
> ------------------------------------------------------
>
> Key: WFCORE-2564
> URL: https://issues.jboss.org/browse/WFCORE-2564
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Beta9
> Reporter: Jeff Mesnil
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Beta11
>
>
> The :resolve-path operation will always resolve the path based on the relative-to attribute.
> In the messaging subsystem, we have a different behaviour where the relative-to attribute is *ignored* (whether it is defined or not) when the path value correponds to an absolute path.
> To be consistent with this behaviour, the :resolve-path operation builder would need customization and specify that the relative-to attribute must be ignored when the path is absolute.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month