[JBoss JIRA] (JGRP-1605) API changes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1605?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1605:
---------------------------
Description:
API changes to be done in 4.0, which break code:
* MessageDispatcher: remove MessageListener
* Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* Remove @Deprecated methods, properties or classes
* Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
* Make {{RspFilter}} --> {{RspFilter<T>}}
* {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
* Request<T>
* RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
was:
API changes to be done in 4.0, which break code:
* MessageDispatcher: remove MessageListener
* Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* Remove @Deprecated methods, properties or classes
* Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
* Make {{RspFilter}} --> {{RspFilter<T>}}
* {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
* Request<T>
* RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
> API changes
> -----------
>
> Key: JGRP-1605
> URL: https://issues.jboss.org/browse/JGRP-1605
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> API changes to be done in 4.0, which break code:
> * MessageDispatcher: remove MessageListener
> * Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
> * Remove @Deprecated methods, properties or classes
> * Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
> * Make {{RspFilter}} --> {{RspFilter<T>}}
> * {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
> * Request<T>
> * RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
> * RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (JGRP-2007) Adapt code to use new Java 8 features
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2007?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2007 at 1/26/16 8:48 AM:
---------------------------------------------------------
Also look at
* -MessageBatch-: DONE
* Table (Visitor)
* Use default methods in interfaces
* Replace NotifyingFuture with CompletableFuture
* -Condition / CondVar- : DONE
was (Author: belaban):
Also look at
* MessageBatch
* Table (Visitor)
* Use default methods in interfaces
* Replace NotifyingFuture with CompletableFuture
* -Condition / CondVar- : DONE
> Adapt code to use new Java 8 features
> -------------------------------------
>
> Key: JGRP-2007
> URL: https://issues.jboss.org/browse/JGRP-2007
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> E.g replace loops for forEach() etc
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (DROOLS-1041) Javadoc build error on Java 8
by Petr Široký (JIRA)
Petr Široký created DROOLS-1041:
-----------------------------------
Summary: Javadoc build error on Java 8
Key: DROOLS-1041
URL: https://issues.jboss.org/browse/DROOLS-1041
Project: Drools
Issue Type: Bug
Components: build
Affects Versions: 6.4.0.Beta1, 6.3.0.Final
Reporter: Petr Široký
Assignee: Petr Široký
Priority: Critical
Drools build currently fails during Javadoc generation, when executed on Java 8.
{code}
[ERROR] javadoc: error - com.sun.tools.doclets.internal.toolkit.util.DocletAbortException: java.lang.ClassCastException: com.sun.tools.doclets.formats.html.PropertyWriterImpl cannot be cast to com.sun.tools.doclets.formats.html.AbstractExecutableMemberWriter
[ERROR]
[ERROR] Command line was: /home/_opt/tools/jdk1.8.0_51/jre/../bin/javadoc -J-Xmx512m -J-Xms128m @options @packages
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (JGRP-2007) Adapt code to use new Java 8 features
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2007?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2007 at 1/26/16 7:06 AM:
---------------------------------------------------------
Also look at
* MessageBatch
* Table (Visitor)
* Use default methods in interfaces
* Replace NotifyingFuture with CompletableFuture
* -Condition / CondVar- : DONE
was (Author: belaban):
Also look at
* MessageBatch
* Table (Visitor)
* Use default methods in interfaces
* Replace NotifyingFuture with CompletableFuture
* Condition / CondVar
> Adapt code to use new Java 8 features
> -------------------------------------
>
> Key: JGRP-2007
> URL: https://issues.jboss.org/browse/JGRP-2007
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> E.g replace loops for forEach() etc
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (WFLY-5989) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/WFLY-5989?page=com.atlassian.jira.plugin.... ]
Ondrej Kotek commented on WFLY-5989:
------------------------------------
Without permissions described above the test fails with:
{noformat}
[0m[31m12:31:00,339 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /web/CallEjbServlet: java.lang.RuntimeException: javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found]
at org.jboss.as.test.integration.naming.remote.multiple.CallEjbServlet.doGet(CallEjbServlet.java:44)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
at java.security.AccessController.doPrivileged(Native Method)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found]
at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:51)
at org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:152)
at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
at javax.naming.InitialContext.init(InitialContext.java:244)
at javax.naming.InitialContext.<init>(InitialContext.java:216)
at org.jboss.as.test.integration.naming.remote.multiple.CallEjbServlet.doGet(CallEjbServlet.java:33)
... 31 more
Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
at org.xnio.Xnio.doGetInstance(Xnio.java:238)
at org.xnio.Xnio.getInstance(Xnio.java:193)
at org.jboss.naming.remote.client.EndpointCache.get(EndpointCache.java:47)
at org.jboss.naming.remote.client.InitialContextFactory.createEndpoint(InitialContextFactory.java:226)
at org.jboss.naming.remote.client.InitialContextFactory.getOrCreateEndpoint(InitialContextFactory.java:207)
at org.jboss.naming.remote.client.InitialContextFactory.getOrCreateNamingStore(InitialContextFactory.java:170)
at org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:146)
... 41 more
{noformat}
Debugging on {{WildflySecurityManager}} reveals missing {{FilePermission}} for XNIO module jar.
----
Having permissions described above without {{FilePermission}} for marshalling the test fails with:
{noformat}
[0m[31m12:24:27,523 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /web/CallEjbServlet: java.lang.ExceptionInInitializerError
at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1.sendVersionHeader(RemoteNamingStoreV1.java:85)
at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1.start(RemoteNamingStoreV1.java:80)
at org.jboss.naming.remote.protocol.v1.VersionOne.getRemoteNamingStore(VersionOne.java:51)
at org.jboss.naming.remote.protocol.Versions.getRemoteNamingStore(Versions.java:55)
at org.jboss.naming.remote.client.RemoteContextFactory.createVersionedStore(RemoteContextFactory.java:73)
at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:202)
at org.jboss.naming.remote.client.HaRemoteNamingStore.namingStore(HaRemoteNamingStore.java:149)
at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:130)
at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:272)
at org.jboss.naming.remote.client.RemoteContext.lookupInternal(RemoteContext.java:104)
at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:93)
at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:146)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.jboss.as.test.integration.naming.remote.multiple.CallEjbServlet.doGet(CallEjbServlet.java:36)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
at java.security.AccessController.doPrivileged(Native Method)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.Final-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/jboss-marshalling-river-1.4.10.Final.jar" "read")" in code source "(vfs:/content/ejb.ear/web.war/WEB-INF/classes <no signer certificates>)" of "null")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:377)
at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137)
at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81)
at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
at java.net.URL.openStream(URL.java:1038)
at java.util.ServiceLoader.parse(ServiceLoader.java:304)
at java.util.ServiceLoader.access$200(ServiceLoader.java:185)
at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:357)
at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:323)
at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:396)
at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:395)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398)
at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
at org.jboss.marshalling.Marshalling.loadMarshallerFactory(Marshalling.java:90)
at org.jboss.marshalling.Marshalling.getProvidedMarshallerFactory(Marshalling.java:86)
at org.jboss.naming.remote.protocol.v1.WriteUtil.<clinit>(WriteUtil.java:48)
... 46 more
{noformat}
> FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5989
> URL: https://issues.jboss.org/browse/WFLY-5989
> Project: WildFly
> Issue Type: Bug
> Components: Remoting, Security Manager
> Affects Versions: 10.0.0.CR5
> Reporter: Ondrej Kotek
> Assignee: David Lloyd
> Priority: Critical
>
> Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like
> {noformat}
> ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager
> {noformat}
> results in exception:
> {noformat}
> java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> {noformat}
> To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_:
> {noformat}
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"),
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"),
> new RemotingPermission("createEndpoint"),
> new RuntimePermission("createXnioWorker"),
> new RemotingPermission("addConnectionProvider"),
> new RuntimePermission("modifyThread"),
> new RuntimePermission("accessDeclaredMembers"),
> new ReflectPermission("suppressAccessChecks")
> {noformat}
> which is very confusing.
> Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (WFCORE-1330) Deployment error after reboot [WFLYSRV0137]
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1330?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet edited comment on WFCORE-1330 at 1/26/16 6:34 AM:
--------------------------------------------------------------------
Hum, the war should be read and written by the user that is running WildFly. Now it all depends on what rights does this WildFly user have. He should be able to write in the WildFly directories since you are in /opt I'm wondering what you have set.
was (Author: ehugonnet):
Hum, the war should be read and written by the user that is running Wildfly. Now it all depends on what rights does this WildFly user have. He should be able to write in the WildFly directories since you are in /opt I'm wondering what you have set.
> Deployment error after reboot [WFLYSRV0137]
> -------------------------------------------
>
> Key: WFCORE-1330
> URL: https://issues.jboss.org/browse/WFCORE-1330
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.2.Final
> Environment: Ubuntu 14.04 LTS 64bit, jre-1.8.0_65
> Several deployed (JavaEE) web applications including non XA datasources that connect to a MySQL instance.
> Reporter: Tobi Tobias
> Assignee: ehsavoie Hugonnet
> Priority: Critical
>
> I have a working configuration on wildfly 9.0.2 final with several web applications (JavaEE).
> After a couple of days, I deployed another war file via jboss CLI. This application worked correctly and no deployment error occurred.
> But if I restart the server now, I get following error message:
> 10:36:01,893 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "MM-Controller-0.1.0-SNAPSHOT.war")]) - failure description: "WFLYSRV0137: No deployment content with hash 966847a6f5f5bf8c3470f07ea9e65b7bbcdcd7b7 is available in the deployment content repository for deployment 'MM-Controller-0.1.0-SNAPSHOT.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart."
> 10:36:01,990 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> I reproduced this at least 30 times - even with different jars. I always get this error. The server works fine as long as I don't reboot.
> The only way to fix the configuration is to manually remove the deployments from the standalone.xml.
> But this is not an option for me as I want to have the wildfly running as production server where I have several automatic deployments every day.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
