[JBoss JIRA] (WFCORE-1354) Cannot clone a profile with a remoting subsystem but no io subsystem
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1354?page=com.atlassian.jira.plugi... ]
Jason Greene updated WFCORE-1354:
---------------------------------
Fix Version/s: 2.1.0.CR2
(was: 2.1.0.CR1)
> Cannot clone a profile with a remoting subsystem but no io subsystem
> --------------------------------------------------------------------
>
> Key: WFCORE-1354
> URL: https://issues.jboss.org/browse/WFCORE-1354
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Remoting
> Affects Versions: 2.0.10.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.1.0.CR2
>
>
> The remoting subsystem added a requirement for the new io subsystem's worker capability, but it has special logic such that the requirement is only added if an endpoint resource is configured. So, legacy configs (pre-io) won't have that resource, so there is no requirement.
> This breaks down in the case of the profile 'clone' op, as a placeholder resource we add for the endpoint (to allow reads of the default endpoint config data) ends up getting 'described' and added by the cloning process. So that added resource triggers an unmet requirement for the io worker:
> {code}
> [domain@localhost:9990 /] /profile=default:clone(to-profile=test)
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
> org.wildfly.io.worker.default in context 'profile=test'; There are no known registration points which can provide this capability."},
> "rolled-back" => true
> }
> {code}
> I'm not sure how to deal with this; some sort of marker is needed to disable 'describing' that placeholder resource.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6118) EJB subsystem adds a capability but does not remove it in remove handler
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-6118:
--------------------------------------
Summary: EJB subsystem adds a capability but does not remove it in remove handler
Key: WFLY-6118
URL: https://issues.jboss.org/browse/WFLY-6118
Project: WildFly
Issue Type: Bug
Components: Domain Management, EJB
Affects Versions: 10.0.0.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 10.1.0.Final
EJB3SubsystemAdd adds capability org.wildfly.ejb3.clustered.singleton but then EJB3SubsystemRemove does not remove it.
This breaks use cases where the subsystem is repeatedly added, particularly a cycle of
/profile=foo:clone(to-profile=bar)
... make some adjustments to bar
... oops, screwed up on those adjustments, lets start over!
/profile=bar:remove
/profile=foo:clone(to-profile=bar)
The last step will fail with:
{code}
[Host Controller] [33m[0m[31m12:05:13,818 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([[0m
[Host Controller] [31m ("profile" => "clone"),[0m
[Host Controller] [31m ("subsystem" => "ejb3")[0m
[Host Controller] [31m]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.ejb3.clustered.singleton' is already registered in context 'profile=clone'.[0m
[Host Controller] [31m at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:146)[0m
[Host Controller] [31m at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1430)[0m
[Host Controller] [31m at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1417)[0m
[Host Controller] [31m at org.jboss.as.ejb3.subsystem.EJB3SubsystemAdd.recordCapabilitiesAndRequirements(EJB3SubsystemAdd.java:178)[0m
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-1051) KieScanner does not initialize if missing to locate a kjar dependency of test scope
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1051?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-1051:
----------------------------------------
Description of proposed patch.
In {{KieRepositoryScannerImpl}} :
{code}
private Map<ReleaseId, DependencyDescriptor> indexAtifacts(ArtifactResolver artifactResolver) {
Map<ReleaseId, DependencyDescriptor> depsMap = new HashMap<ReleaseId, DependencyDescriptor>();
for (DependencyDescriptor dep : artifactResolver.getAllDependecies()) {
Artifact artifact = artifactResolver.resolveArtifact(dep.getReleaseId());
log.debug( artifact + " resolved to " + artifact.getFile() );
if (isKJar(artifact.getFile())) {
depsMap.put(dep.getReleaseIdWithoutVersion(), new DependencyDescriptor(artifact));
}
}
return depsMap;
}
{code}
problem is that if the dependency "dep" is not resolvable at runtime, the method {{artifactResolver.resolveArtifact(...)}} will return a null, and in turn a NPE, and in turn will fail the initialization of the KieScanner.
Proposal is to null guard the rest of the above mentioned code - if the variable "artifact" is not resolved, not considered as a KJar.
The ideal would be to have also the scope in the dependency/artifact information, so to check for this specifically, but frankly couldn't locate this data to propose a better patch for now - in case just reject it and let me know a few pointers I'm keen in getting it corrected because we have this issue on our projects.
Many thanks.
ps: with the proposed patch:
{code}
2016-02-03 18:09:02,278 INFO [com.acme.run_test_deps.App] (main) start
2016-02-03 18:09:02,306 DEBUG [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (main) KieModule Lookup. ReleaseId com.acme:test-deps:LATEST was not in cache, checking classpath
2016-02-03 18:09:02,306 DEBUG [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (main) KieModule Lookup. ReleaseId com.acme:test-deps:LATEST was not in cache, checking maven repository
[WARNING] The POM for com.acme:onlyfor-test-dep:jar:1.0.0-SNAPSHOT is missing, no dependency information available
2016-02-03 18:09:05,706 INFO [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (main) KieModule was added: ZipKieModule[releaseId=com.acme:test-deps:1.0.0-SNAPSHOT,file=C:\Users\mmortari\.m2\repository\com\acme\test-deps\1.0.0-SNAPSHOT\test-deps-1.0.0-SNAPSHOT.jar]
2016-02-03 18:09:07,005 DEBUG [org.kie.api.builder.KieScanner] (main) org.drools:drools-core:jar:6.2.0.Final resolved to C:\Users\mmortari\.m2\repository\org\drools\drools-core\6.2.0.Final\drools-core-6.2.0.Final.jar
2016-02-03 18:09:07,006 DEBUG [org.kie.api.builder.KieScanner] (main) org.mvel:mvel2:jar:2.2.4.Final resolved to C:\Users\mmortari\.m2\repository\org\mvel\mvel2\2.2.4.Final\mvel2-2.2.4.Final.jar
2016-02-03 18:09:07,007 DEBUG [org.kie.api.builder.KieScanner] (main) log4j:log4j:jar:1.2.17 resolved to C:\Users\mmortari\.m2\repository\log4j\log4j\1.2.17\log4j-1.2.17.jar
2016-02-03 18:09:07,008 DEBUG [org.kie.api.builder.KieScanner] (main) com.google.protobuf:protobuf-java:jar:2.5.0 resolved to C:\Users\mmortari\.m2\repository\com\google\protobuf\protobuf-java\2.5.0\protobuf-java-2.5.0.jar
2016-02-03 18:09:07,009 DEBUG [org.kie.api.builder.KieScanner] (main) org.kie:kie-internal:jar:6.2.0.Final resolved to C:\Users\mmortari\.m2\repository\org\kie\kie-internal\6.2.0.Final\kie-internal-6.2.0.Final.jar
2016-02-03 18:09:07,011 DEBUG [org.kie.api.builder.KieScanner] (main) com.thoughtworks.xstream:xstream:jar:1.4.7 resolved to C:\Users\mmortari\.m2\repository\com\thoughtworks\xstream\xstream\1.4.7\xstream-1.4.7.jar
2016-02-03 18:09:07,012 DEBUG [org.kie.api.builder.KieScanner] (main) org.slf4j:slf4j-api:jar:1.7.2 resolved to C:\Users\mmortari\.m2\repository\org\slf4j\slf4j-api\1.7.2\slf4j-api-1.7.2.jar
2016-02-03 18:09:07,013 DEBUG [org.kie.api.builder.KieScanner] (main) org.drools:drools-compiler:jar:6.2.0.Final resolved to C:\Users\mmortari\.m2\repository\org\drools\drools-compiler\6.2.0.Final\drools-compiler-6.2.0.Final.jar
2016-02-03 18:09:07,286 WARN [org.kie.scanner.MavenRepository] (main) Unable to resolve artifact: com.acme:onlyfor-test-dep:1.0.0-SNAPSHOT
org.eclipse.aether.resolution.ArtifactResolutionException: Could not find artifact com.acme:onlyfor-test-dep:jar:1.0.0-SNAPSHOT in internalmirror (http://localhost:8081/nexus/content/groups/public/)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:444)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223)
at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294)
at org.kie.scanner.MavenRepository.resolveArtifact(MavenRepository.java:216)
at org.kie.scanner.MavenRepository.resolveArtifact(MavenRepository.java:205)
at org.kie.scanner.MavenRepository.resolveArtifact(MavenRepository.java:201)
at org.kie.scanner.ArtifactResolver.resolveArtifact(ArtifactResolver.java:51)
at org.kie.scanner.KieRepositoryScannerImpl.indexAtifacts(KieRepositoryScannerImpl.java:330)
at org.kie.scanner.KieRepositoryScannerImpl.setKieContainer(KieRepositoryScannerImpl.java:73)
at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieScanner(KieServicesImpl.java:115)
at com.acme.run_test_deps.App.main(App.java:20)
Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact com.acme:onlyfor-test-dep:jar:1.0.0-SNAPSHOT in internalmirror (http://localhost:8081/nexus/content/groups/public/)
at org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:39)
at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:355)
at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
at org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581)
at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421)
... 11 more
2016-02-03 18:09:07,288 DEBUG [org.kie.api.builder.KieScanner] (main) com.acme:onlyfor-test-dep:1.0.0-SNAPSHOT not resolved.
2016-02-03 18:09:07,289 DEBUG [org.kie.api.builder.KieScanner] (main) commons-codec:commons-codec:jar:1.4 resolved to C:\Users\mmortari\.m2\repository\commons-codec\commons-codec\1.4\commons-codec-1.4.jar
2016-02-03 18:09:07,291 DEBUG [org.kie.api.builder.KieScanner] (main) org.antlr:antlr-runtime:jar:3.5 resolved to C:\Users\mmortari\.m2\repository\org\antlr\antlr-runtime\3.5\antlr-runtime-3.5.jar
2016-02-03 18:09:07,292 DEBUG [org.kie.api.builder.KieScanner] (main) org.codehaus.janino:janino:jar:2.5.16 resolved to C:\Users\mmortari\.m2\repository\org\codehaus\janino\janino\2.5.16\janino-2.5.16.jar
2016-02-03 18:09:07,294 DEBUG [org.kie.api.builder.KieScanner] (main) org.eclipse.jdt.core.compiler:ecj:jar:4.3.1 resolved to C:\Users\mmortari\.m2\repository\org\eclipse\jdt\core\compiler\ecj\4.3.1\ecj-4.3.1.jar
2016-02-03 18:09:07,295 DEBUG [org.kie.api.builder.KieScanner] (main) xpp3:xpp3_min:jar:1.1.4c resolved to C:\Users\mmortari\.m2\repository\xpp3\xpp3_min\1.1.4c\xpp3_min-1.1.4c.jar
2016-02-03 18:09:07,296 DEBUG [org.kie.api.builder.KieScanner] (main) junit:junit:jar:4.11 resolved to C:\Users\mmortari\.m2\repository\junit\junit\4.11\junit-4.11.jar
2016-02-03 18:09:07,297 DEBUG [org.kie.api.builder.KieScanner] (main) org.slf4j:slf4j-log4j12:jar:1.7.2 resolved to C:\Users\mmortari\.m2\repository\org\slf4j\slf4j-log4j12\1.7.2\slf4j-log4j12-1.7.2.jar
2016-02-03 18:09:07,298 DEBUG [org.kie.api.builder.KieScanner] (main) org.hamcrest:hamcrest-core:jar:1.3 resolved to C:\Users\mmortari\.m2\repository\org\hamcrest\hamcrest-core\1.3\hamcrest-core-1.3.jar
2016-02-03 18:09:07,299 DEBUG [org.kie.api.builder.KieScanner] (main) xmlpull:xmlpull:jar:1.1.3.1 resolved to C:\Users\mmortari\.m2\repository\xmlpull\xmlpull\1.1.3.1\xmlpull-1.1.3.1.jar
2016-02-03 18:09:07,301 DEBUG [org.kie.api.builder.KieScanner] (main) org.kie:kie-api:jar:6.2.0.Final resolved to C:\Users\mmortari\.m2\repository\org\kie\kie-api\6.2.0.Final\kie-api-6.2.0.Final.jar
RUNNING
{code}
is working OK, the KieScanner do initialize, enabling DEBUG in the log shows the 10second timeout for check for updates, and the last line is showing the status of the KieScanner indeed as running.
> KieScanner does not initialize if missing to locate a kjar dependency of test scope
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1051
> URL: https://issues.jboss.org/browse/DROOLS-1051
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.2.0.Final, 6.3.0.Final
> Reporter: Matteo Mortari
> Assignee: Mark Proctor
> Priority: Minor
> Attachments: reproducer-DROOLS-1051.zip
>
>
> I will attach PR for proposal of patch for {{KieRepositoryScannerImpl}}.
> I will attach reproducer code.
> Suppose a kjar has a _test_ scope dependency which may not be resolvable at runtime; the KieContainer will be created correctly (warning raised in log) but the initialization of the KieScanner fail with NPE.
> Expected behavior: also the KieScanner shall be able to initialize if the KieContainer is working correctly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-1051) KieScanner does not initialize if missing to locate a kjar dependency of test scope
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1051?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-1051:
-----------------------------------
Attachment: reproducer-DROOLS-1051.zip
Reproducers
> KieScanner does not initialize if missing to locate a kjar dependency of test scope
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1051
> URL: https://issues.jboss.org/browse/DROOLS-1051
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.2.0.Final, 6.3.0.Final
> Reporter: Matteo Mortari
> Assignee: Mark Proctor
> Priority: Minor
> Attachments: reproducer-DROOLS-1051.zip
>
>
> I will attach PR for proposal of patch for {{KieRepositoryScannerImpl}}.
> I will attach reproducer code.
> Suppose a kjar has a _test_ scope dependency which may not be resolvable at runtime; the KieContainer will be created correctly (warning raised in log) but the initialization of the KieScanner fail with NPE.
> Expected behavior: also the KieScanner shall be able to initialize if the KieContainer is working correctly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-1051) KieScanner does not initialize if missing to locate a kjar dependency of test scope
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-1051:
--------------------------------------
Summary: KieScanner does not initialize if missing to locate a kjar dependency of test scope
Key: DROOLS-1051
URL: https://issues.jboss.org/browse/DROOLS-1051
Project: Drools
Issue Type: Bug
Affects Versions: 6.3.0.Final, 6.2.0.Final
Reporter: Matteo Mortari
Assignee: Mark Proctor
Priority: Minor
I will attach PR for proposal of patch for {{KieRepositoryScannerImpl}}.
I will attach reproducer code.
Suppose a kjar has a _test_ scope dependency which may not be resolvable at runtime; the KieContainer will be created correctly (warning raised in log) but the initialization of the KieScanner fail with NPE.
Expected behavior: also the KieScanner shall be able to initialize if the KieContainer is working correctly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1340) Store "host ignore" data in the domain wide model
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1340?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1340:
-------------------------------------
Comment: was deleted
(was: A WFC 2 slave will send its ignore-unused-configuration setting when it registers. If this is set to true, the DC will not use any of this domain wide data in its handling of that slave. That setting means the slave is taking responsibility for informing the DC of what should be ignored. Mixing this WFCORE-1340 functionality into that creates too much complication.
An EAP 6.x slave can't set ignore-unused-configuration, so there is no confusion for that use case, which is the primary one.)
> Store "host ignore" data in the domain wide model
> -------------------------------------------------
>
> Key: WFCORE-1340
> URL: https://issues.jboss.org/browse/WFCORE-1340
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
> An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
> Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
> 1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
> 2) Extensions are not covered, so new extensions in later releases may need to be manually configured.
> Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data. The concept will be referred to as a "host-exclude" because what is happening in this case is not the slave ignoring some resources, it's the DC excluding them from the slave's view.
> Proposed structure:
> Resources are at address /host-exclude=*
> Attributes are:
> * management-major-version
> * management-minor-version
> * management-micro-version
> * host-release
> These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4, WildFly10.0) from which the api versions can be derived.
> If management-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
> In addition to the above scoping attributes, the following attributes will be supported:
> * ignored-extensions
> * active-server-groups
> * active-socket-binding-groups
> The ignored-extensions attribute is a list of extension names the resources for which (/extension=X) should be treated as ignored by the target hosts.
> The active-server-groups attribute is a list of server groups names the members of which should be treated as *not* ignored by the target hosts. These are the groups used by the host's servers. The server-group and related profile and socket-binding-group resources will not be ignored; all others of these types will be ignored. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
> The active-socket-binding-groups attribute is only meaningful if active-server-groups is set, and it only needs to be set if the set of socket-binding-groups associated with the groups listed in active-socket-binding-groups is not the complete set of sbgs needed on server's running the legacy release. This can happen is the server-config element for some servers overrides the normal socket-binding-group specified in the server-group config and specifies some different sbg. This is expected to be an edge case.
>
> Adding a new group to active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
> Changing the profile or socket-binding-group associated with a group listed in active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
> There is other data that could be included in these resources, e.g. fine grained "exclude" information matching what can be configured in host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand.
> A WildFly Core 2 or later slave will send its ignore-unused-configuration setting when it registers. If this is set to 'true', the DC will not use any of the domain wide active-server-groups and active-socket-binding-groups data in its handling of that slave. That setting means the slave is taking responsibility for informing the DC of what should server-groups, profiles and socket-binding-groups be ignored. Mixing this WFCORE-1340 functionality into that creates too much complication. However, the domain-wide 'ignored-extensions' data *will* be used for the slave.
> An EAP 6.x slave can't set ignore-unused-configuration, so there is no confusion for that use case, which is the primary one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-998) NullPointerException at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-998?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-998:
------------------------------------------------
Radovan Synek <rsynek(a)redhat.com> changed the Status of [bug 1302141|https://bugzilla.redhat.com/show_bug.cgi?id=1302141] from MODIFIED to VERIFIED
> NullPointerException at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> ---------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-998
> URL: https://issues.jboss.org/browse/DROOLS-998
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: OpenJDK Runtime Environment (IcedTea 2.6.3) (7u91-2.6.3-0ubuntu0.14.04.1)
> Reporter: Christian Spurk
> Assignee: Mario Fusco
> Fix For: 6.4.0.CR1
>
>
> The following {{NullPointerException}} occurs for the following rule:
> {code}
> Exception in thread "main" java.lang.NullPointerException
> at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
> at org.drools.core.phreak.PhreakAccumulateNode.doLeftDeletes(PhreakAccumulateNode.java:603)
> at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:65)
> at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:565)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:536)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:372)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:332)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:142)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:978)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1292)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260)
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:109)
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:34)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:292)
> at Test.main(Test.java:13)
> {code}
> {code}
> rule "test"
> when
> not( String() )
> accumulate(
> Long();
> sum(1)
> )
> ( Boolean() or not( Float() ) )
> then
> insert(new String());
> end
> {code}
> (Please ignore the nonsensical rule; I simply couldn't reproduce this issue in any better way without providing you my larger system where the (more complex) rule makes more sense.)
> I'm using a default KIE configuration to load the rule:
> {{kmodule.xml}}:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule" />
> {code}
> {{Test.java}}:
> {code}
> import org.kie.api.KieBase;
> import org.kie.api.KieServices;
> import org.kie.api.runtime.StatelessKieSession;
> import org.kie.internal.command.CommandFactory;
> public class Test {
> public static void main(String[] args) {
> KieBase kieBase = KieServices.Factory.get().getKieClasspathContainer()
> .getKieBase();
> StatelessKieSession session = kieBase.newStatelessKieSession();
> session.execute(CommandFactory.newFireAllRules());
> }
> }
> {code}
> This issue might be related with DROOLS-987.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5850) Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5850?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-5850:
----------------------------------------
[~lthon] What you describe is where I vaguely see WildFly capabilities and requirements going. That is the user declares capabilities they want and then we work out how to add those (and any missing requirements) to the config, using some default configuration of the capability. In some combination with the feature-pack stuff and perhaps future provisioning stuff [~aloubyansky] is looking at. The feature pack stuff currently does things a bit like this, but it's a tool for building dists, not updating existing ones. And what it does is currently xml oriented; i.e. it builds up a config file via text manipulation.
It will be quite a while before this kind of thing comes to fruition though, as it's something we progress on as we get bits of time here and there.
> Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
> ----------------------------------------------------------------
>
> Key: WFLY-5850
> URL: https://issues.jboss.org/browse/WFLY-5850
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Ladislav Thon
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 10.1.0.Final
>
>
> I just tried to migrate a {{standalone.xml}} server from clean EAP 6.4.0 to WildFly 10.0.0.CR4 and then deploy the {{server-side}} part of the {{ejb-remote}} quickstart:
> {code}
> git clone git@github.com:jboss-developer/jboss-eap-quickstarts.git
> cd jboss-eap-quickstarts/
> git checkout -b 6.4.x origin/6.4.x
> cd ejb-remote/server-side/
> mvn clean package -s ../../settings.xml
> cd target
> unzip .../jboss-eap-6.4.0.zip
> unzip .../wildfly-10.0.0.CR4.zip
> cp jboss-eap-6.4/standalone/configuration/standalone.xml wildfly-10.0.0.CR4/standalone/configuration/test.xml
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml --admin-only
> # on a separate console
> ./wildfly-10.0.0.CR4/bin/jboss-cli.sh -c --controller=localhost:9999
> /subsystem=threads:remove
> /extension=org.jboss.as.threads:remove
> /subsystem=web:migrate
> shutdown
> # on the original console
> cp jboss-ejb-remote-server-side.jar wildfly-10.0.0.CR4/standalone/deployments/
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml
> {code}
> What I get is this horrible stack trace:
> {code}
> 15:35:50,913 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "jboss-ejb-remote-server-side.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath.
> at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:271)
> at org.hibernate.validator.internal.cdi.ValidationExtension.<init>(ValidationExtension.java:109)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_66]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_66]
> at java.lang.Class.newInstance(Class.java:442) [rt.jar:1.8.0_66]
> at org.jboss.as.weld.deployment.WeldPortableExtensions.tryRegisterExtension(WeldPortableExtensions.java:53)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:121)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:81)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> ... 5 more
> 15:35:50,921 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "jboss-ejb-remote-server-side.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"jboss-ejb-remote-server-side.jar\"
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath."}}
> {code}
> When I deploy the same JAR to a clean install of WildFly 10.0.0.CR4, it works just fine. This suggests that something (probably the EJB subsystem?) doesn't correctly parse/serialize the legacy configuration. Or something like that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5850) Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFLY-5850?page=com.atlassian.jira.plugin.... ]
Ladislav Thon commented on WFLY-5850:
-------------------------------------
I'm not suggesting that we should do anything more right now, and certainly not as a part of this JIRA. That said, I also think that extensions/subsystems should own their default configuration and the need to duplicate that inside the migration tool is a bit suboptimal ;-)
> Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
> ----------------------------------------------------------------
>
> Key: WFLY-5850
> URL: https://issues.jboss.org/browse/WFLY-5850
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Ladislav Thon
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 10.1.0.Final
>
>
> I just tried to migrate a {{standalone.xml}} server from clean EAP 6.4.0 to WildFly 10.0.0.CR4 and then deploy the {{server-side}} part of the {{ejb-remote}} quickstart:
> {code}
> git clone git@github.com:jboss-developer/jboss-eap-quickstarts.git
> cd jboss-eap-quickstarts/
> git checkout -b 6.4.x origin/6.4.x
> cd ejb-remote/server-side/
> mvn clean package -s ../../settings.xml
> cd target
> unzip .../jboss-eap-6.4.0.zip
> unzip .../wildfly-10.0.0.CR4.zip
> cp jboss-eap-6.4/standalone/configuration/standalone.xml wildfly-10.0.0.CR4/standalone/configuration/test.xml
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml --admin-only
> # on a separate console
> ./wildfly-10.0.0.CR4/bin/jboss-cli.sh -c --controller=localhost:9999
> /subsystem=threads:remove
> /extension=org.jboss.as.threads:remove
> /subsystem=web:migrate
> shutdown
> # on the original console
> cp jboss-ejb-remote-server-side.jar wildfly-10.0.0.CR4/standalone/deployments/
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml
> {code}
> What I get is this horrible stack trace:
> {code}
> 15:35:50,913 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "jboss-ejb-remote-server-side.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath.
> at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:271)
> at org.hibernate.validator.internal.cdi.ValidationExtension.<init>(ValidationExtension.java:109)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_66]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_66]
> at java.lang.Class.newInstance(Class.java:442) [rt.jar:1.8.0_66]
> at org.jboss.as.weld.deployment.WeldPortableExtensions.tryRegisterExtension(WeldPortableExtensions.java:53)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:121)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:81)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> ... 5 more
> 15:35:50,921 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "jboss-ejb-remote-server-side.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"jboss-ejb-remote-server-side.jar\"
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath."}}
> {code}
> When I deploy the same JAR to a clean install of WildFly 10.0.0.CR4, it works just fine. This suggests that something (probably the EJB subsystem?) doesn't correctly parse/serialize the legacy configuration. Or something like that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months