[JBoss JIRA] (DROOLS-5362) Dependencies not necessarily loaded
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5362?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5362:
--------------------------------
Sprint: 2020 Week 22-24 (from May 25)
> Dependencies not necessarily loaded
> -----------------------------------
>
> Key: DROOLS-5362
> URL: https://issues.redhat.com/browse/DROOLS-5362
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 7.29.0.Final
> Reporter: Steve Davidson
> Assignee: Mario Fusco
> Priority: Major
> Labels: Kie-Server, kie-server
> Attachments: KieDependencyDemo.tbz
>
>
> When a Rule has a dependency on a class imported from a library jar in the local repository, the rule fails to compile/load:
> {code}
> May 22, 2020 3:35:05 PM org.drools.compiler.kie.builder.impl.AbstractKieProject buildKnowledgePackages
> SEVERE: Unable to build KieBaseModel:default-dependency-demo
> Unable to resolve ObjectType 'DemoData' : [Rule name='Inventory Item 001']
> Unable to resolve ObjectType 'DemoData' : [Rule name='Inventory Item 002']
> Rule Compilation error : [Rule name='Inventory Item 001']
> com/j2eeguys/demo/rules/Rule_Inventory_Item_0012002200180.java (2:40) : Only a type can be imported. com.j2eeguys.demo.data.DemoData resolves to a package
> com/j2eeguys/demo/rules/Rule_Inventory_Item_0012002200180.java (8:490) : jds cannot be resolved
> com/j2eeguys/demo/rules/Rule_Inventory_Item_0012002200180.java (9:543) : jds cannot be resolved
> Rule Compilation error : [Rule name='Inventory Item 002']
> com/j2eeguys/demo/rules/Rule_Inventory_Item_0021364978446.java (2:40) : Only a type can be imported. com.j2eeguys.demo.data.DemoData resolves to a package
> com/j2eeguys/demo/rules/Rule_Inventory_Item_0021364978446.java (8:490) : jds cannot be resolved
> com/j2eeguys/demo/rules/Rule_Inventory_Item_0021364978446.java (9:543) : jds cannot be resolved
> Error importing : 'com.j2eeguys.demo.data.DemoData'
> May 22, 2020 3:35:05 PM org.kie.server.services.impl.KieServerImpl createContainer
> SEVERE: Error creating container 'Kie Dependency Demo: kie-server' for module 'com.j2eeguys.demo:demo-dependency-rules:0.1.0-SNAPSHOT'
> java.lang.RuntimeException: Error while creating KieBase[Message [id=1, kieBase=default-dependency-demo, level=ERROR, path=com/j2eeguys/demo/rules/kieIssueDemo.drl, line=7, column=0
> text=Unable to resolve ObjectType 'DemoData'], Message [id=2, kieBase=default-dependency-demo, level=ERROR, path=com/j2eeguys/demo/rules/kieIssueDemo.drl, line=16, column=0
> text=Unable to resolve ObjectType 'DemoData'], Message [id=3, kieBase=default-dependency-demo, level=ERROR, path=com/j2eeguys/demo/rules/kieIssueDemo.drl, line=5, column=0
> text=Rule Compilation error Only a type can be imported. com.j2eeguys.demo.data.DemoData resolves to a package
> jds cannot be resolved
> jds cannot be resolved], Message [id=4, kieBase=default-dependency-demo, level=ERROR, path=com/j2eeguys/demo/rules/kieIssueDemo.drl, line=14, column=0
> text=Rule Compilation error Only a type can be imported. com.j2eeguys.demo.data.DemoData resolves to a package
> jds cannot be resolved
> jds cannot be resolved], Message [id=5, kieBase=default-dependency-demo, level=ERROR, path=com/j2eeguys/demo/rules/kieIssueDemo.drl, line=1, column=0
> text=Error importing : 'com.j2eeguys.demo.data.DemoData']]
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:379)
> at org.kie.server.services.drools.DroolsKieServerExtension.createContainer(DroolsKieServerExtension.java:98)
> at org.kie.server.services.impl.KieServerImpl.createContainer(KieServerImpl.java:286)
> at org.kie.server.remote.rest.common.resource.KieServerRestImpl.createContainer(KieServerRestImpl.java:157)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:443)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:233)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:139)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:142)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:219)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.eclipse.jetty.servlet.ServletHolder$NotAsyncServlet.service(ServletHolder.java:1401)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:760)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1617)
> at org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
> at org.kie.server.services.impl.security.web.CaptureHttpRequestFilter.doFilter(CaptureHttpRequestFilter.java:42)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:501)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1592)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1296)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1562)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1211)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:386)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:562)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:378)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:270)
> at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
> at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:388)
> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
> at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13509) Convert the EJB ApplicationSecurityDomain Service to new MSC APIs
by Darran Lofthouse (Jira)
Darran Lofthouse created WFLY-13509:
---------------------------------------
Summary: Convert the EJB ApplicationSecurityDomain Service to new MSC APIs
Key: WFLY-13509
URL: https://issues.redhat.com/browse/WFLY-13509
Project: WildFly
Issue Type: Task
Components: EJB
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 21.0.0.Beta1
This is in preparation for changes being made under WFLY-13434, under that issue it is desirable to re-advertise the SecurityDomain as an alias of the ApplicationSecurityDomain service - this is easier to achieve with the new MSC APIs.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFCORE-4982) Remove streaming from DeploymentUnitPhaseService
by Darran Lofthouse (Jira)
Darran Lofthouse created WFCORE-4982:
----------------------------------------
Summary: Remove streaming from DeploymentUnitPhaseService
Key: WFCORE-4982
URL: https://issues.redhat.com/browse/WFCORE-4982
Project: WildFly Core
Issue Type: Bug
Components: Server
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 12.0.0.Beta4
Presently the following is executed for every deployment for every deployment phase: -
{code:java}
Set<String> subSystemNames = list.stream().map(e -> e.getSubsystemName()).collect(Collectors.toSet());
{code}
This will be leading to a lot of unnecessary object allocation which could be avoided with a simple for loop instead.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ELY-1971) Bad designed wildlfy-elytron jar, shaded jar with dependencies
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-1971?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on ELY-1971:
---------------------------------------
The wildfly-elytron artefact is really only an intermediate artefact kept around for backwards compatibility as the project was split into individual modules but we kept the original artefact around for situations that already depended upon it.
If anything which is not a part of the Elytron project is shaded into the jar then that is in general a bug as it's only intent was to aggregate the WildFly Elytron classes into a single jar.
We probably should also look at the exclusions as this artefact should not need the Elytron artefacts a second time but I also expect this artefact to have a limited life and be removed in the next major version. Instead of shaded jars we probably should instead be looking at a small set of boms for some of the most common use cases.
> Bad designed wildlfy-elytron jar, shaded jar with dependencies
> --------------------------------------------------------------
>
> Key: ELY-1971
> URL: https://issues.redhat.com/browse/ELY-1971
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Marek Novotny
> Priority: Minor
>
> Wildfly-elytron jar is shaded with all wildfly elytron modules + jboss-logging, but it keeps the shaded classes in jar in its dependency chain which makes duplicated classes in dependency tree when using the wildfly-elytron in maven project.
> Avoiding duplicates would effectively need to add exclusion dependency to wildfly-elytron like:
> {noformat}
> <dependency>
> <groupId>org.wildlfy.security</groupId>
> <artifactId>wildfly-elytron</artifactId>
> <version>some-version</version>
> <exclusions>
> <exclusion>
> <groupId>*</groupId>
> <artifactId>*</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ELY-1971) Bad designed wildlfy-elytron jar, shaded jar with dependencies
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-1971?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated ELY-1971:
----------------------------------
Description:
Wildfly-elytron jar is shaded with all wildfly elytron modules + jboss-logging, but it keeps the shaded classes in jar in its dependency chain which makes duplicated classes in dependency tree when using the wildfly-elytron in maven project.
Avoiding duplicates would effectively need to add exclusion dependency to wildfly-elytron like:
{noformat}
<dependency>
<groupId>org.wildlfy.security</groupId>
<artifactId>wildfly-elytron</artifactId>
<version>some-version</version>
<exclusions>
<exclusion>
<groupId>*</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>
</dependency>
{noformat}
was:
Wildfly-elytron jar is shaded with all wildfly elytron modules + jboss-logging, but it keeps the shaded classes in jar in its dependency chain which makes duplicated classes in dependency tree when using the wildfly-elytron in maven project.
Avoiding duplicates would effectively need to add exclusion dependency to wildfly-elytron like:
{noformat}
<dependency>
<groupId>org.wildlfy.security</groupId>
<artifactId>wildfly-elytron</artifactId>
<version>some-version</version>
<exclusions>
<exclusion>
<groupId>*</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>
</dependency>
{noformat}
which is just a hack for bad designed artifact IMHO.
> Bad designed wildlfy-elytron jar, shaded jar with dependencies
> --------------------------------------------------------------
>
> Key: ELY-1971
> URL: https://issues.redhat.com/browse/ELY-1971
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Marek Novotny
> Priority: Optional
>
> Wildfly-elytron jar is shaded with all wildfly elytron modules + jboss-logging, but it keeps the shaded classes in jar in its dependency chain which makes duplicated classes in dependency tree when using the wildfly-elytron in maven project.
> Avoiding duplicates would effectively need to add exclusion dependency to wildfly-elytron like:
> {noformat}
> <dependency>
> <groupId>org.wildlfy.security</groupId>
> <artifactId>wildfly-elytron</artifactId>
> <version>some-version</version>
> <exclusions>
> <exclusion>
> <groupId>*</groupId>
> <artifactId>*</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ELY-1971) Bad designed wildlfy-elytron jar, shaded jar with dependencies
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-1971?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated ELY-1971:
----------------------------------
Priority: Minor (was: Optional)
> Bad designed wildlfy-elytron jar, shaded jar with dependencies
> --------------------------------------------------------------
>
> Key: ELY-1971
> URL: https://issues.redhat.com/browse/ELY-1971
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Marek Novotny
> Priority: Minor
>
> Wildfly-elytron jar is shaded with all wildfly elytron modules + jboss-logging, but it keeps the shaded classes in jar in its dependency chain which makes duplicated classes in dependency tree when using the wildfly-elytron in maven project.
> Avoiding duplicates would effectively need to add exclusion dependency to wildfly-elytron like:
> {noformat}
> <dependency>
> <groupId>org.wildlfy.security</groupId>
> <artifactId>wildfly-elytron</artifactId>
> <version>some-version</version>
> <exclusions>
> <exclusion>
> <groupId>*</groupId>
> <artifactId>*</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ELY-1971) Bad designed wildlfy-elytron jar, shaded jar with dependencies
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-1971?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated ELY-1971:
----------------------------------
Priority: Optional (was: Major)
> Bad designed wildlfy-elytron jar, shaded jar with dependencies
> --------------------------------------------------------------
>
> Key: ELY-1971
> URL: https://issues.redhat.com/browse/ELY-1971
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Marek Novotny
> Assignee: Darran Lofthouse
> Priority: Optional
>
> Wildfly-elytron jar is shaded with all wildfly elytron modules + jboss-logging, but it keeps the shaded classes in jar in its dependency chain which makes duplicated classes in dependency tree when using the wildfly-elytron in maven project.
> Avoiding duplicates would effectively need to add exclusion dependency to wildfly-elytron like:
> {noformat}
> <dependency>
> <groupId>org.wildlfy.security</groupId>
> <artifactId>wildfly-elytron</artifactId>
> <version>some-version</version>
> <exclusions>
> <exclusion>
> <groupId>*</groupId>
> <artifactId>*</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
> {noformat}
> which is just a hack for bad designed artifact IMHO.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ELY-1971) Bad designed wildlfy-elytron jar, shaded jar with dependencies
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-1971?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned ELY-1971:
-------------------------------------
Assignee: (was: Darran Lofthouse)
> Bad designed wildlfy-elytron jar, shaded jar with dependencies
> --------------------------------------------------------------
>
> Key: ELY-1971
> URL: https://issues.redhat.com/browse/ELY-1971
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Marek Novotny
> Priority: Optional
>
> Wildfly-elytron jar is shaded with all wildfly elytron modules + jboss-logging, but it keeps the shaded classes in jar in its dependency chain which makes duplicated classes in dependency tree when using the wildfly-elytron in maven project.
> Avoiding duplicates would effectively need to add exclusion dependency to wildfly-elytron like:
> {noformat}
> <dependency>
> <groupId>org.wildlfy.security</groupId>
> <artifactId>wildfly-elytron</artifactId>
> <version>some-version</version>
> <exclusions>
> <exclusion>
> <groupId>*</groupId>
> <artifactId>*</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
> {noformat}
> which is just a hack for bad designed artifact IMHO.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month