January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1019) Publish kmodule.xsd (with version in filename) to allow code completion in user IDE's

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1019?page=com.atlassian.jira.plugi... ] Geoffrey De Smet edited comment on DROOLS-1019 at 1/5/16 11:16 AM: ------------------------------------------------------------------- The xsd's are online now, for example here: http://www.drools.org/xsd/kmodule_6_3.xsd Mario found out that the examples already used the 6.0.0 target namespace, so it can't be made versionless in the 6 series :( was (Author: ge0ffrey): The xsd's are online now, for example here: http://www.drools.org/xsd/kmodule_6_3.xsd Mario found out that the examples already used the 6.0.0 namespace, so it can't be made versionless in the 6 series. > Publish kmodule.xsd (with version in filename) to allow code completion in user IDE's > ------------------------------------------------------------------------------------- > > Key: DROOLS-1019 > URL: https://issues.jboss.org/browse/DROOLS-1019 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Geoffrey De Smet > Assignee: Geoffrey De Smet > > Discussion Mario & Geoffrey: > - The xsd file will be published on drools.org, with a version in the filename under the xsd directory: > -- http://www.drools.org/xsd/kmodule_6_0.xsd > -- http://www.drools.org/xsd/kmodule_6_1.xsd > -- http://www.drools.org/xsd/kmodule_6_2.xsd > -- http://www.drools.org/xsd/kmodule_6_3.xsd > - The version in the filename does not break backwards compatibility because drools 6.3 accepts an kmodule.xml that references kmodule_6_0.xsd > -- Users are recommended but not obligated to change their xsd when upgrading. > -- This is the same versioning strategy as used for web.xml, beans.xml, etc in JEE. > - The target namespace will adjusted to avoid containing a version number (as that does break backwards compatibility) > - The release procedure will include copying the xsd file during a community .0.Final release. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1019) Publish kmodule.xsd (with version in filename) to allow code completion in user IDE's

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1019?page=com.atlassian.jira.plugi... ] Geoffrey De Smet updated DROOLS-1019: ------------------------------------- Description: Discussion Mario & Geoffrey: - The xsd file will be published on drools.org, with a version in the filename under the xsd directory: -- http://www.drools.org/xsd/kmodule_6_0.xsd -- http://www.drools.org/xsd/kmodule_6_1.xsd -- http://www.drools.org/xsd/kmodule_6_2.xsd -- http://www.drools.org/xsd/kmodule_6_3.xsd - The version in the filename does not break backwards compatibility because drools 6.3 accepts an kmodule.xml that references kmodule_6_0.xsd -- Users are recommended but not obligated to change their xsd when upgrading. -- This is the same versioning strategy as used for web.xml, beans.xml, etc in JEE. - The target namespace will adjusted to avoid containing a version number (as that does break backwards compatibility when changed) - The release procedure will include copying the xsd file during a community .0.Final release. was: Discussion Mario & Geoffrey: - The xsd file will be published on drools.org, with a version in the filename under the xsd directory: -- http://www.drools.org/xsd/kmodule_6_0.xsd -- http://www.drools.org/xsd/kmodule_6_1.xsd -- http://www.drools.org/xsd/kmodule_6_2.xsd -- http://www.drools.org/xsd/kmodule_6_3.xsd - The version in the filename does not break backwards compatibility because drools 6.3 accepts an kmodule.xml that references kmodule_6_0.xsd -- Users are recommended but not obligated to change their xsd when upgrading. -- This is the same versioning strategy as used for web.xml, beans.xml, etc in JEE. - The target namespace will adjusted to avoid containing a version number (as that does break backwards compatibility) - The release procedure will include copying the xsd file during a community .0.Final release. > Publish kmodule.xsd (with version in filename) to allow code completion in user IDE's > ------------------------------------------------------------------------------------- > > Key: DROOLS-1019 > URL: https://issues.jboss.org/browse/DROOLS-1019 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Geoffrey De Smet > Assignee: Geoffrey De Smet > > Discussion Mario & Geoffrey: > - The xsd file will be published on drools.org, with a version in the filename under the xsd directory: > -- http://www.drools.org/xsd/kmodule_6_0.xsd > -- http://www.drools.org/xsd/kmodule_6_1.xsd > -- http://www.drools.org/xsd/kmodule_6_2.xsd > -- http://www.drools.org/xsd/kmodule_6_3.xsd > - The version in the filename does not break backwards compatibility because drools 6.3 accepts an kmodule.xml that references kmodule_6_0.xsd > -- Users are recommended but not obligated to change their xsd when upgrading. > -- This is the same versioning strategy as used for web.xml, beans.xml, etc in JEE. > - The target namespace will adjusted to avoid containing a version number (as that does break backwards compatibility when changed) > - The release procedure will include copying the xsd file during a community .0.Final release. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1019) Publish kmodule.xsd (with version in filename) to allow code completion in user IDE's

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1019?page=com.atlassian.jira.plugi... ] Mario Fusco reassigned DROOLS-1019: ----------------------------------- Assignee: Geoffrey De Smet (was: Mario Fusco) > Publish kmodule.xsd (with version in filename) to allow code completion in user IDE's > ------------------------------------------------------------------------------------- > > Key: DROOLS-1019 > URL: https://issues.jboss.org/browse/DROOLS-1019 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Geoffrey De Smet > Assignee: Geoffrey De Smet > > Discussion Mario & Geoffrey: > - The xsd file will be published on drools.org, with a version in the filename under the xsd directory: > -- http://www.drools.org/xsd/kmodule_6_0.xsd > -- http://www.drools.org/xsd/kmodule_6_1.xsd > -- http://www.drools.org/xsd/kmodule_6_2.xsd > -- http://www.drools.org/xsd/kmodule_6_3.xsd > - The version in the filename does not break backwards compatibility because drools 6.3 accepts an kmodule.xml that references kmodule_6_0.xsd > -- Users are recommended but not obligated to change their xsd when upgrading. > -- This is the same versioning strategy as used for web.xml, beans.xml, etc in JEE. > - The target namespace will adjusted to avoid containing a version number (as that does break backwards compatibility) > - The release procedure will include copying the xsd file during a community .0.Final release. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1019) Publish kmodule.xsd (with version in filename) to allow code completion in user IDE's

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1019?page=com.atlassian.jira.plugi... ] Geoffrey De Smet commented on DROOLS-1019: ------------------------------------------ PR on release procedure: https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/pull/122 > Publish kmodule.xsd (with version in filename) to allow code completion in user IDE's > ------------------------------------------------------------------------------------- > > Key: DROOLS-1019 > URL: https://issues.jboss.org/browse/DROOLS-1019 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > Discussion Mario & Geoffrey: > - The xsd file will be published on drools.org, with a version in the filename under the xsd directory: > -- http://www.drools.org/xsd/kmodule_6_0.xsd > -- http://www.drools.org/xsd/kmodule_6_1.xsd > -- http://www.drools.org/xsd/kmodule_6_2.xsd > -- http://www.drools.org/xsd/kmodule_6_3.xsd > - The version in the filename does not break backwards compatibility because drools 6.3 accepts an kmodule.xml that references kmodule_6_0.xsd > -- Users are recommended but not obligated to change their xsd when upgrading. > -- This is the same versioning strategy as used for web.xml, beans.xml, etc in JEE. > - The target namespace will adjusted to avoid containing a version number (as that does break backwards compatibility) > - The release procedure will include copying the xsd file during a community .0.Final release. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1017) NPE deleting an expired event in equality mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1017?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on DROOLS-1017: ------------------------------------------------- Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1295786|https://bugzilla.redhat.com/show_bug.cgi?id=1295786] from ASSIGNED to MODIFIED > NPE deleting an expired event in equality mode > ---------------------------------------------- > > Key: DROOLS-1017 > URL: https://issues.jboss.org/browse/DROOLS-1017 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.4.x > > > Trying to delete an already expired event in equality mode causes the following NPE in the TMS: > {code} > java.lang.NullPointerException > at org.drools.core.common.NamedEntryPoint.delete(NamedEntryPoint.java:506) > at org.drools.core.common.NamedEntryPoint.delete(NamedEntryPoint.java:442) > at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1120) > at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:121) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1003) > at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1346) > at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1284) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1303) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1293) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1274) > at org.drools.compiler.integrationtests.CepEspTest.testDeleteExpiredEventWithTimestampAndEqualityKey(CepEspTest.java:5682) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2000) Output of ProtocolStack.printProtocolSpecAsXML() cannot be used as a protocol stack without manual modifications

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2000?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2000: -------------------------------- Although, if you submit a pull request (e.g. write the fully qualified classname)?... :-) > Output of ProtocolStack.printProtocolSpecAsXML() cannot be used as a protocol stack without manual modifications > ---------------------------------------------------------------------------------------------------------------- > > Key: JGRP-2000 > URL: https://issues.jboss.org/browse/JGRP-2000 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.4 > Reporter: Jim Thomas > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.7 > > > The output of printProtocolSpecAsXML does not contain the pbcast package prefix for NACKACK2, GMS, STATE, etc. so the load fails due to class load failure. > Suggest either add org.jgroups.protocols.pbcast to the protocol loading search or write protocol names with full classpath when printing the spec. > Might it also make sense to skip writing out deprecated parameters? > Reason: I'm generating my protocol stack programmatically because some of the parameter values are determined at run time. In order to facilitate some experimentation with timeouts/retries/etc. I decided to temporarily use an xml file which I first generate by writing out the stack to an xml file which we can tweak the settings for subsequent runs. Since every member has a unique protocol stack keeping the edits to a minimum is helpful. (Maybe using property variables would be a better approach for me?) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2000) Output of ProtocolStack.printProtocolSpecAsXML() cannot be used as a protocol stack without manual modifications

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2000?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2000: --------------------------- Fix Version/s: 3.6.7 I'll look at this before releasing 3.6.7, but I can't guarantee I'll fix it, as I never envisaged the way you use it. > Output of ProtocolStack.printProtocolSpecAsXML() cannot be used as a protocol stack without manual modifications > ---------------------------------------------------------------------------------------------------------------- > > Key: JGRP-2000 > URL: https://issues.jboss.org/browse/JGRP-2000 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.4 > Reporter: Jim Thomas > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.7 > > > The output of printProtocolSpecAsXML does not contain the pbcast package prefix for NACKACK2, GMS, STATE, etc. so the load fails due to class load failure. > Suggest either add org.jgroups.protocols.pbcast to the protocol loading search or write protocol names with full classpath when printing the spec. > Might it also make sense to skip writing out deprecated parameters? > Reason: I'm generating my protocol stack programmatically because some of the parameter values are determined at run time. In order to facilitate some experimentation with timeouts/retries/etc. I decided to temporarily use an xml file which I first generate by writing out the stack to an xml file which we can tweak the settings for subsequent runs. Since every member has a unique protocol stack keeping the edits to a minimum is helpful. (Maybe using property variables would be a better approach for me?) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-591) revertReloadRequired() throws a NPE is reloadRequired has not been called

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-591?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-591: ------------------------------------------------ Romain Pelisse <rpelisse(a)redhat.com> changed the Status of [bug 1294591|https://bugzilla.redhat.com/show_bug.cgi?id=1294591] from ASSIGNED to POST > revertReloadRequired() throws a NPE is reloadRequired has not been called > ------------------------------------------------------------------------- > > Key: WFCORE-591 > URL: https://issues.jboss.org/browse/WFCORE-591 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha19 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 1.0.0.Beta1 > > > If an operation step handler calls org.jboss.as.controller.OperationContext#revertReloadRequired() when org.jboss.as.controller.OperationContext#reloadRequired() has not been called, it throws a NPE: > {noformat} > java.lang.NullPointerException > at org.jboss.as.controller.ControlledProcessState.revertReloadRequired(ControlledProcessState.java:181) > at org.jboss.as.controller.AbstractOperationContext.revertReloadRequired(AbstractOperationContext.java:1037) > at org.jboss.as.controller.test.RevertReloadRequiredTestCase$TestResourceAddHandler.rollbackRuntime(RevertReloadRequiredTestCase.java:98) > at org.jboss.as.controller.AbstractAddStepHandler$1$1.handleRollback(AbstractAddStepHandler.java:133) > at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1419) > at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1385) > at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1367) > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1323) > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1283) > at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1172) > at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:929) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:877) > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601) > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1182) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:205) > {noformat} > The NPE is caused by this.activeStep.restartStamp field which is set only when reloadRequired() (or restartRequired()) is called. > My OSH may call reloadRequired() or not depending on some runtime state and I could add some logic to make sure I call > I can fix my handle to check that I call context.revertReloadRequired() only I had previously called reloadRequired () first. > However, in order to make the OperationContext more robust, I think that the revertReloadRequired() method should instead be a no-op if there is no reload required. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1019) Publish kmodule.xsd (with version in filename) to allow code completion in user IDE's

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1019?page=com.atlassian.jira.plugi... ] Geoffrey De Smet updated DROOLS-1019: ------------------------------------- Description: Discussion Mario & Geoffrey: - The xsd file will be published on drools.org, with a version in the filename under the xsd directory: -- http://www.drools.org/xsd/kmodule_6_0.xsd -- http://www.drools.org/xsd/kmodule_6_1.xsd -- http://www.drools.org/xsd/kmodule_6_2.xsd -- http://www.drools.org/xsd/kmodule_6_3.xsd - The version in the filename does not break backwards compatibility because drools 6.3 accepts an kmodule.xml that references kmodule_6_0.xsd -- Users are recommended but not obligated to change their xsd when upgrading. -- This is the same versioning strategy as used for web.xml, beans.xml, etc in JEE. - The target namespace will adjusted to avoid containing a version number (as that does break backwards compatibility) > Publish kmodule.xsd (with version in filename) to allow code completion in user IDE's > ------------------------------------------------------------------------------------- > > Key: DROOLS-1019 > URL: https://issues.jboss.org/browse/DROOLS-1019 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > Discussion Mario & Geoffrey: > - The xsd file will be published on drools.org, with a version in the filename under the xsd directory: > -- http://www.drools.org/xsd/kmodule_6_0.xsd > -- http://www.drools.org/xsd/kmodule_6_1.xsd > -- http://www.drools.org/xsd/kmodule_6_2.xsd > -- http://www.drools.org/xsd/kmodule_6_3.xsd > - The version in the filename does not break backwards compatibility because drools 6.3 accepts an kmodule.xml that references kmodule_6_0.xsd > -- Users are recommended but not obligated to change their xsd when upgrading. > -- This is the same versioning strategy as used for web.xml, beans.xml, etc in JEE. > - The target namespace will adjusted to avoid containing a version number (as that does break backwards compatibility) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1019) Publish kmodule.xsd (with version in filename) to allow code completion in user IDE's

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1019?page=com.atlassian.jira.plugi... ] Geoffrey De Smet updated DROOLS-1019: ------------------------------------- Description: Discussion Mario & Geoffrey: - The xsd file will be published on drools.org, with a version in the filename under the xsd directory: -- http://www.drools.org/xsd/kmodule_6_0.xsd -- http://www.drools.org/xsd/kmodule_6_1.xsd -- http://www.drools.org/xsd/kmodule_6_2.xsd -- http://www.drools.org/xsd/kmodule_6_3.xsd - The version in the filename does not break backwards compatibility because drools 6.3 accepts an kmodule.xml that references kmodule_6_0.xsd -- Users are recommended but not obligated to change their xsd when upgrading. -- This is the same versioning strategy as used for web.xml, beans.xml, etc in JEE. - The target namespace will adjusted to avoid containing a version number (as that does break backwards compatibility) - The release procedure will include copying the xsd file during a community .0.Final release. was: Discussion Mario & Geoffrey: - The xsd file will be published on drools.org, with a version in the filename under the xsd directory: -- http://www.drools.org/xsd/kmodule_6_0.xsd -- http://www.drools.org/xsd/kmodule_6_1.xsd -- http://www.drools.org/xsd/kmodule_6_2.xsd -- http://www.drools.org/xsd/kmodule_6_3.xsd - The version in the filename does not break backwards compatibility because drools 6.3 accepts an kmodule.xml that references kmodule_6_0.xsd -- Users are recommended but not obligated to change their xsd when upgrading. -- This is the same versioning strategy as used for web.xml, beans.xml, etc in JEE. - The target namespace will adjusted to avoid containing a version number (as that does break backwards compatibility) > Publish kmodule.xsd (with version in filename) to allow code completion in user IDE's > ------------------------------------------------------------------------------------- > > Key: DROOLS-1019 > URL: https://issues.jboss.org/browse/DROOLS-1019 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > Discussion Mario & Geoffrey: > - The xsd file will be published on drools.org, with a version in the filename under the xsd directory: > -- http://www.drools.org/xsd/kmodule_6_0.xsd > -- http://www.drools.org/xsd/kmodule_6_1.xsd > -- http://www.drools.org/xsd/kmodule_6_2.xsd > -- http://www.drools.org/xsd/kmodule_6_3.xsd > - The version in the filename does not break backwards compatibility because drools 6.3 accepts an kmodule.xml that references kmodule_6_0.xsd > -- Users are recommended but not obligated to change their xsd when upgrading. > -- This is the same versioning strategy as used for web.xml, beans.xml, etc in JEE. > - The target namespace will adjusted to avoid containing a version number (as that does break backwards compatibility) > - The release procedure will include copying the xsd file during a community .0.Final release. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016