[JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly
by Aleksandar Kostadinov (JIRA)
[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ]
Aleksandar Kostadinov commented on WFCORE-433:
----------------------------------------------
One thing I'd like to suggest, is to make Wildfly able to store configuration in some human readable diff-like approach. That means we have a single file that denotes all configuration changes from the default configuration file and the only place for user to look for what is different than the defaults. This could make upgrading server and changing default values smoother for the users.
Also could make auditing, creating test deployments, etc. much easier.
Storing the file in a git repo will also make much more sense.
> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
> Key: WFCORE-433
> URL: https://issues.jboss.org/browse/WFCORE-433
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JASSIST-256) Javassist - add annotation to class doesn't work on reflections
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-256?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-256:
---------------------------------------
Yes, but the version including this fixing has not been released yet.
> Javassist - add annotation to class doesn't work on reflections
> ---------------------------------------------------------------
>
> Key: JASSIST-256
> URL: https://issues.jboss.org/browse/JASSIST-256
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: JDK1.7, IDEA
> Reporter: Rui C.
> Assignee: Shigeru Chiba
> Priority: Minor
> Fix For: 3.21.0-GA
>
>
> {code:java}
> ClassPool pool = ClassPool.getDefault();
> CtClass superclass = pool.getCtClass(AbstractEntity.class.getName());
> CtClass cc = pool.makeClass("com.rapid.develop.entity.Ponit", superclass);
> ClassFile ccFile = cc.getClassFile();
> ConstPool constpool = ccFile.getConstPool();
> AnnotationsAttribute attr = new AnnotationsAttribute(constpool, AnnotationsAttribute.visibleTag);
> Annotation entityAnno = new Annotation("Entity", constpool);
> Annotation tableAnno = new Annotation("Table", constpool);
> tableAnno.addMemberValue("name", new StringMemberValue("test", ccFile.getConstPool()));
> attr.addAnnotation(entityAnno);
> attr.addAnnotation(tableAnno);
> ccFile.addAttribute(attr);
> Class clazz = cc.toClass();
> Object o = clazz.newInstance();
> assertTrue(o.getClass().getName().equals("com.rapid.develop.entity.Ponit"));
> // annotations length = zero
> java.lang.annotation.Annotation[] annotations = clazz.getDeclaredAnnotations();
> assertEquals(2, annotations.length);
> {code}
> I used javassist to add annotation for class， I saw these annotations were added to class file.
> But I can't get them using java API clazz.getDeclaredAnnotations() and clazz.getAnnotations()
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6884) Add XSD schema testing for clustering subsystems
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-6884:
------------------------------------
Summary: Add XSD schema testing for clustering subsystems
Key: WFLY-6884
URL: https://issues.jboss.org/browse/WFLY-6884
Project: WildFly
Issue Type: Feature Request
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Radoslav Husar
Assignee: Radoslav Husar
I noticed a huge batch of ignored tests in clustering subsystems, the missing bits and pieces that allow for XSD testing were missing in infinispan, jgroups and singleton subsystems.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6884) Add XSD schema testing for clustering subsystems
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6884?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6884:
---------------------------------
Description: I noticed a large batch of ignored tests in clustering subsystems, the missing bits and pieces that allow for XSD testing were missing in infinispan, jgroups and singleton subsystems. (was: I noticed a huge batch of ignored tests in clustering subsystems, the missing bits and pieces that allow for XSD testing were missing in infinispan, jgroups and singleton subsystems.)
> Add XSD schema testing for clustering subsystems
> ------------------------------------------------
>
> Key: WFLY-6884
> URL: https://issues.jboss.org/browse/WFLY-6884
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> I noticed a large batch of ignored tests in clustering subsystems, the missing bits and pieces that allow for XSD testing were missing in infinispan, jgroups and singleton subsystems.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1677) Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions properly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1677?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1677:
------------------------------------------
We have https://github.com/wildfly/wildfly/blob/master/testsuite/integration/smok... for validating generated configs.
A subsystem test can't validate the generated config as we don't generate a config in the subsystem module. Perhaps we could. Or perhaps the test ^^^ is sufficient.
> Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions properly
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1677
> URL: https://issues.jboss.org/browse/WFCORE-1677
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 2.2.0.CR8
> Reporter: Radoslav Husar
> Assignee: Kabir Khan
> Priority: Minor
>
> It sounds to me that the test should really be validating the generated XML files, rather than the templates.
> {noformat}
> testSchemaOfSubsystemTemplates[8](org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase) Time elapsed: 0.052 sec <<< FAILURE!
> java.lang.AssertionError: error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected.
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.subsystem.test.SchemaValidator$1.error(SchemaValidator.java:73)
> at org.apache.xerces.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:135)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:394)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:282)
> at org.apache.xerces.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:481)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3571)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidComplexType(XMLSchemaValidator.java:3508)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidType(XMLSchemaValidator.java:3434)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.processElementContent(XMLSchemaValidator.java:3336)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.handleEndElement(XMLSchemaValidator.java:2383)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.endElement(XMLSchemaValidator.java:894)
> at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(XMLNSDocumentScannerImpl.java:673)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1645)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
> at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
> at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
> at org.apache.xerces.jaxp.validation.StreamValidatorHelper.validate(StreamValidatorHelper.java:186)
> at org.apache.xerces.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:129)
> at javax.xml.validation.Validator.validate(Validator.java:124)
> at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:123)
> at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:101)
> at org.jboss.as.subsystem.test.AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates(AbstractSubsystemBaseTest.java:144)
> at org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase.testSchemaOfSubsystemTemplates(SubsystemParsingTestCase.java:130)
> Results :
> Failed tests:
> SubsystemParsingTestCase.testSchemaOfSubsystemTemplates:130->AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates:144 error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-64) Filesystem deployment scanner deployment failure removes unrelated deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-64?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFCORE-64:
-----------------------------------
Fix Version/s: 1.0.0.Alpha6
> Filesystem deployment scanner deployment failure removes unrelated deployments
> ------------------------------------------------------------------------------
>
> Key: WFCORE-64
> URL: https://issues.jboss.org/browse/WFCORE-64
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha5
> Environment: WIndows and Linux platforms both exhibit the issue
> Reporter: Jess Holle
> Assignee: ehsavoie Hugonnet
> Fix For: 1.0.0.Alpha6
>
>
> If one's standalone-full.xml configuration contains something like:
> <deployments>
> <deployment name="MyWebApp.war" runtime-name="MyWebApp.war" enabled="true">
> <fs-exploded path="../../SomeDir/MyWebApp.war" relative-to="jboss.home.dir"/>
> </deployment>
> </deployments>
> whether manually inserted (while the server is not running) or installed via the CLI via
> /deployment=ServiceCenter.war/:add(runtime-name=ServiceCenter.war,content=[{archive=false,path="../../Windchill/ServiceCenter.war",relative-to="jboss.home.dir"}])
> and a deployment scanner like:
> <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
> <deployment-scanner name="1" path="../../../Applications" relative-to="jboss.server.base.dir" scan-interval="5000" auto-deploy-exploded="true"/>
> </subsystem>
> a failure by a deployment-scanner to deploy an application (exploded in my case, though I'm not sure this makes a difference) will cause the explicitly listed <deployments> to be removed from the configuration!
> This occurs irrespective of the value used for auto-deploy-exploded and to <deployment> elements that had already successfully been deployed and started.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1677) Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions properly
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1677?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFCORE-1677:
-----------------------------------
Summary: Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions properly (was: Make org.jboss.as.subsystem.test.AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions)
> Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions properly
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1677
> URL: https://issues.jboss.org/browse/WFCORE-1677
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 2.2.0.CR8
> Reporter: Radoslav Husar
> Assignee: Kabir Khan
> Priority: Minor
>
> It sounds to me that the test should really be validating the generated XML files, rather than the templates.
> {noformat}
> testSchemaOfSubsystemTemplates[8](org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase) Time elapsed: 0.052 sec <<< FAILURE!
> java.lang.AssertionError: error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected.
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.subsystem.test.SchemaValidator$1.error(SchemaValidator.java:73)
> at org.apache.xerces.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:135)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:394)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:282)
> at org.apache.xerces.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:481)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3571)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidComplexType(XMLSchemaValidator.java:3508)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidType(XMLSchemaValidator.java:3434)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.processElementContent(XMLSchemaValidator.java:3336)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.handleEndElement(XMLSchemaValidator.java:2383)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.endElement(XMLSchemaValidator.java:894)
> at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(XMLNSDocumentScannerImpl.java:673)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1645)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
> at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
> at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
> at org.apache.xerces.jaxp.validation.StreamValidatorHelper.validate(StreamValidatorHelper.java:186)
> at org.apache.xerces.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:129)
> at javax.xml.validation.Validator.validate(Validator.java:124)
> at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:123)
> at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:101)
> at org.jboss.as.subsystem.test.AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates(AbstractSubsystemBaseTest.java:144)
> at org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase.testSchemaOfSubsystemTemplates(SubsystemParsingTestCase.java:130)
> Results :
> Failed tests:
> SubsystemParsingTestCase.testSchemaOfSubsystemTemplates:130->AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates:144 error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1677) Make org.jboss.as.subsystem.test.AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions
by Radoslav Husar (JIRA)
Radoslav Husar created WFCORE-1677:
--------------------------------------
Summary: Make org.jboss.as.subsystem.test.AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions
Key: WFCORE-1677
URL: https://issues.jboss.org/browse/WFCORE-1677
Project: WildFly Core
Issue Type: Feature Request
Components: Test Suite
Affects Versions: 2.2.0.CR8
Reporter: Radoslav Husar
Assignee: Kabir Khan
Priority: Minor
It sounds to me that the test should really be validating the generated XML files, rather than the templates.
{noformat}
testSchemaOfSubsystemTemplates[8](org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase) Time elapsed: 0.052 sec <<< FAILURE!
java.lang.AssertionError: error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected.
at org.junit.Assert.fail(Assert.java:88)
at org.jboss.as.subsystem.test.SchemaValidator$1.error(SchemaValidator.java:73)
at org.apache.xerces.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:135)
at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:394)
at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325)
at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:282)
at org.apache.xerces.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:481)
at org.apache.xerces.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3571)
at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidComplexType(XMLSchemaValidator.java:3508)
at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidType(XMLSchemaValidator.java:3434)
at org.apache.xerces.impl.xs.XMLSchemaValidator.processElementContent(XMLSchemaValidator.java:3336)
at org.apache.xerces.impl.xs.XMLSchemaValidator.handleEndElement(XMLSchemaValidator.java:2383)
at org.apache.xerces.impl.xs.XMLSchemaValidator.endElement(XMLSchemaValidator.java:894)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(XMLNSDocumentScannerImpl.java:673)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1645)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
at org.apache.xerces.jaxp.validation.StreamValidatorHelper.validate(StreamValidatorHelper.java:186)
at org.apache.xerces.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:129)
at javax.xml.validation.Validator.validate(Validator.java:124)
at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:123)
at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:101)
at org.jboss.as.subsystem.test.AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates(AbstractSubsystemBaseTest.java:144)
at org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase.testSchemaOfSubsystemTemplates(SubsystemParsingTestCase.java:130)
Results :
Failed tests:
SubsystemParsingTestCase.testSchemaOfSubsystemTemplates:130->AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates:144 error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1676) read-attribute --node is badly handled
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-1676:
--------------------------------------------
Summary: read-attribute --node is badly handled
Key: WFCORE-1676
URL: https://issues.jboss.org/browse/WFCORE-1676
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
read-attribute --node=interface=public namespaces should fail and fails
read-attribute namespaces --node=interface=public should fail and doesn't
read-attribute --node=interface=public init-address should succeed and succeeds
read-attribute init-address --node=interface=public should succeed and fails
This is due to some logic in place to retrieve the node value.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months