Consolidation of properties
by Kabir Khan
Looking at standalone.xml we have
<system-properties>
<property name="foo" value="bar"/>
<property name="key" value="value"/>
</system-properties>
Then OSGi uses another format with the value in the element text:
<subsystem xmlns="urn:jboss:domain:osgi:1.0" activation="lazy">
<configuration pid="org.apache.felix.webconsole.internal.servlet.OsgiManager">
<property name="manager.root">jboss-osgi</property>
</configuration>
<properties>
<property name="org.jboss.osgi.system.modules">
org.apache.log4j,
org.jboss.as.osgi,
</property>
<property name="org.osgi.framework.system.packages.extra">
org.apache.log4j;version=1.2,
org.jboss.as.osgi.service;version=7.0,
org.jboss.osgi.spi.capability;version=1.0,
org.jboss.osgi.spi.util;version=1.0,
org.jboss.osgi.testing;version=1.0,
</property>
</properties>
Security is trying to do this:
> <security-properties>a=b,c=d</security-properties>
Then there are several xsd's in the AS7 codebase that take properties whose formats I haven't checked. Is it worth consolidating all these into one xml format?
12 years, 11 months
Deployment Terms
by ssilvert＠redhat.com
I put together a list of 18 terms used to describe deployment and
deployment actions for AS7:
http://community.jboss.org/wiki/AS7DeploymentTerms
Sorry for the need to scroll. "View as PDF" makes it look nicer.
I've tried to be a bit more strict about this than we've been in the
past. Thus, terms like "deployment" and "deploy" are not so
overloaded. All this is important because we need to have consistency
between the console, CLI, and documentation.
Also, consistent terminology will help people learn what is now a
rather complex, but powerful deployment environment. The list itself
provides a bit of a tutorial on AS7 deployment.
Feedback is very welcome.
Stan
12 years, 11 months
EE/EJB rework branch merged
by David M. Lloyd
The EJB rework branch is pushed upstream. It consists of 114 commits
and changes the way interceptors, instantiation, and EE injection works
for EJBs, managed beans, servlets, and more.
Just giving a heads-up.
--
- DML
12 years, 11 months
Security Subsystem management use cases
by Heiko Braun
Can we expect any security subsystem management op's in the near future?
(before 7.0.Final)
Currently there isn't much to lean on:
[domain@localhost:9999 /] /profile=default/subsystem=security:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {"security-domain" => {"other" => {"authentication" => [{
"code" => "UsersRoles",
"flag" => "required"
}]}}},
"compensating-operation" => undefined
}
Ike
12 years, 11 months
AS Console 7.0.Final: Subsystem coverage
by Heiko Braun
Attached you'll find a list of subsystems that we currently plan to include in 7.0.Final.
IMO, this provides reasonable set of features without going too much into the details.
The aim is to provide a console feature set that's helps solving the daily admin tasks,
but is useful during development as well.
In case the subsystem you maintain is not listed, but you think it should, then speak up now.
Ike
12 years, 11 months
Seeing one failed deployment stop other successful deployments
by Scott Stark
I'm seeing a problem with one bad deployment failing other deployments
when starting a server with more than one deployment in the deployments
directory. If I startup the server with:
[root@ip-10-72-59-227 log]# ls ../deployments/
README.txt ROOT.war.dodeploy weld-permalink.war.dodeploy
ROOT.war weld-permalink.war
and the weld-permalink.war fails, the successfully deployed ROOT.war is
stopped. Why would that be?
18:18:02,233 INFO [org.jboss.as] (MSC service thread 1-1) JBoss AS
7.0.0.Beta3-SNAPSHOT "TBD" started in 8363ms - Started 77 of 96 services
(19 services are passive or on-demand)18:18:02,250 INFO
[org.jboss.as.server.deployment] (pool-3-thread-1) Content ad
ded at location
/var/lib/libra/efb401bdb2e641528a1f9278ca091719/jbossas/test3/jbossas-7.0.0/standalone/data/content/fc/b80fdb5b58448bebcdb680ac7790fdcfea5965/content
18:18:02,282 WARN [org.jboss.vfs] (MSC service thread 1-2) VFS was
unable to set the URLStreamHandlerFactory. This will have unpredictable
results
18:18:02,284 INFO [org.jboss.as.server.deployment] (MSC service thread
1-1) Starting deployment of "weld-permalink.war"
18:18:02,633 WARN [org.jboss.as.server.deployment.module] (MSC service
thread 1-3) META-INF directory
/content/weld-permalink.war/WEB-INF/classes/META-INF ignored as it is
not a valid location for META-INF18:18:05,609 WARN
[org.jboss.as.server.deployment.service-loader] (MSC service thread 1-1)
Encountered invalid class name
"com.sun.faces.vendor.Tomcat6InjectionProvider:org.apache.catalina.util.DefaultAnnotationProcessor"
for service type "com.sun.faces.spi.injectionprovider"18:18:05,609 WARN
[org.jboss.as.server.deployment.service-loader] (MSC service thread 1-1)
Encountered invalid class name
"com.sun.faces.vendor.Jetty6InjectionProvider:org.mortbay.jetty.plus.annotation.InjectionCollection"
for service type "com.sun.faces.spi.injectionprovider"
18:18:05,967 INFO [org.jboss.weld] (MSC service thread 1-1) Processing
CDI deployment: weld-permalink.war18:18:06,068 INFO [org.jboss.web]
(MSC service thread 1-2) registering web context:
18:18:06,069 INFO [org.jboss.as.server.deployment] (MSC service thread
1-2) Com
pleted deployment of "ROOT.war" in 3800 ms
18:18:06,872 INFO [org.jboss.weld] (MSC service thread 1-3) Starting
Services for CDI deployment: weld-permalink.war
18:18:06,069 INFO [org.jboss.as.server.deployment] (MSC service thread
1-2) Completed deployment of "ROOT.war" in 3800 ms
18:18:06,872 INFO [org.jboss.weld] (MSC service thread 1-3) Starting
Services for CDI deployment: weld-permalink.war
18:18:07,172 INFO [org.jboss.weld.Version] (MSC service thread 1-3)
WELD-000900 1.1.0 (Final)18:18:07,277 INFO [org.jboss.weld] (MSC
service thread 1-3) Starting weld service
18:18:08,042 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3)
MSC00001: Failed to start service
jboss.deployment.unit."weld-permalink.war".WeldService:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."weld-permalink.war".WeldService:
java.lang.ClassCastException:
org.jboss.weldx.transaction.org$jboss$weld$bean-org$jboss$as$weld$deployment$WeldDeployment$additionalClasses-Built-in-UserTransaction_$$_WeldProxy
cannot be cast to javassist.util.proxy.ProxyObject
...
18:18:08,218 INFO [org.jboss.as.server.deployment] (MSC service thread
1-2) Stopped deployment weld-permalink.war in 112ms
18:18:08,534 INFO [org.jboss.as.server.deployment] (MSC service thread
1-2) Stopped deployment ROOT.war in 422ms
[root@ip-10-72-59-227 log]# ls ../deployments/
README.txt ROOT.war.failed weld-permalink.war.failed
ROOT.war weld-permalink.war
12 years, 11 months
Seeing NPE on simple war deployment
by Scott Stark
when I pulled down the current repo and did the build, it fails on the
smoke tests, but it did build the server target. If I try running that
with a simple ROOT.war, it is failing to deploy with the following NPE:
19:17:45,706 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4)
MSC00001: Failed to start service
jboss.deployment.unit."ROOT.war".PARSE:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."ROOT.war".PARSE: Failed to process phase PARSE of
deployment "ROOT.war"
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:108)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
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.NullPointerException
at
org.jboss.as.server.deployment.annotation.AnnotationIndexUtils.getAnnotationIndexes(AnnotationIndexUtils.java:55)
at
org.jboss.as.web.deployment.WarAnnotationDeploymentProcessor.deploy(WarAnnotationDeploymentProcessor.java:116)
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:102)
... 4 more
12 years, 11 months
TX subsystem management use cases
by Heiko Braun
Can anyone shed some light on the management op's for the transaction subsystem?
The attribute names indicate more sophisticated features, like statistics.
I would need to know how to work with this data in order expose reasonable functionality through the web UI.
[domain@localhost:9999 /] /profile=default/subsystem=transactions:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"core-environment" => {
"socket-binding" => "txn-socket-process-id",
"node-identifier" => undefined
},
"recovery-environment" => {
"socket-binding" => "txn-recovery-environment",
"status-socket-binding" => "txn-status-manager"
},
"coordinator-environment" => {
"enable-statistics" => undefined,
"default-timeout" => undefined
},
"object-store" => {
"relative-to" => undefined,
"path" => undefined
}
},
"compensating-operation" => undefined
}
Ike
12 years, 11 months
New xsd and management operations for drivers
by Stefano Maestri
Hi,
In this branch
you can find some changes in datasources subsystem, mainly regarding
drivers. Please don't merge it since it needs IronJacamar CR1 not yet
released.
https://github.com/maeste/jboss-as/tree/IJ-CR1
To get what are changed have a look to the new driver type in xsd
https://github.com/maeste/IronJacamar/blob/master/common/src/main/resourc...
As you can see it provide not-mandatory major and minor version as asked
here
https://issues.jboss.org/browse/AS7-711
Moreover it provide an attribute called name that is a symbolic name
user have to provide and this name is used to address this particular
driver. Both in management operations and in standalone/domain.xml
removing the annoying notation drivername#major.minor to point to the
driver. Since version are optional and no more used for DriverService
name they are just used to check if specified version and actual driver
version is the same during deployment and as user's information in
management and xml.
Have a look how standalone.xml (same for domain.xml) is now appearing:
https://github.com/maeste/jboss-as/blob/IJ-CR1/build/src/main/resources/s...
As you have probably noticed here and in xsd there are 2 element of
driver tag to specify driver-class and xa-datasource-class. It permits
to support as module also jdbc driver previous than jdbc4. Of course it
is possible only as module, while deployment is still supported only for
jdbc4 drivers while we can't specify driver-class anywhere.
Finally here you have the two operation and answer to query installed
drivers:
/subsystem=datasources:installed-drivers-list
{
"outcome" => "success",
"result" => [
{
"driver-name" => "h2",
"deployment-name" => undefined,
"module-name" => "com.h2database.h2",
"module-slot" => "main",
"driver-class" => "org.h2.Driver",
"major-version" => 1,
"minor-version" => 2,
"jdbc-compliant" => true
},
{
"driver-name" => "ojdbc6.jar",
"deployment-name" => "ojdbc6.jar",
"module-name" => undefined,
"module-slot" => undefined,
"driver-class" => "oracle.jdbc.OracleDriver",
"major-version" => 11,
"minor-version" => 2,
"jdbc-compliant" => true
}
],
"compensating-operation" => undefined
}
[domain@localhost:9999 /]
/subsystem=datasources:get-installed-driver(driver-name="ojdbc6.jar")
{
"outcome" => "success",
"result" => [{
"driver-name" => "ojdbc6.jar",
"deployment-name" => "ojdbc6.jar",
"driver-module-name" => undefined,
"module-slot" => undefined,
"driver-class-name" => "oracle.jdbc.OracleDriver",
"driver-major-version" => 11,
"driver-minor-version" => 2,
"jdbc-compliant" => true
}],
"compensating-operation" => undefined
}
As explained in AS7-328 this operation in domain mode are available at
host level, and not at domain/profile level. Something like that
/host=local/server=server-one/subsystem=datasources:installed-drivers-list
Any comments or suggestions are more than welcome.
regards
S.
12 years, 11 months
