[JBoss JIRA] (WFLY-13195) Upgrade WildFly Common to 1.5.2.Final
by Ingo Weiss (Jira)
[ https://issues.redhat.com/browse/WFLY-13195?page=com.atlassian.jira.plugi... ]
Ingo Weiss reassigned WFLY-13195:
---------------------------------
Assignee: Daniel Kreling (was: Yeray Borges Santana)
> Upgrade WildFly Common to 1.5.2.Final
> -------------------------------------
>
> Key: WFLY-13195
> URL: https://issues.redhat.com/browse/WFLY-13195
> Project: WildFly
> Issue Type: Component Upgrade
> Affects Versions: 7.3.0.GA
> Reporter: Ingo Weiss
> Assignee: Daniel Kreling
> Priority: Major
> Labels: MP3.3
> Fix For: 7.3.1.GA
>
>
> This dependency is brought in by wildfly-core into wildfly, however, we are still requiring it explicitly in wildfly because it is used as a plugin dependency on wildfly-galleon-maven-plugin:
> {code:xml}
> <plugin>
> <groupId>org.wildfly.galleon-plugins</groupId>
> <artifactId>wildfly-galleon-maven-plugin</artifactId>
> <version>${version.org.wildfly.galleon-plugins}</version>
> <dependencies>
> <!-- feature-spec-gen uses wildfly-embedded to generate the feature specs, hence the designated wildfly-embedded version must match the pack one -->
> <dependency>
> <groupId>org.wildfly.core</groupId>
> <artifactId>wildfly-embedded</artifactId>
> <version>${version.org.wildfly.core}</version>
> </dependency>
> <!-- If you add a dependency on wildfly-embedded you need to bring your own transitives -->
> <dependency>
> <groupId>org.wildfly.common</groupId>
> <artifactId>wildfly-common</artifactId>
> <version>${version.org.wildfly.common}</version>
> </dependency>
> </dependencies>
> </plugin>
> {code}
> So, this upgrade is just to keep it in sync with the currentwildfly-core version we are using at the moment
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13195) Upgrade WildFly Common to 1.5.2.Final
by Ingo Weiss (Jira)
Ingo Weiss created WFLY-13195:
---------------------------------
Summary: Upgrade WildFly Common to 1.5.2.Final
Key: WFLY-13195
URL: https://issues.redhat.com/browse/WFLY-13195
Project: WildFly
Issue Type: Component Upgrade
Reporter: Ingo Weiss
Assignee: Yeray Borges Santana
Fix For: 19.0.0.Beta1
This dependency is brought in by wildfly-core into wildfly, however, we are still requiring it explicitly in wildfly because it is used as a plugin dependency on wildfly-galleon-maven-plugin:
{code:xml}
<plugin>
<groupId>org.wildfly.galleon-plugins</groupId>
<artifactId>wildfly-galleon-maven-plugin</artifactId>
<version>${version.org.wildfly.galleon-plugins}</version>
<dependencies>
<!-- feature-spec-gen uses wildfly-embedded to generate the feature specs, hence the designated wildfly-embedded version must match the pack one -->
<dependency>
<groupId>org.wildfly.core</groupId>
<artifactId>wildfly-embedded</artifactId>
<version>${version.org.wildfly.core}</version>
</dependency>
<!-- If you add a dependency on wildfly-embedded you need to bring your own transitives -->
<dependency>
<groupId>org.wildfly.common</groupId>
<artifactId>wildfly-common</artifactId>
<version>${version.org.wildfly.common}</version>
</dependency>
</dependencies>
</plugin>
{code}
So, this upgrade is just to keep it in sync with the currentwildfly-core version we are using at the moment
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13194) Upgrade galleon to 4.2.3
by Ingo Weiss (Jira)
Ingo Weiss created WFLY-13194:
---------------------------------
Summary: Upgrade galleon to 4.2.3
Key: WFLY-13194
URL: https://issues.redhat.com/browse/WFLY-13194
Project: WildFly
Issue Type: Component Upgrade
Components: Build System
Reporter: Ingo Weiss
Assignee: Jean Francois Denise
Fix For: 19.0.0.Beta1
This upgrade allows to get rid-off universe and producer dependencies needed when generating offliner file.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-5126) JavaDialectConfiguration.LANGUAGE_LEVELS being strings causes binary search to not properly locate version 9
by Nikola Atanasov (Jira)
Nikola Atanasov created DROOLS-5126:
---------------------------------------
Summary: JavaDialectConfiguration.LANGUAGE_LEVELS being strings causes binary search to not properly locate version 9
Key: DROOLS-5126
URL: https://issues.redhat.com/browse/DROOLS-5126
Project: Drools
Issue Type: Bug
Affects Versions: 7.33.0.Final
Reporter: Nikola Atanasov
Assignee: Mario Fusco
When i created a simple drools project (version 7.33.0.final) in eclipse (plugin version 7.32.0 final), i ran into the following error.
(Note: drools file didn't specify "dialect java")
{code:java}
java.lang.RuntimeException: Unable to load dialect 'org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration:java:org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration'
at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.addDialect(KnowledgeBuilderConfigurationImpl.java:405)
at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.buildDialectConfigurationMap(KnowledgeBuilderConfigurationImpl.java:391)
at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.init(KnowledgeBuilderConfigurationImpl.java:239)
at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.init(KnowledgeBuilderConfigurationImpl.java:191)
at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.<init>(KnowledgeBuilderConfigurationImpl.java:159)
at org.drools.compiler.kie.builder.impl.AbstractKieProject.getBuilderConfiguration(AbstractKieProject.java:302)
at org.drools.compiler.kie.builder.impl.AbstractKieProject.createKnowledgeBuilder(AbstractKieProject.java:288)
at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages(AbstractKieProject.java:213)
at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:75)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:274)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:242)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:192)
at com.sample.RunnableTest.createKieBase(RunnableTest.java:67)
at com.sample.RunnableTest.run(RunnableTest.java:36)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.RuntimeException: value '9' is not a valid language level
at org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration.setJavaLanguageLevel(JavaDialectConfiguration.java:102)
at org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration.init(JavaDialectConfiguration.java:80)
at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.addDialect(KnowledgeBuilderConfigurationImpl.java:401)
... 14 more
{code}
Once debugged, i saw that the "LANGUAGE_LEVEL" array in "JavaDialectConfiguration" stores the java versions as strings, and in the method that throws the exception "setJavaLanguageLevel", it uses binary search to locate the version from that array.
The problem with this is that it compares them lexicographically, so java version 9 would be greater than versions 10, 11 and 12.
So, out of the array {"1.5", "1.6", "1.7", "1.8", "9", "10", "11", "12"}, to find 9, the following values are tried out:
# Start: low=0, high=7
# Middle (index 3) is 1.8, smaller than 9, move middle to 10, low=4(mid + 1), high=7
# Middle (index 5) is 10, smaller than 9, move middle to 11, low=6(mid + 1), high=7
# Middle (index 6) is 11, smaller than 9, move middle to 12, low=7(mid + 1), high=7
# Middle is 12, smaller than 9, low > high, end search
The fix would be simple enough, either they should be sorted (lexicographically), or they should be floats.
My default workspace jre is 9.0.1.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13185) Rest-client can't be used without opentracing subsystem present in config
by r searls (Jira)
[ https://issues.redhat.com/browse/WFLY-13185?page=com.atlassian.jira.plugi... ]
r searls edited comment on WFLY-13185 at 3/4/20 3:57 PM:
---------------------------------------------------------
Rather than throw a NullPointException when a class without a @RegisterRestClient
annotation is presented to RestClientExtension, RESTEasy should handle this scenario in
some better fashion. Team discussion is under way.
was (Author: rsearls):
Rather than throw a NullPointException when a class without a @RegisterRestClient
annotation is present to RestClientExtension RESTEasy should handle this scenario in
some better fashion. Team discussion is under way.
> Rest-client can't be used without opentracing subsystem present in config
> -------------------------------------------------------------------------
>
> Key: WFLY-13185
> URL: https://issues.redhat.com/browse/WFLY-13185
> Project: WildFly
> Issue Type: Bug
> Components: MP REST Client
> Reporter: Jean Francois Denise
> Assignee: Alessio Soldano
> Priority: Critical
> Attachments: README, rest-reproducer.zip
>
>
> Trying to provision the following set of galleon layers:
> jaxrs ==> for jaxrs and rest-client
> microprofile-config
> I am getting an NPE. If open-tracing is provisioned along with jaxrs, no NPE and client injection works fine.
> java.lang.NullPointerException
> at org.jboss.resteasy.microprofile.client.RestClientExtension.extractBaseUri(RestClientExtension.java:40)
> at org.jboss.resteasy.microprofile.client.RestClientExtension.registerRestClient(RestClientExtension.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95)
> at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:85)
> at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:168)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:330)
> at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:123)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:308)
> at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:286)
> at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:207)
> at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:176)
> at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:166)
> at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:219)
> at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:421)
> at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:79)
> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:96)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13185) Rest-client can't be used without opentracing subsystem present in config
by r searls (Jira)
[ https://issues.redhat.com/browse/WFLY-13185?page=com.atlassian.jira.plugi... ]
r searls commented on WFLY-13185:
---------------------------------
Rather than throw a NullPointException when a class without a @RegisterRestClient
annotation is present to RestClientExtension RESTEasy should handle this scenario in
some better fashion. Team discussion is under way.
> Rest-client can't be used without opentracing subsystem present in config
> -------------------------------------------------------------------------
>
> Key: WFLY-13185
> URL: https://issues.redhat.com/browse/WFLY-13185
> Project: WildFly
> Issue Type: Bug
> Components: MP REST Client
> Reporter: Jean Francois Denise
> Assignee: Alessio Soldano
> Priority: Critical
> Attachments: README, rest-reproducer.zip
>
>
> Trying to provision the following set of galleon layers:
> jaxrs ==> for jaxrs and rest-client
> microprofile-config
> I am getting an NPE. If open-tracing is provisioned along with jaxrs, no NPE and client injection works fine.
> java.lang.NullPointerException
> at org.jboss.resteasy.microprofile.client.RestClientExtension.extractBaseUri(RestClientExtension.java:40)
> at org.jboss.resteasy.microprofile.client.RestClientExtension.registerRestClient(RestClientExtension.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95)
> at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:85)
> at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:168)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:330)
> at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:123)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:308)
> at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:286)
> at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:207)
> at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:176)
> at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:166)
> at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:219)
> at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:421)
> at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:79)
> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:96)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13185) Rest-client can't be used without opentracing subsystem present in config
by r searls (Jira)
[ https://issues.redhat.com/browse/WFLY-13185?page=com.atlassian.jira.plugi... ]
r searls commented on WFLY-13185:
---------------------------------
The cause of the NullPointerException in RestClientExtension is the
"ProcessAnnotatedType<?> type" input parameter (i.e. class com.example.wfjwt.client.Service)
which Weld creates and passes into method RestClientExtension.registerRestClient no
longer has the annotation @RegisterRestClient.
I have traced the issue back to the point of Weld creation,
org.jboss.weld.annotated.slim.backed.BackedAnnotatedType line 64
this.constructors = new BackedAnnotatedConstructors();
The constructor returned is
public abstract interface @ApplicationScoped class com.example.wfjwt.client.Service
There is no @RegisterRestClient annotation present.
I suggest contacting the Weld team about this. I will be happy to collaborate
with them to resolve this but I know nothing about welds support for MPC.
> Rest-client can't be used without opentracing subsystem present in config
> -------------------------------------------------------------------------
>
> Key: WFLY-13185
> URL: https://issues.redhat.com/browse/WFLY-13185
> Project: WildFly
> Issue Type: Bug
> Components: MP REST Client
> Reporter: Jean Francois Denise
> Assignee: Alessio Soldano
> Priority: Critical
> Attachments: README, rest-reproducer.zip
>
>
> Trying to provision the following set of galleon layers:
> jaxrs ==> for jaxrs and rest-client
> microprofile-config
> I am getting an NPE. If open-tracing is provisioned along with jaxrs, no NPE and client injection works fine.
> java.lang.NullPointerException
> at org.jboss.resteasy.microprofile.client.RestClientExtension.extractBaseUri(RestClientExtension.java:40)
> at org.jboss.resteasy.microprofile.client.RestClientExtension.registerRestClient(RestClientExtension.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95)
> at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:85)
> at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:168)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:330)
> at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:123)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:308)
> at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:286)
> at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:207)
> at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:176)
> at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:166)
> at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:219)
> at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:421)
> at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:79)
> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:96)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months