[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)
11 years, 1 month
[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)
11 years, 1 month
[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)
11 years, 1 month
[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)
11 years, 1 month
[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)
11 years, 1 month
[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)
11 years, 1 month
[JBoss JIRA] (WFCORE-386) Ability to configure a custom RBAC implementation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-386?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-386:
------------------------------------
Fix Version/s: (was: 1.0.0.CR1)
> Ability to configure a custom RBAC implementation
> -------------------------------------------------
>
> Key: WFCORE-386
> URL: https://issues.jboss.org/browse/WFCORE-386
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Priority: Optional
> Labels: RBAC-WF-only
>
> Allow configuration of a module name and set of key/value properties to allow users to plug in a custom implementation of the CustomAuthorizer interface. The impl would be loadable via the ServiceLoader mechanism.
> The hooks to integrate such a custom impl into the server are already done, so this is should be just a matter of adding the config capability.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFCORE-406) Resource description for platform mbean properties that throw UnsupportedOperationException should say nillable="true"
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-406?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-406:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
> Resource description for platform mbean properties that throw UnsupportedOperationException should say nillable="true"
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-406
> URL: https://issues.jboss.org/browse/WFCORE-406
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: FreeBSD, OpenJDK 1.6
> Reporter: Brian Stansberry
> Priority: Minor
> Fix For: 2.0.0.Beta1
>
>
> Some platform mbean getters are documented to throw a UOE on some VMs. The read-resource handler will catch the UOE and leave the attribute undefined, but the description says it's not nillable.
> Specifically, PlatformMBeanDescriptions.getThreadingResource()'s THREAD_CPU_TIME_ENABLED attribute, although there may well be others.
> This leads to this unit test failure on jvms where the UOE is thrown:
> failure message="thread-cpu-time-enabled is undefined"
> type="junit.framework.AssertionFailedError">junit.fra mework.AssertionFailedError: thread-cpu-time-enabled is undefined
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at
> org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.validateResource(PlatformMBeanResourceUn
> itTestCase.java:595)
> at org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.basicResourceTest(PlatformMBeanResourceUnitTestCase.java:563)
> at
> org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.testThreadingMXBean(PlatformMBeanResourceUnitTestCase.java:340)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFCORE-429) Incremental redeployment (single file update) over management API
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/WFCORE-429?page=com.atlassian.jira.plugin... ]
Max Rydahl Andersen commented on WFCORE-429:
--------------------------------------------
To be clear, exploded is great if I got access to the file system either locally or remotely.
It's when I do *not* have that which is the case when EAP is running in docker, cloud etc. that alternative deployment via management becomes useful.
The "external" mode is what is of very little use to me since if I already have access to the filesystem I just do an exploded deployment to begin with.
> 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)
11 years, 1 month
[JBoss JIRA] (WFCORE-424) .jar's on "current runtime classpath"
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-424?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-424:
------------------------------------
Component/s: (was: CLI)
I'm removing the CLI component as I don't see the need for anything specific in the CLI other than the core ability to execute whatever low-level ops a user types in.
> .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)
11 years, 1 month