[JBoss JIRA] (WFCORE-4612) Dependency on javaee.api by ExternalModuleDependencySpecService should be optional
by Brian Stansberry (Jira)
Brian Stansberry created WFCORE-4612:
----------------------------------------
Summary: Dependency on javaee.api by ExternalModuleDependencySpecService should be optional
Key: WFCORE-4612
URL: https://issues.jboss.org/browse/WFCORE-4612
Project: WildFly Core
Issue Type: Enhancement
Components: Server
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The module spec for any module created by ExternalModuleSpecService has a dependency on javaee.api added. That should be an optional dependency, allowing this feature to be used in slimmed servers that may not have the javaee.api module installed.
It seems it's pretty easy to provision such a server, as that module is not heavily depended on:
{code}
$ git grep javaee.api | grep module.xml | grep -v src/test
feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml: <module name="javaee.api"/>
feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml: reexported by javaee.api. -->
feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml:<module xmlns="urn:jboss:module:1.5" name="javaee.api">
feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml: <module name="javaee.api"/>
jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml: <module name="javaee.api"/>
jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml: reexported by javaee.api. -->
jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml: <module name="javaee.api"/>
jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml: reexported by javaee.api. -->
{code}
JavaEEDependencyProcessor in WildFly explicitly does not add javaee.api as a dep.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFCORE-4611) Complete AttributeDefinition.getImmutableFlags() -> getFlags() transition
by Paul Ferraro (Jira)
Paul Ferraro created WFCORE-4611:
------------------------------------
Summary: Complete AttributeDefinition.getImmutableFlags() -> getFlags() transition
Key: WFCORE-4611
URL: https://issues.jboss.org/browse/WFCORE-4611
Project: WildFly Core
Issue Type: Bug
Components: Management
Affects Versions: 9.0.2.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
During the 3.0.0 development cycle, the AttributeDefinition.getFlags() methods was deprecated with the intention of letting consumers know to generalize the return type from an EnumSet<AttributeAccess.Flag> to a Set<AttributeAccess.Flag>.
I think enough time has passed to complete this transition.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-12390) Hot-Deploy throws IllegalStateException: Timer already cancelled
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12390?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-12390:
-----------------------------------------
[~r0osl] Also, please describe how you do hot-deploy, just in case the precise details are relevant / provide some clue.
> Hot-Deploy throws IllegalStateException: Timer already cancelled
> ----------------------------------------------------------------
>
> Key: WFLY-12390
> URL: https://issues.jboss.org/browse/WFLY-12390
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 17.0.1.Final
> Environment: any OS
> single Wildfly 17 (not yet in production)
> Reporter: David Schmidt
> Assignee: Cheng Fang
> Priority: Major
>
> I did an Upgrade from 11 to 17.0.1 and now I'm getting IllegalStateException on hot-deploys.
> What I tried without result:
> * truncate the jboss_ejb_timer table (to remove existing)
> * remove all old @Schedule and add a new different timer
> * use @Resource TimerService instead of @Schedule
> restart allows to deploy again (for a time)
> {code}
> 2019-08-16 16:13:14,940 ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."xxxxxxx.war".component.CronJobs.START: org.jboss.msc.service.Star
> tException in service jboss.deployment.unit."xxxxxxx.war".component.CronJobs.START: java.lang.IllegalStateException: Timer already cancelled.
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 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:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.IllegalStateException: Timer already cancelled.
> at java.util.Timer.sched(Timer.java:397)
> at java.util.Timer.schedule(Timer.java:193)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.scheduleTimeout(TimerServiceImpl.java:906)
> at org.jboss.as.ejb3.timerservice.TimerImpl.scheduleTimeout(TimerImpl.java:537)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:785)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:756)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.activate(TimerServiceImpl.java:223)
> at org.jboss.as.ejb3.component.EJBComponent.init(EJBComponent.java:595)
> at org.jboss.as.ee.component.BasicComponent.start(BasicComponent.java:222)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:136)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 8 more
> {code}
> As it happens in programming, I can't reproduce this at the moment. I got tormented for weeks but today it doesn't happen...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months