[JBoss JIRA] (WFLY-13405) Update CommonDeploymentService in release.
by Alexander Golovko (Jira)
[ https://issues.redhat.com/browse/WFLY-13405?page=com.atlassian.jira.plugi... ]
Alexander Golovko updated WFLY-13405:
-------------------------------------
Issue Type: Bug (was: Feature Request)
Description:
Current calls of ROOT_LOGGER.debugf("Started/Stopped CommonDeployment %s", new Object[0]); is error. It raises MissingFormatArgumentException exception since new Object[0] is empty array and it not compatible with %s in format argument.
Summary: Update CommonDeploymentService in release. (was: Update CommonDeploymentService in release. Current)
> Update CommonDeploymentService in release.
> ------------------------------------------
>
> Key: WFLY-13405
> URL: https://issues.redhat.com/browse/WFLY-13405
> Project: WildFly
> Issue Type: Bug
> Reporter: Alexander Golovko
> Assignee: Brian Stansberry
> Priority: Major
>
> Current calls of ROOT_LOGGER.debugf("Started/Stopped CommonDeployment %s", new Object[0]); is error. It raises MissingFormatArgumentException exception since new Object[0] is empty array and it not compatible with %s in format argument.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-313) [EAP7-1386] Cannot deploy simple jax-rs application to server without microprofile extenstions
by Ronald Sigal (Jira)
[ https://issues.redhat.com/browse/WFWIP-313?page=com.atlassian.jira.plugin... ]
Ronald Sigal edited comment on WFWIP-313 at 4/25/20 6:07 PM:
-------------------------------------------------------------
Hi [~pkremens],
Yeah, that old pull request was a straightforward port from RESTEasy 4.x to 3.x, and it assumes the presence of MicroProfile Config and Smallrye Config. Making MP Config optional complicates things. I've got a ResteasyConfig class now that tests for the presence of the related jars so that things won't blow up:
{code}
public ResteasyConfig()
{
try
{
Class.forName("org.eclipse.microprofile.config.spi.ConfigSource");
Class.forName("org.jboss.resteasy.microprofile.config.ServletConfigSourceImpl");
config = ResteasyConfigProvider.getConfig();
}
catch (Throwable e)
{
// Leave config == null.
}
}
{code}
So ResteasyConfigProvider.getConfig() won't get called unless the necessary classes are available.
I think I'll write a unit test that verifies that RESTEasy can run in the absence of the Config jars.
-Ron
was (Author: ron_sigal):
Hi [~pkremens],
Yeah, that old pull request was a straightforward port from RESTEasy 4.x to 3.x, and it assumes the presence of MicroProfile Config and Smallrye Config. Making MP Config optional complicates things. I've got a ResteasyConfig class now that tests for the presence of the related jars so that things won't blow up:
{code}
public ResteasyConfig()
{
try
{
Class.forName("org.eclipse.microprofile.config.spi.ConfigSource");
Class.forName("org.jboss.resteasy.microprofile.config.ServletConfigSourceImpl");
config = ResteasyConfigProvider.getConfig();
}
catch (Throwable e)
{
// Leave config == null.
}
}
{code}
So ResteasyConfigProvider.getConfig() won't get called unless the necessary classes are available.
I ran part of the RESTEasy testsuite, including the tests in org.jboss.resteasy.test.microprofile.config, after stripping the microprofile and wildrye stuff out of standalone.xml, and it passed.
I think I'll write a unit test that verifies that RESTEasy can run in the absence of the Config jars.
-Ron
> [EAP7-1386] Cannot deploy simple jax-rs application to server without microprofile extenstions
> ----------------------------------------------------------------------------------------------
>
> Key: WFWIP-313
> URL: https://issues.redhat.com/browse/WFWIP-313
> Project: WildFly WIP
> Issue Type: Quality Risk
> Reporter: Petr Kremensky
> Assignee: Ronald Sigal
> Priority: Major
>
> This one is probably caused by a fact that https://github.com/resteasy/Resteasy/pull/2250 was submitted a long time before the "MicroProfile Config will be available to EAP only when installing the MicroProfile expansion pack" was introduces. I just want to be sure that we're on a same page here and my understanding that this is a valid use case for EAP7-1386 is correct. If so, we might include similar use case into test plan to cover this.
> *Reproduce*
> Update the standalone.xml configuration file inside the WildFly server - remove all microprofile extensions/subsystems from it, and deploy a simple Jax-rs application - e.g. https://github.com/wildfly/quickstart/tree/master/helloworld-rs
> * WildFly 19.0.0.Final with default RESTEasy (3.11.0.Final)
> No issues with deployment.
> * WildFly 19.0.0.Final with RESTEasy 3.10.0-SNAPSHOT from https://github.com/resteasy/Resteasy/pull/2250 (7f10848)
> {noformat}
> 07:55:08,542 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 68) MSC000001: Failed to start service jboss.deployment.unit."helloworld-rs.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."helloworld-rs.war".undertow-deployment: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
> at org.eclipse.microprofile.config.spi.ConfigProviderResolver.loadSpi(ConfigProviderResolver.java:125)
> at org.eclipse.microprofile.config.spi.ConfigProviderResolver.instance(ConfigProviderResolver.java:110)
> at org.eclipse.microprofile.config.ConfigProvider.getConfig(ConfigProvider.java:105)
> at org.jboss.resteasy.microprofile.config.ResteasyConfigProvider.getConfig(ResteasyConfigProvider.java:11)
> at org.jboss.resteasy.plugins.server.servlet.ConfigurationBootstrap.getParameter(ConfigurationBootstrap.java:353)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:136)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:42)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:305)
> at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:145)
> at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:585)
> at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:556)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:598)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:97)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78)
> ... 8 more
> 07:55:08,546 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "helloworld-rs.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"helloworld-rs.war\".undertow-deployment" => "java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
> Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!"}}
> 07:55:08,547 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "helloworld-rs.war" was rolled back with the following failure message:
> {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"helloworld-rs.war\".undertow-deployment" => "java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
> Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!"}}
> {noformat}
> Please let me know in case that my expectations about this use case are wrong.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (LOGMGR-272) Create release for Jakarta EE 9 APIs
by James Perkins (Jira)
[ https://issues.redhat.com/browse/LOGMGR-272?page=com.atlassian.jira.plugi... ]
James Perkins commented on LOGMGR-272:
--------------------------------------
[~rhn-engineering-sstark] 2.3.0.Alpha1 has been released.
> Create release for Jakarta EE 9 APIs
> ------------------------------------
>
> Key: LOGMGR-272
> URL: https://issues.redhat.com/browse/LOGMGR-272
> Project: JBoss Log Manager
> Issue Type: Component Upgrade
> Components: core, ext
> Affects Versions: 3.0.0.Final
> Reporter: Scott Stark
> Assignee: James Perkins
> Priority: Major
> Fix For: 2.3.0.Alpha1
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> Our Jakarta EE reference implementations like Weld and Hibernate Validator have jboss-logmanager dependencies that have a conflict if the logmanager is configured to use the JsonFormatter since the Jakarta EE 9 version has changed the package to jakarta.json.* from javax.json.*.
> The core module does have a dependency on json for testing of the JsonFormatter.
> There are currently 2.0.0-RC2 versions of the jakarta.json:jakarta.json-api and org.glassfish:jakarta.json-api depednencies that support the jakarta.json.* packages. I'm not sure what branch/version numbering scheme would be wanted for this update, but I can create the PR for this once that is decided.
> Technically both javax and jakarta based versions could be used if a new version of the JsonFormatter was introduced under a new name, say JsonJkFormatter.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-314) [EAP7-1386] additional ConfigSources are always initialized
by Ronald Sigal (Jira)
[ https://issues.redhat.com/browse/WFWIP-314?page=com.atlassian.jira.plugin... ]
Ronald Sigal commented on WFWIP-314:
------------------------------------
Hi [~pkremens],
The way MicroProfile works is that it looks for a service loader file named META-INF/services/org.eclipse.microprofile.config.spi.ConfigSource and loads the contents. Currently, the file in resteasy-jaxrs is
{code}
org.jboss.resteasy.microprofile.config.ServletConfigSource
org.jboss.resteasy.microprofile.config.FilterConfigSource
org.jboss.resteasy.microprofile.config.ServletContextConfigSource
{code}
If there are no servlet-context properties, for example, that ConfigSource will be empty.
Note that if the Config jars are absent, then the ConfigSources won't get loaded. See https://issues.redhat.com/browse/WFWIP-313 for more about that.
-Ron
> [EAP7-1386] additional ConfigSources are always initialized
> -----------------------------------------------------------
>
> Key: WFWIP-314
> URL: https://issues.redhat.com/browse/WFWIP-314
> Project: WildFly WIP
> Issue Type: Quality Risk
> Reporter: Petr Kremensky
> Assignee: Ronald Sigal
> Priority: Minor
>
> I've noticed that three additional config sources provided by EAP7-1386 are always registered among config sources, even they are empty. I'll probably reject this one myself soon :) as I still have to look into the implementation of SPI for mp config, so I can assume that this is just out of box behaviour we have no control over.
> Test with a simple servlet from [helloworld|https://github.com/wildfly/quickstart/tree/master/helloworld] quickstart with following addition:
> {code:java}
> ConfigProvider.getConfig().getConfigSources().forEach(configSource -> {
> System.out.println("=================================");
> System.out.println(configSource.getName());
> System.out.println(configSource.getOrdinal());
> System.out.println("Property names: " + configSource.getPropertyNames().stream().collect(Collectors.joining(", ")));
> });
> {code}
> output:
> {noformat}
> =================================
> SysPropConfigSource
> 400
> [Standalone], awt.toolkit, ...
> =================================
> EnvConfigSource
> 300
> PATH, INVOCATION_ID, ...
> =================================
> null:null:ServletConfigSource
> 60
> =================================
> null:null:FilterConfigSource
> 50
> =================================
> null:ServletContextConfigSource
> 40
> {noformat}
> Notice that {{PropertiesConfigSource}} is missing there as none was put to classpath. On the other hand {PropertiesConfigSource} is present once added to classpath, even it is empty.
> {noformat}
> ...
> =================================
> PropertiesConfigSource[source=vfs:/content/helloworld.war/WEB-INF/classes/META-INF/microprofile-config.properties]
> 100
> Property names:
> =================================
> null:null:ServletConfigSource
> 60
> Property names:
> =================================
> null:null:FilterConfigSource
> 50
> Property names:
> =================================
> null:ServletContextConfigSource
> 40
> Property names:
> {noformat}
> As stated before, I'd probably close this one myself once I'll take deeper look into it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-313) [EAP7-1386] Cannot deploy simple jax-rs application to server without microprofile extenstions
by Ronald Sigal (Jira)
[ https://issues.redhat.com/browse/WFWIP-313?page=com.atlassian.jira.plugin... ]
Ronald Sigal commented on WFWIP-313:
------------------------------------
Hi [~pkremens],
Yeah, that old pull request was a straightforward port from RESTEasy 4.x to 3.x, and it assumes the presence of MicroProfile Config and Smallrye Config. Making MP Config optional complicates things. I've got a ResteasyConfig class now that tests for the presence of the related jars so that things won't blow up:
{code}
public ResteasyConfig()
{
try
{
Class.forName("org.eclipse.microprofile.config.spi.ConfigSource");
Class.forName("org.jboss.resteasy.microprofile.config.ServletConfigSourceImpl");
config = ResteasyConfigProvider.getConfig();
}
catch (Throwable e)
{
// Leave config == null.
}
}
{code}
So ResteasyConfigProvider.getConfig() won't get called unless the necessary classes are available.
I ran part of the RESTEasy testsuite, including the tests in org.jboss.resteasy.test.microprofile.config, after stripping the microprofile and wildrye stuff out of standalone.xml, and it passed.
I think I'll write a unit test that verifies that RESTEasy can run in the absence of the Config jars.
-Ron
> [EAP7-1386] Cannot deploy simple jax-rs application to server without microprofile extenstions
> ----------------------------------------------------------------------------------------------
>
> Key: WFWIP-313
> URL: https://issues.redhat.com/browse/WFWIP-313
> Project: WildFly WIP
> Issue Type: Quality Risk
> Reporter: Petr Kremensky
> Assignee: Ronald Sigal
> Priority: Major
>
> This one is probably caused by a fact that https://github.com/resteasy/Resteasy/pull/2250 was submitted a long time before the "MicroProfile Config will be available to EAP only when installing the MicroProfile expansion pack" was introduces. I just want to be sure that we're on a same page here and my understanding that this is a valid use case for EAP7-1386 is correct. If so, we might include similar use case into test plan to cover this.
> *Reproduce*
> Update the standalone.xml configuration file inside the WildFly server - remove all microprofile extensions/subsystems from it, and deploy a simple Jax-rs application - e.g. https://github.com/wildfly/quickstart/tree/master/helloworld-rs
> * WildFly 19.0.0.Final with default RESTEasy (3.11.0.Final)
> No issues with deployment.
> * WildFly 19.0.0.Final with RESTEasy 3.10.0-SNAPSHOT from https://github.com/resteasy/Resteasy/pull/2250 (7f10848)
> {noformat}
> 07:55:08,542 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 68) MSC000001: Failed to start service jboss.deployment.unit."helloworld-rs.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."helloworld-rs.war".undertow-deployment: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
> at org.eclipse.microprofile.config.spi.ConfigProviderResolver.loadSpi(ConfigProviderResolver.java:125)
> at org.eclipse.microprofile.config.spi.ConfigProviderResolver.instance(ConfigProviderResolver.java:110)
> at org.eclipse.microprofile.config.ConfigProvider.getConfig(ConfigProvider.java:105)
> at org.jboss.resteasy.microprofile.config.ResteasyConfigProvider.getConfig(ResteasyConfigProvider.java:11)
> at org.jboss.resteasy.plugins.server.servlet.ConfigurationBootstrap.getParameter(ConfigurationBootstrap.java:353)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:136)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:42)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:305)
> at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:145)
> at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:585)
> at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:556)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:598)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:97)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78)
> ... 8 more
> 07:55:08,546 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "helloworld-rs.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"helloworld-rs.war\".undertow-deployment" => "java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
> Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!"}}
> 07:55:08,547 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "helloworld-rs.war" was rolled back with the following failure message:
> {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"helloworld-rs.war\".undertow-deployment" => "java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
> Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!"}}
> {noformat}
> Please let me know in case that my expectations about this use case are wrong.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5155) Regression Issue: compile failed when use a decision table as Context Entry value
by xiaodong zhang (Jira)
[ https://issues.redhat.com/browse/DROOLS-5155?page=com.atlassian.jira.plug... ]
xiaodong zhang closed DROOLS-5155.
----------------------------------
> Regression Issue: compile failed when use a decision table as Context Entry value
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-5155
> URL: https://issues.redhat.com/browse/DROOLS-5155
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.33.0.Final
> Reporter: xiaodong zhang
> Assignee: Matteo Mortari
> Priority: Blocker
> Attachments: 11.png, aaa.dmn
>
>
> Regression Issue: compile failed when use a decision table as Context Entry value.
> The error message is :
> DMN: Validation of the DMN Model cannot be performed because of some runtime exception 'org.kie.dmn.model.v1_2.TContextEntry cannot be cast to org.kie.dmn.model.api.NamedElement'. (DMN Validation stopped on failed validation for some DMN Model)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (LOGMGR-272) Create release for Jakarta EE 9 APIs
by James Perkins (Jira)
[ https://issues.redhat.com/browse/LOGMGR-272?page=com.atlassian.jira.plugi... ]
James Perkins commented on LOGMGR-272:
--------------------------------------
Looks like Nexus is down :(. I'm ready to release 2.3.0.Alpha1 once Nexus is back up.
> Create release for Jakarta EE 9 APIs
> ------------------------------------
>
> Key: LOGMGR-272
> URL: https://issues.redhat.com/browse/LOGMGR-272
> Project: JBoss Log Manager
> Issue Type: Component Upgrade
> Components: core, ext
> Affects Versions: 3.0.0.Final
> Reporter: Scott Stark
> Assignee: James Perkins
> Priority: Major
> Fix For: 2.3.0.Alpha1
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> Our Jakarta EE reference implementations like Weld and Hibernate Validator have jboss-logmanager dependencies that have a conflict if the logmanager is configured to use the JsonFormatter since the Jakarta EE 9 version has changed the package to jakarta.json.* from javax.json.*.
> The core module does have a dependency on json for testing of the JsonFormatter.
> There are currently 2.0.0-RC2 versions of the jakarta.json:jakarta.json-api and org.glassfish:jakarta.json-api depednencies that support the jakarta.json.* packages. I'm not sure what branch/version numbering scheme would be wanted for this update, but I can create the PR for this once that is decided.
> Technically both javax and jakarta based versions could be used if a new version of the JsonFormatter was introduced under a new name, say JsonJkFormatter.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (LOGMGR-272) Create release for Jakarta EE 9 APIs
by James Perkins (Jira)
[ https://issues.redhat.com/browse/LOGMGR-272?page=com.atlassian.jira.plugi... ]
James Perkins updated LOGMGR-272:
---------------------------------
Fix Version/s: 2.3.0.Alpha1
> Create release for Jakarta EE 9 APIs
> ------------------------------------
>
> Key: LOGMGR-272
> URL: https://issues.redhat.com/browse/LOGMGR-272
> Project: JBoss Log Manager
> Issue Type: Component Upgrade
> Components: core, ext
> Affects Versions: 3.0.0.Final
> Reporter: Scott Stark
> Assignee: James Perkins
> Priority: Major
> Fix For: 2.3.0.Alpha1
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> Our Jakarta EE reference implementations like Weld and Hibernate Validator have jboss-logmanager dependencies that have a conflict if the logmanager is configured to use the JsonFormatter since the Jakarta EE 9 version has changed the package to jakarta.json.* from javax.json.*.
> The core module does have a dependency on json for testing of the JsonFormatter.
> There are currently 2.0.0-RC2 versions of the jakarta.json:jakarta.json-api and org.glassfish:jakarta.json-api depednencies that support the jakarta.json.* packages. I'm not sure what branch/version numbering scheme would be wanted for this update, but I can create the PR for this once that is decided.
> Technically both javax and jakarta based versions could be used if a new version of the JsonFormatter was introduced under a new name, say JsonJkFormatter.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (LOGMGR-272) Create release for Jakarta EE 9 APIs
by Scott Stark (Jira)
[ https://issues.redhat.com/browse/LOGMGR-272?page=com.atlassian.jira.plugi... ]
Scott Stark commented on LOGMGR-272:
------------------------------------
Sure, Alpha is fine and I suppose at some point Quarkus will want the Jakarta version, but right now I don't think they are in a hurry to move to those apis.
> Create release for Jakarta EE 9 APIs
> ------------------------------------
>
> Key: LOGMGR-272
> URL: https://issues.redhat.com/browse/LOGMGR-272
> Project: JBoss Log Manager
> Issue Type: Component Upgrade
> Components: core, ext
> Affects Versions: 3.0.0.Final
> Reporter: Scott Stark
> Assignee: James Perkins
> Priority: Major
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> Our Jakarta EE reference implementations like Weld and Hibernate Validator have jboss-logmanager dependencies that have a conflict if the logmanager is configured to use the JsonFormatter since the Jakarta EE 9 version has changed the package to jakarta.json.* from javax.json.*.
> The core module does have a dependency on json for testing of the JsonFormatter.
> There are currently 2.0.0-RC2 versions of the jakarta.json:jakarta.json-api and org.glassfish:jakarta.json-api depednencies that support the jakarta.json.* packages. I'm not sure what branch/version numbering scheme would be wanted for this update, but I can create the PR for this once that is decided.
> Technically both javax and jakarta based versions could be used if a new version of the JsonFormatter was introduced under a new name, say JsonJkFormatter.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years