[JBoss JIRA] (WFLY-3710) Break close association of AppclientXml with WildFly-Core
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-3710:
--------------------------------------
Summary: Break close association of AppclientXml with WildFly-Core
Key: WFLY-3710
URL: https://issues.jboss.org/browse/WFLY-3710
Project: WildFly
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Application Client, Domain Management
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 9.0.0.Beta1
AppClientXml is written on the basis that it is in the same project as the remaining domain management parsers, as an example it is dependent on calling certain version specific vault methods.
Changes will also be needed to wildfly-core but any access to parsers in wildfly-core should be switched to agreed entry points that will be maintained by compatibility.
As an example this block: -
{code}
if (element == Element.VAULT) {
switch (namespace) {
//Less than 1.1 does not end up in this method
case DOMAIN_1_1:
case DOMAIN_1_2:
case DOMAIN_1_3:
case DOMAIN_1_4:
case DOMAIN_1_5:
case DOMAIN_2_0:
case DOMAIN_2_1: {
parseVault_1_1(reader, address, namespace, list);
break;
}
default: {
parseVault_3_0(reader, address, namespace, list);
}
}
{code}
Should be replaced with a call to parseVault(), the parseVault() method will then be responsible for identifying the correct version.
Changes should also be made to AppClientXml to make it compatible with multiple major versions in use concurrently for jboss-as-config - otherwise this class is seriously likely to be missed again for all further updates.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (DROOLS-553) Build does not build on maven 3.2.2 with an empty repository
by Skip Skip (JIRA)
[ https://issues.jboss.org/browse/DROOLS-553?page=com.atlassian.jira.plugin... ]
Skip Skip commented on DROOLS-553:
----------------------------------
Thanks Geoffrey for getting back to me on this.
> Build does not build on maven 3.2.2 with an empty repository
> ------------------------------------------------------------
>
> Key: DROOLS-553
> URL: https://issues.jboss.org/browse/DROOLS-553
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
> Priority: Blocker
>
> Our community contributors should be able to just build our stuff with the latest maven version. Currently that doesn't work.
> Building with maven 3.0.5 works.
> To reproduce:
> - Use maven 3.2.2
> - Build droolsjbpm-build-bootstrap
> - Do not build uberfire first
> - rm ~/.m2/repository/org/uberfire
> => this will force droolsjbpm-build-bootstrap to download the uberfire-bom 6.2.0-SNAPSHOT, which fails with maven 3.2.2:
> {code}
> $ mvn clean install -Dfull -DskipTests -U
> [INFO] Scanning for projects...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project org.kie:kie-parent-with-dependencies:6.2.0-SNAPSHOT (/Users/.../OptaPlanner/droolsjbpm-build-bootstrap/kie-parent-with-dependencies/pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not find artifact org.uberfire:uberfire-bom:pom:0.4.2-SNAPSHOT @ org.kie:kie-parent-with-dependencies:[unknown-version], /Users/.../OptaPlanner/droolsjbpm-build-bootstrap/kie-parent-with-dependencies/pom.xml, line 137, column 19 -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (DROOLS-571) Add a specialized single function accumulate implementation
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-571:
----------------------------------
Summary: Add a specialized single function accumulate implementation
Key: DROOLS-571
URL: https://issues.jboss.org/browse/DROOLS-571
Project: Drools
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Reporter: Mario Fusco
Assignee: Mario Fusco
For performance reason, in order to avoid useless arrays creation and for loop traversing them, we need to add a specialized accumulate implementation that is for a single function
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (WFLY-3661) PluggableMBeanServerImpl.findDelegateForNewObject() rejects null ObjectName arg
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3661?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-3661:
----------------------------------
[~JessHolle] https://github.com/wildfly/wildfly-core/pull/76 should fix this
> PluggableMBeanServerImpl.findDelegateForNewObject() rejects null ObjectName arg
> -------------------------------------------------------------------------------
>
> Key: WFLY-3661
> URL: https://issues.jboss.org/browse/WFLY-3661
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMX
> Affects Versions: 8.0.0.Final
> Reporter: Jess Holle
> Assignee: Kabir Khan
>
> According to the Javadoc on MBeanRegistration.preRegister(), one may register an MBean with a null ObjectName and let the MBean's preRegister() method compute the ObjectName.
> Unfortunately, org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegateForNewObject() violates this contract -- throwing an exception when the incoming ObjectName is null.
> This is a clear bug which breaks numerous JMX MBeans I've authored, which compute their own ObjectNames within preRegister().
> Ideally the result of preRegister would be used as an input to findDelegateForNewObject(), but unfortunately one of the inputs to preRegister() is the MBeanServer, which is, of course, what findDelegateForNewObject() is looking up. Given this circularity, it would seem that findDelegateForNewObject() should simply return rootMBeanServer for null ObjectName inputs. In any case it should not entirely fail to register such MBeans.
> Fortunately, I have a utility wrapper around MBean registration, so I've added the following hack immediately prior to actually registering the MBean to workaround this issue:
> /* Hack to work around JBoss Wildfly bug (https://issues.jboss.org/browse/WFLY-3661).
> This isn't really quite correct, of course, since this means preRegister() will get called twice,
> but it appears to be about the best we can do.
> */
> if ( objectName == null )
> if ( mbean instanceof MBeanRegistration )
> if ( "org.jboss.as.jmx.PluggableMBeanServerImpl".equals( mbeanserver.getClass().getName() ) )
> objectName = ((MBeanRegistration)mbean).preRegister( mbeanserver, objectName );
> where mbeanserver is obtained via ManagementFactory.getPlatformMBeanServer().
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (JBMETA-377) NullPointerException occurs during parsing web.xml with missing context param-name
by Jay Kumar SenSharma (JIRA)
[ https://issues.jboss.org/browse/JBMETA-377?page=com.atlassian.jira.plugin... ]
Jay Kumar SenSharma commented on JBMETA-377:
--------------------------------------------
Sent a new Pull request for this issue:
https://github.com/jboss/metadata/pull/65
With this fix it should report the actual cause of the deployment failure as following:
{code}
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[16,7]
Message: <param-name> is not defined properly inside the web.xml
at org.jboss.metadata.parser.ee.ParamValueMetaDataParser.parse(ParamValueMetaDataParser.java:90)
at org.jboss.metadata.parser.servlet.WebCommonMetaDataParser.parse(WebCommonMetaDataParser.java:70)
at org.jboss.metadata.parser.servlet.WebMetaDataParser.parse(WebMetaDataParser.java:184)
at org.jboss.metadata.parser.servlet.WebMetaDataParser.parse(WebMetaDataParser.java:57)
{code}
> NullPointerException occurs during parsing web.xml with missing context param-name
> ----------------------------------------------------------------------------------
>
> Key: JBMETA-377
> URL: https://issues.jboss.org/browse/JBMETA-377
> Project: JBoss Metadata
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: common
> Affects Versions: 8.0.0.Final
> Reporter: Jay Kumar SenSharma
>
> [Opening this issue to track down the issue specific to jboss metadata]
> While deploying a WAR, If the web.xml file is used which has context <param-value> defined, However it has missing <param-name> then it causes NullPointerException.
> Refer to for more details: https://issues.jboss.org/browse/WFLY-3699
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (DROOLS-570) Rule inheritance fails when using or pattern binding
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-570?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-570:
----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> Rule inheritance fails when using or pattern binding
> ----------------------------------------------------
>
> Key: DROOLS-570
> URL: https://issues.jboss.org/browse/DROOLS-570
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Environment: Windows 7 VM. Running drools using a JUnit driver
> Reporter: Eugene Shvartsman
> Assignee: Mario Fusco
> Attachments: tester-module.7z
>
>
> I've found a certain combination of rules (when using inheritance) that causes drools to throw the following exception: http://pastebin.com/xxq5ZtAC
> The rules that cause this exception to occur can be found here: http://pastebin.com/wM6rWY8L
> I've simplified my original rules down to the lowest level of detail that still throws the exception. The exception is no longer thrown if I:
> 1. Don't use rule inheritance
> 2. Don't have an or statement
> 3. Don't reference an LHS defined variable in the RHS of ruleB
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months