[JBoss JIRA] (WFLY-7075) proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-7075:
------------------------------------
Regarding the lack of feedback on the JPA_SPEC-6 issue, do you disagree with the current JPA 2.1 spec wording in 7.6.4.1:
{quote}
If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
associated with the JTA transaction and the target component specifies a persistence context of
type SynchronizationType.SYNCHRONIZED, the IllegalStateException is
thrown by the container.
{quote}
>From the JPA_SPEC-6 issue, the description is:
{quote}
Whether or not to propagate a persistence context of type SynchronizationType.UNSYNCHRONIZED to a component with persistence context of type SynchronizationType.SYNCHRONIZED if the former has been joined to the JTA transaction.
{quote}
IMO, I think it could be useful for you to also express your opinion about JPA_SPEC-6 on the users(a)jpa-spec.java.net mailing list. You could link to the WFLY-7075 jira as well, in that discussion. Even if your feedback about JPA_SPEC-6 is late, it is always useful to discuss why a change could help you, so that the change might be considered in a future JPA spec version.
> proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> 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.
> *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, 10 months
[JBoss JIRA] (WFLY-7075) proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-7075:
-------------------------------
Security: (was: Red Hat Internal)
> proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> 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.
> *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, 10 months
[JBoss JIRA] (WFLY-7076) Elytron introduces SSL/TLS protocol constraints
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7076?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-5932 to WFLY-7076:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7076 (was: JBEAP-5932)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR4)
> Elytron introduces SSL/TLS protocol constraints
> -----------------------------------------------
>
> Key: WFLY-7076
> URL: https://issues.jboss.org/browse/WFLY-7076
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> {noformat}
> "protocols" => {
> "type" => LIST,
> "description" => "The enabled protocols.",
> "expressions-allowed" => true,
> "nillable" => false,
> "allowed" => [
> "SSLv2",
> "SSLv3",
> "TLSv1",
> "TLSv1_1",
> "TLSv1_2",
> "TLSv1_3"
> ],
> "value-type" => STRING,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {noformat}
> Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values?
> Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value.
> IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java.
> Note, IBM java already today defines little bit different protocols set [2]
> I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place.
> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN...
> [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
by Viacheslav Astapkovich (JIRA)
[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ]
Viacheslav Astapkovich commented on WFLY-6127:
----------------------------------------------
Registered as: WFLY-7075
> Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6127
> URL: https://issues.jboss.org/browse/WFLY-6127
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 9.0.2.Final, 10.0.0.Final
> Reporter: Mazen Mahmoud
> Assignee: Scott Marlow
> Priority: Blocker
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
> Attachments: server-log.txt
>
>
> SPEC: If a component is called and the JTA transaction is propagated into that component:
> If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
> associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container
> We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED)
> stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED)
> SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED):
> PC is propagated from SFB1 to SFB2 without any exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1127) SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1127?page=com.atlassian.jira.plugi... ]
Dan Berindei commented on WFCORE-1127:
--------------------------------------
This is going to be a problem again with JGroups 4.0. JGroups always creates the socket first, and binds it later. {{ManagedSocketFactoryTest}} explicitly tests that unbound sockets are registered with the (mocked) {{SocketBindingManager.UnnamedBindingRegistry}}.
JGroups prior to version 4.0 "fixes" this by always replacing the {{ManagedSocketFactory}} set by {{JChannelFactory.init()}} with its own {{DefaultSocketFactory}} in {{JChannel.startStack()}}. But JGroups 4.0 actually tries to use the {{SocketFactory}} injected by the JGroups subsystem, and fails with an {{IllegalStateException}}.
> SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-1127
> URL: https://issues.jboss.org/browse/WFCORE-1127
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.1.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.2.Final
>
>
> A failure like this isn't necessary:
> {code}
> 08:02:23,475 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector: java.lang.IllegalStateException
> at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:96)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalStateException
> at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.unregisterBinding(SocketBindingManagerImpl.java:501)
> at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73)
> at org.jboss.as.clustering.jgroups.ManagedSocketFactory.close(ManagedSocketFactory.java:148)
> at org.jgroups.protocols.UDP.closeUnicastSocket(UDP.java:577)
> at org.jgroups.protocols.UDP.destroySockets(UDP.java:429)
> at org.jgroups.protocols.UDP.start(UDP.java:274)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> at org.jgroups.JChannel.startStack(JChannel.java:890)
> at org.jgroups.JChannel._preConnect(JChannel.java:553)
> at org.jgroups.JChannel.connect(JChannel.java:288)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94)
> ... 5 more
> {code}
> If there's no socket address, it should just move on.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1772) /core-service=capability-registry:get-provider-points only returning a single provider point.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1772?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-1772:
-------------------------------------
Labels: affects_elytron (was: )
> /core-service=capability-registry:get-provider-points only returning a single provider point.
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-1772
> URL: https://issues.jboss.org/browse/WFCORE-1772
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: This was reproduced using wildfly/master running the standalone-elytron.xml configuration.
> Reporter: Darran Lofthouse
> Assignee: Tomaz Cerar
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha8
>
>
> Running the following: -
> {noformat}
> [standalone@localhost:9990 /] /core-service=capability-registry:get-provider-points(name=org.wildfly.security.security-realm)
> {
> "outcome" => "success",
> "result" => ["/subsystem=elytron/filesystem-realm=*"]
> }
> {noformat}
> However there are other resources that can provide this capability e.g.
> {noformat}
> [standalone@localhost:9990 /] ./subsystem=elytron/properties-realm=*:read-resource-description
> {
> "outcome" => "success",
> "result" => [{
> "address" => [
> ("subsystem" => "elytron"),
> ("properties-realm" => "*")
> ],
> "outcome" => "success",
> "result" => {
> "description" => "A security realm definition backed by properties files.",
> "capabilities" => [{
> "name" => "org.wildfly.security.security-realm",
> "dynamic" => true
> }],
> "attributes" => {
> "groups-attribute" => {
> "type" => STRING,
> "description" => "The name of the attribute in the returned AuthorizationIdentity that should contain the group membership information for the identity.",
> "expressions-allowed" => true,
> "nillable" => true,
> "default" => "groups",
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> "groups-properties" => {
> "type" => OBJECT,
> "description" => "The properties file containing the users and their groups.",
> "expressions-allowed" => false,
> "nillable" => true,
> "value-type" => {
> "path" => {
> "type" => STRING,
> "description" => "The path to the file containing the users and their groups.",
> "expressions-allowed" => true,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "relative-to" => {
> "type" => STRING,
> "description" => "The pre-defined path the path is relative to.",
> "expressions-allowed" => true,
> "nillable" => true,
> "requires" => ["path"],
> "min-length" => 1L,
> "max-length" => 2147483647L
> }
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> "plain-text" => {
> "type" => BOOLEAN,
> "description" => "Are the passwords store in plain text within the properties file?",
> "expressions-allowed" => true,
> "nillable" => true,
> "default" => false,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> "synchronized" => {
> "type" => STRING,
> "description" => "The time the properties files that back this realm were last loaded.",
> "expressions-allowed" => false,
> "nillable" => false,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-only",
> "storage" => "runtime"
> },
> "users-properties" => {
> "type" => OBJECT,
> "description" => "The properties file containing the users and their passwords.",
> "expressions-allowed" => false,
> "nillable" => false,
> "value-type" => {
> "path" => {
> "type" => STRING,
> "description" => "The path to the file containing the users and their passwords.",
> "expressions-allowed" => true,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "relative-to" => {
> "type" => STRING,
> "description" => "The pre-defined path the path is relative to.",
> "expressions-allowed" => true,
> "nillable" => true,
> "requires" => ["path"],
> "min-length" => 1L,
> "max-length" => 2147483647L
> }
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> }
> },
> "operations" => undefined,
> "notifications" => undefined,
> "children" => {}
> }
> }]
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1772) /core-service=capability-registry:get-provider-points only returning a single provider point.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-1772:
----------------------------------------
Summary: /core-service=capability-registry:get-provider-points only returning a single provider point.
Key: WFCORE-1772
URL: https://issues.jboss.org/browse/WFCORE-1772
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Environment: This was reproduced using wildfly/master running the standalone-elytron.xml configuration.
Reporter: Darran Lofthouse
Assignee: Tomaz Cerar
Fix For: 3.0.0.Alpha8
Running the following: -
{noformat}
[standalone@localhost:9990 /] /core-service=capability-registry:get-provider-points(name=org.wildfly.security.security-realm)
{
"outcome" => "success",
"result" => ["/subsystem=elytron/filesystem-realm=*"]
}
{noformat}
However there are other resources that can provide this capability e.g.
{noformat}
[standalone@localhost:9990 /] ./subsystem=elytron/properties-realm=*:read-resource-description
{
"outcome" => "success",
"result" => [{
"address" => [
("subsystem" => "elytron"),
("properties-realm" => "*")
],
"outcome" => "success",
"result" => {
"description" => "A security realm definition backed by properties files.",
"capabilities" => [{
"name" => "org.wildfly.security.security-realm",
"dynamic" => true
}],
"attributes" => {
"groups-attribute" => {
"type" => STRING,
"description" => "The name of the attribute in the returned AuthorizationIdentity that should contain the group membership information for the identity.",
"expressions-allowed" => true,
"nillable" => true,
"default" => "groups",
"min-length" => 1L,
"max-length" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "resource-services"
},
"groups-properties" => {
"type" => OBJECT,
"description" => "The properties file containing the users and their groups.",
"expressions-allowed" => false,
"nillable" => true,
"value-type" => {
"path" => {
"type" => STRING,
"description" => "The path to the file containing the users and their groups.",
"expressions-allowed" => true,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
},
"relative-to" => {
"type" => STRING,
"description" => "The pre-defined path the path is relative to.",
"expressions-allowed" => true,
"nillable" => true,
"requires" => ["path"],
"min-length" => 1L,
"max-length" => 2147483647L
}
},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "resource-services"
},
"plain-text" => {
"type" => BOOLEAN,
"description" => "Are the passwords store in plain text within the properties file?",
"expressions-allowed" => true,
"nillable" => true,
"default" => false,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "resource-services"
},
"synchronized" => {
"type" => STRING,
"description" => "The time the properties files that back this realm were last loaded.",
"expressions-allowed" => false,
"nillable" => false,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-type" => "read-only",
"storage" => "runtime"
},
"users-properties" => {
"type" => OBJECT,
"description" => "The properties file containing the users and their passwords.",
"expressions-allowed" => false,
"nillable" => false,
"value-type" => {
"path" => {
"type" => STRING,
"description" => "The path to the file containing the users and their passwords.",
"expressions-allowed" => true,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
},
"relative-to" => {
"type" => STRING,
"description" => "The pre-defined path the path is relative to.",
"expressions-allowed" => true,
"nillable" => true,
"requires" => ["path"],
"min-length" => 1L,
"max-length" => 2147483647L
}
},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "resource-services"
}
},
"operations" => undefined,
"notifications" => undefined,
"children" => {}
}
}]
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1771) CLI - Tab completion in composite operation throws IAE
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1771?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-1771:
-----------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1784
> CLI - Tab completion in composite operation throws IAE
> ------------------------------------------------------
>
> Key: WFCORE-1771
> URL: https://issues.jboss.org/browse/WFCORE-1771
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha7
> Reporter: Michal Petrov
> Assignee: Jean-Francois Denise
>
> Getting an exception when trying to make a composite operation
> {code}
> [standalone@localhost:9990 /] :composite(steps=[{aException in thread "Aesh Process Loop 1409160703" java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:139)
> at org.jboss.dmr.ModelNode.keys(ModelNode.java:1378)
> at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:502)
> at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:332)
> at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:254)
> at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:74)
> at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:134)
> at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63)
> at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143)
> at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:155)
> at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:423)
> at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165)
> at org.jboss.aesh.console.Console.processInternalOperation(Console.java:773)
> at org.jboss.aesh.console.Console.execute(Console.java:733)
> at org.jboss.aesh.console.Console.access$900(Console.java:73)
> at org.jboss.aesh.console.Console$6.run(Console.java:642)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Happens only for certain strings, e.g.
> * {{:composite(steps=\[{a<TAB>}} fails
> * {{:composite(steps=\[a<TAB>}} doesn't fail (suggests "," or "]")
> * {{:composite(steps=\[a=<TAB>}} fails
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months