[JBoss JIRA] (WFLY-9587) Investigate and introduce capabilities for the transactional subsytems transations/xts/rts
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9587?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-9587:
----------------------------------------
[~ochaloup] Hi!
Just an FYI, long ago I did some experiments related to capabilities and the tx subsystem, mostly trying to work with real use cases in order to work out how the WFCORE stuff should work. I didn't carry on with doing stuff for the tx subsystem because working out what API the capabilities should expose was more than I could take on at the time. And working out that API is really the most important thing. In the tx case it could be a bit complicated.
But anyway, FWIW https://github.com/bstansberry/wildfly/commits/use-cap-req has a couple tx-related commits that might have some useful bits and pieces or at least illustrate some things to think about. There are a couple interesting things about tx that I played with. (Note that that code is way way out of date so it should not serve as a reference for how to use capabilities.)
The interesting bits were:
1) IIOP can consume a cap from tx in order to set up some corba interceptors. 99% of requirers of capabilities end up consuming an MSC service provided by the capability, but *maybe* this IIOP thing is a use case for the "Custom integration APIs provided by a capability" thing discussed on the "Working with WildFly Capabilities" document. TBH though, AFAIK no other code is using that stuff, while MSC services are really widely used. So if the corba interceptor thing can use a service without too much pain that might be better in the long run. Being the only use case for a bit of tech has it's downsides. ;)
2) IIOP and JTS have a circular relationship, which the capability stuff can support. It's unusual though.
3) Whether JTS is available depends on the setting of an attribute in a resource, rather than the existence of the resource. This is also a bit unusual (but allowed.) A bit of a twist though is unfortunately the 'jts' attribute allows expressions. When a management operation runs, all capabilities and requirements must be recorded in Stage.MODEL. But, if a vault expression is used, the expression cannot be reliably resolved until Stage.RUNTIME. For this reason, we now know to disallow expressions on attributes that control capabilities and requirements. In most cases that's not a problem as we guessed long ago that we shouldn't allow expressions on what we used to call "model reference attributes", e.g. things like "socket-binding=http". But this "jts" one is a different kind of case. We can't break compatibility by no longer allowing expressions for this attribute, but the presence of an expression *might* be a problem. The 3rd commit in that branch has some logic meant to deal with this. It might not be the best approach, but I regarded it as ok at the time. The problem really only exists if someone uses a vault expression for the 'jts' attribute. I regard that as an extreme corner case. So extreme that it's a tiny bit tempting to break compatibility and just fail if we hit it.
> Investigate and introduce capabilities for the transactional subsytems transations/xts/rts
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-9587
> URL: https://issues.jboss.org/browse/WFLY-9587
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions, XTS
> Affects Versions: 11.0.0.Final
> Reporter: Ondra Chaloupka
> Assignee: Ondra Chaloupka
>
> The notion of capability is not introduced to the transactional system. The WFLY integration expecting subsystem providing it. The transaction subsystems should support so.
> https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-457) SASL SAML Authentication Mechanism
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-457?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-457:
---------------------------
Comment: was deleted
(was: Sorry, edit: I has bad understood the RFC, the IdP sends authentication statement to the browser/sasl client, which sends it into sasl sever over sasl. There should be no problem in such case...
{panel}
in the form of an authentication statement or failure, using an indirect response via the client browser or the handler (and with an external browser, client control should be passed back to the SASL client).
{panel})
> SASL SAML Authentication Mechanism
> ----------------------------------
>
> Key: ELY-457
> URL: https://issues.jboss.org/browse/ELY-457
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SASL
> Reporter: Darran Lofthouse
> Assignee: Jan Kalina
> Fix For: 2.0.0.Alpha1
>
>
> https://tools.ietf.org/html/rfc6595
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3440) CLI incorrectly parses byte literals
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3440?page=com.atlassian.jira.plugi... ]
Tomas Hofman updated WFCORE-3440:
---------------------------------
Description:
* Deploy two deployments,
* read content hashes of the deployments,
* try to {{:full-replace-deployment}} the first deployment with the content hash of the other one (or any made up content hash for that matter).
The byte values of the content hash are not parsed correctly - whenever there's a value larger than 0x7f (e.g. 0xef), the parsing fails with "Value out of range. Value:"ef" Radix:16".
{code}
[standalone@localhost:9990 /] /deployment=*:read-resource
{
"outcome" => "success",
"result" => [
{
"address" => [("deployment" => "FilterServlet.war")],
"outcome" => "success",
"result" => {
"content" => [{
"hash" => bytes {
0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3,
0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8,
0x97, 0xed, 0x09, 0x33
},
"archive" => undefined
}],
...
}
}, ...
]
}
[standalone@localhost:9990 /] :full-replace-deployment(name=FilterServlet.war, content=[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}])
Failed to parse '[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}]': Value out of range. Value:"ef" Radix:16
was:
* Deploy two deployments,
* read content hashes of the deployments,
* try to {{:full-replace-deployment}} the first deployment with the content hash of the other one (or any made up content hash for that matter).
The byte values of the content hash are not parsed correctly - whenever there's a value larger than 0x7f (e.g. 0xef), the parsing fails with "Value out of range. Value:"ef" Radix:16".
{code}
[standalone@localhost:9990 /] /deployment=*:read-resource
{
"outcome" => "success",
"result" => [
{
"address" => [("deployment" => "FilterServlet.war")],
"outcome" => "success",
"result" => {
"content" => [{
"hash" => bytes {
0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3,
0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8,
0x97, 0xed, 0x09, 0x33
},
"archive" => undefined
}],
...
}
}, ...
]
}
[standalone@localhost:9990 /] :full-replace-deployment(name=FilterServlet.war, content=[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}])
Failed to parse '[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}]': Value out of range. Value:"ef" Radix:16
[standalone@localhost:9990 /] :full-replace-deployment(name=FilterServlet.war, content=[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}])
{code}
> CLI incorrectly parses byte literals
> -------------------------------------
>
> Key: WFCORE-3440
> URL: https://issues.jboss.org/browse/WFCORE-3440
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Alpha3
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> * Deploy two deployments,
> * read content hashes of the deployments,
> * try to {{:full-replace-deployment}} the first deployment with the content hash of the other one (or any made up content hash for that matter).
> The byte values of the content hash are not parsed correctly - whenever there's a value larger than 0x7f (e.g. 0xef), the parsing fails with "Value out of range. Value:"ef" Radix:16".
> {code}
> [standalone@localhost:9990 /] /deployment=*:read-resource
> {
> "outcome" => "success",
> "result" => [
> {
> "address" => [("deployment" => "FilterServlet.war")],
> "outcome" => "success",
> "result" => {
> "content" => [{
> "hash" => bytes {
> 0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3,
> 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8,
> 0x97, 0xed, 0x09, 0x33
> },
> "archive" => undefined
> }],
> ...
> }
> }, ...
> ]
> }
> [standalone@localhost:9990 /] :full-replace-deployment(name=FilterServlet.war, content=[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}])
> Failed to parse '[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}]': Value out of range. Value:"ef" Radix:16
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3440) CLI incorrectly parses byte literals
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3440?page=com.atlassian.jira.plugi... ]
Tomas Hofman updated WFCORE-3440:
---------------------------------
Description:
* Deploy two deployments,
* read content hashes of the deployments,
* try to {{:full-replace-deployment}} the first deployment with the content hash of the other one (or any made up content hash for that matter).
The byte values of the content hash are not parsed correctly - whenever there's a value larger than 0x7f (e.g. 0xef), the parsing fails with "Value out of range. Value:"ef" Radix:16".
{code}
[standalone@localhost:9990 /] /deployment=*:read-resource
{
"outcome" => "success",
"result" => [
{
"address" => [("deployment" => "FilterServlet.war")],
"outcome" => "success",
"result" => {
"content" => [{
"hash" => bytes {
0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3,
0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8,
0x97, 0xed, 0x09, 0x33
},
"archive" => undefined
}],
...
}
}, ...
]
}
[standalone@localhost:9990 /] :full-replace-deployment(name=FilterServlet.war, content=[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}])
Failed to parse '[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}]': Value out of range. Value:"ef" Radix:16
{code}
was:
* Deploy two deployments,
* read content hashes of the deployments,
* try to {{:full-replace-deployment}} the first deployment with the content hash of the other one (or any made up content hash for that matter).
The byte values of the content hash are not parsed correctly - whenever there's a value larger than 0x7f (e.g. 0xef), the parsing fails with "Value out of range. Value:"ef" Radix:16".
{code}
[standalone@localhost:9990 /] /deployment=*:read-resource
{
"outcome" => "success",
"result" => [
{
"address" => [("deployment" => "FilterServlet.war")],
"outcome" => "success",
"result" => {
"content" => [{
"hash" => bytes {
0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3,
0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8,
0x97, 0xed, 0x09, 0x33
},
"archive" => undefined
}],
...
}
}, ...
]
}
[standalone@localhost:9990 /] :full-replace-deployment(name=FilterServlet.war, content=[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}])
Failed to parse '[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}]': Value out of range. Value:"ef" Radix:16
> CLI incorrectly parses byte literals
> -------------------------------------
>
> Key: WFCORE-3440
> URL: https://issues.jboss.org/browse/WFCORE-3440
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Alpha3
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> * Deploy two deployments,
> * read content hashes of the deployments,
> * try to {{:full-replace-deployment}} the first deployment with the content hash of the other one (or any made up content hash for that matter).
> The byte values of the content hash are not parsed correctly - whenever there's a value larger than 0x7f (e.g. 0xef), the parsing fails with "Value out of range. Value:"ef" Radix:16".
> {code}
> [standalone@localhost:9990 /] /deployment=*:read-resource
> {
> "outcome" => "success",
> "result" => [
> {
> "address" => [("deployment" => "FilterServlet.war")],
> "outcome" => "success",
> "result" => {
> "content" => [{
> "hash" => bytes {
> 0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3,
> 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8,
> 0x97, 0xed, 0x09, 0x33
> },
> "archive" => undefined
> }],
> ...
> }
> }, ...
> ]
> }
> [standalone@localhost:9990 /] :full-replace-deployment(name=FilterServlet.war, content=[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}])
> Failed to parse '[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}]': Value out of range. Value:"ef" Radix:16
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3440) CLI incorrectly parses byte literals
by Tomas Hofman (JIRA)
Tomas Hofman created WFCORE-3440:
------------------------------------
Summary: CLI incorrectly parses byte literals
Key: WFCORE-3440
URL: https://issues.jboss.org/browse/WFCORE-3440
Project: WildFly Core
Issue Type: Bug
Components: CLI
Affects Versions: 4.0.0.Alpha3
Reporter: Tomas Hofman
Assignee: Tomas Hofman
* Deploy two deployments,
* read content hashes of the deployments,
* try to {{:full-replace-deployment}} the first deployment with the content hash of the other one (or any made up content hash for that matter).
The byte values of the content hash are not parsed correctly - whenever there's a value larger than 0x7f (e.g. 0xef), the parsing fails with "Value out of range. Value:"ef" Radix:16".
{code}
[standalone@localhost:9990 /] /deployment=*:read-resource
{
"outcome" => "success",
"result" => [
{
"address" => [("deployment" => "FilterServlet.war")],
"outcome" => "success",
"result" => {
"content" => [{
"hash" => bytes {
0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3,
0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8,
0x97, 0xed, 0x09, 0x33
},
"archive" => undefined
}],
...
}
}, ...
]
}
[standalone@localhost:9990 /] :full-replace-deployment(name=FilterServlet.war, content=[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}])
Failed to parse '[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}]': Value out of range. Value:"ef" Radix:16
[standalone@localhost:9990 /] :full-replace-deployment(name=FilterServlet.war, content=[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}])
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-9585) Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski reassigned WFLY-9585:
------------------------------------
Assignee: Tomasz Adamski
> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
> Key: WFLY-9585
> URL: https://issues.jboss.org/browse/WFLY-9585
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
> Reporter: Shing Lam
> Assignee: Tomasz Adamski
> Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
>
> We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used. But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected.
> We have in the ejb-jar.xml
> {code:xml}
> <enterprise-beans>
> <session>
> <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
> <resource-ref>
> <res-ref-name>jdbc/RMDataSource</res-ref-name>
> <res-type>javax.sql.DataSource</res-type>
> <res-auth>Container</res-auth>
> </resource-ref>
> <persistence-context-ref>
> <persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name>
> </persistence-context-ref>
> </session>
> {code}
> and in jboss-ejb3.xml
> {code:xml}
> <jboss:enterprise-beans>
> <jboss:ejb>
> <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
> <resource-ref>
> <res-ref-name>jdbc/RMDataSource</res-ref-name>
> <res-type>javax.sql.DataSource</res-type>
> <lookup-name>java:jboss/jdbc/RMDataSource</lookup-name>
> </resource-ref>
> </jboss:ejb>
> {code}
> the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4.
> But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;"
> If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB.
> Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months