[JBoss JIRA] (ELY-811) Only AlgorithmCredentials should have parameters
by David Lloyd (JIRA)
David Lloyd created ELY-811:
-------------------------------
Summary: Only AlgorithmCredentials should have parameters
Key: ELY-811
URL: https://issues.jboss.org/browse/ELY-811
Project: WildFly Elytron
Issue Type: Bug
Components: Credentials
Reporter: David Lloyd
Only credentials which have algorithms should have parameters. If a credential needs parameters, it probably needs an algorithm.
You need an algorithm name in order to acquire an AlgorithmParameters object, which is the only thing that can encode/decode algorithm parameters.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (ELY-810) Unify CredentialStore around CredentialSource style storage capability
by David Lloyd (JIRA)
David Lloyd created ELY-810:
-------------------------------
Summary: Unify CredentialStore around CredentialSource style storage capability
Key: ELY-810
URL: https://issues.jboss.org/browse/ELY-810
Project: WildFly Elytron
Issue Type: Task
Components: Credential Store
Reporter: David Lloyd
Assignee: David Lloyd
Fix For: 1.1.0.Beta17
The following needs to be done:
* Move the PB masked password format to a proper password type
* Introduce protection parameters for credential stores and entries
* Drop the admin_key concept in favor of credential store protection parameters
* Introduce a proper vault-compatible credential store
* Introduce a mechanism to pull protection parameters for stores from the client configuration
* Use a credential store which can store (nearly) any credential type
* Update XML accordingly
* Remove dangerous command execution patterns from credential store, make them safe and make them CredentialSources instead
* Clean up exception hierarchy of credential stores
* Introduce simple map-backed credential store
Additionally, the above implies:
* Introduce AlgorithmParameterSpi for password parameter types
* Introduce hashing ability for parameters
* Add missing parameter types for PBE
* Introduce serialization trickery to support picketbox class names for vault files
* Atomic file output stream
* Update tests as needed
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (WFCORE-1556) Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1556?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1556:
------------------------------------------
[~soul2zimate]
I'm not sure what attribute relation change you mean.
One thing I can see happening as a result of this work is that attributes that previously had their AD configured with setAllowNull(true) merely to account for the possibility of alternatives will now use setRequired(true). This will result in a change to the read-resource-description output for the attribute, with the description now more accurately describing the attribute. But this has no effect on what legal values can be passed in. Both before and after the user can either provide a value or provide value for an alternative. So there is no transformation involved.
> Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition
> ---------------------------------------------------------------------------------
>
> Key: WFCORE-1556
> URL: https://issues.jboss.org/browse/WFCORE-1556
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha13
>
>
> The handling of the notions of 'required' and 'nillable' don't comply with the specs in https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+..., particularly the "Description of an Attribute" part, where the 'required' and 'alternatives' fields are well described, with their relationship spelled out, while 'nillable' doesn't appear at all. Then in "Description of an Operation Parameter or Return Value" nillable is specified, although I think those descriptions could be tightened up in general.
> The read-resource-description output for an attribute doesn't show "required" at all.
> After a fair bit of thinking, I've finally recalled why the two separate notions of "required" and "nillable" exist in the first place.
> The "required" and "alternatives" pieces go together. Is something required? And then if it is required, an alternative satisfies. So you can have two attributes/params, both required, but they are alternatives so one is defined and the other is not. And this is an ok thing.
> And then 'nillable' comes in to help clients understand in a simple way whether they need to account for the possibility an undefined value. Basically:
> nillable = !required || alternatives != null
> Right now, nillable is implemented as
> nillable = !required
> There are a number of problems I see with AttributeDefinition:
> 1) We don't output the 'required' metadata unless it's an operation param being described. This is contrary to spec. However we shouldn't fix this unless we can have meaningful values for 'required', ones where the value can be true but the attribute/param can still have an undefined value, due to an alternative being present. If we can't fix that, there's no point outputting required as it's just redundant with what we output for 'nillable'.
> 2) We do output the 'nillable' metadata, even for attribute descriptions, where it isn't in the spec. But in this case I think we change the spec, as dropping nillable would be an incompatible change.
> 3) We don't properly validate the "required but has alternatives case." This can't be validated solely with ParameterValidator impls as those only see a single attribute value and don't have contextual information about other attributes/params. To get around this limitation, devs are saying that attributes with alternatives "allowNull" which is equivalent to saying they are not required. But they are required! So I think a fix for this will require AttributeDefinition itself to validate the overall resource model or operation object, and skip calling the ParameterValidator if the attribute/param is undefined and an alternative is defined.
> 4) AttributeDefinition and AbstractAttributeDefinitionBuilder unfortunately have a getter/setter/constructor param for property "allowNull" instead of a property named "required". This is unfortunate because "allowNull" intuitively maps to "nillable", but "required" is a much more useful thing to set. The value of "nillable" can be derived from a "required" setting and an "alternatives" setting, but the value of required cannot be so derived.
> I think a fix for this would probably start from 4), deprecating setAllowNull, adding get/setRequired and changing the meaning of the AD(Builder) constructor param to "required". The effect of this would be that all current code setting "allowNull" would now be setting a new "required" field. This should be a non-breaking change as in current code that's the effect anyway.
> Next would be to fix 3), by changing how AD validates.
> Next would be to change the metadata we output, such that "required" is always present and the "nillable" value is !required || alternatives != null. And change the spec accordingly.
> Last, in a separate task, would be to find attributes that were configuring "allowNull = true" solely to allow validation to pass when alternatives are present, and fix them to say "required=false".
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (WFCORE-2068) HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2068?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-2068:
----------------------------------------------
Once REM3-250 is fixed we are running onto a random issue caused by
> HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue
> --------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2068
> URL: https://issues.jboss.org/browse/WFCORE-2068
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting, Test Suite
> Reporter: Darran Lofthouse
> Assignee: Jean-Francois Denise
> Priority: Blocker
> Fix For: 3.0.0.Alpha15
>
>
> The listed test case is failing during clean up with the following error: -
> {noformat}
> java.io.IOException: java.io.IOException: WFLYPRT0054: Channel closed
> at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:166)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:135)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:59)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:80)
> {noformat}
> The stage of the test using HTTP Upgrade over a HTTPS connection appears to be working fine, the issue is with the native management interface used for test clean up.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (WFLY-7724) Wildly 10 Freeze no able to ping, nothing happening in logs
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7724?page=com.atlassian.jira.plugin.... ]
Brian Stansberry closed WFLY-7724.
----------------------------------
Resolution: Rejected
Please use the forums for requests for help. Thanks.
> Wildly 10 Freeze no able to ping, nothing happening in logs
> ------------------------------------------------------------
>
> Key: WFLY-7724
> URL: https://issues.jboss.org/browse/WFLY-7724
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: Rohit Lakshykar
> Assignee: Jason Greene
> Priority: Blocker
>
> I am using wildfy 10 sever for financial production machine since more then 8 month.
> I have never faced any issue till yet. From the last few days in every 2 days wildfly server stop responding, even server.log got stopped.
> And i can't see any exception, in logs too. I don't know what this is started happening suddenly.
> Please somebody help me.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (ELY-809) Specific Types for functional interfaces with generic types
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-809:
------------------------------------
Summary: Specific Types for functional interfaces with generic types
Key: ELY-809
URL: https://issues.jboss.org/browse/ELY-809
Project: WildFly Elytron
Issue Type: Enhancement
Components: API / SPI
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.1.0.Beta17
Using MSC and WildFly Core's Capabilities and Requirements support there is a limit as to how far we can go with generic and maintain type safety.
For any type returned by a factory method we should have a type that extends from the functional interface with the geeneric types specified e.g.
{code}
ProvidersSupplier extends Supplier<Provider[]>
{code}
Code that depends on this can still depend on Supplier<Provider[]>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (ELY-808) XML Parsing Deferred into Function
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-808?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse resolved ELY-808.
----------------------------------
Resolution: Duplicate Issue
> XML Parsing Deferred into Function
> ----------------------------------
>
> Key: ELY-808
> URL: https://issues.jboss.org/browse/ELY-808
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Client
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta17
>
>
> e.g.
> {code}
> case "clear-password": {
> function = andThenOp(function, credentialSource -> credentialSource.with(IdentityCredentials.NONE.withCredential(new PasswordCredential(ClearPassword.createRaw(ClearPassword.ALGORITHM_CLEAR, parseClearPassword(reader))))));
> break;
> }
> {code}
> The parsing of clear password is deferred until later.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (ELY-808) XML Parsing Deferred into Function
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-808?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-808:
---------------------------------
Description:
e.g.
{code}
case "clear-password": {
function = andThenOp(function, credentialSource -> credentialSource.with(IdentityCredentials.NONE.withCredential(new PasswordCredential(ClearPassword.createRaw(ClearPassword.ALGORITHM_CLEAR, parseClearPassword(reader))))));
break;
}
{code}
The parsing of clear password is deferred until later.
> XML Parsing Deferred into Function
> ----------------------------------
>
> Key: ELY-808
> URL: https://issues.jboss.org/browse/ELY-808
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Client
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta17
>
>
> e.g.
> {code}
> case "clear-password": {
> function = andThenOp(function, credentialSource -> credentialSource.with(IdentityCredentials.NONE.withCredential(new PasswordCredential(ClearPassword.createRaw(ClearPassword.ALGORITHM_CLEAR, parseClearPassword(reader))))));
> break;
> }
> {code}
> The parsing of clear password is deferred until later.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (DROOLS-1368) Property reactive KieSession.update(fh, h, propName) fails in polymorfic case with "Unknown property"
by Jiri Locker (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1368?page=com.atlassian.jira.plugi... ]
Jiri Locker updated DROOLS-1368:
--------------------------------
Attachment: Drools1368Test.java
> Property reactive KieSession.update(fh, h, propName) fails in polymorfic case with "Unknown property"
> -----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1368
> URL: https://issues.jboss.org/browse/DROOLS-1368
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
> Priority: Critical
> Attachments: Drools1368Test.java
>
>
> I call
> {code}
> kieSession.update(factHandle, entity, variableName);
> {code}
> with entity being an instance of LeadingExam, which extends Exam, which extends AbstractPersistable.
> AbstractPersistable has setId(...).
> Exam has setTopic(...), setRoom(...).
> LeadingExam has setPeriod(...).
> I get this:
> {code}
> java.lang.RuntimeException: Unknown property: period
> at org.drools.core.reteoo.PropertySpecificUtil.setPropertyOnMask(PropertySpecificUtil.java:102)
> at org.drools.core.reteoo.PropertySpecificUtil.calculatePatternMask(PropertySpecificUtil.java:94)
> at org.drools.core.reteoo.PropertySpecificUtil.calculatePositiveMask(PropertySpecificUtil.java:65)
> at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:313)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1605)
> at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:169)
> at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.afterVariableChanged(DroolsScoreDirector.java:156)
> at org.optaplanner.core.impl.heuristic.selector.move.generic.ChangeMove.doMoveOnGenuineVariables(ChangeMove.java:75)
> at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:34)
> at org.optaplanner.core.impl.heuristic.move.CompositeMove.doMove(CompositeMove.java:110)
> at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.doMove(ConstructionHeuristicDecider.java:125)
> at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.decideNextStep(ConstructionHeuristicDecider.java:98)
> at org.optaplanner.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase.solve(DefaultConstructionHeuristicPhase.java:74)
> at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87)
> at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:160)
> at org.optaplanner.examples.common.app.SolverPerformanceTest.runSpeedTest(SolverPerformanceTest.java:65)
> at org.optaplanner.examples.examination.app.ExaminationPerformanceTest.solveComp_set5FastAssert(ExaminationPerformanceTest.java:52)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
> at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Debugging PropertySpecificUtil shows that settableProperties include "id", "room", "topic", but not "period".
> Note that there is also FollowingExam which also extends Exam.
> FollowingExam also has setPeriod(...).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months