AS 7.1.0 ALPHA2 Snapshot - jboss-admin issue
by Vimal Kansal
Hi,
I am running the AS 7.1.0 ALPHA2 SNAPSHOT and when I connect to it using
jboss-admin tool, on help command I do not see messaging subsystem
related commands. The description of help tells that if a subsystem is
inactive, its related command won't show up. But I can see my messaging
subsystem active. I was wondering if this is a bug ?
Thx
Vimal
13 years, 11 months
Failing tests in master
by Kabir Khan
Most of these seem to be timer service related. FWIW I've attached the test report files
Failed tests: testAnnotationTimeoutMethod(org.jboss.as.test.integration.ejb.mdb.timerservice.SimpleTimerMDBTestCase)
testTimedObjectTimeoutMethod(org.jboss.as.test.integration.ejb.mdb.timerservice.SimpleTimerMDBTestCase)
testArountTimeoutInterceptorOrder(org.jboss.as.test.integration.ejb.timerservice.aroundtimeout.TimerServiceInterceptorOrderTestCase)
testRequestScopeActive(org.jboss.as.test.integration.ejb.timerservice.cdi.requestscope.CDIRequestScopeTimerServiceTestCase): expected:<Hello> but was:<null>
createTimerService(org.jboss.as.test.integration.ejb.timerservice.persistence.TimerServicePersistenceFirstTestCase)
testCreateTimerWithInfo(org.jboss.as.test.integration.ejb.timerservice.serialization.TimerServiceSerializationFirstTestCase)
testAnnotationTimeoutMethod(org.jboss.as.test.integration.ejb.timerservice.simple.SimpleTimerServiceTestCase)
testTimedObjectTimeoutMethod(org.jboss.as.test.integration.ejb.timerservice.simple.SimpleTimerServiceTestCase)
testRollbackRetry(org.jboss.as.test.integration.ejb.timerservice.tx.retry.TimerRetryTestCase)
testExceptionRetry(org.jboss.as.test.integration.ejb.timerservice.tx.retry.TimerRetryTestCase)
testAnnotationTimeoutMethod(org.jboss.as.test.integration.ejb.timerservice.view.ViewTimerServiceTestCase)
testTimedObjectTimeoutMethod(org.jboss.as.test.integration.ejb.timerservice.view.ViewTimerServiceTestCase)
13 years, 11 months
Fwd: [AS7 Users] - Common management operations
by ssilvert＠redhat.com
Forwarding to the dev list. I'm wondering to what extent we are
required to support these common operations?
Like Dmitri, I'm finding lots of places where the common operations
are not supported or not working for all attributes.
Is it theoretically possible to do everything you need with the common ops?
Are custom ops needed or are they just for convenience?
Stan
----- Forwarded message from do-not-reply(a)jboss.com -----
Date: Fri, 28 Oct 2011 07:27:26 -0400
From: Dmitri Voronov <do-not-reply(a)jboss.com>
Reply-To: Dmitri Voronov <do-not-reply(a)jboss.com>
Subject: [AS7 Users] - Common management operations
To: Stan Silvert <ssilvert(a)jboss.com>
Dmitri Voronov [http://community.jboss.org/people/dimonv] created the
discussion
"Common management operations"
To view the discussion, visit:
http://community.jboss.org/message/634032#634032
--------------------------------------------------------------
Hi all,
the admin guide
https://docs.jboss.org/author/display/AS7/Management+Clients
https://docs.jboss.org/author/display/AS7/Management+Clients
says:
"... common operations that exist on any node... The common operations are:
* add
* remove
* read-attribute
* write-attribute
* read-children-names
* read-children-resources
* read-children-types
* read-operation-description
* read-operation-names
* read-resource
* read-resource-description"
Thus I can execute e.g.:
[standalone@localhost:9999 /] /extension=org.divo.hr:add
{"outcome" => "success"}
and
[standalone@localhost:9999 /] /subsystem=hr:add
{"outcome" => "success"}
but I cannot execute:
[standalone@localhost:9999 /] /subsystem=hr:remove
{
"outcome" => "failed",
"failure-description" => "No handler for operation remove at
address [(\"subsystem\" => \"hr\")]",
"rolled-back" => true
}
but I can:
[standalone@localhost:9999 /] /extension=org.divo.hr:remove
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
Are subsystems and extenssions an exception?
Anyway, in my opinion as an infrustructure responsible I should be
able to manage extensions and subsystems.
Regards
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/634032#634032]
Start a new discussion in AS7 Users at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
----- End forwarded message -----
Dmitri Voronov [http://community.jboss.org/people/dimonv] created the discussion
"Common management operations"
To view the discussion, visit: http://community.jboss.org/message/634032#634032
--------------------------------------------------------------
Hi all,
the admin guide
https://docs.jboss.org/author/display/AS7/Management+Clients https://docs.jboss.org/author/display/AS7/Management+Clients
says:
"... common operations that exist on any node... The common operations are:
* add
* remove
* read-attribute
* write-attribute
* read-children-names
* read-children-resources
* read-children-types
* read-operation-description
* read-operation-names
* read-resource
* read-resource-description"
Thus I can execute e.g.:
[standalone@localhost:9999 /] /extension=org.divo.hr:add
{"outcome" => "success"}
and
[standalone@localhost:9999 /] /subsystem=hr:add
{"outcome" => "success"}
but I cannot execute:
[standalone@localhost:9999 /] /subsystem=hr:remove
{
"outcome" => "failed",
"failure-description" => "No handler for operation remove at address [(\"subsystem\" => \"hr\")]",
"rolled-back" => true
}
but I can:
[standalone@localhost:9999 /] /extension=org.divo.hr:remove
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
Are subsystems and extenssions an exception?
Anyway, in my opinion as an infrustructure responsible I should be able to manage extensions and subsystems.
Regards
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/634032#634032]
Start a new discussion in AS7 Users at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months
Need info on application client container
by Vimal Kansal
Hi,
I couldn't find much info on how to run the application client container.
(1) I am trying to rut the followingn the application client container
by executing appclient.bat file and I get the following error :
C:\Apps\jboss-as-7.1.0.Alpha2-SNAPSHOT\bin>appclient
Calling
C:\Apps\jboss-as-7.1.0.Alpha2-SNAPSHOT\bin\standalone.conf.bat
16:42:53,802 INFO [org.jboss.modules] JBoss Modules version
1.0.3.GA
16:42:54,034 INFO [org.jboss.msc] JBoss MSC version 1.0.1.GA
16:42:54,082 INFO [org.jboss.as] JBoss AS
7.1.0.Alpha2-SNAPSHOT "Ahoy!" starting
16:42:54,241 ERROR
[org.jboss.as.controller.AbstractControllerService] Error
booting the container: java.lang.RuntimeException:
org.jboss.as.controller.persistence.ConfigurationPersistenceException:
F
ailed to parse configuration
at
org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:139)
[jboss-as-controller-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_27]
Caused by:
org.jboss.as.controller.persistence.ConfigurationPersistenceException:
Failed to parse configuration
at
org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:125)
[jboss-as-controller-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
at
org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:168)
[jboss-as-controller-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
at
org.jboss.as.server.ServerService.boot(ServerService.java:199)
[jboss-as-server-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
at
org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:133)
[jboss-as-controller-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
... 1 more
*Caused by: java.io.FileNotFoundException:
C:\Apps\jboss-as-7.1.0.Alpha2-SNAPSHOT\appclient\configuration\standalone.xml
(The system cannot find the file specified)*
at java.io.FileInputStream.open(Native Method)
[:1.6.0_27]
at
java.io.FileInputStream.<init>(FileInputStream.java:120)
[:1.6.0_27]
at
org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:113)
[jboss-as-controller-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
... 4 more
16:42:54,245 INFO [org.jboss.as] JBoss AS
7.1.0.Alpha2-SNAPSHOT "Ahoy!" stopped in 3ms
C:\Apps\jboss-as-7.1.0.Alpha2-SNAPSHOT\bin>
(2) Any info on as to how to deploy client application to client container.
Thx
Vimal
13 years, 11 months
File system deployment - Handling .failed markers on server restart
by Jaikiran Pai
A user brought up an issue (or rather a non-intuitive behaviour) with
the way we process failed file system deployments. Consider the
following case:
1) User has a foo.war in standalone/deployments folder and that foo.war
is dependent on some setting in the standalone.xml
2) The standalone.xml has an inconsistency which results in the
application deployment to fail when the application is deployed
3) Our file system deployment process creates a foo.war.failed marker to
indicate that failure and to suppress any subsequent re-deployments
until the issue is fixed. The file system deployment scanner picks up
the foo.war for re-deployment if that foo.war.failed marker is removed
or the timestamp of the foo.war changes to a more latest timestamp than
that of the .failed marker.
4) In this user's case, since the cause of failure was a configuration
issue in the standalone.xml, the user stops the server and fixes the
standalone.xml
5) He then restarts the server, but our file system deployment scanner
does *not* pick up foo.war for deployment (nor logs a message) since
neither the .failed marker was removed nor the deployment foo.war had a
new updated timestamp.
6) The user then has to go figure out why the deployment was never
picked up.
I personally don't think we should do any additional (smart?) logic in
the file system deployment scanner to handle this scenario. I would
expect the user to either remove that .failed marker or update the
deployment timestamp once he has fixed the (external) issue. *But* I do
think that we should probably log a (one-time) INFO message during
startup to indicate that the presence of the .failed marker has caused
the scanner to skip the deployment.
Thoughts?
-Jaikiran
13 years, 11 months
Finding out what version of the Detyped API a client is dealing with
by David Bosschaert
Hi all,
Maybe I missed this but I'm wondering is there a declaration of what
version of the Detyped Model is supported by the currently running AS7
instance?
E.g. I can imagine someone writing a CLI-script or a standalone client
to the Detyped API and needing to know what version is supported by the
running server. Do we expose this somewhere? And on what level?
Cheers,
Davdi
13 years, 11 months
