[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
by Viacheslav Astapkovich (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Viacheslav Astapkovich edited comment on WFLY-7075 at 9/18/16 11:46 PM:
------------------------------------------------------------------------
Sorry for long delay.
I have tried to apply suggested solution for our project.
And we have next trouble:
We have a lot of EntityManager in our beans with default @PersistenceContext declaration (Transactional, Synchronized)
We have only one EntityManager with non-default configuration (Extended, Unsynchronized)
If we want to choose behavior - we must change all default EntityManager, not our customized EntityManager. Very laborious way for a big project.
If we set properties in Persistence.xml for my persistence unit - no changes in properties, because i get list of EntityManager Annotation property only.
I can see this property from EntityManagerFactory:
!Screenshot_7.png|thumbnail!
But i have only target property from annotation:
!Screenshot_8.png|thumbnail! and !Screenshot_9.png|thumbnail!
was (Author: veselroger):
Sorry for long delay.
I have tried to apply suggested solution for our project.
And we have next trouble:
We have a lot of EntityManager in our beans with default @PersistenceContext declaration (Transactional, Synchronized)
We have only one EntityManager with non-default configuration (Extended, Unsynchronized)
If we want to choose behavior - we must change all default EntityManager, not our customized EntityManager. Very laborious way for a big project.
If we set properties in Persistence.xml for my persistence unit - no changes in properties, because i get list of EntityManager Annotation property only.
> proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7075
> URL: https://issues.jboss.org/browse/WFLY-7075
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Environment: *AppServer:* WildFly 10.1.0.Final
> *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar
> Reporter: Viacheslav Astapkovich
> Assignee: Scott Marlow
> Attachments: kitchensink-ear.rar, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png
>
>
> As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
>
> *The obtained defect:*
> A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
> The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
> *FIX:*
> We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
> Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
> _Changes_: The method getSynchronizationType returns declared synchronization type.
> [WFLY-7108] is now the tracking jira for the fix.
> *Consequences:*
> We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
> Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
> It requires a declaration of synchronize persistence context.
> We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
> However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
> *Our actions:*
> We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
> This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
> _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
> *Example for reproduction:*
> I modified quickstart example: [^kitchensink-ear.rar]
> MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
> MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
> MemberRepository also perform join Transaction.
> Questions from [~smarlow]:
> - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
> We decided to use Container-managed EntityManager, because
> - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
> - The container makes our job
> We want to use the existing mechanism
> *In Addition:*
> Formally, this is out of JPA SPEC, but we have the following reasons:
> - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
> But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
> ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
> - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
by Viacheslav Astapkovich (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Viacheslav Astapkovich updated WFLY-7075:
-----------------------------------------
Attachment: Screenshot_7.png
Screenshot_8.png
Screenshot_9.png
> proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7075
> URL: https://issues.jboss.org/browse/WFLY-7075
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Environment: *AppServer:* WildFly 10.1.0.Final
> *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar
> Reporter: Viacheslav Astapkovich
> Assignee: Scott Marlow
> Attachments: kitchensink-ear.rar, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png
>
>
> As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
>
> *The obtained defect:*
> A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
> The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
> *FIX:*
> We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
> Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
> _Changes_: The method getSynchronizationType returns declared synchronization type.
> [WFLY-7108] is now the tracking jira for the fix.
> *Consequences:*
> We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
> Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
> It requires a declaration of synchronize persistence context.
> We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
> However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
> *Our actions:*
> We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
> This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
> _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
> *Example for reproduction:*
> I modified quickstart example: [^kitchensink-ear.rar]
> MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
> MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
> MemberRepository also perform join Transaction.
> Questions from [~smarlow]:
> - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
> We decided to use Container-managed EntityManager, because
> - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
> - The container makes our job
> We want to use the existing mechanism
> *In Addition:*
> Formally, this is out of JPA SPEC, but we have the following reasons:
> - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
> But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
> ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
> - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
by Viacheslav Astapkovich (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Viacheslav Astapkovich commented on WFLY-7075:
----------------------------------------------
Sorry for long delay.
I have tried to apply suggested solution for our project.
And we have next trouble:
We have a lot of EntityManager in our beans with default @PersistenceContext declaration (Transactional, Synchronized)
We have only one EntityManager with non-default configuration (Extended, Unsynchronized)
If we want to choose behavior - we must change all default EntityManager, not our customized EntityManager. Very laborious way for a big project.
If we set properties in Persistence.xml for my persistence unit - no changes in properties, because i get list of EntityManager Annotation property only.
> proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7075
> URL: https://issues.jboss.org/browse/WFLY-7075
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Environment: *AppServer:* WildFly 10.1.0.Final
> *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar
> Reporter: Viacheslav Astapkovich
> Assignee: Scott Marlow
> Attachments: kitchensink-ear.rar
>
>
> As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
>
> *The obtained defect:*
> A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
> The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
> *FIX:*
> We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
> Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
> _Changes_: The method getSynchronizationType returns declared synchronization type.
> [WFLY-7108] is now the tracking jira for the fix.
> *Consequences:*
> We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
> Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
> It requires a declaration of synchronize persistence context.
> We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
> However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
> *Our actions:*
> We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
> This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
> _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
> *Example for reproduction:*
> I modified quickstart example: [^kitchensink-ear.rar]
> MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
> MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
> MemberRepository also perform join Transaction.
> Questions from [~smarlow]:
> - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
> We decided to use Container-managed EntityManager, because
> - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
> - The container makes our job
> We want to use the existing mechanism
> *In Addition:*
> Formally, this is out of JPA SPEC, but we have the following reasons:
> - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
> But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
> ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
> - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7105) Incorrect redirection after authentization when using elytron
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7105?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-7105.
----------------------------------
Fix Version/s: 11.0.0.Alpha1
Resolution: Done
> Incorrect redirection after authentization when using elytron
> -------------------------------------------------------------
>
> Key: WFLY-7105
> URL: https://issues.jboss.org/browse/WFLY-7105
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
> Attachments: defined-security-domain.war, roles.properties, standalone-elytron-web-tests.xml, users.properties
>
>
> Having web application which uses defined security domain, which is set up using elytron results in incorrect redirection. It is redirecting after authentication done at {{http://localhost:8080/defined-security-domain/user/}} to {{http://localhost:8080/defined-security-domain/user//user/index.jsp}} instead of to {{http://localhost:8080/defined-security-domain/user/index.jsp}}.
> Note, when using only old security domain setup without elytron, it works just fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7134) Upgrade to Wildfly 10.0.0.Final: Messaging System issue
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-7134?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla updated WFLY-7134:
-----------------------------------
Description:
Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker.
The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis.
http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html
The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:-
Let me know if this is good. Also I have attached the entire standalone-full.xml with this case.
<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
<server name="default">
<security enabled="false"/>
<statistics enabled="true"/>
<security-setting name="#">
<role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
<role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
</security-setting>
<address-setting name="#" redistribution-delay="1000" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
<http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/>
<http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/>
<in-vm-connector name="in-vm" server-id="0"/>
<http-acceptor name="http-acceptor" http-listener="default"/>
<http-acceptor name="http-acceptor-throughput" http-listener="default">
<param name="batch-delay" value="50"/>
<param name="direct-deliver" value="false"/>
</http-acceptor>
<in-vm-acceptor name="in-vm" server-id="0"/>
<jms-queue name="testQueue" entries="java:/queue/test java:jboss/exported/jms/queue/test"/>
<jms-queue name="ISEEOutboundQueue" entries="java:/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/>
<jms-queue name="ISEEInboundQueue" entries="java:/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/>
<jms-queue name="BEEEAuthorizationsQueue" entries="java:/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/>
<jms-queue name="BEEERequisitionsQueue" entries="java:/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/>
<jms-queue name="BEEEInboundQueue" entries="java:/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/>
<jms-topic name="testTopic" entries="java:/topic/test java:jboss/exported/jms/topic/test"/>
<connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
<connection-factory name="RemoteConnectionFactory" entries="java:/RemoteConnectionFactory java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector"/>
<pooled-connection-factory name="activemq-ra" transaction="xa" entries="/JmsXA jboss/DefaultJMSConnectionFactory" connectors="in-vm"/>
</server>
</subsystem>
InitialContext is created with parameters - jmsuser, password, and
BEEERequisitions.JndiProviderUrl=http-remoting://<ip-address>:<port>
BEEERequisitions.JndiFactory=org.jboss.naming.remote.client.InitialContextFactory
Issue we face is that after we upgraded to wildfly 10, the messages are not getting in the queues. This is not consistent as once in a while messages are getting processed.
I have attached the below standalone-full.xml for your reference :-
1. standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine.
2. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.Final which has this JMS issue.
was:
Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker.
The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis.
http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html
The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:-
Let me know if this is good. Also I have attached the entire standalone-full.xml with this case.
<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
<server name="default">
<security enabled="false"/>
<statistics enabled="true"/>
<security-setting name="#">
<role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
<role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
</security-setting>
<address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
<http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/>
<http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/>
<in-vm-connector name="in-vm" server-id="0"/>
<http-acceptor name="http-acceptor" http-listener="default"/>
<http-acceptor name="http-acceptor-throughput" http-listener="default">
<param name="batch-delay" value="50"/>
<param name="direct-deliver" value="false"/>
</http-acceptor>
<in-vm-acceptor name="in-vm" server-id="0"/>
<jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/>
<jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/>
<jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/>
<jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/>
<jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/>
<jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/>
<jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/>
<connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
<connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/>
<pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/>
</server>
</subsystem>
InitialContext is created with parameters - jmsuser, password, and
BEEERequisitions.JndiProviderUrl=http-remoting://<ip-address>:<port>
BEEERequisitions.JndiFactory=org.jboss.naming.remote.client.InitialContextFactory
Issue we face is that after we upgraded to wildfly 10, the messages are not getting in the queues. This is not consistent as once in a while messages are getting processed.
I have attached the below standalone-full.xml for your reference :-
1. standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine.
2. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.Final which has this JMS issue.
> Upgrade to Wildfly 10.0.0.Final: Messaging System issue
> -------------------------------------------------------
>
> Key: WFLY-7134
> URL: https://issues.jboss.org/browse/WFLY-7134
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: standalone-full-WL-10.0.Final.xml, standalone-full-WL-8.2.xml
>
>
> Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker.
> The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis.
> http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html
> The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:-
> Let me know if this is good. Also I have attached the entire standalone-full.xml with this case.
> <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
> <server name="default">
> <security enabled="false"/>
> <statistics enabled="true"/>
> <security-setting name="#">
> <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
> <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
> </security-setting>
> <address-setting name="#" redistribution-delay="1000" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
> <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/>
> <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/>
> <in-vm-connector name="in-vm" server-id="0"/>
> <http-acceptor name="http-acceptor" http-listener="default"/>
> <http-acceptor name="http-acceptor-throughput" http-listener="default">
> <param name="batch-delay" value="50"/>
> <param name="direct-deliver" value="false"/>
> </http-acceptor>
> <in-vm-acceptor name="in-vm" server-id="0"/>
> <jms-queue name="testQueue" entries="java:/queue/test java:jboss/exported/jms/queue/test"/>
> <jms-queue name="ISEEOutboundQueue" entries="java:/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/>
> <jms-queue name="ISEEInboundQueue" entries="java:/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/>
> <jms-queue name="BEEEAuthorizationsQueue" entries="java:/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/>
> <jms-queue name="BEEERequisitionsQueue" entries="java:/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/>
> <jms-queue name="BEEEInboundQueue" entries="java:/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/>
> <jms-topic name="testTopic" entries="java:/topic/test java:jboss/exported/jms/topic/test"/>
> <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
> <connection-factory name="RemoteConnectionFactory" entries="java:/RemoteConnectionFactory java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector"/>
> <pooled-connection-factory name="activemq-ra" transaction="xa" entries="/JmsXA jboss/DefaultJMSConnectionFactory" connectors="in-vm"/>
> </server>
> </subsystem>
> InitialContext is created with parameters - jmsuser, password, and
> BEEERequisitions.JndiProviderUrl=http-remoting://<ip-address>:<port>
> BEEERequisitions.JndiFactory=org.jboss.naming.remote.client.InitialContextFactory
> Issue we face is that after we upgraded to wildfly 10, the messages are not getting in the queues. This is not consistent as once in a while messages are getting processed.
> I have attached the below standalone-full.xml for your reference :-
> 1. standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine.
> 2. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.Final which has this JMS issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JASSIST-263) ClassPool cannot read generated classes
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-263?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-263.
---------------------------------
> ClassPool cannot read generated classes
> ---------------------------------------
>
> Key: JASSIST-263
> URL: https://issues.jboss.org/browse/JASSIST-263
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Reporter: Paul Pogonyshev
> Assignee: Shigeru Chiba
> Fix For: 3.20.0-GA
>
> Attachments: JavassistBug.java
>
>
> ClassPool.get() cannot retrieve classes that are in turn generated at runtime. For example, if I try to define at runtime two classes, one of which extends another, the base will not be found, even though it can be retrieved just fine from my class loader. See the attached example.
> As far as I could trace it, the issue comes from ClassPoolTail.find() returning a null URL for the class. This is understandable, since class definition doesn't exist as a file --- it is generated at runtime. However, ClassPool.get() should still succeed for classes that have no URL, yet can be found through its ClassLoader.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JASSIST-263) ClassPool cannot read generated classes
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-263?page=com.atlassian.jira.plugi... ]
Shigeru Chiba resolved JASSIST-263.
-----------------------------------
Fix Version/s: 3.20.0-GA
Resolution: Done
This is not a bug.
> ClassPool cannot read generated classes
> ---------------------------------------
>
> Key: JASSIST-263
> URL: https://issues.jboss.org/browse/JASSIST-263
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Reporter: Paul Pogonyshev
> Assignee: Shigeru Chiba
> Fix For: 3.20.0-GA
>
> Attachments: JavassistBug.java
>
>
> ClassPool.get() cannot retrieve classes that are in turn generated at runtime. For example, if I try to define at runtime two classes, one of which extends another, the base will not be found, even though it can be retrieved just fine from my class loader. See the attached example.
> As far as I could trace it, the issue comes from ClassPoolTail.find() returning a null URL for the class. This is understandable, since class definition doesn't exist as a file --- it is generated at runtime. However, ClassPool.get() should still succeed for classes that have no URL, yet can be found through its ClassLoader.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JASSIST-263) ClassPool cannot read generated classes
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-263?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-263:
---------------------------------------
findResource() on your BuildClassLoader returns null.
To return something useful, BuildClassLoader has to keep all the bytecode (byte[] arrays) that have been passed to
defineClass() so far. findResource() on the BuildClassLoader will return a reference to that bytecode.
> ClassPool cannot read generated classes
> ---------------------------------------
>
> Key: JASSIST-263
> URL: https://issues.jboss.org/browse/JASSIST-263
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Reporter: Paul Pogonyshev
> Assignee: Shigeru Chiba
> Attachments: JavassistBug.java
>
>
> ClassPool.get() cannot retrieve classes that are in turn generated at runtime. For example, if I try to define at runtime two classes, one of which extends another, the base will not be found, even though it can be retrieved just fine from my class loader. See the attached example.
> As far as I could trace it, the issue comes from ClassPoolTail.find() returning a null URL for the class. This is understandable, since class definition doesn't exist as a file --- it is generated at runtime. However, ClassPool.get() should still succeed for classes that have no URL, yet can be found through its ClassLoader.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7136) Operation to list dependencies/dependents for a deployment
by Guillermo González de Agüero (JIRA)
Guillermo González de Agüero created WFLY-7136:
--------------------------------------------------
Summary: Operation to list dependencies/dependents for a deployment
Key: WFLY-7136
URL: https://issues.jboss.org/browse/WFLY-7136
Project: WildFly
Issue Type: Feature Request
Affects Versions: 10.1.0.Final
Reporter: Guillermo González de Agüero
Assignee: Jason Greene
If a deployment "A" has a dependency on deployment "B", and "B" is undeployed, "A" automatically changes its status to FAILED.
It's currently not possible to list what dependencies and dependents a deployment has. With two new operations (e.g. dependency-list and dependent-list) on the deployment resource, HAL could provide a confirmation dialog warning the user of side effects when undeploying.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months