Operations and {request,reply}-properties
by Heiko W.Rupp
Hi,
Operation descriptions usually have
[domain@localhost:9999 subsystem=security] /profile=default/subsystem=jms/queue=testQueue:read-operation-description(name=add)
{
"outcome" => "success",
"result" => {
"operation-name" => "add",
"description" => "Add a queue.",
"request-properties" => {
......
},
"reply-properties" => {}
},
Should that be true for all operations?
I see e.g. in subsystem=security land :
[domain@localhost:9999 subsystem=security] ./security-domain=other:read-operation-description(name=list-cached-principals)
{
"outcome" => "success",
"result" => {
"operation-name" => "list-cached-principals",
"description" => "Lists the principals stored in the authentication cache for this security domain."
},
"compensating-operation" => undefined
}
14 years, 4 months
hibernate log barf
by Ales Justin
This is my persistence.xml
<persistence-unit name="radar" transaction-type="JTA">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<jta-data-source>java:/H2DS</jta-data-source>
<!-- entities -->
<class>org.jboss.lhotse.server.api.domain.AbstractEntity</class>
<class>org.jboss.lhotse.server.api.domain.TimestampedEntity</class>
<class>org.jboss.lhotse.server.api.domain.GeoPt</class>
<class>org.jboss.lhotse.server.api.domain.Version</class>
<class>com.alterjoc.radar.server.domain.AuditLog</class>
<exclude-unlisted-classes>true</exclude-unlisted-classes>
<properties>
<property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>
<property name="hibernate.hbm2ddl.auto" value="create-drop"/>
<property name="hibernate.show_sql" value="false"/>
<property name="hibernate.format_sql" value="true"/>
</properties>
</persistence-unit>
when running / testing app in latest AS7, Hibernate barfs a ton of INFO / WARN:
* http://pastebin.com/iJCahSFi
It looks like things do work, but definitely something I as a user don't like to see.
-Ales
14 years, 4 months
Can't one search commits on github?
by Scott Stark
I'm trying to find the changes associated with this issue:
https://issues.jboss.org/browse/AS7-486 formerly known as JBAS-9270, but
I can't seem to find a way to search the jboss-as git commits. Am I
missing a search box somewhere? The only one I can find up in the corner
appears to want to search repo names or something not useful.
Is there any way to tie this workflow info to the commit?
Project JBoss Application Server[ 10030 ] Application Server 7[
12311211 ]
Key JBAS-9270 AS7-486 <https://issues.jboss.org/browse/AS7-486>
Workflow jira[ 12444066 ] GIT Pull Request workflow[ 12447354 ]
Component/s
CLI[ 12313802 ]
Component/s CLI[ 12313755 ]
Fix Version/s
7.0.0.Beta3[ 12316375 ]
14 years, 4 months
How to add a deployment to a server group?
by Heiko W.Rupp
HI,
there have been recent changes to the deployment handling
so for /deployment there is now a sub element "content".
The same structure seems to exist for
/server-group=x/deployment=y too. When I :add I always get a duplicate entry exception
Is there an example available how this is supposed to work now?
Thanks
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
14 years, 4 months
Testsuite execution
by Brian Stansberry
I'd like to get feedback on changes to the testsuite found in
https://github.com/bstansberry/jboss-as/commit/efe2051753f6b79788d0515678...
I'll be adding a bunch of integration tests that launch a domain, but
before pushing those I wanted to ensure they weren't run every time
someone did a build. That led to a general effort to simplify how we can
execute the 3 main build cases -- a standard build with some smoke
tests, a no-test fast build, and a full test run. The above commit
results in the following behavior:
1) By default, all normal modules and testsuite modules will be built
(so test compilation issues introduced by code changes will be caught)
but the only tests that will be executed are:
a) the tests in non-testsuite modules
b) the tests in testsuite/smoke
2) By adding -DskipTests=true, no tests will be executed (although
they'll still compile).
3) By adding -DskipTests=false the integration tests in testsuite2,
testsuite/integration and the webservices module will be enabled. So
that results in a full testsuite run (except for the currently empty
benchmark and stress test modules).
The testsuite2, testsuite/integration and the webservices module also
have testFailureIgnore set to true, which means failures in one of the
many modules will not fail the build, allowing the full set of tests to
run. A test failure in a non-testsuite module or in testsuite/smoke will
fail the build.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
14 years, 4 months
Maven artifact for AS7 distribution
by Magesh Kumar Bojan
Do we (plan to) distribute AS7 tag releases to a maven repo? I need to create a custom distribution based on the standard, is there any other way other than building from sources?
cheers,
Magesh
14 years, 4 months
Another ROOT.war issue
by Scott Stark
In the current pull of jboss-as trunk, I can't deploy a simple ROOT.war
due to what looks like a duplicate ROOT or / context, but when there is
no deployment there is no application available under localhost:8080/.
[105](ironmaiden:bin) > ./standalone.sh
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME:
/home/git/JBossAS/jboss-as/build/target/jboss-7.0.0.Beta4-SNAPSHOT
...
17:59:26,587 INFO [org.jboss.as.deployment] (MSC service thread 1-2)
Started FileSystemDeploymentService for directory
/home/git/JBossAS/jboss-as/build/target/jboss-7.0.0.Beta4-SNAPSHOT/standalone/deployments
17:59:26,598 INFO [org.jboss.as.deployment] (DeploymentScanner-threads
- 1) Found ROOT.war in deployment directory. To trigger deployment
create a file called ROOT.war.dodeploy
17:59:26,609 WARN [org.jboss.osgi.framework.internal.URLHandlerPlugin]
(MSC service thread 1-3) Unable to set the URLStreamHandlerFactory
17:59:26,616 WARN [org.jboss.osgi.framework.internal.URLHandlerPlugin]
(MSC service thread 1-3) Unable to set the ContentHandlerFactory
17:59:26,624 INFO [org.apache.catalina.core.AprLifecycleListener] (MSC
service thread 1-5) The Apache Tomcat Native library which allows
optimal performance in production environments was not found on the
java.library.path:
.:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
17:59:26,640 INFO [org.jboss.remoting] (MSC service thread 1-7) JBoss
Remoting version 3.1.0.Beta2
17:59:26,697 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC
service thread 1-2) live server is starting..
17:59:26,699 WARN [org.jboss.vfs] (MSC service thread 1-4) VFS was
unable to set the URLStreamHandlerFactory. This will have unpredictable
results
17:59:26,706 INFO [org.jboss.as.server.deployment] (MSC service thread
1-4) Starting deployment of "ROOT.war"
17:59:26,753 INFO [org.apache.coyote.http11.Http11Protocol] (MSC
service thread 1-8) Starting Coyote HTTP/1.1 on
http-localhost-127.0.0.1-8080
17:59:26,795 INFO [org.jboss.as.connector] (MSC service thread 1-1)
Starting JCA Subsystem (JBoss IronJacamar 1.0.0.Beta6)
17:59:26,843 INFO [org.jboss.as.connector.subsystems.datasources] (MSC
service thread 1-3) Bound data source [java:/H2DS]
17:59:26,952 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8)
MSC00001: Failed to start service jboss.web."ROOT.war":
org.jboss.msc.service.StartException in service jboss.web."ROOT.war":
Failed to start service
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1696)
[jboss-msc-1.0.0.Beta8.jar:1.0.0.Beta8]
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_24]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_24]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
Caused by: java.lang.IllegalArgumentException: Child container with
name already exists
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:804)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:792)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:356)
at
org.jboss.as.web.deployment.WebContextInjector.inject(WebContextInjector.java:57)
at
org.jboss.as.web.deployment.WebContextInjector.inject(WebContextInjector.java:36)
at
org.jboss.msc.inject.CastingInjector.inject(CastingInjector.java:55)
[jboss-msc-1.0.0.Beta8.jar:1.0.0.Beta8]
at
org.jboss.msc.service.ServiceControllerImpl.doInject(ServiceControllerImpl.java:1482)
[jboss-msc-1.0.0.Beta8.jar:1.0.0.Beta8]
at
org.jboss.msc.service.ServiceControllerImpl.access$2000(ServiceControllerImpl.java:47)
[jboss-msc-1.0.0.Beta8.jar:1.0.0.Beta8]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.performInjections(ServiceControllerImpl.java:1709)
[jboss-msc-1.0.0.Beta8.jar:1.0.0.Beta8]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1670)
[jboss-msc-1.0.0.Beta8.jar:1.0.0.Beta8]
... 3 more
17:59:26,968 INFO [org.hornetq.core.remoting.impl.netty.NettyAcceptor]
(MSC service thread 1-2) Started Netty Acceptor version
3.2.1.Final-r2319 localhost:5455 for CORE protocol
17:59:26,969 INFO [org.hornetq.core.remoting.impl.netty.NettyAcceptor]
(MSC service thread 1-2) Started Netty Acceptor version
3.2.1.Final-r2319 localhost:5445 for CORE protocol
17:59:26,970 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC
service thread 1-2) HornetQ Server version 2.1.2.Final (Colmeia, 120)
started
17:59:27,178 ERROR [org.jboss.as] (MSC service thread 1-1) JBoss AS
7.0.0.Beta4-SNAPSHOT "(TBD)" started (with errors) in 2645ms - Started
125 of 182 services (1 services failed or missing dependencies, 56
services are passive or on-demand)
17:59:27,178 INFO [org.jboss.as.server] (MSC service thread 1-7)
Service status report
Services which failed to start:
service jboss.web."ROOT.war":
org.jboss.msc.service.StartException in service jboss.web."ROOT.war":
Failed to start service
17:59:27,197 INFO [org.jboss.as.server.deployment] (MSC service thread
1-1) Stopped deployment ROOT.war in 13ms
17:59:27,200 ERROR [org.jboss.as.deployment] (DeploymentScanner-threads
- 1) undefined
14 years, 4 months
Linux Service Control for AS
by Andrew Lee Rubinger
This email from Dan Allen yesterday:
---------------
One of the *huge* pains for sys admins assuming control of JBoss AS for
the first time is getting it setup as a system service. We provide this
for our EAP RPMs of course, but we just about annoy the crap out of
system admins and accidental developer admins struggling with
this seemingly simple task.
But no more!
Since one of the main themes of AS 7 is "admin-friendly", then we should
definitely recommend this dead simple recipe for setting up JBoss AS as
an upstart service. The Torquebox guys show how to do this with AS 6
(which is part of the Torquebox distribution).
http://torquebox.org/news/2011/05/11/simplify-your-deployment/
which was inspired by the original article by Heroku
http://adam.heroku.com/past/2011/5/9/applying_the_unix_process_model_to_w...
The recipe involves running foreman on a Procfile. foreman is a ruby
gem. But actually, foreman is really just a means to an end. In the end,
you are just creating three files in /etc/init that look like this:
*/etc/init/jboss-as.conf*
pre-start script
bash << "EOF"
mkdir -p /var/log/jboss-as
chown -R dallen /var/log/jboss-as
EOF
end script
*/etc/init/jboss-as-default-1.conf*
start on starting jboss-as-default
stop on stopping jboss-as-default
respawn
chdir /home/dallen/opt/jboss-as
exec su dallen -c 'export PORT=5000; ./bin/run.sh >>
/var/log/jboss-as/default-1.log 2>&1'
*/etc/init/jboss-as-default.conf*
start on starting jboss-as
stop on stopping jboss-as
The it's just:
start jboss-as
and
stop jboss-as
Ahhhhhh.
We should definitely include this in the AS documentation (both for AS 6
and AS 7). You can't imagine how many hours this is going to save admins.
14 years, 4 months
Maven Compiler Plug-In
by James Perkins
On the current branch I'm working on I've switched the
maven-compiler-plugin from version 2.1 to version 2.3.2. The reason
being that with version 2.2+ generated source files can be written to
target/generated-sources rather than being written to the same directory
class files are.
Is there any reason this would be a problem for anyone?
--
James R. Perkins
JBoss by Red Hat
14 years, 4 months
