September 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5020) Server fails to start with transactions configured to be run with JDBCObject store

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-5020?page=com.atlassian.jira.plugin.... ] Stefano Maestri commented on WFLY-5020: --------------------------------------- Hi, I'm a bit puzzled by your module config. A correct deployment w/ module should have a module created in modules/system/layers/base directory w/ its jar and a module.xml definition. Then standalone config of datasource should looks like: {code:java} <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true"> <connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url> <driver>microsoft</driver> <security> <user-name>username1</user-name> <password>password1</password> </security> </datasource> <drivers> <driver name="h2" module="com.h2database.h2"> <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class> </driver> <driver name="microsoft" module="com.microsoft.sql"></driver> </drivers> {code} Please note definition of driver in xml pointing the created module. I can't see anything of this in your module configuration. Anyway I've configured and tried exactly the above configuration and it works w/o problem. Looking again in the code I can see jdbc-store isn't designed to work w/ hot deployed driver (BTW it's not a best practice in general), I thought it was pointed out in documentation, but quite frankly I haven't found it. Maybe something to improve in documentation, but it's a different area and issue is solved even for sql server and any other database using module configuration. So I'm closing again this issue. Feel free to open a documentation improvement issue pointing this comment. regards S. > Server fails to start with transactions configured to be run with JDBCObject store > ---------------------------------------------------------------------------------- > > Key: WFLY-5020 > URL: https://issues.jboss.org/browse/WFLY-5020 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Hayk Hovsepyan > Assignee: Stefano Maestri > Priority: Blocker > Fix For: 10.0.0.Final > > Attachments: server.log, server_module.log, standalone.xml, standalone_module.xml > > > When you configure transactions subsystem for running with JDBCObject store, the app server fails to start because of a error below. > Error message: > {code} > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]): org.jboss.msc.service.CircularDependencyException: Container jboss-as has a circular dependency: [service jboss.txn.ArjunaObjectStoreEnvironment, service jboss.txn.ArjunaRecoveryManager, service jboss.connector.transactionintegration, service jboss.rarepository, service jboss.data-source.java:jboss/datasources/jdbc-store, service jboss.data-source.reference-factory.JDBCPool, service jboss.naming.context.java.jboss.datasources.jdbc-store] > {code} > Datasource configuration is: > {code} > <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true"> > <connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url> > <driver>sqljdbc4.jar</driver> > <security> > <user-name>username1</user-name> > <password>password1</password> > </security> > </datasource> > {code} > and the transaction config looks like this > {code} > <jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5020) Server fails to start with transactions configured to be run with JDBCObject store

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-5020?page=com.atlassian.jira.plugin.... ] Stefano Maestri resolved WFLY-5020. ----------------------------------- Resolution: Done > Server fails to start with transactions configured to be run with JDBCObject store > ---------------------------------------------------------------------------------- > > Key: WFLY-5020 > URL: https://issues.jboss.org/browse/WFLY-5020 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Hayk Hovsepyan > Assignee: Stefano Maestri > Priority: Blocker > Fix For: 10.0.0.Final > > Attachments: server.log, server_module.log, standalone.xml, standalone_module.xml > > > When you configure transactions subsystem for running with JDBCObject store, the app server fails to start because of a error below. > Error message: > {code} > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]): org.jboss.msc.service.CircularDependencyException: Container jboss-as has a circular dependency: [service jboss.txn.ArjunaObjectStoreEnvironment, service jboss.txn.ArjunaRecoveryManager, service jboss.connector.transactionintegration, service jboss.rarepository, service jboss.data-source.java:jboss/datasources/jdbc-store, service jboss.data-source.reference-factory.JDBCPool, service jboss.naming.context.java.jboss.datasources.jdbc-store] > {code} > Datasource configuration is: > {code} > <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true"> > <connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url> > <driver>sqljdbc4.jar</driver> > <security> > <user-name>username1</user-name> > <password>password1</password> > </security> > </datasource> > {code} > and the transaction config looks like this > {code} > <jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1009) Treat intra-domain transactional ":reload" and ":shutdown" requests similarly to how we handle end user requests

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1009?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet reassigned WFCORE-1009: ----------------------------------------- Assignee: ehsavoie Hugonnet > Treat intra-domain transactional ":reload" and ":shutdown" requests similarly to how we handle end user requests > ---------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1009 > URL: https://issues.jboss.org/browse/WFCORE-1009 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > > ModelControllerClientOperationHandler.ExecuteRequestHandler has special logic for the ":reload" op such that once the operation notifies that it is prepared, it immediately sends the final "success" result to the client, not waiting for the op execution to return to send it. This allows the response to go out to the client before the reload starts shutting down services. WFCORE-1008 proposes expanding this to the ":shutdown" operation as well. > This JIRA proposes expanding this to the TransactionalProtocolOperationHandler used for intra-domain process requests as well. > The implementation here would be slightly different in that the response to the prepared notification from the op would be unchanged. What would change would be the handling of the tx commit coming from the client. The tx commit message handling would send the response instead of waiting for the original op to complete. > The client side state related to the status of the reloading/shutting down slave HC or server should be fine. A master HC's tracking of slaves is unaffected by proxying a reload or shutdown op; it monitors the master<->slave comm channel to track the slave. Same thing for an HC reloading a server. For the case where an HC is stopping a server by sending a ":shutdown" request, the response to the request puts the HC's view of the server's state into InternalState.PROCESS_STOPPING. This state is valid as soon as the HC commits the ":shutdown" request, so this JIRA is consistent with that handling. > (Note: This special handling of ":reload" isn't a perfect thing, as it only covers the direct use of the ":reload" op. It doesn't cover things like a reload as a step in a composite. For the composite case, we need to give the step handlers for the other steps a chance to run any ResultHandlers they have registered and fix up the response before we send it back, so we can't just ignore that part of the execution.) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1008) Treat ":shutdown" requests similarly to ":reload" in the server-side operation handler

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1008?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet reassigned WFCORE-1008: ----------------------------------------- Assignee: ehsavoie Hugonnet > Treat ":shutdown" requests similarly to ":reload" in the server-side operation handler > -------------------------------------------------------------------------------------- > > Key: WFCORE-1008 > URL: https://issues.jboss.org/browse/WFCORE-1008 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > > ModelControllerClientOperationHandler.ExecuteRequestHandler has special logic for the ":reload" op such that once the operation notifies that it is prepared, it immediately sends the final "success" result to the client, not waiting for the op execution to return to send it. This allows the response to go out to the client before the reload starts shutting down services. > A ":shutdown" op has similar effects to a ":reload" so there is no reason to treat it differently. > (Note: This special handling of ":reload" isn't a perfect thing, as it only covers the direct use of the ":reload" op. It doesn't cover things like a reload as a step in a composite. For the composite case, we need to give the step handlers for the other steps a chance to run any ResultHandlers they have registered and fix up the response before we send it back, so we can't just ignore that part of the execution.) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5419) Deployed webservices in war do not show up in admin console

