[JBoss JIRA] (WFCORE-1353) Cannot clone or ad-hoc describe legacy extensions
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1353?page=com.atlassian.jira.plugi... ]
Jason Greene updated WFCORE-1353:
---------------------------------
Fix Version/s: 2.1.0.CR2
(was: 2.1.0.CR1)
> Cannot clone or ad-hoc describe legacy extensions
> -------------------------------------------------
>
> Key: WFCORE-1353
> URL: https://issues.jboss.org/browse/WFCORE-1353
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.10.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.1.0.CR2
>
>
> Trying to clone a profile that includes legacy extensions results in this failure (which is buried and not properly reported, but that's a different problem):
> WFLYCTL0309: Legacy extension 'org.jboss.as.web' is not supported on servers running this version. The extension is only supported for use by hosts running a previous release in a mixed-version managed domain
> It's created by UnsupportedSubsystemDescribeHandler.
> That failure made some sense when the only use of the 'describe' op was by an HC launching a domain server, but now 'describe' is also an impl detail of the 'clone' op, and describe may also be executed independently by users.
> We need to distinguish the server launch case from other uses and only fail in the former.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ]
Jason Greene updated WFCORE-1351:
---------------------------------
Fix Version/s: 2.1.0.CR2
(was: 2.1.0.CR1)
> FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1351
> URL: https://issues.jboss.org/browse/WFCORE-1351
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Ondrej Kotek
> Assignee: David Lloyd
> Priority: Critical
> Fix For: 2.1.0.CR2
>
>
> # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like
> {noformat}
> ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager
> {noformat}
> results in exception:
> {noformat}
> java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> {noformat}
> To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_:
> {noformat}
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"),
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"),
> new RemotingPermission("createEndpoint"),
> new RuntimePermission("createXnioWorker"),
> new RemotingPermission("addConnectionProvider"),
> new RuntimePermission("modifyThread"),
> new RuntimePermission("accessDeclaredMembers"),
> new ReflectPermission("suppressAccessChecks")
> {noformat}
> which is very confusing.
> Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[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)
8 years, 5 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)
8 years, 5 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)
8 years, 5 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)
8 years, 5 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)
8 years, 5 months