[JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-94?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated REMJMX-94:
-----------------------------------
Fix Version/s: 2.0.1.Final
(was: 2.0.1.CR2)
> Memory leak in remoting-jmx
> ---------------------------
>
> Key: REMJMX-94
> URL: https://issues.jboss.org/browse/REMJMX-94
> Project: Remoting JMX
> Issue Type: Bug
> Affects Versions: 1.1.3.Final
> Reporter: Libor Zoubek
> Assignee: Darran Lofthouse
> Labels: memory_leak
> Fix For: 2.0.1.Final
>
>
> In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx. Leak is very notable once we restart our plugin container (each plugin has in it's own classloader) Classes owned by RHQ Server plugin don't get GCed.
> I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating following steps:
> 1. start new thread
> 2. assign URL classloader to this thread (point it to jboss-client.jar)
> 3. connect & disconnect to jmx-remoting endpoint
> In this test no classes don't get GCed which after serveral iterations ends up in OOM.
> My test/example is here https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org...
> I am not sure if memleak is in remoting-jmx or some other underlying stuff.
> I thought https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned does not help.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-94?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on REMJMX-94:
----------------------------------------
[~dmlloyd] Might need to run this one by you - debugging this myself with the XNIO version currently used in WildFly (And Core) I am still seeing the same behaviour that Brad describes with the classloaders being kept around with references leading back to ThreadLocalCache of ByteBufferSlicePool.
Within Remoting JMX I have double checked and there are no remaining places that I fail to clean up resources that I created so not sure if there is anything else I can do to clean this up myself.
I do have a heap dump after modifying the test case if you want.
> Memory leak in remoting-jmx
> ---------------------------
>
> Key: REMJMX-94
> URL: https://issues.jboss.org/browse/REMJMX-94
> Project: Remoting JMX
> Issue Type: Bug
> Affects Versions: 1.1.3.Final
> Reporter: Libor Zoubek
> Assignee: Darran Lofthouse
> Labels: memory_leak
> Fix For: 2.0.1.CR2
>
>
> In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx. Leak is very notable once we restart our plugin container (each plugin has in it's own classloader) Classes owned by RHQ Server plugin don't get GCed.
> I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating following steps:
> 1. start new thread
> 2. assign URL classloader to this thread (point it to jboss-client.jar)
> 3. connect & disconnect to jmx-remoting endpoint
> In this test no classes don't get GCed which after serveral iterations ends up in OOM.
> My test/example is here https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org...
> I am not sure if memleak is in remoting-jmx or some other underlying stuff.
> I thought https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned does not help.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-4374) java.lang.IllegalAccessError and other classloader issues
by Anindhya Sharma (JIRA)
[ https://issues.jboss.org/browse/WFLY-4374?page=com.atlassian.jira.plugin.... ]
Anindhya Sharma commented on WFLY-4374:
---------------------------------------
David,
We have supported multiple Java Application servers (and continue to do so) over the years and multiple versions of them. WebSphere, WebLogic and JBoss. In all the versions of all these products (JBoss included) we have never had this issue using the Class-Path entry in manifest file, even for the same class in different jar files. We have supported Jboss 4, 5, 6 and 7, the last one being 7.2.0.Final. Are you saying that the issue is due to how the implementation has been done in Jboss modules that is causing the issue and that the implementation in Wildfly honors the Java EE spec and hence you will not fix this? Trying to understand why this was changed in Wildfly when all other application servers in multiple versions honor this scheme? Is it because the Java EE spec changed or because that is how Jboss modules are implemented?
Given that all previous versions of Jboss have worked like mentioned in the issue (and other products still support it), would you be able to help point out specific of the Java EE specification that caused this changed in how Wildfly is working? Again trying to understand whether Wildfly just fixed an issue that was there in previous versions of Jboss and other vendor products...?
Thanks!
> java.lang.IllegalAccessError and other classloader issues
> ---------------------------------------------------------
>
> Key: WFLY-4374
> URL: https://issues.jboss.org/browse/WFLY-4374
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final, 9.0.0.Beta2
> Environment: Windows 7/Java 7 update 67
> Reporter: John Sipher
> Assignee: David Lloyd
> Attachments: problem-demo.zip
>
>
> Update 4/1/2015: I have verified that 9.0.0.Beta2 fixes the IllegalAccessError and the war file in problem-demo.zip/hello-world6/target now duplicates the original problem. The order of the jar files in the classpath should be
> WEB-INF/lib/patch/patch2.jar
> WEB-INF/lib/patch/patch1.jar
> WEB-INF/lib/base/helloworld-sans-cdi.jar
> org.jboss.as.quickstarts.helloworld.HelloService exists in both patch2.jar and helloworld-sans-cdi.jar. The version from patch2.jar should be used because it is first in the classpath, but the classloader is picking up the original class from helloworld-sans-cdi.jar instead.
> Original problem description follows:
> We use manifest-only jar files in our WAR and EAR files to control the order that jar files are searched for classes. When we issue patches, we put the modified class(es) in a separate jar file, add that jar file to the affected EAR or WAR file, and update the classpath in our manifest-only jar file to put the new patch at the beginning of the class path so that it will be used in place of the original class (which is still in the original jar file).
>
> For example, WEB-INF/lib will contain a single jar file named manifest.jar and sub-folders named 3rdparty, base, patch, and custom. The Class-Path entry in WEB-INF/lib/manifest.jar|META-INF/MANIFEST.MF looks like this:
> Class-Path: 3rdparty/manifest.jar patch/manifest.jar base/manifest.jar custom/manifest.jar
>
> When we publish a patch, the patch jar file is added to WEB-INF/lib/patch and to the front of the classpath in WEB-INF/lib/patch/manifest.jar's MANIFEST.MF.
>
> This worked fine for us for years with JBoss 4.2.3.GA, 5.1.0.GA, 7.1.2.Final, and 7.2.0.Final, but it's broken in WildFly 8.2.0.Final.
> When I run it in debug I can see where the problem shows up in this section of org.jboss.modules.Module (lines 562 - 573).
> final String path = pathOfClass(className);
> final Map<String, List<LocalLoader>> paths = getPathsUnchecked();
> final List<LocalLoader> loaders = paths.get(path);
> if (loaders != null) {
> Class<?> clazz;
> for (LocalLoader loader : loaders) {
> clazz = loader.loadClassLocal(className, resolve);
> if (clazz != null) {
> return clazz;
> }
> }
> }
> The modules in the loaders list at line 565 are
> * deployment.service.ear.lib/base/shared.jar:main
> * deployment.service.ear.lib/base/deployment.jar:main
> * deployment.service.ear.lib/patch/patch.jar:main
> The last one should actually be the first in the list. I haven't been able to track down the actual source of the error yet.
> I've been trying to create a simple example based on the helloworld quickstart to reproduce the problem, but I haven't been successful yet because of other classloader errors that I've run into. I decided to go ahead and open this issue and document the things I am able to reproduce. Those are:
> 1. CDI injection doesn't work when the annotated classes are in jar files under WEB-INF/lib instead of unpacked in WEB-INF/classes.
> 2. WildFly doesn't process the javax.servlet.annotation.WebServlet annotation if the jar file containing the annotated class is in a sub-folder of WEB-INF/lib.
> 3. WildFly throws a java.lang.IllegalAccessError trying to load a "patched" class.
> The first problem exists in both 7.2.0.Final and 8.2.0.Final. The other two problems are new in 8.2.0.Final.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[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 fear we're not on the same page as to what I meant, as it's not simple. :)
> 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
>
> (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.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-625) Error message in CLI if extension existing on the server is not present in the CLI instalaltion
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-625?page=com.atlassian.jira.plugin... ]
Alexey Loubyansky commented on WFCORE-625:
------------------------------------------
After the PR has been merged, it's going to look like this:
[olubyans@fedovo bin]$ cd . && ./jboss-cli.sh -c
Warning! There were errors trying to load extensions. For more details, please, execute 'extension-commands --errors'
[standalone@localhost:9990 /] extension-commands --errors
The following problems were encountered while looking for additional commands in extensions:
1) Module org.jboss.as.clustering.infinispan from extension org.jboss.as.clustering.infinispan available on the server couldn't be loaded locally: org.jboss.as.clustering.infinispan:main
2) Module org.jboss.as.connector from extension org.jboss.as.connector available on the server couldn't be loaded locally: org.jboss.as.connector:main
3) Module org.jboss.as.ee from extension org.jboss.as.ee available on the server couldn't be loaded locally: org.jboss.as.ee:main
4) Module org.jboss.as.ejb3 from extension org.jboss.as.ejb3 available on the server couldn't be loaded locally: org.jboss.as.ejb3:main
5) Module org.jboss.as.jaxrs from extension org.jboss.as.jaxrs available on the server couldn't be loaded locally: org.jboss.as.jaxrs:main
6) Module org.jboss.as.jdr from extension org.jboss.as.jdr available on the server couldn't be loaded locally: org.jboss.as.jdr:main
7) Module org.jboss.as.jpa from extension org.jboss.as.jpa available on the server couldn't be loaded locally: org.jboss.as.jpa:main
8) Module org.jboss.as.jsf from extension org.jboss.as.jsf available on the server couldn't be loaded locally: org.jboss.as.jsf:main
9) Module org.jboss.as.mail from extension org.jboss.as.mail available on the server couldn't be loaded locally: org.jboss.as.mail:main
10) Module org.jboss.as.naming from extension org.jboss.as.naming available on the server couldn't be loaded locally: org.jboss.as.naming:main
11) Module org.jboss.as.pojo from extension org.jboss.as.pojo available on the server couldn't be loaded locally: org.jboss.as.pojo:main
12) Module org.jboss.as.sar from extension org.jboss.as.sar available on the server couldn't be loaded locally: org.jboss.as.sar:main
13) Module org.jboss.as.security from extension org.jboss.as.security available on the server couldn't be loaded locally: org.jboss.as.security:main
14) Module org.jboss.as.transactions from extension org.jboss.as.transactions available on the server couldn't be loaded locally: org.jboss.as.transactions:main
15) Module org.jboss.as.webservices from extension org.jboss.as.webservices available on the server couldn't be loaded locally: org.jboss.as.webservices:main
16) Module org.jboss.as.weld from extension org.jboss.as.weld available on the server couldn't be loaded locally: org.jboss.as.weld:main
17) Module org.wildfly.extension.batch from extension org.wildfly.extension.batch available on the server couldn't be loaded locally: org.wildfly.extension.batch:main
18) Module org.wildfly.extension.bean-validation from extension org.wildfly.extension.bean-validation available on the server couldn't be loaded locally: org.wildfly.extension.bean-validation:main
19) Module org.wildfly.extension.security.manager from extension org.wildfly.extension.security.manager available on the server couldn't be loaded locally: org.wildfly.extension.security.manager:main
20) Module org.wildfly.extension.undertow from extension org.wildfly.extension.undertow available on the server couldn't be loaded locally: org.wildfly.extension.undertow:main
> Error message in CLI if extension existing on the server is not present in the CLI instalaltion
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-625
> URL: https://issues.jboss.org/browse/WFCORE-625
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 1.0.0.Beta2
> Reporter: ehsavoie Hugonnet
> Assignee: Alexey Loubyansky
>
> When using the jboss-cli from a WildFly-Core installation to manage a WildFly Full server you get error messages about missing extensions :
> Errors caught while loading extensions:
> 1) Failed to load module org.jboss.as.clustering.infinispan for extension org.jboss.as.clustering.infinispan: org.jboss.as.clustering.infinispan:main
> 2) Failed to load module org.jboss.as.connector for extension org.jboss.as.connector: org.jboss.as.connector:main
> 3) Failed to load module org.jboss.as.ee for extension org.jboss.as.ee: org.jboss.as.ee:main
> 4) Failed to load module org.jboss.as.ejb3 for extension org.jboss.as.ejb3: org.jboss.as.ejb3:main
> 5) Failed to load module org.jboss.as.jaxrs for extension org.jboss.as.jaxrs: org.jboss.as.jaxrs:main
> 6) Failed to load module org.jboss.as.jdr for extension org.jboss.as.jdr: org.jboss.as.jdr:main
> 7) Failed to load module org.jboss.as.jpa for extension org.jboss.as.jpa: org.jboss.as.jpa:main
> 8) Failed to load module org.jboss.as.jsf for extension org.jboss.as.jsf: org.jboss.as.jsf:main
> 9) Failed to load module org.jboss.as.mail for extension org.jboss.as.mail: org.jboss.as.mail:main
> 10) Failed to load module org.jboss.as.naming for extension org.jboss.as.naming: org.jboss.as.naming:main
> 11) Failed to load module org.jboss.as.pojo for extension org.jboss.as.pojo: org.jboss.as.pojo:main
> 12) Failed to load module org.jboss.as.sar for extension org.jboss.as.sar: org.jboss.as.sar:main
> 13) Failed to load module org.jboss.as.security for extension org.jboss.as.security: org.jboss.as.security:main
> 14) Failed to load module org.jboss.as.transactions for extension org.jboss.as.transactions: org.jboss.as.transactions:main
> 15) Failed to load module org.jboss.as.webservices for extension org.jboss.as.webservices: org.jboss.as.webservices:main
> 16) Failed to load module org.jboss.as.weld for extension org.jboss.as.weld: org.jboss.as.weld:main
> 17) Failed to load module org.wildfly.extension.batch for extension org.wildfly.extension.batch: org.wildfly.extension.batch:main
> 18) Failed to load module org.wildfly.extension.bean-validation for extension org.wildfly.extension.bean-validation: org.wildfly.extension.bean-validation:main
> 19) Failed to load module org.wildfly.extension.security.manager for extension org.wildfly.extension.security.manager: org.wildfly.extension.security.manager:main
> 20) Failed to load module org.wildfly.extension.undertow for extension org.wildfly.extension.undertow: org.wildfly.extension.undertow:main
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-4374) java.lang.IllegalAccessError and other classloader issues
by John Sipher (JIRA)
[ https://issues.jboss.org/browse/WFLY-4374?page=com.atlassian.jira.plugin.... ]
John Sipher commented on WFLY-4374:
-----------------------------------
I can see a security rationale for restricting a package to one jar, but we have a lot of infrastructure built around the old classloader behavior and this change breaks it badly. Would it be possible to add a system property that enables the old behavior? I'd be happy to try implementing it if you could point me in the right direction.
> java.lang.IllegalAccessError and other classloader issues
> ---------------------------------------------------------
>
> Key: WFLY-4374
> URL: https://issues.jboss.org/browse/WFLY-4374
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final, 9.0.0.Beta2
> Environment: Windows 7/Java 7 update 67
> Reporter: John Sipher
> Assignee: David Lloyd
> Attachments: problem-demo.zip
>
>
> Update 4/1/2015: I have verified that 9.0.0.Beta2 fixes the IllegalAccessError and the war file in problem-demo.zip/hello-world6/target now duplicates the original problem. The order of the jar files in the classpath should be
> WEB-INF/lib/patch/patch2.jar
> WEB-INF/lib/patch/patch1.jar
> WEB-INF/lib/base/helloworld-sans-cdi.jar
> org.jboss.as.quickstarts.helloworld.HelloService exists in both patch2.jar and helloworld-sans-cdi.jar. The version from patch2.jar should be used because it is first in the classpath, but the classloader is picking up the original class from helloworld-sans-cdi.jar instead.
> Original problem description follows:
> We use manifest-only jar files in our WAR and EAR files to control the order that jar files are searched for classes. When we issue patches, we put the modified class(es) in a separate jar file, add that jar file to the affected EAR or WAR file, and update the classpath in our manifest-only jar file to put the new patch at the beginning of the class path so that it will be used in place of the original class (which is still in the original jar file).
>
> For example, WEB-INF/lib will contain a single jar file named manifest.jar and sub-folders named 3rdparty, base, patch, and custom. The Class-Path entry in WEB-INF/lib/manifest.jar|META-INF/MANIFEST.MF looks like this:
> Class-Path: 3rdparty/manifest.jar patch/manifest.jar base/manifest.jar custom/manifest.jar
>
> When we publish a patch, the patch jar file is added to WEB-INF/lib/patch and to the front of the classpath in WEB-INF/lib/patch/manifest.jar's MANIFEST.MF.
>
> This worked fine for us for years with JBoss 4.2.3.GA, 5.1.0.GA, 7.1.2.Final, and 7.2.0.Final, but it's broken in WildFly 8.2.0.Final.
> When I run it in debug I can see where the problem shows up in this section of org.jboss.modules.Module (lines 562 - 573).
> final String path = pathOfClass(className);
> final Map<String, List<LocalLoader>> paths = getPathsUnchecked();
> final List<LocalLoader> loaders = paths.get(path);
> if (loaders != null) {
> Class<?> clazz;
> for (LocalLoader loader : loaders) {
> clazz = loader.loadClassLocal(className, resolve);
> if (clazz != null) {
> return clazz;
> }
> }
> }
> The modules in the loaders list at line 565 are
> * deployment.service.ear.lib/base/shared.jar:main
> * deployment.service.ear.lib/base/deployment.jar:main
> * deployment.service.ear.lib/patch/patch.jar:main
> The last one should actually be the first in the list. I haven't been able to track down the actual source of the error yet.
> I've been trying to create a simple example based on the helloworld quickstart to reproduce the problem, but I haven't been successful yet because of other classloader errors that I've run into. I decided to go ahead and open this issue and document the things I am able to reproduce. Those are:
> 1. CDI injection doesn't work when the annotated classes are in jar files under WEB-INF/lib instead of unpacked in WEB-INF/classes.
> 2. WildFly doesn't process the javax.servlet.annotation.WebServlet annotation if the jar file containing the annotated class is in a sub-folder of WEB-INF/lib.
> 3. WildFly throws a java.lang.IllegalAccessError trying to load a "patched" class.
> The first problem exists in both 7.2.0.Final and 8.2.0.Final. The other two problems are new in 8.2.0.Final.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-429) Incremental redeployment (single file update) over management API
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFCORE-429?page=com.atlassian.jira.plugin... ]
Jason Greene commented on WFCORE-429:
-------------------------------------
Ah ok, that is likely a simpler solution and appears to meet the needs.
> 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
>
> (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.3.11#6341)
9 years, 9 months
[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:
-----------------------------------------
Agreed that we need to sort out the requirements.
I think the relevant concepts need to be clarified. There are two aspects of deployments:
1) Exploded vs zipped
2) Content used by the server is stored in the content repo and manipulated via the management API (aka Managed) vs stored externally and manipulated via the filesystem (aka unmanaged).
We support 3 of the 4 possible combinations thereof. We don't support Exploded + Managed.
The scanner is just a tangent; it's an automated client that utilizes two of the four permutations: Exploded + unmanaged and zipped + managed. It doesn't use zipped + unmanaged because it doesn't need to.
Based on the first few comments on EAP7-204, my expectation was the first goal was to add the 4th of the four combinations: Exploded + managed. Doing so removes any requirement for the client to have access to the server/host filesystem.
> 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
>
> (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.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-424) .jar's on "current runtime classpath"
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-424?page=com.atlassian.jira.plugin... ]
Tomaz Cerar commented on WFCORE-424:
------------------------------------
[~brian.stansberry] looks like another good example where introducing "class loading" subsystem could be useful, this way it could expose deployment model with this info. But that only applies for deployed apps.
> .jar's on "current runtime classpath"
> -------------------------------------
>
> Key: WFCORE-424
> URL: https://issues.jboss.org/browse/WFCORE-424
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Modules
> Reporter: Ondrej Zizka
> Assignee: David Lloyd
> Fix For: 1.0.0.CR1
>
>
> (Based on JBDS use case - see EAP6-1)
> In certain scenarios, JBDS needs to know the classpath. (Compilation of non-maven project, against a remote server, ...(?) )
> The classpath would be:
> * for the deployment after deployed
> * for a generic deployment if it was deployed right now - what would WildFly use?
> * for the deployment before deployed - sounds a bit advanced but technically possible
> We (David, Stuart, Jason, Max, Ondra) have discussed this on EAP F2F 2014.
> The output was that we don't need exact classpath / list of jars which would probably end up being almost all modules; rather we need the direct deps. As someone said - "just to get rid of the red lines in the IDE".
> The non-maven compilation use case is that the user has a server in a directory, and the jars to build against should all be in there. So the IDE should be able to ask WildFly for a list of .jar's to build the application against, and just use that instead of forcing the user to gather them manually.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months