by skarimir skarimir (JIRA)

skarimir skarimir created WFLY-5419: --------------------------------------- Summary: Deployed webservices in war do not show up in admin console Key: WFLY-5419 URL: https://issues.jboss.org/browse/WFLY-5419 Project: WildFly Issue Type: Bug Components: Web Console, Web Services Affects Versions: 10.0.0.CR2, 9.0.1.Final Reporter: skarimir skarimir Assignee: Heiko Braun Webservices deployed in a war do not show up in the Administration Console under runtime > subsystems > webservices. This works in wildfly 8 with the same war. You can reproduce this using the quickstart example https://github.com/wildfly/quickstart/tree/9.x/helloworld-ws -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5418) start-delivery/stop-delivery operations are missing from MDB deployment in domain mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5418?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-5418: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1266913 Bugzilla Update: Perform > start-delivery/stop-delivery operations are missing from MDB deployment in domain mode > -------------------------------------------------------------------------------------- > > Key: WFLY-5418 > URL: https://issues.jboss.org/browse/WFLY-5418 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: JBoss AS7 7.2.0.Final > Environment: JBoss EAP 6.4.3 > Reporter: Tom Ross > Assignee: Jeff Mesnil > > It is possible to start/stop delivery of messages to MDB in standalone mode using operations > start-delivery() and stop-delivery() on MDB deployment. > Those operations are missing from MDB deployment in domain mode -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3921) Support direct JMX mbeans as dependecies

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3921?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-3921: ----------------------------------- Fix Version/s: (was: 10.0.0.Final) I'm unscheduling this because the initial attempt at it proved harder than we expected and I don't believe that at this point we know when (or how) to resolve it. > Support direct JMX mbeans as dependecies > ---------------------------------------- > > Key: WFLY-3921 > URL: https://issues.jboss.org/browse/WFLY-3921 > Project: WildFly > Issue Type: Feature Request > Components: JMX > Affects Versions: 9.0.0.Alpha1 > Reporter: Ales Justin > Assignee: Ales Justin > > We should be able to depend on existing mbeans from jboss-service.xml. > (e.g. mbeans registered directly from JMX API) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-277) TS: Integrate JUnitDiff

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-277?page=com.atlassian.jira.plugin.s... ] Brian Stansberry closed WFLY-277. --------------------------------- Resolution: Won't Fix I'm closing this as there is no activity on it. > TS: Integrate JUnitDiff > ----------------------- > > Key: WFLY-277 > URL: https://issues.jboss.org/browse/WFLY-277 > Project: WildFly > Issue Type: Feature Request > Components: Test Suite > Reporter: Ondrej Zizka > Assignee: Ondrej Zizka > Priority: Minor > Original Estimate: 3 weeks > Remaining Estimate: 3 weeks > > Running with > {code} > -DjunitDiff='<path1>:<path2>:<path3>' > {code} > would create a comparison to given testsuite result sets (JUnit .xml and txt files). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-277) TS: Integrate JUnitDiff

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-277?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated WFLY-277: ---------------------------------- Fix Version/s: (was: 10.0.0.Final) > TS: Integrate JUnitDiff > ----------------------- > > Key: WFLY-277 > URL: https://issues.jboss.org/browse/WFLY-277 > Project: WildFly > Issue Type: Feature Request > Components: Test Suite > Reporter: Ondrej Zizka > Assignee: Ondrej Zizka > Priority: Minor > Original Estimate: 3 weeks > Remaining Estimate: 3 weeks > > Running with > {code} > -DjunitDiff='<path1>:<path2>:<path3>' > {code} > would create a comparison to given testsuite result sets (JUnit .xml and txt files). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5418) start-delivery/stop-delivery operations are missing from MDB deployment in domain mode

by Tom Ross (JIRA)

Tom Ross created WFLY-5418: ------------------------------ Summary: start-delivery/stop-delivery operations are missing from MDB deployment in domain mode Key: WFLY-5418 URL: https://issues.jboss.org/browse/WFLY-5418 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: JBoss AS7 7.2.0.Final Environment: JBoss EAP 6.4.3 Reporter: Tom Ross Assignee: Jeff Mesnil It is possible to start/stop delivery of messages to MDB in standalone mode using operations start-delivery() and stop-delivery() on MDB deployment. Those operations are missing from MDB deployment in domain mode -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2015