[JBoss JIRA] (JBTM-2281) Merge the documentation manuals together
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2281?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2281:
--------------------------------
Description:
The documentation for our project is available here:
Narayana Documentation 5.0.2.Final - JBoss Community
As you can see it consists of several downloads including multiple books, links to various JavaDocs and some IDL files. Personally I think it might be easier to locate documentation entries if there is a single document to consult and a single JavaDoc link. I consulted our users whether anyone would object to us producing a single document and single JavaDoc set and received no objection. I am also thinking of no longer publishing the IDL as separate files as these are always tagged and available in our repo.
One way or another we need to make it clear in the docs what is in product and what is in project. Its not quite so important for our community users to know this but when translating docs into product manuals it is crucial. Currently this is done because everything under https://github.com/jbosstm/documentation/tree/master/docs is product related and things one level up are various community projects. An obvious way to merge the docs is merge everything under docs and then everything under ../* except docs - i.e. 2 manuals
was:
The documentation for our project is available here:
Narayana Documentation 5.0.2.Final - JBoss Community
As you can see it consists of several downloads including multiple books, links to various JavaDocs and some IDL files. Personally I think it might be easier to locate documentation entries if there is a single document to consult and a single JavaDoc link. I consulted our users whether anyone would object to us producing a single document and single JavaDoc set and received no objection. I am also thinking of no longer publishing the IDL as separate files as these are always tagged and available in our repo.
> Merge the documentation manuals together
> ----------------------------------------
>
> Key: JBTM-2281
> URL: https://issues.jboss.org/browse/JBTM-2281
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: Documentation
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
>
> The documentation for our project is available here:
> Narayana Documentation 5.0.2.Final - JBoss Community
>
> As you can see it consists of several downloads including multiple books, links to various JavaDocs and some IDL files. Personally I think it might be easier to locate documentation entries if there is a single document to consult and a single JavaDoc link. I consulted our users whether anyone would object to us producing a single document and single JavaDoc set and received no objection. I am also thinking of no longer publishing the IDL as separate files as these are always tagged and available in our repo.
> One way or another we need to make it clear in the docs what is in product and what is in project. Its not quite so important for our community users to know this but when translating docs into product manuals it is crucial. Currently this is done because everything under https://github.com/jbosstm/documentation/tree/master/docs is product related and things one level up are various community projects. An obvious way to merge the docs is merge everything under docs and then everything under ../* except docs - i.e. 2 manuals
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JBTM-2281) Merge the documentation manuals together
by Tom Jenkinson (JIRA)
Tom Jenkinson created JBTM-2281:
-----------------------------------
Summary: Merge the documentation manuals together
Key: JBTM-2281
URL: https://issues.jboss.org/browse/JBTM-2281
Project: JBoss Transaction Manager
Issue Type: Feature Request
Components: Documentation
Reporter: Tom Jenkinson
Assignee: Gytis Trikleris
The documentation for our project is available here:
Narayana Documentation 5.0.2.Final - JBoss Community
As you can see it consists of several downloads including multiple books, links to various JavaDocs and some IDL files. Personally I think it might be easier to locate documentation entries if there is a single document to consult and a single JavaDoc link. I consulted our users whether anyone would object to us producing a single document and single JavaDoc set and received no objection. I am also thinking of no longer publishing the IDL as separate files as these are always tagged and available in our repo.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[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, I think [~gavinking] tried to refactor it and failed because the TCCL calls were actually working by accident/luck rather than by design. So when he refactored it everything stopped working and he could not figure out how to fix it.
> 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.1#6329)
10 years, 2 months
[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 can look into providing an implementation using this approach. Our docs do say "This is not recommended, but provides a fallback for environments where use of JNDI is not feasible" but I do not know why it's not recommended - I will find out.
But given that we have ceylon.transaction fully working with the JNDI approach why do we need to jettison its use?
> 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.1#6329)
10 years, 2 months
[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:
-----------------------------------------
[~mmusgrov]: would this be enough to get rid of JNDI for us entirely then?
> 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.1#6329)
10 years, 2 months
[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 Gavin,
This would be best as a discussion on the Narayana forum: https://community.jboss.org/en/jbosstm
Two brief points:
1. Narayana is not a JCA implementation, its a transaction manager. The core transaction manager is not connection aware, it is however XAResource aware and so for spec compliance the psuedocode you showed would be closest phrased as:
XADataSource xads = youJustDontNeedTo();
XAResource xar = xads.getXAConnection().getXAResource();
narayana.getTransactionManager().getTransaction().enlistResource(xar)
2. However, we do have something called a transactional driver which does broadly what you are speaking of, its **not in product** but does allow you to pass an XADataSource to it. I have just updated our unit test to use h2 so you can see it in action: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jdbc/tests/clas...
I think we should close this as not a bug and move the discussion onto the forum.
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.1#6329)
10 years, 2 months
[JBoss JIRA] (JBTM-2280) alternative to JNDI
by Gavin King (JIRA)
[ https://issues.jboss.org/browse/JBTM-2280?page=com.atlassian.jira.plugin.... ]
Gavin King commented on JBTM-2280:
----------------------------------
Well, I guess it's _similar_, but not quite the same since that other issue is about the CDI `BeanManager`, not about `DataSource`s.
> 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.1#6329)
10 years, 2 months
[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:
-----------------------------------------
Suggestimate suggests that this is similar to JBTM-2225, which appears to be true, no?
> 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.1#6329)
10 years, 2 months
[JBoss JIRA] (JBTM-2280) alternative to JNDI
by Gavin King (JIRA)
[ https://issues.jboss.org/browse/JBTM-2280?page=com.atlassian.jira.plugin.... ]
Gavin King updated JBTM-2280:
-----------------------------
Description:
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.
was:
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 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.
> 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.1#6329)
10 years, 2 months
[JBoss JIRA] (JBTM-2280) alternative to JNDI
by Gavin King (JIRA)
[ https://issues.jboss.org/browse/JBTM-2280?page=com.atlassian.jira.plugin.... ]
Gavin King updated JBTM-2280:
-----------------------------
Description:
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 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.
was:
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 JDNI-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 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.
> 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 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.1#6329)
10 years, 2 months