[JBoss JIRA] (WFLY-1914) Application client container doesn't start
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1914?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1914:
-----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> made a comment on [bug 999465|https://bugzilla.redhat.com/show_bug.cgi?id=999465]
Ah, I see. ER3.1 was just some sort of respin of ER3 that didn't include any new fixes.
> Application client container doesn't start
> ------------------------------------------
>
> Key: WFLY-1914
> URL: https://issues.jboss.org/browse/WFLY-1914
> Project: WildFly
> Issue Type: Bug
> Components: Application Client
> Affects Versions: 8.0.0.Alpha4
> Reporter: jaikiran pai
> Assignee: jaikiran pai
> Fix For: 8.0.0.Beta1
>
>
> Application client container fails to start with the following exception:
> {code}
> 16:23:40,742 INFO [org.jboss.as.jacorb] (MSC service thread 1-7) JBAS016328: CORBA Naming Service started
> 16:23:40,744 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
> ("subsystem" => "naming"),
> ("service" => "remote-naming")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.naming.remote is missing [jboss.remoting.endpoint.subsystem]"]}
> 16:23:40,779 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.remoting.endpoint.subsystem (missing) dependents: [service jboss.naming.remote]
> 16:23:40,782 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" started (with errors) in 1471ms - Started 99 of 103 services (1 services failed or missing dependencies, 9 services are lazy, passive or on-demand)
> {code}
> when started using the following command:
> {code}
> JBOSS_HOME/bin/appclient.sh /foo/bar/some.jar
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-1914) Application client container doesn't start
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1914?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1914:
-----------------------------------------------
Aleksandar Kostadinov <akostadi(a)redhat.com> made a comment on [bug 999465|https://bugzilla.redhat.com/show_bug.cgi?id=999465]
Brian, I speculated that it is ER3.1, I'm using RPM distro that's possibly not exactly matching 3.1. I'll try again when ER5 is out.
> Application client container doesn't start
> ------------------------------------------
>
> Key: WFLY-1914
> URL: https://issues.jboss.org/browse/WFLY-1914
> Project: WildFly
> Issue Type: Bug
> Components: Application Client
> Affects Versions: 8.0.0.Alpha4
> Reporter: jaikiran pai
> Assignee: jaikiran pai
> Fix For: 8.0.0.Beta1
>
>
> Application client container fails to start with the following exception:
> {code}
> 16:23:40,742 INFO [org.jboss.as.jacorb] (MSC service thread 1-7) JBAS016328: CORBA Naming Service started
> 16:23:40,744 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
> ("subsystem" => "naming"),
> ("service" => "remote-naming")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.naming.remote is missing [jboss.remoting.endpoint.subsystem]"]}
> 16:23:40,779 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.remoting.endpoint.subsystem (missing) dependents: [service jboss.naming.remote]
> 16:23:40,782 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" started (with errors) in 1471ms - Started 99 of 103 services (1 services failed or missing dependencies, 9 services are lazy, passive or on-demand)
> {code}
> when started using the following command:
> {code}
> JBOSS_HOME/bin/appclient.sh /foo/bar/some.jar
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2218) Subsystem transformers against 7.2.0
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-2218?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-2218:
-----------------------------
Description:
We have not tested the majority of subsystem transformers against AS 7.2.0. I have attempted to document why we need subsystem transformation here, and also how to use the framework:
https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+Transfo...
This document is WIP, and I will be updating it a bit more over the next few days.
https://gist.github.com/kabir/6825607 contains the difference of a running WildFly instance against AS 7.2.0 in domain mode (for subsystems you don't really need to bother about this one)
https://gist.github.com/kabir/6825559 contains the difference of a running WildFly instance against AS 7.2.0 in standalone mode, here you can see what has changed in the subsystems.
When creating a new subsystem transformers test against 7.2.0, you will need the resource definition for the ModelVersion your subsystem uses in 7.2.0. If this is not found, you need to add a test to your subsystem, which you can delete once you have the .dmr file containing the resource defintion. Here is what I did to generate the file for JMX
{code}
@Test
public void deleteMeWhenDone() throws Exception {
ModelTestControllerVersion controllerVersion = ModelTestControllerVersion.V7_2_0_FINAL;
ModelVersion modelVersion = ModelVersion.create(1, 1, 0); //Whatever version of your subsystem 7.2.0.Final has
KernelServicesBuilder builder = createKernelServicesBuilder(null);
builder.createLegacyKernelServicesBuilder(null, controllerVersion, modelVersion)
.addMavenResourceURL("org.jboss.as:jboss-as-jmx:" + controllerVersion.getMavenGavVersion());
KernelServices services = builder.build();
generateLegacySubsystemResourceRegistrationDmr(services, modelVersion);
}
{code}
Now run the test and delete it. The legacy .dmr file should be in {{target/test-classes/org/jboss/as/subsystem/test/<your-subsystem-name>-<your-version>.dmr}}. Copy this .dmr file to {{subsystem-test/framework/src/main/resources/org/jboss/as/subsystem/test}}.
You will likely also need to update org.jboss.as.subsystem.test.KnownVersions to include your latest subsystem version, once you start doing real testing.
Bear in mind that if you need to add some transformation to 7.2.0 due to some new feature in WildFly 8, you will probably also need to add the same transformation to 7.1.x as well!
Although some subsystems already have added transformers, we still need to add tests.
was:
We have not tested the majority of subsystem transformers against AS 7.2.0. I have attempted to document why we need subsystem transformation here, and also how to use the framework:
https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+Transfo...
This document is WIP, and I will be updating it a bit more over the next few days.
https://gist.github.com/kabir/6825607 contains the difference of a running WildFly instance against AS 7.2.0 in domain mode (for subsystems you don't really need to bother about this one)
https://gist.github.com/kabir/6825559 contains the difference of a running WildFly instance against AS 7.2.0 in standalone mode, here you can see what has changed in the subsystems.
When creating a new subsystem transformers test against 7.2.0, you will need the resource definition for the ModelVersion your subsystem uses in 7.2.0. If this is not found, you need to add a test to your subsystem, which you can delete once you have the .dmr file containing the resource defintion. Here is what I did to generate the file for JMX
{code}
@Test
public void deleteMeWhenDone() throws Exception {
ModelTestControllerVersion controllerVersion = ModelTestControllerVersion.V7_2_0_FINAL;
ModelVersion modelVersion = ModelVersion.create(1, 1, 0); //Whatever version of your subsystem 7.2.0.Final has
KernelServicesBuilder builder = createKernelServicesBuilder(null);
builder.createLegacyKernelServicesBuilder(null, controllerVersion, modelVersion)
.addMavenResourceURL("org.jboss.as:jboss-as-jmx:" + controllerVersion.getMavenGavVersion());
KernelServices services = builder.build();
generateLegacySubsystemResourceRegistrationDmr(services, modelVersion);
}
{code}
Now run the test and delete it. The legacy .dmr file should be in {{target/test-classes/org/jboss/as/subsystem/test/<your-subsystem-name>-<your-version>.dmr}}. Copy this .dmr file to {{subsystem-test/framework/src/main/resources/org/jboss/as/subsystem/test}}.
You will likely also need to update org.jboss.as.subsystem.test.KnownVersions to include your latest subsystem version, once you start doing real testing.
Bear in mind that if you need to add some transformation to 7.2.0 due to some new feature in WildFly 8, you will probably also need to add the same transformation to 7.1.x as well!
> Subsystem transformers against 7.2.0
> ------------------------------------
>
> Key: WFLY-2218
> URL: https://issues.jboss.org/browse/WFLY-2218
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 8.0.0.CR1
> Reporter: Kabir Khan
> Assignee: Brian Stansberry
>
> We have not tested the majority of subsystem transformers against AS 7.2.0. I have attempted to document why we need subsystem transformation here, and also how to use the framework:
> https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+Transfo...
> This document is WIP, and I will be updating it a bit more over the next few days.
> https://gist.github.com/kabir/6825607 contains the difference of a running WildFly instance against AS 7.2.0 in domain mode (for subsystems you don't really need to bother about this one)
> https://gist.github.com/kabir/6825559 contains the difference of a running WildFly instance against AS 7.2.0 in standalone mode, here you can see what has changed in the subsystems.
> When creating a new subsystem transformers test against 7.2.0, you will need the resource definition for the ModelVersion your subsystem uses in 7.2.0. If this is not found, you need to add a test to your subsystem, which you can delete once you have the .dmr file containing the resource defintion. Here is what I did to generate the file for JMX
> {code}
> @Test
> public void deleteMeWhenDone() throws Exception {
> ModelTestControllerVersion controllerVersion = ModelTestControllerVersion.V7_2_0_FINAL;
> ModelVersion modelVersion = ModelVersion.create(1, 1, 0); //Whatever version of your subsystem 7.2.0.Final has
> KernelServicesBuilder builder = createKernelServicesBuilder(null);
> builder.createLegacyKernelServicesBuilder(null, controllerVersion, modelVersion)
> .addMavenResourceURL("org.jboss.as:jboss-as-jmx:" + controllerVersion.getMavenGavVersion());
> KernelServices services = builder.build();
> generateLegacySubsystemResourceRegistrationDmr(services, modelVersion);
> }
> {code}
> Now run the test and delete it. The legacy .dmr file should be in {{target/test-classes/org/jboss/as/subsystem/test/<your-subsystem-name>-<your-version>.dmr}}. Copy this .dmr file to {{subsystem-test/framework/src/main/resources/org/jboss/as/subsystem/test}}.
> You will likely also need to update org.jboss.as.subsystem.test.KnownVersions to include your latest subsystem version, once you start doing real testing.
> Bear in mind that if you need to add some transformation to 7.2.0 due to some new feature in WildFly 8, you will probably also need to add the same transformation to 7.1.x as well!
> Although some subsystems already have added transformers, we still need to add tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (LOGMGR-67) Improve LogManager formatter capability: System resources, thread ID and minified category
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-67?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on LOGMGR-67:
-----------------------------------------------
James Perkins <jperkins(a)redhat.com> made a comment on [bug 994744|https://bugzilla.redhat.com/show_bug.cgi?id=994744]
Looks like the expression is attempting to be resolved by server instead of allowing the logmanager to resovle the expression.
> Improve LogManager formatter capability: System resources, thread ID and minified category
> ------------------------------------------------------------------------------------------
>
> Key: LOGMGR-67
> URL: https://issues.jboss.org/browse/LOGMGR-67
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 1.3.2.Final
> Environment: JBoss EAP 6.0.1
> Reporter: Jeremy KUHN
> Assignee: James Perkins
> Labels: jboss
> Fix For: 1.5.0.Final, 2.0.0.Beta1
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Hello,
> We are currently developing a major JEE application running on multiple JBoss EAP 6.0.1 instances in a service oriented architecture.
> The current implementation of JBoss-logmanager (1.3.2.Final) shipped with JBoss EAP doesn't provide the functionality we require in term of logging formatting.
> We are missing:
> - Thread ID (Thread names are too long and of different length that disturb the reading of logs)
> - we haven't find a way to get the hostname displayed in the logs, a simple solution would be to be able to include System properties and therefore the jboss.host.name property in the pattern. System properties would also be interesting to identified the log coming from a specific application (we'll have one application deployed per JBoss instance). Ideally, we'd like to have the ability to provide a context name to know which application has logged the event but this seems to have been delivered with logging profiles.
> - logback has this interesting feature that lets you minify the log category: instead of org.jboss.logmanager.config.ConfigAction you'll get o.j.l.c.ConfigAction which is more readable in the logs.
> Regards
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2222) SecurityExceptions when starting server with signed jars in an exploded app deployment
by Matt Fluet (JIRA)
[ https://issues.jboss.org/browse/WFLY-2222?page=com.atlassian.jira.plugin.... ]
Matt Fluet commented on WFLY-2222:
----------------------------------
David, our testing with your latest commit looks good. Automated restarts ran all weekend...our control site hit the SecurityException twice, but the site patched with the fix worked fine.
> SecurityExceptions when starting server with signed jars in an exploded app deployment
> --------------------------------------------------------------------------------------
>
> Key: WFLY-2222
> URL: https://issues.jboss.org/browse/WFLY-2222
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Reporter: Matt Fluet
> Assignee: David Lloyd
> Priority: Critical
> Attachments: 0001-Fix-ClassLoader-SecurityException-with-jar-certifica.patch
>
>
> This issue is directly related to https://issues.jboss.org/browse/AS7-2724, where signed jars are sometimes throwing a security exception when the server starts up and then classes cannot be loaded out of certain packages (appears to be some sort of a concurrency issue).
> The fix for that issue was applied to JarFileResourceLoader here: https://github.com/jboss-modules/jboss-modules/commit/8cf33f5c02c0c4bf6f9...
> However, our application is exploded, so the VFSResourceLoader needs a similar fix. I will attach a git patch file with the change we're proposing.
> To test the theory, we applied the patch to one server and left another as is as a control...we then left a process running that continually restarted the server for 3 days. The control server hit the SecurityException problem 5 times, and the patched server didn't show it at all.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months