[JBoss JIRA] (AS7-5562) Log message too cryptic when deployment references a non-existent configuration in profile config
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/AS7-5562?page=com.atlassian.jira.plugin.s... ]
Brad Maxwell moved JBPAPP-9934 to AS7-5562:
-------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-5562 (was: JBPAPP-9934)
Issue Type: Enhancement (was: Bug)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: 7.1.2.Final (EAP)
(was: EAP 6.0.0)
Component/s: Server
(was: Other)
Security: (was: Public)
Fix Version/s: Open To Community
(was: TBD EAP 6)
Docs QE Status: (was: NEW)
> Log message too cryptic when deployment references a non-existent configuration in profile config
> -------------------------------------------------------------------------------------------------
>
> Key: AS7-5562
> URL: https://issues.jboss.org/browse/AS7-5562
> Project: Application Server 7
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: Open To Community
>
> Attachments: helloWorld.ear, helloWorld.ear-source.zip
>
>
> When a jboss-ejb-client.xml inside of a deployment that references an outbound-socket that does not exist in the standalone.xml, it logs a cryptic message and does not explain where the issue is. Note when a deployment contains more sub deployements, the log message is much larger and the issue if you know what to look for is hidden in the middle.
> 15:41:01,189 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.ejb3.dd-based-ejb-client-context.\"helloWorld.ear\" Missing[jboss.remoting.endpoint.subsystem.outbound-connection.part101node01-connection]","jboss.deployment.subunit.\"helloWorld.ear\".\"helloWorld.war\".INSTALL Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"helloWorld.ear\".INSTALL Missing[JBAS014861: <one or more transitive dependencies>]"]}}}
> The error message should be translated to say something to the extent of
> "Your deployment helloWorld.ear contains a jboss-ejb-client.xml which references an outbound-socket named part101node01 which is not defined in your JBoss profile's remoting subsystem configuration"
> jboss.ejb3.dd-based-ejb-client-context.\"helloWorld.ear - this shows that helloWorld.ear is the deployment, jboss.ejb3.dd-based-ejb-client-context seems to the jboss-ejb-client.xml
> jboss.remoting.endpoint.subsystem.outbound-connection.part101node01-connection - this shows that the subsystem that is missing the outbound-configuration is the remoting subsystem and that the reference name missing is part101node01
--
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
13 years, 9 months
[JBoss JIRA] (JBWEB-232) Allow StandardContext to expose start problems to callers instead of logging them
by Brian Stansberry (JIRA)
Brian Stansberry created JBWEB-232:
--------------------------------------
Summary: Allow StandardContext to expose start problems to callers instead of logging them
Key: JBWEB-232
URL: https://issues.jboss.org/browse/JBWEB-232
Project: JBoss Web
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Affects Versions: JBossWeb-7.0.10.GA
Reporter: Brian Stansberry
Assignee: Remy Maucherat
See discussion of the log.txt attached to AS7-2322. That JIRA is about how AS7 handles exceptions, but in the case of the example the user attached, there is not much the AS can do. StandardContext is catching any exceptions that occur, logging at error, and then discarding the exception.
I can see how this behavior might be appropriate for some usages, e.g. standalone Tomcat. And the logic after an exception is caught is complex, so I can see why just throwing a LifecycleException is not an option. But is it possible to have a configuration property on StandardContext such that instead of logging and discarding exceptions, it would *not* log them and retain the exception so the caller to start() could access it? Or perhaps throw it on in a LifecycleException at the end? Basically some mechanism such that the AS' WebDeploymentService could take responsibility for reporting the exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] Created: (JBAS-8316) Simple command line installer
by Brian Stansberry (JIRA)
Simple command line installer
-----------------------------
Key: JBAS-8316
URL: https://jira.jboss.org/browse/JBAS-8316
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Fix For: 7.0.0.M1
The AS is going to support two different running modes (see "Standalone Server" vs the rest of the discussion on http://community.jboss.org/docs/DOC-15215) and a flexible configuration for defining the "profile" a server will run. Profiles will not be represented via filesystem directories; rather they will be pure configuration.
The two different running modes will result in slightly different filesystem layouts -- see discussion in http://community.jboss.org/thread/153858.
The upshot of all this is using AS 7 will not be like previous versions where you could download the distribution, unzip, cd to bin/ and type ./run.sh -c some-std-config". Rather, I envision something like this:
1) download, unzip, cd bin
2) ./install.sh --someparamstotellitwhatyouwant
Params to tell it what you want would be whether you're running in standalone mode or full domain, which of a set of pre-packaged profiles you want, maybe some more stuff. From this, installer would create the appropriate filesystem layout, generate a domain.xml+host.mxl or standalone.xml
3) ./run.sh
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-5560) jboss-cli.bat --debug option not shifted properly
by Cheng Fang (JIRA)
Cheng Fang created AS7-5560:
-------------------------------
Summary: jboss-cli.bat --debug option not shifted properly
Key: AS7-5560
URL: https://issues.jboss.org/browse/AS7-5560
Project: Application Server 7
Issue Type: Feature Request
Components: Scripts
Affects Versions: 7.2.0.Alpha1
Reporter: Cheng Fang
Assignee: Brian Stansberry
Windows only.
After appending debug options to JAVA_OPTS, the original --debug xxxx is not stripped out, and is passed to JBoss Modules, which failed:
{noformat}
C:\jboss-as7\jboss-as-7.2.0.Alpha1-SNAPSHOT\bin>"C:\Program Files\Java\jdk1.6.0_31\bin\java" -XX:+TieredCompilation -XX:
+UseCompressedOops -Dprogram.name=-d -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n "-Dorg.jboss.boot.l
og.file=C:\jboss-as7\jboss-as-7.2.0.Alpha1-SNAPSHOT\standalone\log\boot.log" "-Dlogging.configuration=file:C:\jboss-as7
\jboss-as-7.2.0.Alpha1-SNAPSHOT\standalone/configuration/logging.properties" -jar "C:\jboss-as7\jboss-as-7.2.0.Alpha
1-SNAPSHOT\jboss-modules.jar" -mp "C:\jboss-as7\jboss-as-7.2.0.Alpha1-SNAPSHOT\modules" -jaxpmodule "javax.xml.j
axp-provider" org.jboss.as.standalone -Djboss.home.dir="C:\jboss-as7\jboss-as-7.2.0.Alpha1-SNAPSHOT" -d
Listening for transport dt_socket at address: 8787
{noformat}
--
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
13 years, 9 months
[JBoss JIRA] (AS7-5422) Logging configuration DUP should be more deterministic
by James Perkins (JIRA)
James Perkins created AS7-5422:
----------------------------------
Summary: Logging configuration DUP should be more deterministic
Key: AS7-5422
URL: https://issues.jboss.org/browse/AS7-5422
Project: Application Server 7
Issue Type: Feature Request
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
Notes from [~kconner]:
The findConfigFile method does a recursive search of the resource, looking for the configuration files, but there seems to be a couple of problems with this
- the order of the search may be dependent on the platform as VFS seems
to rely on the filesystem order (not classpath) so it may not be
deterministic across platforms.
- any log4j.xml/log4j.properties/jboss-log4j.xml will overwrite the
previously discovered resource, resulting in the last being chosen.
I came across this while debugging some strange behaviour when deploying drools-guvnor.war into EAP 6. What I discovered is that this loop first identified the top most resource (/content/drools-guvnor.war/WEB-INF/classes/log4j.xml) but then overwrote it with an embedded one (/content/drools-guvnor.war/WEB-INF/lib/webdav-servlet-2.0.jar/log4j.xml) but it doesn't appear as if this method has a well defined behaviour.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months