[JBoss JIRA] (WFLY-5232) Naming store is null before CDI lifecycle BeforeShutdown event fires
by Ryan Emerson (JIRA)
Ryan Emerson created WFLY-5232:
----------------------------------
Summary: Naming store is null before CDI lifecycle BeforeShutdown event fires
Key: WFLY-5232
URL: https://issues.jboss.org/browse/WFLY-5232
Project: WildFly
Issue Type: Bug
Reporter: Ryan Emerson
Assignee: Jason Greene
Attachments: reproducer.tar.gz
A CDI extension has a BeforeShutdown event handler that looks up the UserTransaction and performs a clean-up operation. If the application is undeployed, all works as expected, but if Wildfly is shut down gracefully the lookup fails.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5231) [Migration operation] [Web to Undertow] Web - access-log and its directory attributes are not migrated
by Radim Hatlapatka (JIRA)
Radim Hatlapatka created WFLY-5231:
--------------------------------------
Summary: [Migration operation] [Web to Undertow] Web - access-log and its directory attributes are not migrated
Key: WFLY-5231
URL: https://issues.jboss.org/browse/WFLY-5231
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Radim Hatlapatka
Assignee: Stuart Douglas
Priority: Critical
When migrating access-log via {{:migrate}} and access-log contains directory definition, the properties {{relative-to}} and {{path}} are not migrated.
Web subsystem snippet:
{code:xml}
<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default" native="false">
<virtual-server name="default" enable-welcome-root="true">
<alias name="localhost"/>
<alias name="example.com"/>
<access-log resolve-hosts="true" prefix="test" rotate="false">
<directory relative-to="jboss.server.log.dir" path="testvs/vs"/>
</access-log>
</virtual-server>
</subsystem>
{code}
access log part expected to be migrated as
{code:xml}
<access-log rotate="false" prefix="test" directory="testvs/vs" relative-to="jboss.server.log.dir" />
{code}
instead it is migrated without the {{directory}} and {{relative-to}} attributes:
<access-log rotate="false" prefix="test"/>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5231) [Migration operation] [Web to Undertow] Web - access-log and its directory attributes are not migrated
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5231?page=com.atlassian.jira.plugin.... ]
Radim Hatlapatka updated WFLY-5231:
-----------------------------------
Affects Version/s: 10.0.0.Beta2
> [Migration operation] [Web to Undertow] Web - access-log and its directory attributes are not migrated
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5231
> URL: https://issues.jboss.org/browse/WFLY-5231
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Beta2
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
> Priority: Critical
>
> When migrating access-log via {{:migrate}} and access-log contains directory definition, the properties {{relative-to}} and {{path}} are not migrated.
> Web subsystem snippet:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default" native="false">
> <virtual-server name="default" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> <access-log resolve-hosts="true" prefix="test" rotate="false">
> <directory relative-to="jboss.server.log.dir" path="testvs/vs"/>
> </access-log>
> </virtual-server>
> </subsystem>
> {code}
> access log part expected to be migrated as
> {code:xml}
> <access-log rotate="false" prefix="test" directory="testvs/vs" relative-to="jboss.server.log.dir" />
> {code}
> instead it is migrated without the {{directory}} and {{relative-to}} attributes:
> <access-log rotate="false" prefix="test"/>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (ELY-279) Support CORS
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-279:
------------------------------------
Summary: Support CORS
Key: ELY-279
URL: https://issues.jboss.org/browse/ELY-279
Project: WildFly Elytron
Issue Type: Feature Request
Components: HTTP
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.1.0.Alpha1
This is something that can possibly be tied in around the HTTP authentication framework meaning that the control of this can live in the HTTP authentication policy within Elytron rather than at the front end.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5230) Check status of Transaction prior to UserTransactionCommitTask and UserTransactionRollbackTask
by Johnathon Lee (JIRA)
Johnathon Lee created WFLY-5230:
-----------------------------------
Summary: Check status of Transaction prior to UserTransactionCommitTask and UserTransactionRollbackTask
Key: WFLY-5230
URL: https://issues.jboss.org/browse/WFLY-5230
Project: WildFly
Issue Type: Enhancement
Components: EJB
Affects Versions: 9.0.1.Final
Reporter: Johnathon Lee
UserTransactionCommitTask should check the status and say something like "if not committed, call commit"
UserTransactionRollbackTask should check the status and say something like "if not rolled back, call rollback"
Note that those two operations when combined are not atomic and the reaper thread may in parallel roll it back. E.g.
app thread
if tx not committed
reaper thread
rollback tx
app thread
commit
But that should only happen rarely. It would result in an exception to the client and log messages and would not be considered a defect.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5213) Injecting external context to Artemis fails
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil edited comment on WFLY-5213 at 8/28/15 9:39 AM:
------------------------------------------------------------
it works for me after adding an dependency to org.jboss.invocation in the org.apache.activemq.artemis module.
# Remote Artemis broker
User credentials: "user"/"pass"
2 JMS queues:
<queue name="inQueue"/>
<queue name="outQueue"/>
# WildFly Configuration:
Add an external context to connect to the remote Artemis:
{noformat}
<subsystem xmlns="urn:jboss:domain:naming:2.0">
<bindings>
<external-context name="java:/remote/artemis/" module="org.apache.activemq.artemis" class="javax.naming.InitialContext" cache="true">
<environment>
<property name="java.naming.factory.initial" value="org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory"/>
<property name="java.naming.provider.url" value="tcp://127.0.0.1:61616"/>
</environment>
</external-context>
</bindings>
<remote-naming/>
</subsystem>
{noformat}
Add an outbound-socket-binding
{noformat}
<outbound-socket-binding name="remote-artemis">
<remote-destination host="localhost" port="61616"/>
</outbound-socket-binding>
{noformat}
Add a messaging-activemq's remote-connector and a pooled-connection-factory to connect to the remote Artemis:
{noformat}
<remote-connector name="remote-artemis" socket-binding="remote-artemis"/>
...
<pooled-connection-factory name="remote-artemis" password="pass" user="user" entries="java:/jms/remoteCF" connectors="remote-artemis"/>
{noformat}
# MDB Configuration:
{noformat}
@MessageDriven(name = "HelloWorldQueueMDB", activationConfig = {
@ActivationConfigProperty(propertyName = "connectionFactoryLookup", propertyValue = "java:/jms/remoteCF"),
@ActivationConfigProperty(propertyName="user", propertyValue="user"),
@ActivationConfigProperty(propertyName="password", propertyValue="pass"),
@ActivationConfigProperty(propertyName = "destinationLookup", propertyValue = "java:/remote/artemis/dynamicQueues/inQueue"),
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge") })
public class HelloWorldQueueMDB implements MessageListener {
...
}
{noformat}
It uses the remote-artemis pooled-connection-factory and looks up the queue from the external-context.
Likewise, code to send a message to the queue from a Servlet is using the external context:
{noformat}
@Inject
@JMSConnectionFactory("java:/jms/remoteCF")
@JMSPasswordCredential(userName = "user", password = "pass")
private JMSContext context;
@Resource(lookup = "java:/remote/artemis/dynamicQueues/inQueue")
private Queue queue;
{noformat}
Without the dependency to org.jboss.invocation, it fails:
{noformat}
Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup remote/artemis/dynamicQueues/inQueue [Root exception is java.lang.NoClassDefFoundError: org/jboss/invocation/proxy/classloading/MethodStore]
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:88)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
{noformat}
The org.apache.activemq.artemis is missing a dependency to the org.jboss.invocation module to be used from an external-context. Once the dependency is added, the external context is working as expected and the context is propertly injected
was (Author: jmesnil):
it works for me after adding an dependency to org.jboss.invocation in the org.apache.activemq.artemis module.
# Remote Artemis broker
User credentials: "user"/"pass"
2 JMS queues:
<queue name="inQueue"/>
<queue name="outQueue"/>
# WildFly Configuration:
Add an external context to connect to the remote Artemis:
{noformat}
<subsystem xmlns="urn:jboss:domain:naming:2.0">
<bindings>
<external-context name="java:/remote/artemis/" module="org.apache.activemq.artemis" class="javax.naming.InitialContext" cache="true">
<environment>
<property name="java.naming.factory.initial" value="org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory"/>
<property name="java.naming.provider.url" value="tcp://127.0.0.1:61616"/>
</environment>
</external-context>
</bindings>
<remote-naming/>
</subsystem>
{noformat}
Add an outbound-socket-binding
{noformat}
<outbound-socket-binding name="remote-artemis">
<remote-destination host="localhost" port="61616"/>
</outbound-socket-binding>
{noformat}
Add a messaging-activemq's remote-connector and a pooled-connection-factory to connect to the remote Artemis:
{noformat}
<remote-connector name="remote-artemis" socket-binding="remote-artemis"/>
...
<pooled-connection-factory name="remote-artemis" password="pass" user="user" entries="java:/jms/remoteCF" connectors="remote-artemis"/>
{noformat}
# MDB Configuration:
@MessageDriven(name = "HelloWorldQueueMDB", activationConfig = {
@ActivationConfigProperty(propertyName = "connectionFactoryLookup", propertyValue = "java:/jms/remoteCF"),
@ActivationConfigProperty(propertyName="user", propertyValue="user"),
@ActivationConfigProperty(propertyName="password", propertyValue="pass"),
@ActivationConfigProperty(propertyName = "destinationLookup", propertyValue = "java:/remote/artemis/dynamicQueues/inQueue"),
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge") })
public class HelloWorldQueueMDB implements MessageListener {
...
}
It uses the remote-artemis pooled-connection-factory and looks up the queue from the external-context.
Likewise, code to send a message to the queue from a Servlet is using the external context:
{noforma}
@Inject
@JMSConnectionFactory("java:/jms/remoteCF")
@JMSPasswordCredential(userName = "user", password = "pass")
private JMSContext context;
@Resource(lookup = "java:/remote/artemis/dynamicQueues/inQueue")
private Queue queue;
{noformat}
Without the dependency to org.jboss.invocation, it fails:
{noformat}
Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup remote/artemis/dynamicQueues/inQueue [Root exception is java.lang.NoClassDefFoundError: org/jboss/invocation/proxy/classloading/MethodStore]
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:88)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
{noformat}
The org.apache.activemq.artemis is missing a dependency to the org.jboss.invocation module to be used from an external-context. Once the dependency is added, the external context is working as expected and the context is propertly injected
> Injecting external context to Artemis fails
> -------------------------------------------
>
> Key: WFLY-5213
> URL: https://issues.jboss.org/browse/WFLY-5213
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Beta2
> Reporter: Ondřej Kalman
> Assignee: Jeff Mesnil
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5213) Injecting external context or its destinations in MDB fails
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-5213:
-----------------------------------
it works for me after adding an dependency to org.jboss.invocation in the org.apache.activemq.artemis module.
# Remote Artemis broker
User credentials: "user"/"pass"
2 JMS queues:
<queue name="inQueue"/>
<queue name="outQueue"/>
# WildFly Configuration:
Add an external context to connect to the remote Artemis:
{noformat}
<subsystem xmlns="urn:jboss:domain:naming:2.0">
<bindings>
<external-context name="java:/remote/artemis/" module="org.apache.activemq.artemis" class="javax.naming.InitialContext" cache="true">
<environment>
<property name="java.naming.factory.initial" value="org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory"/>
<property name="java.naming.provider.url" value="tcp://127.0.0.1:61616"/>
</environment>
</external-context>
</bindings>
<remote-naming/>
</subsystem>
{noformat}
Add an outbound-socket-binding
{noformat}
<outbound-socket-binding name="remote-artemis">
<remote-destination host="localhost" port="61616"/>
</outbound-socket-binding>
{noformat}
Add a messaging-activemq's remote-connector and a pooled-connection-factory to connect to the remote Artemis:
{noformat}
<remote-connector name="remote-artemis" socket-binding="remote-artemis"/>
...
<pooled-connection-factory name="remote-artemis" password="pass" user="user" entries="java:/jms/remoteCF" connectors="remote-artemis"/>
{noformat}
# MDB Configuration:
@MessageDriven(name = "HelloWorldQueueMDB", activationConfig = {
@ActivationConfigProperty(propertyName = "connectionFactoryLookup", propertyValue = "java:/jms/remoteCF"),
@ActivationConfigProperty(propertyName="user", propertyValue="user"),
@ActivationConfigProperty(propertyName="password", propertyValue="pass"),
@ActivationConfigProperty(propertyName = "destinationLookup", propertyValue = "java:/remote/artemis/dynamicQueues/inQueue"),
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge") })
public class HelloWorldQueueMDB implements MessageListener {
...
}
It uses the remote-artemis pooled-connection-factory and looks up the queue from the external-context.
Likewise, code to send a message to the queue from a Servlet is using the external context:
{noforma}
@Inject
@JMSConnectionFactory("java:/jms/remoteCF")
@JMSPasswordCredential(userName = "user", password = "pass")
private JMSContext context;
@Resource(lookup = "java:/remote/artemis/dynamicQueues/inQueue")
private Queue queue;
{noformat}
Without the dependency to org.jboss.invocation, it fails:
{noformat}
Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup remote/artemis/dynamicQueues/inQueue [Root exception is java.lang.NoClassDefFoundError: org/jboss/invocation/proxy/classloading/MethodStore]
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:88)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
{noformat}
The org.apache.activemq.artemis is missing a dependency to the org.jboss.invocation module to be used from an external-context. Once the dependency is added, the external context is working as expected and the context is propertly injected
> Injecting external context or its destinations in MDB fails
> -----------------------------------------------------------
>
> Key: WFLY-5213
> URL: https://issues.jboss.org/browse/WFLY-5213
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Beta2
> Reporter: Ondřej Kalman
> Assignee: Jeff Mesnil
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5213) Injecting external context to Artemis fails
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-5213:
------------------------------
Summary: Injecting external context to Artemis fails (was: Injecting external context or its destinations in MDB fails)
> Injecting external context to Artemis fails
> -------------------------------------------
>
> Key: WFLY-5213
> URL: https://issues.jboss.org/browse/WFLY-5213
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Beta2
> Reporter: Ondřej Kalman
> Assignee: Jeff Mesnil
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5229) Run the Setup task teardown methods before @AfterClass
by ehsavoie Hugonnet (JIRA)
ehsavoie Hugonnet created WFLY-5229:
---------------------------------------
Summary: Run the Setup task teardown methods before @AfterClass
Key: WFLY-5229
URL: https://issues.jboss.org/browse/WFLY-5229
Project: WildFly
Issue Type: Enhancement
Components: Test Suite
Reporter: ehsavoie Hugonnet
In manualmode, if you do some model modification in a SetupTask you can't undo it in the teardown method as this happends after the whole test. By executing the teardown before the @AfterClass we can shutdown the server(s) in the @AfterClass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
