[JBoss JIRA] (DROOLS-1152) New jBPM maven project can be created only with hello world process
by Robert (Bob) Brodt (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1152?page=com.atlassian.jira.plugi... ]
Robert (Bob) Brodt commented on DROOLS-1152:
--------------------------------------------
I'm not seeing this, I'm able to create JUnit test processes with both types.
> New jBPM maven project can be created only with hello world process
> -------------------------------------------------------------------
>
> Key: DROOLS-1152
> URL: https://issues.jboss.org/browse/DROOLS-1152
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Affects Versions: 6.4.0.Final
> Environment: * JBDS 9.1.0.GA
> * drools-jbpm plugin 6.4.1.201604291802
> Reporter: Jozef Marko
> Assignee: Robert (Bob) Brodt
>
> In project created via [1] can be created only hello world sample process while in project created via [2] can be created also more complex sample process and optionally JUnit test.
> [1]
> File -> New -> Other -> jBPM -> jBPM project -> project with example files -> build project using maven
> [2]
> File -> New -> Other -> jBPM -> jBPM project -> project with example files -> build project using Java and jBPM classes
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-384) Server does wrongly reference a list of socket binding groups
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-384?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-384:
------------------------------------
Labels: 2.2 (was: )
> Server does wrongly reference a list of socket binding groups
> -------------------------------------------------------------
>
> Key: WFCORE-384
> URL: https://issues.jboss.org/browse/WFCORE-384
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Ken Wills
> Labels: 2.2
> Fix For: 3.0.0.Beta1
>
>
> hbraun: i see that a server (host=foo/server=bar) can have a list of socket-binding-groups
> [10:59am] hbraun: shouldn't that be a a single socket binding instead?
> [11:00am] emuckenhuber: oh... yeah
> [11:00am] hbraun: maybe it's just the description that's wrong
> [11:00am] emuckenhuber: that sounds similar to the jvm thing we had
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6554) Cache configuration are not eagerly defined in Cache Container
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6554?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6554:
------------------------------------
I can't see why this should be happening. Can you attach a reproducer?
> Cache configuration are not eagerly defined in Cache Container
> --------------------------------------------------------------
>
> Key: WFLY-6554
> URL: https://issues.jboss.org/browse/WFLY-6554
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
>
> In WF8 we used the cache configuration start="EAGER" to force the initialization of the cache configuration.
> In my scenario, we especially used that trick to define all cache configuration (i.e. entity / timestamps / local-query) in the hibernate cache container before any of our war was deployed. Doing so, when wiring the EntityManager programatically (in our application), we were able to depend on the JNDIRegionFactory without getting any NullPointerException/etc.
> This trick has only one bad side effect, which was the creation of unecessary caches.
> Now in WF10, the eager feature is gone and it seems that even if the cache container is available at startup (as discussed in: https://developer.jboss.org/thread/259151) the defined caches are not.
> I do not know if this is a bug or this is by design but this seems wrong to me.
> If we define caches within standalone.xml, I would definitly like to have them defined at the container level. I think it's fair to assume that when pulling the CacheManager all defined caches should have been there.
> I would suggest that when reading all the infinispan subsystem, each cache contained in each cache container be eagerly defined to avoid any issue (and I really meant "defined" and not "started").
> Doing so this would resolve our EntityManager second level cache bootstraping without relying on our application to define the missing cache configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6571) ClassNotFoundException while using remote-store for hibernate entity cache
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6571?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-6571.
------------------------------
Resolution: Duplicate Issue
Duplicate of WFLY-6203.
> ClassNotFoundException while using remote-store for hibernate entity cache
> --------------------------------------------------------------------------
>
> Key: WFLY-6571
> URL: https://issues.jboss.org/browse/WFLY-6571
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Environment: * Java version: 1.8.0_45, vendor: Oracle Corporation
> * OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Reporter: Gunther v. Wolffersdorff
> Assignee: Paul Ferraro
> Labels: infinispan, remote-store
> Attachments: infinispan.zip, persistence.xml, sample.zip, standalone.sample.ha.xml
>
>
> * configure hibernate cache, default cache is entity
> * configure entity cache as invalidation-cache with remote-store
> * deploying an application having @Cachable entities
> -> you get:
> 08:55:54,656 UTC INFO [org.hibernate.cache.spi.UpdateTimestampsCache] (ServerService Thread Pool -- 28) HHH000250: Starting update timestamps cache at region: sample-ear.ear/sample-ejb.jar#primary.org.hibernate.ca che.spi.UpdateTimestampsCache
> 08:55:54,656 UTC INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 28) WFLYCLINF0002: Started sample-ear.ear/sample-ejb.jar#primary.org.hibernate.cache.spi.UpdateTimestampsCache cache from hi bernate container
> 08:55:54,656 UTC INFO [org.hibernate.cache.internal.StandardQueryCache] (ServerService Thread Pool -- 28) HHH000248: Starting query cache at region: sample-ear.ear/sample-ejb.jar#primary.org.hibernate.cache.intern al.StandardQueryCache
> 08:55:54,671 UTC INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 28) WFLYCLINF0002: Started sample-ear.ear/sample-ejb.jar#primary.org.hibernate.cache.internal.StandardQueryCache cache from hibernate container
> 08:55:54,754 UTC ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 28) MSC000001: Failed to start service jboss.persistenceunit."sample-ear.ear/sample-ejb.jar#primary": org.jboss.msc.service.StartExc eption in service jboss.persistenceunit."sample-ear.ear/sample-ejb.jar#primary": javax.persistence.PersistenceException: [PersistenceUnit: primary] Unable to build Hibernate SessionFactory
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172) [wildfly-jpa-10.0.0.Final.jar:10.0.0.Final]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-10.0.0.Final.jar:10.0.0.Final]
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182) [wildfly-jpa-10.0.0.Final.jar:10.0.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.persistence.PersistenceException: [PersistenceUnit: primary] Unable to build Hibernate SessionFactory
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:954) [hibernate-entitymanager-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:882) [hibernate-entitymanager-5.0.7.Final.jar:5.0.7.Final]
> at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154) [wildfly-jpa-10.0.0.Final.jar:10.0.0.Final]
> ... 7 more
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.start() on object of type PersistenceManagerImpl
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:870)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:639)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:628)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:531)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:222)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:849)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:621)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:572)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:440)
> at org.jboss.as.clustering.infinispan.DefaultCacheContainer.lambda$getCache$6(DefaultCacheContainer.java:119)
> at org.jboss.as.clustering.infinispan.DefaultCacheContainer$$Lambda$112/661685893.run(Unknown Source)
> at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:120)
> at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:114)
> at org.hibernate.cache.infinispan.InfinispanRegionFactory.getCache(InfinispanRegionFactory.java:673)
> at org.hibernate.cache.infinispan.InfinispanRegionFactory.buildEntityRegion(InfinispanRegionFactory.java:285)
> at org.hibernate.internal.SessionFactoryImpl.determineEntityRegionAccessStrategy(SessionFactoryImpl.java:619) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:332) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444) [hibernate-core-5.0.7.Final.jar:5.0.7.Final]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879) [hibernate-entitymanager-5.0.7.Final.jar:5.0.7.Final]
> ... 9 more
> Caused by: org.infinispan.commons.CacheException: Unable to start cache loaders
> at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:174)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_45]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_45]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> ... 28 more
> Caused by: org.infinispan.commons.CacheConfigurationException: Unable to instantiate class org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy
> at org.infinispan.commons.util.Util.loadClass(Util.java:103)
> at org.infinispan.client.hotrod.configuration.ConfigurationBuilder.balancingStrategy(ConfigurationBuilder.java:125)
> at org.infinispan.persistence.remote.RemoteStore.buildRemoteConfiguration(RemoteStore.java:221)
> at org.infinispan.persistence.remote.RemoteStore.start(RemoteStore.java:89)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:141)
> ... 33 more
> Caused by: java.lang.ClassNotFoundException: org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy from [Module "deployment.sample-ear.ear.sample-ejb.jar:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) [jboss-modules.jar:1.5.1.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) [jboss-modules.jar:1.5.1.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) [jboss-modules.jar:1.5.1.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) [jboss-modules.jar:1.5.1.Final]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.8.0_45]
> at java.lang.Class.forName(Class.java:348) [rt.jar:1.8.0_45]
> at org.infinispan.commons.util.Util.loadClassStrict(Util.java:158)
> at org.infinispan.commons.util.Util.loadClass(Util.java:101)
> ... 37 more
> domain.xml is:
> {{<cache-container name="hibernate" default-cache="entity" module="org.hibernate.infinispan">
> <transport lock-timeout="60000"/>
> <local-cache name="local-query">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> <replicated-cache name="timestamps" mode="ASYNC"/>
> </cache-container>}}
> The attached infinispan.zip conatins some changes to the module configuration
> (module.xml's) in $JBOSS_HOME/modules/system/layers/base/org/infinispan. This
> config changes are marked wih ALVARA an fix the problem for us.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6561) EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
by Kevin Chen (JIRA)
[ https://issues.jboss.org/browse/WFLY-6561?page=com.atlassian.jira.plugin.... ]
Kevin Chen commented on WFLY-6561:
----------------------------------
[~swd847], thank you for your efforts.
> EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-6561
> URL: https://issues.jboss.org/browse/WFLY-6561
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
> Assignee: Stuart Douglas
>
> On Wildfly10, we are experiencing intermittent problems where on server startup, an @Timeout annotated method can be executed hundreds of times in a second (log below). Going through the references to the @Timeout methods and the @Scheduled methods, all scheduled methods are set to be non-persistent (ex: timerConfig.setPersistent(false), persistent=false) so we don't know how this could occur. It is not consistent and our only solution has been to kill the Wildfly10 server process and restart.
> 13:47:27,824 WARN [org.jboss.as.ejb3] (EJB default - 6) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 96) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 97) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 37) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1503) Reading the logging subsystem resource can be slow if several log files exist
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1503?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-1503:
---------------------------------------
Excellent thanks for the confirmation [~pvorb]!
> Reading the logging subsystem resource can be slow if several log files exist
> -----------------------------------------------------------------------------
>
> Key: WFCORE-1503
> URL: https://issues.jboss.org/browse/WFCORE-1503
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Labels: 2.2
> Attachments: wildfly-logging-patch-02.jar
>
>
> The logging subsystem uses a dynamic resource to list log files as resources. These are the files that are allowed to be read or downloaded and are attached to known file handlers.
> When several file handlers are defined the file tree walker is invoked several times per {{read-resource-operation}}. This may be happening for each stage of an operation. Ideally we could either cache the file listing per-operation or only execute at the runtime stage. This may not be an option for dynamic resources however.
> As a result of this poor performance the web console is very slow to load the logging subsystem configuration. This is not an issue with the web console.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1153) Version detection when adding drools runtime doesn't work
by Tomas David (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1153?page=com.atlassian.jira.plugi... ]
Tomas David commented on DROOLS-1153:
-------------------------------------
After discussion with [~bbrodt]: proposed solution is to take a version from the manifest file of a one drools runtime jar. This allows to automatically complete the version in drools preferences page.
> Version detection when adding drools runtime doesn't work
> ---------------------------------------------------------
>
> Key: DROOLS-1153
> URL: https://issues.jboss.org/browse/DROOLS-1153
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Environment: JBDS 9.1.0.GA
> Drools plugin 6.4.1-Snapshot
> Reporter: Tomas David
> Assignee: Robert (Bob) Brodt
> Priority: Minor
> Labels: reported-by-qe
> Attachments: add_drools_runtime_dialog.png
>
>
> When you add a drools runtime, version is not automatically detected and "Version must be in the form major#.minor#.patch#" text is displayed. User has to specify a version manually instead of automatic detection from binaries.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-429) Incremental redeployment (single file update) over management API
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-429?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-429:
-----------------------------------------
I've drafted a requirements doc for this:
https://developer.jboss.org/docs/DOC-55497
I've also got a local prototype branch that does a small bit of this, which I'll link later this week once it gets polished a bit more. At that point it won't have much functionality particularly interesting to a user but it should have a lot of the needed underpinnings.
> Incremental redeployment (single file update) over management API
> -----------------------------------------------------------------
>
> Key: WFCORE-429
> URL: https://issues.jboss.org/browse/WFCORE-429
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Reporter: Ondrej Zizka
> Labels: deploy, deployment, incremental, redeployment
> Fix For: 3.0.0.Beta1
>
>
> (Based on JBDS use case - see EAP6-1)
> See also https://mojo.redhat.com/docs/DOC-934058 for notes
> By incremental redeployment, we mean the situation when something is deployed, and after changes (in IDE e.g.), only that single file (.jsp, .xml, .class) would be re-deployed to the server, *over management API* - which is, you'd give it a stream and a path where it belongs in the deployment, and the operation would accept that file and put it to the right place in VFS, clear caches etc.
> Use cases:
> Big .war's, mainly on remote
> Cloud deployments
> Also, you loose sessions etc.
> "JSP recompile on file update" - mgmt API operation - added in WildFly 8?
> Not expected to work in domain mode.
> Stuart said that session persistence is implemented in WFly 8, but not the incremental redeployment.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-429) Incremental redeployment (single file update) over management API
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-429?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-429:
------------------------------------
Fix Version/s: 3.0.0.Beta1
> Incremental redeployment (single file update) over management API
> -----------------------------------------------------------------
>
> Key: WFCORE-429
> URL: https://issues.jboss.org/browse/WFCORE-429
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Reporter: Ondrej Zizka
> Labels: deploy, deployment, incremental, redeployment
> Fix For: 3.0.0.Beta1
>
>
> (Based on JBDS use case - see EAP6-1)
> See also https://mojo.redhat.com/docs/DOC-934058 for notes
> By incremental redeployment, we mean the situation when something is deployed, and after changes (in IDE e.g.), only that single file (.jsp, .xml, .class) would be re-deployed to the server, *over management API* - which is, you'd give it a stream and a path where it belongs in the deployment, and the operation would accept that file and put it to the right place in VFS, clear caches etc.
> Use cases:
> Big .war's, mainly on remote
> Cloud deployments
> Also, you loose sessions etc.
> "JSP recompile on file update" - mgmt API operation - added in WildFly 8?
> Not expected to work in domain mode.
> Stuart said that session persistence is implemented in WFly 8, but not the incremental redeployment.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years