[JBoss JIRA] (WFLY-7155) Update Hibernate to 5.0.11
by Frank Langelage (JIRA)
Frank Langelage created WFLY-7155:
-------------------------------------
Summary: Update Hibernate to 5.0.11
Key: WFLY-7155
URL: https://issues.jboss.org/browse/WFLY-7155
Project: WildFly
Issue Type: Component Upgrade
Components: JPA / Hibernate
Affects Versions: 10.2.0.Final, 11.0.0.Alpha1
Reporter: Frank Langelage
Assignee: Scott Marlow
Fix For: 10.2.0.Final, 11.0.0.Beta1
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on JASSIST-261:
--------------------------------------
I have no suggestions myself. Would it make sense to ask the OpenJDK team working on Jigsaw for help? There is also a survey at [https://www.surveymonkey.de/r/JDK9EA], looking for feedback on experiences with JDK9.
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-7154) poor description of session-timeout, maximum-session-cache-size attributes
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7154?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev reassigned WFLY-7154:
-----------------------------------
Assignee: Ilia Vassilev (was: Darran Lofthouse)
> poor description of session-timeout, maximum-session-cache-size attributes
> --------------------------------------------------------------------------
>
> Key: WFLY-7154
> URL: https://issues.jboss.org/browse/WFLY-7154
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
> Priority: Minor
>
> Describe more properly in model/XSD client-ssl-context and server-ssl-context attributes:
> * session-timeout
> Should be timeout specified in seconds?
> What does default value mean?
> Negative values could be restricted on model level.
> {code}
> "session-timeout" => {
> "type" => INT,
> "description" => "The timeout for SSL sessions.",
> "expressions-allowed" => true,
> "nillable" => true,
> "default" => 0,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {code}
> {code}
> <xs:attribute name="session-timeout" type="xs:int" default="0">
> <xs:annotation>
> <xs:documentation>
> The timeout for SSL sessions.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> {code}
> * maximum-session-cache-size
> What does default value 0 mean?
> Negative values could be restricted on model level
> {code}
> "maximum-session-cache-size" => {
> "type" => INT,
> "description" => "The maximum number of SSL sessions to be cached.",
> "expressions-allowed" => true,
> "nillable" => true,
> "default" => 0,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {code}
> {code}
> <xs:attribute name="maximum-session-cache-size" type="xs:int" default="0">
> <xs:annotation>
> <xs:documentation>
> The maximum number of SSL sessions in the cache.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-7075:
------------------------------------
Excellent to hear, thank you very much for reporting this issue and related ones as well.
Thanks also for supplying the patches as well, even though we didn't get to discuss further whether you would do a pull request with them. On your next contribution(s), we can try harder, to get your code changes in.
> proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png
>
>
> 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.
> [WFLY-7108] is now the tracking jira for the fix.
> *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-7154) poor description of session-timeout, maximum-session-cache-size attributes
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7154?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-6091 to WFLY-7154:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7154 (was: JBEAP-6091)
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.DR5)
> poor description of session-timeout, maximum-session-cache-size attributes
> --------------------------------------------------------------------------
>
> Key: WFLY-7154
> URL: https://issues.jboss.org/browse/WFLY-7154
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Minor
>
> Describe more properly in model/XSD client-ssl-context and server-ssl-context attributes:
> * session-timeout
> Should be timeout specified in seconds?
> What does default value mean?
> Negative values could be restricted on model level.
> {code}
> "session-timeout" => {
> "type" => INT,
> "description" => "The timeout for SSL sessions.",
> "expressions-allowed" => true,
> "nillable" => true,
> "default" => 0,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {code}
> {code}
> <xs:attribute name="session-timeout" type="xs:int" default="0">
> <xs:annotation>
> <xs:documentation>
> The timeout for SSL sessions.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> {code}
> * maximum-session-cache-size
> What does default value 0 mean?
> Negative values could be restricted on model level
> {code}
> "maximum-session-cache-size" => {
> "type" => INT,
> "description" => "The maximum number of SSL sessions to be cached.",
> "expressions-allowed" => true,
> "nillable" => true,
> "default" => 0,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {code}
> {code}
> <xs:attribute name="maximum-session-cache-size" type="xs:int" default="0">
> <xs:annotation>
> <xs:documentation>
> The maximum number of SSL sessions in the cache.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1810) PeriodicSizeRotatingFileHandler's are always replaced during boot
by Panagiotis Sotiropoulos (JIRA)
Panagiotis Sotiropoulos created WFCORE-1810:
-----------------------------------------------
Summary: PeriodicSizeRotatingFileHandler's are always replaced during boot
Key: WFCORE-1810
URL: https://issues.jboss.org/browse/WFCORE-1810
Project: WildFly Core
Issue Type: Bug
Components: Logging
Reporter: Panagiotis Sotiropoulos
Assignee: James Perkins
Fix For: 2.0.0.CR6
A {{periodic-size-rotating-file-handler}} will be replaced during the subsystem add operation. This could be an issue with {{async-handler}}'s where the handler may see the old handler that was closed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-1299) DROOLS-778 is back with 6.4.0
by Christoph Schachinger (JIRA)
Christoph Schachinger created DROOLS-1299:
---------------------------------------------
Summary: DROOLS-778 is back with 6.4.0
Key: DROOLS-1299
URL: https://issues.jboss.org/browse/DROOLS-1299
Project: Drools
Issue Type: Sub-task
Components: core engine
Affects Versions: 6.4.0.Final
Reporter: Christoph Schachinger
Assignee: Mario Fusco
Issue DROOLS-778 is back again with version 6.4.0.FINAL
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-778) Deserialization error: java.io.InvalidClassException: org.drools.base.evaluators.StrEvaluatorDefinition$StrEvaluator; no valid constructor
by Christoph Schachinger (JIRA)
[ https://issues.jboss.org/browse/DROOLS-778?page=com.atlassian.jira.plugin... ]
Christoph Schachinger commented on DROOLS-778:
----------------------------------------------
The issue is back with 6.4.0. We are serialising the knowledge-packages and deserializing them (for a quicker startup). This stars breaking with 6.4 for thouse rules which have the "str" operation in their WHEN condition.
> Deserialization error: java.io.InvalidClassException: org.drools.base.evaluators.StrEvaluatorDefinition$StrEvaluator; no valid constructor
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-778
> URL: https://issues.jboss.org/browse/DROOLS-778
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 5.5.0.Final
> Environment: Windows 7; Java 6; Drools 5.5.0.Final (incl. drools-core, drools-compiler, drools-spring and drools-camel)
> Reporter: Philip McWilliams
> Assignee: Mario Fusco
> Fix For: 6.0.0.Final
>
>
> I am seeking to compile rules at build-time and then save (serialize) the output to disk. At deployment, I then wish to build a knowledge base from the deserialized knowledge packages (rather than by re-compiling the source rules files).
> In general this works ... unless I use the "str" operator in an LHS. This operator is implemented by the *org.drools.base.evaluators.StrEvaluatorDefinition$StrEvaluator* class and this class does not appear to deserialize properly.
> A round trip exercise on my local machine always fails with this error:
> {code}
> java.io.InvalidClassException: org.drools.base.evaluators.StrEvaluatorDefinition$StrEvaluator; org.drools.base.evaluators.StrEvaluatorDefinition$StrEvaluator; no valid constructor
> {code}
> My serialization/deserialization code is standard ... to serialize:
> {code}
> private void saveOutput(KnowledgeBuilder kbuilder) throws IOException {
> Collection<KnowledgePackage> kpkgs = kbuilder.getKnowledgePackages();
> String outputFilename = outputFile == null ? "" : outputFile.trim();
> if (outputFilename.isEmpty()) {
> outputFilename = project.getBasedir() + "target/classes/drools.drlx";
> }
> ObjectOutputStream out = null;
> try {
> getLog().info("Saving compiled Drools output to " + outputFilename);
> out = new ObjectOutputStream(new FileOutputStream(outputFilename));
> out.writeObject(kpkgs);
> } finally {
> if (out != null) {
> out.close();
> }
> }
> }
> {code}
> ... to deserialize:
> {code}
> private Collection<KnowledgePackage> deserializeKnowledgePackages(Resource[] knowledgePackageObjects) throws IOException, ClassNotFoundException {
> Collection<KnowledgePackage> knowledgePackages = new ArrayList<KnowledgePackage>();
> for (Resource knowledgePackageObject : knowledgePackageObjects) {
> LOG.info("Deserializing pre-compiled package " + knowledgePackageObject.getFilename());
> ObjectInputStream in = null;
> try {
> in = new ObjectInputStream(knowledgePackageObject.getInputStream());
> // The input stream might contain an individual package or a collection.
> knowledgePackages.addAll((Collection<KnowledgePackage>) in.readObject());
> } finally {
> if (in != null) {
> in.close();
> }
> }
> }
> return knowledgePackages;
> }
> {code}
> My workaround is to avoid using the "str" operator.
> *Apologies*: I have *not* checked version 6.2.0.Final because I have not yet worked out what versions of the Drools Spring and Camel modules to use (for 5.5.0.Final they were all versioned identically).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ELY-623) Checking for anonymous principal by name is insufficient
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-623?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-623:
--------------------------------------
Sorry, didn't read Honza's question fully ;-)
> Checking for anonymous principal by name is insufficient
> --------------------------------------------------------
>
> Key: ELY-623
> URL: https://issues.jboss.org/browse/ELY-623
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: David Lloyd
> Assignee: Jan Kalina
>
> In {{src/main/java/org/wildfly/security/auth/server/SecurityIdentity.java}}:
> {noformat}
> + if (AnonymousPrincipal.getInstance().getName().equals(name)) {
> + if (! context.authorizeAnonymous(false)) {
> + throw log.runAsAuthorizationFailed(getPrincipal(), new AnonymousPrincipal(), null);
> + }
> + } else {
> + if (! (context.importIdentity(this) && context.authorize(name, authorize))) {
> + throw log.runAsAuthorizationFailed(getPrincipal(), new NamePrincipal(name), null);
> + }
> }
> {noformat}
> Only a type check is sufficient to determine if a principal is anonymous. In this fix, the string name "anonymous" takes on a special meaning for the first time, which should not be the case.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-7153) Inconsistency of resources *-ssl-context in model vs. XSD
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7153?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-6089 to WFLY-7153:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7153 (was: JBEAP-6089)
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.DR5)
> Inconsistency of resources *-ssl-context in model vs. XSD
> ---------------------------------------------------------
>
> Key: WFLY-7153
> URL: https://issues.jboss.org/browse/WFLY-7153
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> * in client-ssl-context there is attribute {{security-domain}} in XSD, which is not in model. In case of client-ssl-context this probably does not make sense and reaaly should't be in XSD, neither.
> * in both *-ssl-context there is provider in XSD and provider-loader in model. Sync it please. Probably possibility to specify both could be useful.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months