[JBoss JIRA] (WFCORE-1783) CLI GUI throws exception when editing boolean attribute with expression
by Ivo Hrádek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1783?page=com.atlassian.jira.plugi... ]
Ivo Hrádek edited comment on WFCORE-1783 at 9/12/16 8:16 AM:
-------------------------------------------------------------
Hi,
I've made simple PR [1] to fix this.
Also note that boolean attributes, can be set only to true/false through modal dialog in GUI, however you can edit _cmd_ input in order to set it to some expression.
btw: I think this should be in WFCORE.
--
[1] https://github.com/wildfly/wildfly-core/pull/1789
was (Author: ihradek):
Hi,
I've made simple PR [1] to fix this.
Also note that boolean attributes, can be set only to true/false through modal dialog in GUI, however you can edit *cmd* input in order to set it to some expression.
btw: I think this should be in WFCORE.
--
[1] https://github.com/wildfly/wildfly-core/pull/1789
> CLI GUI throws exception when editing boolean attribute with expression
> -----------------------------------------------------------------------
>
> Key: WFCORE-1783
> URL: https://issues.jboss.org/browse/WFCORE-1783
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: John Mazzitelli
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> When in the CLI GUI, if you try to edit a boolean attribute whose current value is an expression then an exception is thrown and you can't edit it - the popup dialog is really small and blank.
> See "Steps to Reproduce" for replication procedures.
> Here's the exception:
> java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66)
> at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:262)
> at org.jboss.as.cli.gui.OperationDialog$RequestProp.setInputComponentValue(OperationDialog.java:428)
> at org.jboss.as.cli.gui.OperationDialog$RequestProp.<init>(OperationDialog.java:336)
> at org.jboss.as.cli.gui.OperationDialog.setProps(OperationDialog.java:157)
> at org.jboss.as.cli.gui.OperationDialog.<init>(OperationDialog.java:73)
> at org.jboss.as.cli.gui.OperationMenu$OperationAction.actionPerformed(OperationMenu.java:152)
> at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
> at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
> at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
> at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
> at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
> at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:833)
> at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:877)
> at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289)
> at java.awt.Component.processMouseEvent(Component.java:6535)
> at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
> at java.awt.Component.processEvent(Component.java:6300)
> at java.awt.Container.processEvent(Container.java:2236)
> at java.awt.Component.dispatchEventImpl(Component.java:4891)
> at java.awt.Container.dispatchEventImpl(Container.java:2294)
> at java.awt.Component.dispatchEvent(Component.java:4713)
> at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888)
> at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466)
> at java.awt.Container.dispatchEventImpl(Container.java:2280)
> at java.awt.Window.dispatchEventImpl(Window.java:2750)
> at java.awt.Component.dispatchEvent(Component.java:4713)
> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
> at java.awt.EventQueue.access$500(EventQueue.java:97)
> at java.awt.EventQueue$3.run(EventQueue.java:709)
> at java.awt.EventQueue$3.run(EventQueue.java:703)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
> at java.awt.EventQueue$4.run(EventQueue.java:731)
> at java.awt.EventQueue$4.run(EventQueue.java:729)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1783) CLI GUI throws exception when editing boolean attribute with expression
by Ivo Hrádek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1783?page=com.atlassian.jira.plugi... ]
Ivo Hrádek moved WFLY-6739 to WFCORE-1783:
------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1783 (was: WFLY-6739)
Component/s: CLI
(was: CLI)
Affects Version/s: (was: 10.0.0.Final)
> CLI GUI throws exception when editing boolean attribute with expression
> -----------------------------------------------------------------------
>
> Key: WFCORE-1783
> URL: https://issues.jboss.org/browse/WFCORE-1783
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: John Mazzitelli
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> When in the CLI GUI, if you try to edit a boolean attribute whose current value is an expression then an exception is thrown and you can't edit it - the popup dialog is really small and blank.
> See "Steps to Reproduce" for replication procedures.
> Here's the exception:
> java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66)
> at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:262)
> at org.jboss.as.cli.gui.OperationDialog$RequestProp.setInputComponentValue(OperationDialog.java:428)
> at org.jboss.as.cli.gui.OperationDialog$RequestProp.<init>(OperationDialog.java:336)
> at org.jboss.as.cli.gui.OperationDialog.setProps(OperationDialog.java:157)
> at org.jboss.as.cli.gui.OperationDialog.<init>(OperationDialog.java:73)
> at org.jboss.as.cli.gui.OperationMenu$OperationAction.actionPerformed(OperationMenu.java:152)
> at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
> at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
> at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
> at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
> at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
> at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:833)
> at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:877)
> at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289)
> at java.awt.Component.processMouseEvent(Component.java:6535)
> at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
> at java.awt.Component.processEvent(Component.java:6300)
> at java.awt.Container.processEvent(Container.java:2236)
> at java.awt.Component.dispatchEventImpl(Component.java:4891)
> at java.awt.Container.dispatchEventImpl(Container.java:2294)
> at java.awt.Component.dispatchEvent(Component.java:4713)
> at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888)
> at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466)
> at java.awt.Container.dispatchEventImpl(Container.java:2280)
> at java.awt.Window.dispatchEventImpl(Window.java:2750)
> at java.awt.Component.dispatchEvent(Component.java:4713)
> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
> at java.awt.EventQueue.access$500(EventQueue.java:97)
> at java.awt.EventQueue$3.run(EventQueue.java:709)
> at java.awt.EventQueue$3.run(EventQueue.java:703)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
> at java.awt.EventQueue$4.run(EventQueue.java:731)
> at java.awt.EventQueue$4.run(EventQueue.java:729)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6739) CLI GUI throws exception when editing boolean attribute with expression
by Ivo Hrádek (JIRA)
[ https://issues.jboss.org/browse/WFLY-6739?page=com.atlassian.jira.plugin.... ]
Ivo Hrádek commented on WFLY-6739:
----------------------------------
Hi,
I've made simple PR [1] to fix this.
Also note that boolean attributes, can be set only to true/false through modal dialog in GUI, however you can edit *cmd* input in order to set it to some expression.
btw: I think this should be in WFCORE.
--
[1] https://github.com/wildfly/wildfly-core/pull/1789
> CLI GUI throws exception when editing boolean attribute with expression
> -----------------------------------------------------------------------
>
> Key: WFLY-6739
> URL: https://issues.jboss.org/browse/WFLY-6739
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 10.0.0.Final
> Reporter: John Mazzitelli
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> When in the CLI GUI, if you try to edit a boolean attribute whose current value is an expression then an exception is thrown and you can't edit it - the popup dialog is really small and blank.
> See "Steps to Reproduce" for replication procedures.
> Here's the exception:
> java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66)
> at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:262)
> at org.jboss.as.cli.gui.OperationDialog$RequestProp.setInputComponentValue(OperationDialog.java:428)
> at org.jboss.as.cli.gui.OperationDialog$RequestProp.<init>(OperationDialog.java:336)
> at org.jboss.as.cli.gui.OperationDialog.setProps(OperationDialog.java:157)
> at org.jboss.as.cli.gui.OperationDialog.<init>(OperationDialog.java:73)
> at org.jboss.as.cli.gui.OperationMenu$OperationAction.actionPerformed(OperationMenu.java:152)
> at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
> at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
> at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
> at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
> at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
> at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:833)
> at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:877)
> at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289)
> at java.awt.Component.processMouseEvent(Component.java:6535)
> at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
> at java.awt.Component.processEvent(Component.java:6300)
> at java.awt.Container.processEvent(Container.java:2236)
> at java.awt.Component.dispatchEventImpl(Component.java:4891)
> at java.awt.Container.dispatchEventImpl(Container.java:2294)
> at java.awt.Component.dispatchEvent(Component.java:4713)
> at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888)
> at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466)
> at java.awt.Container.dispatchEventImpl(Container.java:2280)
> at java.awt.Window.dispatchEventImpl(Window.java:2750)
> at java.awt.Component.dispatchEvent(Component.java:4713)
> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
> at java.awt.EventQueue.access$500(EventQueue.java:97)
> at java.awt.EventQueue$3.run(EventQueue.java:709)
> at java.awt.EventQueue$3.run(EventQueue.java:703)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
> at java.awt.EventQueue$4.run(EventQueue.java:731)
> at java.awt.EventQueue$4.run(EventQueue.java:729)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JGRP-2099) TP: one single thread pool
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2099?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2099:
--------------------------------
Hmm... instead of spawning a new thread when the thread pool is full, perhaps an internal thread pool (no queue, min=0, max=4) that's not exposed to configuration would be better: internal requests received within the idle timeout would allow us to reuse the thread(s) spawned by the pool.
This would not be more costly that spawning a new thread every time...
A {{RejectedExecutionException}} could still be handled by spawning a new thread, but this should almost never occur.
> TP: one single thread pool
> --------------------------
>
> Key: JGRP-2099
> URL: https://issues.jboss.org/browse/JGRP-2099
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Currently, TP has 4 thread pools:
> * OOB
> * Regular
> * Internal
> * Timer (used by TimeScheduler3)
> The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks.
> This not only simplify configuration (1 config section rather than 4), but also reduces the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result.
> The new common pool would have the following characteristics:
> * Default rejection policy of "abort" (so we can handle pool exhaustion)
> * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed
> * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks
> * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1774) Use core-service=capability-registry to provide tab completion suggestions for model reference attributes
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1774?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1774:
----------------------------------------------
[~brian.stansberry], I am wandering if looking at the last part of the name of a resource would allow to fully identify the capability. There is 2 * in the pattern, so the dynamic part of the capability should be composed of 2 items.
For example: org.wildly.clustering.transport.diagnostics-socket-binding ==> /subsystem=jgroups/stack=*/transport=*
We should propose: tcp.TCP, udp.UDP, ...
I have been looking at the /core-service=capability-registry resource.capabilities list content. This list seems to contain all the registered capabilities. It seems that it contains enough information to complete capabilities. Am I right or does the resources tree contains more?
A possible algorithm would be to:
1 Retrieve all capabilities from the registry
2 Expose all capabilities names that starts with the static part (retrieved in the capability-reference). static part being removed from the names exposed by completion.
For the diagnostics-socket-binding example, the registry contains:
org.wildfly.clustering.transport.diagnostics-socket-binding.tcp.TCP
org.wildfly.clustering.transport.diagnostics-socket-binding.udp.UDP
org.wildfly.clustering.transport.diagnostics-socket-binding.anothertcp.TCP
The completion would propose:
tcp.TCP
udp.UDP
anothertcp.TCP
I have a question related to static capabilities. Does it makes sense to have an argument to reference one? What would be the value for a static one?
Thanks.
> Use core-service=capability-registry to provide tab completion suggestions for model reference attributes
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1774
> URL: https://issues.jboss.org/browse/WFCORE-1774
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Reporter: Brian Stansberry
> Assignee: Jean-Francois Denise
>
> A "model reference" attribute is one whose value points to some other aspect of the model, e.g. "socket-binding" => "http". With the capability and requirement function we are rolling out in the server[1] we have the ability for clients to understand what values are valid for the reference. This should be used in CLI tab completion.
> [~claudio4j] has utitlized this for UI suggestions in HAL so he or Harald can be a resource for the exact algorithm that has worked best. Here's the basics though:
> 1) This applies to attributes or operation params where the read-resource-description or read-operation-description includes a "capability-reference" field. The value of the field shows the static portion of the capability name. For example an attribute that's used for a socket binding name would show "org.wildfly.network.socket-binding".
> 2) The [/host=*]/core-service=capability resource shows information about what capabilities are available on the system. This includes 2 attributes "capabilities" and "possible-capabilities". The former shows the specific capabilities that are actually present; i.e. the resources that provide the capability are part of the configuration. The latter shows capabilities that could be present, given the installed extensions, if the relevant resources were added.
> That resource includes two operations "get-capability" and "get-provider-points" that can show more details about what resources provide a capability:
> {code}
> [standalone@embedded core-service=capability-registry] :get-provider-points(name=org.wildfly.network.socket-binding)
> {
> "outcome" => "success",
> "result" => ["/socket-binding-group=*/socket-binding=*"]
> }
> {code}
> That tells you that capabilities of type org.wildfly.network.socket-binding are registered by resources using address pattern /socket-binding-group=*/socket-binding=*
> 3) With that information the CLI can see what resources actually exist on the system and use the value portion of the final element of their address as the suggestion list for tab completion.
> HAL may be doing something slightly different from what I describe; they have concrete experience.
> It may be possible for the API exposed by core-service=capability-registry to be enhanced to make this easier. If you want something, please don't hesitate to ask Tomaz Cerar or myself.
> [1] https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-7091) Not able to configure list of key/trust managers on elytron ssl context.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7091?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-7091:
----------------------------------------
The references capability is of multiple key-managers and trust managers: -
https://developer.jboss.org/wiki/WildFlySecurityElytron-CapabilitiesAndRe...
Although the API is about having an array with multiple 'Managers' the reality is this always tends to be an array of length 1 containing just an X.509 manager. If aggregation is ever justified instead of supporting the list here I think I would add aggregate-key/trust-manager resources which is a similar pattern to how other components are currently aggregated,
> Not able to configure list of key/trust managers on elytron ssl context.
> ------------------------------------------------------------------------
>
> Key: WFLY-7091
> URL: https://issues.jboss.org/browse/WFLY-7091
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> Base on xsd/model documentation key-managers and trust-managers attributes seems to be meant to hold list of managers. That also comply to SSLContext init() method [1]. Hovewer, in elytron subsystem, they are of type string and any my tries to set list (space/comma delimited list) failed.
> XSD documentation
> * key-managers - Reference to the KeyManagers to be used by this SSLContext.
> * trust-managers - Reference to the TrustManagers to be used by this SSLContext.
> Model description:
> {noformat}
> "key-managers" => {
> "type" => STRING,
> "description" => "Reference to the key managers to use within the SSLContext.",
> "expressions-allowed" => false,
> "nillable" => true,
> "capability-reference" => "org.wildfly.security.key-managers",
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> "trust-managers" => {
> "type" => STRING,
> "description" => "Reference to the trust managers to use within the SSLContext.",
> "expressions-allowed" => false,
> "nillable" => true,
> "capability-reference" => "org.wildfly.security.trust-managers",
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {noformat}
> [1] https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLContext.html#i...
--
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 Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7076?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-7076:
----------------------------------------
For the subsystem yes we need to drop it to being String based, within Elytron start a discussion in HipChat when everyone around as we have the filtering mechanism there that makes use of the enum.
> 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: Jan Kalina
>
> {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] (WFCORE-1782) Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct
by Dietrich Schmidt (JIRA)
Dietrich Schmidt created WFCORE-1782:
----------------------------------------
Summary: Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct
Key: WFCORE-1782
URL: https://issues.jboss.org/browse/WFCORE-1782
Project: WildFly Core
Issue Type: Bug
Components: Server
Affects Versions: 2.2.0.Final
Environment: Wildfly 10.1.0 running under Windows 10 with Java 1.8.0_91
Reporter: Dietrich Schmidt
Assignee: Jason Greene
Fix For: 2.2.1.Final
Attachments: Verklemmung.zip
Wildfly 8.2.0 and 10.0.0 work fine with a Singleton Bean, which has a @Postconstruct method and in this method several threads are created with the ManagedExecutorService. These threads call a method in another Singleton EJB, which has been injected.
This call is blocked in Wildfly 10.1.0 until the Prostconstruct thread has ended.
I assume that the behaviour of Wildfly 8.2.0 + 10.0.0 is correct and the behaviour of Wildfly 10.1.0 is a bug.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months