[JBoss JIRA] (WFCORE-388) Overall 'server-state' flag on the Host Controller
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-388?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-388:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
> Overall 'server-state' flag on the Host Controller
> --------------------------------------------------
>
> Key: WFCORE-388
> URL: https://issues.jboss.org/browse/WFCORE-388
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 2.0.0.Beta1
>
>
> This is for consideration; we need to see if it makes sense.
> Request is for an attribute on the HC that indicates aggregate 'server-state'. The desire is to know when all servers are available, and thus it is safe to invoke management ops knowing all servers will receive them.
> The only reason a server wouldn't receive an op is if it is started in a non-blocking mode, so the server gets its config but then hasn't connected with the HC and therefore won't get update operations. Starting the server in blocking mode will avoid this situation (as could changes to how we start servers, to make it more like how a slave HC registers with the master HC). So, before doing this let's first look at how to reduce/eliminate the use case for it.
> Also to consider when looking at this is how to represent servers in things like "restart-required" state in this overall aggregate 'server-state'.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-399) Domain Management - Support for database connection pool in non AS process.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-399?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-399:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
[~dlofthouse] How does this relate to the Elytron work? I'm scheduling it out of WFCORE 1.0 because it won't happen, but I don't want to leave it in 2.0 either unless it's clearly required for the Elytron work.
> Domain Management - Support for database connection pool in non AS process.
> ---------------------------------------------------------------------------
>
> Key: WFCORE-399
> URL: https://issues.jboss.org/browse/WFCORE-399
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Brian Stansberry
> Fix For: 2.0.0.Beta1
>
>
> We need to support authentication for users stored in database, the domain management is in a non-AS process so we also need a pool of database connections.
> These connections will be used to read only from the database, other than the isolation offered by the driver we should not require any advanced transaction support.
--
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 Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/WFCORE-429?page=com.atlassian.jira.plugin... ]
Max Rydahl Andersen commented on WFCORE-429:
--------------------------------------------
if it does not work for non-exploded deployments then it wont be usable in context of deploying to a dockerized or cloud running EAP with no SSH/SCP access.
> 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:
-----------------------------------------
[~luck3y] FYI. This relates to the managed exploded deployment EAP7-204 JIRA, although reading this it implies it may work for non-exploded deployments too, which I don't think we should support, except via the deployment-overlay feature.
At this point this JIRA should be regarded as informational, an input to the requirements gathering around EAP7-204. Perhaps it becomes the upstream JIRA for EAP7-204, perhaps it becomes extra stuff to do later, perhaps it gets closed and other JIRAs get opened.
> 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] (WFLY-4374) java.lang.IllegalAccessError and other classloader issues
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-4374?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-4374:
-----------------------------------
You cannot split packages across JARs due to modularity rules. That'll be the cause of your #3 error. The other two sound like questions for the user forums.
> 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-470) support patching through the http mgmt API
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-470?page=com.atlassian.jira.plugin... ]
Kabir Khan commented on WFCORE-470:
-----------------------------------
I am planning/hoping to revisit the HTTP management API over the next few months to make it more RESTful. A side effect of that work might be that this task becomes simpler.
> support patching through the http mgmt API
> ------------------------------------------
>
> Key: WFCORE-470
> URL: https://issues.jboss.org/browse/WFCORE-470
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Patching
> Affects Versions: 1.0.0.Alpha1
> Reporter: Emanuel Muckenhuber
> Fix For: 2.0.0.Beta1
>
>
> The patch operation requires an input stream attachment of the patch content, which is not generally supported for all operations of the http API. We probably need to do something similar to the deployment add-content handler.
--
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 updated WFCORE-429:
------------------------------------
Fix Version/s: (was: 1.0.0.CR1)
> 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-310) Don't copy the contents to all hosts when assigning a deployment to a server-group
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-310?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-310:
---------------------------------------
Fix Version/s: 2.0.0.CR1
(was: 1.0.0.CR1)
Assignee: luck3y (was: Brian Stansberry)
Ken, this is another one in the general area of slave host to master host interaction. See the bugzilla for a pretty thorough discussion.
> Don't copy the contents to all hosts when assigning a deployment to a server-group
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-310
> URL: https://issues.jboss.org/browse/WFCORE-310
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Emanuel Muckenhuber
> Assignee: luck3y
> Fix For: 2.0.0.CR1
>
>
> When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-391) Add management API descriptions for alias resources and attributes
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-391?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-391:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
> Add management API descriptions for alias resources and attributes
> ------------------------------------------------------------------
>
> Key: WFCORE-391
> URL: https://issues.jboss.org/browse/WFCORE-391
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 2.0.0.Beta1
>
>
> When a resource or an attribute is an alias for a different resource or attribute, the management API description data should include information describing that relationship.
> For an attribute, an alias relationship is different from an 'alternatives' relationship, as the latter is a mutually exclusive arrangement (one alternative must be undefined if the other isn't) while with an alias, both attributes will exist but will always have the same value, and attempting to set them to different values (e.g. using both as params with different values in an 'add' op) is invalid.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-363) ManagementResourceRegistration.getOverrideModel never returns null
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-363?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-363:
---------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
Assignee: (was: Brian Stansberry)
> ManagementResourceRegistration.getOverrideModel never returns null
> ------------------------------------------------------------------
>
> Key: WFCORE-363
> URL: https://issues.jboss.org/browse/WFCORE-363
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 2.0.0.Beta1
>
>
> ManagementResourceRegistration.getOverrideModel ends up returning the wildcard registration if there is no override registration. This isn't correct.
> The fix isn't trivial because fixing it results in nasty failures in the smoke tests. From looking at the uses of this method (which all involve a null check) I assume there are some bugs in the code that calls this method that get exposed once it does what it should.
> This bug is the cause of the initial failure of my WFLY-2880 fix.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months