January 2015 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2322) Add linux64el7 to the Narayana CI matrix for BlackTie

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2322?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-2322: ---------------------------- Summary: Add linux64el7 to the Narayana CI matrix for BlackTie (was: Add el7 to the Narayana CI matrix for BlackTie) > Add linux64el7 to the Narayana CI matrix for BlackTie > ----------------------------------------------------- > > Key: JBTM-2322 > URL: https://issues.jboss.org/browse/JBTM-2322 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.0.5 > > > Currently we do not build blacktie on the EL7 node (sansa). We should do this and add it to the narayana matrix job: http://albany.eng.hst.ams2.redhat.com/view/Narayana+BlackTie/job/narayana/ -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2327) wildfly-blacktie does not contain jars in the release

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2327?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-2327: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > wildfly-blacktie does not contain jars in the release > ----------------------------------------------------- > > Key: JBTM-2327 > URL: https://issues.jboss.org/browse/JBTM-2327 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.0.4 > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.0.5 > > > it does not copy the artifact into the module folder as it looks like missing the "copy-module-artifacts="true" in the server-provisioning.xml -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2327) wildfly-blacktie does not contain jars in the release

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2327?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-2327: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/798 > wildfly-blacktie does not contain jars in the release > ----------------------------------------------------- > > Key: JBTM-2327 > URL: https://issues.jboss.org/browse/JBTM-2327 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.0.4 > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.0.5 > > > it does not copy the artifact into the module folder as it looks like missing the "copy-module-artifacts="true" in the server-provisioning.xml -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2327) wildfly-blacktie does not contain jars in the release

by Amos Feng (JIRA)

Amos Feng created JBTM-2327: ------------------------------- Summary: wildfly-blacktie does not contain jars in the release Key: JBTM-2327 URL: https://issues.jboss.org/browse/JBTM-2327 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Affects Versions: 5.0.4 Reporter: Amos Feng Assignee: Amos Feng Priority: Blocker Fix For: 5.0.5 it does not copy the artifact into the module folder as it looks like missing the "copy-module-artifacts="true" in the server-provisioning.xml -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2326) Provide a management interface to see a list of Xids that are being being considered for recovery by the recovery manager

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-2326: ----------------------------------- Summary: Provide a management interface to see a list of Xids that are being being considered for recovery by the recovery manager Key: JBTM-2326 URL: https://issues.jboss.org/browse/JBTM-2326 Project: JBoss Transaction Manager Issue Type: Feature Request Components: JTA, Tooling Reporter: Tom Jenkinson Assignee: Tom Jenkinson Although it is possible to see the list of current transactions in the CLI, for those branches that are available for recovery it can be useful to see the list that the recovery manager is considering. I have often looked in the debugger at this state: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com... so it might be useful to others. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2280) alternative to JNDI

by Stephane Epardaud (JIRA)

[ https://issues.jboss.org/browse/JBTM-2280?page=com.atlassian.jira.plugin.... ] Stephane Epardaud commented on JBTM-2280: ----------------------------------------- Well this sounds great, I hope we can validate that it fixes our specific problem. > alternative to JNDI > ------------------- > > Key: JBTM-2280 > URL: https://issues.jboss.org/browse/JBTM-2280 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gavin King > Assignee: Tom Jenkinson > > So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JNDI-bound datasources. > Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself and other folks who are much better programmers than me have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. > IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. > XADataSource xads = youJustDontNeedToCare(); > DataSource ds = narayana.registerDataSource(xads); > Or something like that. Of course I'm sure I'm missing some subtleties here. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2280) alternative to JNDI

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2280?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2280: ------------------------------------- Hi Stephane, I added a feature over here JBTM-2325 it will be in the next version of Narayana - hope it works for you. I created a forum entry over here if you would like to discuss it further: https://developer.jboss.org/message/909177#909177 Thanks, Tom > alternative to JNDI > ------------------- > > Key: JBTM-2280 > URL: https://issues.jboss.org/browse/JBTM-2280 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gavin King > Assignee: Tom Jenkinson > > So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JNDI-bound datasources. > Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself and other folks who are much better programmers than me have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. > IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. > XADataSource xads = youJustDontNeedToCare(); > DataSource ds = narayana.registerDataSource(xads); > Or something like that. Of course I'm sure I'm missing some subtleties here. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2325) Allow the user to provide a reference to an XADataSource for Transactional Driver

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-2325: ----------------------------------- Summary: Allow the user to provide a reference to an XADataSource for Transactional Driver Key: JBTM-2325 URL: https://issues.jboss.org/browse/JBTM-2325 Project: JBoss Transaction Manager Issue Type: Feature Request Components: Transaction Core Affects Versions: 5.0.4 Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.0.5 Certain environments have class loader constraints that do not let the direct recoverable connection load the users configured XADataSource. It is therefore necessary to provide an implementation that can be passed by reference. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2280) alternative to JNDI

by Stephane Epardaud (JIRA)

[ https://issues.jboss.org/browse/JBTM-2280?page=com.atlassian.jira.plugin.... ] Stephane Epardaud commented on JBTM-2280: ----------------------------------------- So this was closed and then fixed? > alternative to JNDI > ------------------- > > Key: JBTM-2280 > URL: https://issues.jboss.org/browse/JBTM-2280 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gavin King > Assignee: Tom Jenkinson > > So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JNDI-bound datasources. > Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself and other folks who are much better programmers than me have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. > IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. > XADataSource xads = youJustDontNeedToCare(); > DataSource ds = narayana.registerDataSource(xads); > Or something like that. Of course I'm sure I'm missing some subtleties here. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2280) alternative to JNDI

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2280?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-2280: ---------------------------------------- I have updated the ceylon code to use Toms changes that allow the user to provide the datasource (I will raise a ceylon PR after we do the next narayana release). This change means that the ceylon user no longer needs to register his datasources via JNDI. > alternative to JNDI > ------------------- > > Key: JBTM-2280 > URL: https://issues.jboss.org/browse/JBTM-2280 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gavin King > Assignee: Tom Jenkinson > > So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JNDI-bound datasources. > Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself and other folks who are much better programmers than me have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. > IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. > XADataSource xads = youJustDontNeedToCare(); > DataSource ds = narayana.registerDataSource(xads); > Or something like that. Of course I'm sure I'm missing some subtleties here. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues January 2015