dump of circularity issues
by Scott Stark
I have caused a circularity somewhere, but the log does not contain what
the associated dependency graph is. This is during the boot of the
server so I can't go into jmx and look at things. Is there a way to get
more information on this in the log? Setting everything to trace level
in the logging.properties is not adding anything about the error.
10:43:14,730 INFO [org.jboss.as.naming] Activating Naming Subsystem
10:43:14,745 INFO [org.jboss.as.clustering.infinispan.subsystem]
Activating Infinispan subsystem.
10:43:14,798 INFO [org.jboss.as.security] Activating Security Subsystem
10:43:14,904 ERROR [org.jboss.as.server] Boot update failed:
"org.jboss.msc.service.CircularDependencyException: Service jboss-as has
a circular dependency"
10:43:15,037 INFO [org.jboss.as.connector.subsystems.datasources]
Deploying JDB
13 years, 6 months
AS 7 profiling output while running under load
by Scott Marlow
You probably saw Andy Miller's notes, explaining how to profile AS7 with
the oprofile tool on Fedora
(http://community.jboss.org/wiki/ProfilingAS7UsingOProfileOnFedora).
http://pastebin.com/ewvCdC48 contains output from a performance test. I
wanted to share this with everyone, as its interesting to see how much
CPU is used by various parts of our codebase. Take the information with
a grain of salt, as its not that meaningful by itself.
This could probably be combined with a traditional profiler (which would
show the reason why something was called thousands of times). But at
least this gives you an idea of which code to focus on.
I'm still trying to understand what some of the oprofile details mean
exactly as well.
Scott
13 years, 6 months
I'm having the weirdest problem with server.log showing up in bin
by Scott Stark
I'm having the strangest problem with the server.log showing up in the
bin directory in my fork of jboss-as
(https://github.com/starksm64/jboss-as). It is reproducible and I'm
seeing it on two different machines. I do not see it if I clone
https://github.com/jbossas/jboss-as directly, but I do not have any
outstanding changes in my workspace, so I don't know where the change is
being introduced.
I have debugged it to the point of seeing that the
PeriodicRotatingFileHandlerAdd.execute call receives a ModelNode
operation that has the file.{path,relative-to} information:
{
"operation" => "add",
"address" => [
("subsystem" => "logging"),
("periodic-rotating-file-handler" => "FILE")
],
"autoflush" => true,
"level" => "INFO",
"formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n",
"file" => {
"path" => "server.log",
"relative-to" => "jboss.server.log.dir"
},
"append" => true,
"suffix" => ".yyyy-MM-dd",
"operation-headers" => {"rollback-on-runtime-failure" => false},
"encoding" => undefined
}
but this test at PeriodicRotatingFileHandlerAdd.java:95 fails and so the
dependency on relative-to is not added:
if
(operation.hasDefined(CommonAttributes.RELATIVE_TO)) {
fileBuilder.addDependency(AbstractPathService.pathNameOf(operation.get(FILE,
RELATIVE_TO).asString()), String.class,
fileService.getRelativeToInjector());
}
Anyone know what is going on before I spend any more time debugging this?
[533][valkyrie: bin]$ ls
domain.bat jboss-admin.bat standalone.bat wsconsume.bat
wsprovide.sh
domain.conf jboss-admin.sh standalone.conf wsconsume.sh
domain.sh server.log standalone.sh wsprovide.bat
[534][valkyrie: bin]$ ls ../standalone/log/
boot.log
13 years, 6 months
subsystem description keys
by Scott Stark
I see that some subsystems use CHILDREN as the model key to describe the
subsystem root children, while others are using ATTRIBUTES. It does not
appear to make a different right now, but I assume it will at some point?
Logging:
subsystem.get(CHILDREN, CommonAttributes.ROOT_LOGGER,
DESCRIPTION).set(bundle.getString("root.logger"));
Transactions:
subsystem.get(ATTRIBUTES, CORE_ENVIRONMENT,
DESCRIPTION).set(bundle.getString("core-environment"));
13 years, 6 months
Error build AS7
by Howard Gao
Hi,
Today I build AS7 and keep getting this error
[ERROR] Failed to execute goal on project
jboss-as-arquillian-protocol-servlet: Could not resolve dependencies for
project
org.jboss.as:jboss-as-arquillian-protocol-servlet:jar:7.0.0.Beta4-SNAPSHOT:
Failed to collect dependencies for
[org.jboss.arquillian.protocol:arquillian-protocol-jmx:jar:1.0.0.Alpha4.SP9
(compile), org.jboss.arquillian:arquillian-spi:jar:1.0.0.Alpha4.SP9
(compile), org.jboss.jsfunit:jboss-jsfunit-core:jar:2.0.0.Beta1
(compile), org.jboss.shrinkwrap:shrinkwrap-api:jar:1.0.0-alpha-11
(compile),
org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar:1.0.0.Final
(compile), org.jboss.arquillian:arquillian-api:jar:1.0.0.Alpha4.SP9
(compile), junit:junit:jar:4.8.2 (test),
org.jboss.as:jboss-as-build-config:jar:7.0.0.Beta4-SNAPSHOT (compile)]:
Failed to read artifact descriptor for
org.jboss.shrinkwrap:shrinkwrap-api:jar:1.0.0-alpha-11: Could not
transfer artifact org.jboss.shrinkwrap:shrinkwrap-api:pom:1.0.0-alpha-11
from/to jboss-public-repository-group
(http://repository.jboss.org/nexus/content/groups/public/): Error
transferring file: Connection refused -> [Help 1]
It seems a connection broken issue but using a browser I can open this url
http://repository.jboss.org/nexus/content/groups/public/org/jboss/shrinkw...
or
https://repository.jboss.org/nexus/content/groups/public/org/jboss/shrink...
Does anybody have an idea?
Thanks
Howard
13 years, 6 months
Creating the Module earlier in the deployment
by Stuart Douglas
I was thinking that at the moment we are creating the module very late in the the deployment process, which seems unnecessary, as all the information we need to create it is available quite early on in the parse phase.
I think it would simplify quite a lot of the code if we changed the deployment order so the module gets created much earlier, and is availible during parsing of EJB components etc. At the moment we seem to have a lot of code that stores information into string representations of a class/method, only to change it into a Class/Method object in a later phase. If this code could just work the the DeploymentReflectionIndex straight away, I think it could result in much cleaner code.
Does this seems like a good idea, or or there some drawbacks to this that I am missing?
Stuart
13 years, 6 months
async-handler missing attribute FILE_NAME
by Francesco Marchioni
Hi all,
there seems to be an issue with async-handler configuration.The attribute
"FILE_NAME" is required from async-handler type but there's no mention of it
in jboss-logging.xsd
:61 ---><async-handler name="ASYNC" >
<level name="INFO" />
<sub-handlers>
<handler-ref name="FILE" />
</sub-handlers>
</async-handler>
This produces an unexpected error:
08:45:41,281 ERROR [stderr] Caused by: javax.xml.stream.XMLStreamException:
ParseError at [row,col]:[61,6]
08:45:41,281 ERROR [stderr] Message: Missing required attribute(s):
FILE_NAME
08:45:41,281 ERROR [stderr] at
org.jboss.as.controller.parsing.ParseUtils.missingRequired(ParseUtils.java:115)
08:45:41,281 ERROR [stderr] at
org.jboss.as.logging.LoggingSubsystemParser.parseAsyncHandlerElement(LoggingSubsystemParser.java:256)
08:45:41,281 ERROR [stderr] at
org.jboss.as.logging.LoggingSubsystemParser.readElement(LoggingSubsystemParser.java:146)
08:45:41,281 ERROR [stderr] at
org.jboss.as.logging.LoggingSubsystemParser.readElement(LoggingSubsystemParser.java:81)
08:45:41,281 ERROR [stderr] at
org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100)
08:45:41,281 ERROR [stderr] at
org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
08:45:41,281 ERROR [stderr] at
org.jboss.as.controller.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:382)
08:45:41,281 ERROR [stderr] at
org.jboss.as.controller.parsing.StandaloneXml.readServerElement(StandaloneXml.java:156)
08:45:41,281 ERROR [stderr] at
org.jboss.as.controller.parsing.StandaloneXml.readElement(StandaloneXml.java:89)
08:45:41,281 ERROR [stderr] at
org.jboss.as.controller.parsing.StandaloneXml.readElement(StandaloneXml.java:77)
08:45:41,281 ERROR [stderr] at
org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100)
08:45:41,281 ERROR [stderr] at
org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:59)
08:45:41,296 ERROR [stderr] at
org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:105)
08:45:41,296 ERROR [stderr] ... 5 more
08:45:41,296 INFO [org.jboss.as] JBoss AS 7.0.0.Beta3 "Salyut" stopped in
3ms
Regards
Francesco
13 years, 6 months
Couple of minor changes to jboss-admin.sh script
by Scott Stark
I want to be able to find out what deployments exist in a server in a
scripting environment. There are a couple of issues in the
jboss-admin.sh that prevent this from being done. The first is the dump
of the environment header:
=========================================================================
JBoss Admin Command-line Interface
JBOSS_HOME:
/home/git/JBossAS/jboss-as/build/target/jboss-7.0.0.Beta4-SNAPSHOT
JAVA:
/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin/java
JAVA_OPTS:
=========================================================================
1. I would like to add a -q/--quiet option that disables the output of
this header. It would also suppress the "Connected..." and "Closed..."
msgs as all I want to see is the output of the command that is being
executed to simplify the script's parsing of the returned information.
2. The second is the handling of arguments with strings. The way the
launch of the org.jboss.as.cli module is done, arguments to the
jboss-admin.sh with quotes around spaces are incorrectly interpretted as
multiple arguments. For example, trying to list the deployments using:
[130](ironmaiden:bin) > ./jboss-admin.sh --connect command='ls deployment'
Connected to standalone controller at localhost:9999
extension path subsystem
deployment management-interfaces management
interface socket-binding-group
Closed connection to localhost:9999
produced just the result of an "ls" command without any arguments. The
reason is that the CommandLineMain.main saw 3 arguments instead of 2:
{"--connect", "command=ls", "deployment"}. The "$@" list of arguments
to the shell script needs to be hard quoted so that the eval command
properly expands the arguments. With this, the previous command now
produces the expected listing of the deployment node:
[131](ironmaiden:bin) > ./jboss-admin.sh --connect command='ls deployment'
Connected to standalone controller at localhost:9999
ROOT.war
Closed connection to localhost:9999
In these examples I have not yet suppressed the "Connected..." and
"Closed..." msgs coming from the CommandLineMain class.
13 years, 6 months
SecurityAssociation, getCallerPrincipal() returns null
by Christoph Gostner
Hello,
I'm testing the authentication mechanism in JBoss AS 7.
I tried to access the caller principal (mainly to display the princiapl's
name).
But the Method SecurityAssociation.getCallerPrincipal() always returns null.
if(!server)
return principal;
where principal is null
I tested it with BasicAuthentication and JBoss Negotiation, in both cases
the caller principal is null. Compared to JBoss AS 5, the principal is set.
Could this be an error or is the method not implemented correctly (yet)?
Regards,
Christoph
13 years, 6 months
