CLI new (generic type) commands
by Alexey Loubyansky
So, I've pushed the prototype for the new approach.
http://community.jboss.org/wiki/GenericTypeCLICommands
Advantages
- any changes in the management model (added/removed operations,
properties, etc) become immediately available in CLI commands without
code changes in the CLI;
- command help content is generated from the description of type,
operations and properties in the management model (so, no text
duplication, localization, etc);
- commands can be added and removed at runtime and customized by the user;
-the total number of cli commands will decrease and they, in a way, will
be better categorized.
Disadvantages
Tab-completion suffers from insufficient info in the management model
about the types, values and relationships/dependencies between the node
and operation properties.
- enumeration values, if the type is boolean, I can do it, but if it's
something else (e.g. tx isolation) the allowed values would have to be
specified in the management model for the type in fixed format;
- exclusive properties, e.g. driver-class/driver-name for datasources.
If I code the data-source command myself I can automatically exclude one
if the other one has been specified;
- referencing properties, e.g. driver-name accepts values that are
registered jdbc driver names, for that to tab-complete, this reference
would have to be described in the model.
There are probably other things that I forgot to mention. I'll follow up
if I remember something.
As always, feedback, ideas, suggestions are welcome.
Thanks,
Alexey
PS: it's not yet in the master as I send it, I did send the pull request
though, so, it's gonna be soon.
12 years, 10 months
detecting JPA usage in AS7 applications...
by Scott Marlow
Currently, we are injecting JPA related module dependencies into
applications that have valid persistence units in persistence.xml.
This is wrong I think. We probably only need to look for the presence
of @PersistenceUnit @PersistenceContext and same in deployment
descriptors (which we currently also do).
I don't want to inject the JPA dependencies just because there is
persistence unit definition (we can still parse it and have it available
for use).
This might help us deploy native Hibernate applications that don't use
EE JPA.
Scott
12 years, 11 months
How should META-INF/services be dealt with in modules?
by Scott Stark
So I have been looking at what the minimum is for a reasteasy based war
to work with an application/xml content type since the providers for
that are bundled in the as7 modules, but the providers are not getting
registered by default. The war does not include any of the resteasy jars
in its WEB-INF/lib as it looks like everything should already be
included in the as7 modules.
In order for this to work, I have to register all of the
javax.ws.rs.ext.Provider annotated classes from the
resteasy-jaxb-provider-2.1.0.GA.jar in my resteasy Application:
import javax.ws.rs.core.Application;
public class StatusApplication extends Application {
@Override
public Set<Class<?>> getClasses() {
Class<?>[] classes = {
org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider.class,
org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlRootElementProvider.class,
org.jboss.resteasy.plugins.providers.jaxb.JAXBElementProvider.class,
org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlTypeProvider.class,
org.jboss.resteasy.plugins.providers.jaxb.CollectionProvider.class,
org.jboss.resteasy.plugins.providers.jaxb.MapProvider.class,
org.jboss.resteasy.plugins.providers.jaxb.XmlJAXBContextFinder.class
};
for(Class<?> c : classes)
providers.add(c);
return providers;
}
Normally resteasy is expecting that it can locate these via the jar
META-INF/services/javax.ws.rs.ext.Providers mechanism, but when the
resteasy framework does the following call while processing the application:
Enumeration<URL> en =
Thread.currentThread().getContextClassLoader().getResources("META-INF/services/"
+ Providers.class.getName());
all it sees is the
resteasy-jaxrs-2.1.0.GA.jar/META-INF/services/javax.ws.rs.ext.Providers
resources. It looks like many of the other resteasy provider modules
would not be loaded simply because they are purely extension modules
with implementations.
What is the correct way to integrate a collection of services using the
META-INF/services mechanism?
12 years, 11 months
datasource/connection-url reference to interfaces/ports
by Scott Stark
The datasource/connection-url property in the domain model is outside of
the interfaces and socket-binding-group usage. The current
datasource_1_0.xsd does not have a reference to sockets or interfaces.
We also don't seem to be setting jboss.server.* system properties that
could be used to create a configuration fragment like:
<datasource jndi-name="java:jboss/datasources/MysqlDS" enabled="true"
use-java-context="true" pool-name="H2DS">
<connection-url>jdbc:mysql://${jboss.server.default.interface}:${jboss.server.socket-binding-group.mysql}/database</connection-url>
<driver>mysql</driver>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
</datasource>
What is the plan to allow jca connection factories to integrate into the
interfaces/ports part of the domain model?
This came up as we add support for mysql in the openshift express
cartridge, and modification of the connection-url for the host the
server is running on requires changes in two parts of the standalone.xml
configuration rather than one.
12 years, 11 months
Dear subsystem owners/components leads ....
by Heiko Braun
Currently the console provides management operations for a very basic set of use cases.
This needs to be extended for AS 7.1.
Going forward we require your feedback. What do you think should be tackled next?
Most of these questions are very problem domain specific. It would be great if all component leads
could take some time and think about the following:
- does my component expose reasonable management operations?
- what would developers expect? what about system administrators?
- how does play within a managed domain?
- is my component part of a layered product? what's needed there?
We don't expect you to provide the UI, but at least the low level management operations need to be implemented by your team.
Think about the most frequently used operations. We don't need to expose every nitty gritty details of you configuration schema.
It would be really great help, if you could assign somebody to be our point of contact for all questions management related.
Make sure you plan some time early in this iteration so we can work through these issues.
Prepare for change requests and new component releases.
Last but not least, some areas that I believe can be improved:
- security
- clustering
- ejb, jpa, weld
- transactions
- messaging (non JMS)
- infinispan
Thanks for your help,
Ike
12 years, 11 months
Default values in the model
by Brian Stansberry
Emanuel,
Or chat yesterday about the downsides of storing default values in the
in-memory management model got me thinking a bit.
Downsides:
1) The in-memory model no longer represents the user configuration
values; it also stores defaults. This is an issue when marshalling back
to xml; you either have to make the xml verbose by writing back all the
defaults, or you don't write back defaults and lose the fact the user
included the value in the original.
2) Possible versioning issues in a domain where different hosts run
different versions; i.e. if the version on the domain controller host
stores and pushes to servers a default value that a server running an
earlier version doesn't understand. This would really be a bug, since a
change in a default value should spur an increment in the subsystem's
schema and appropriate handling by the parser. But still, storing
defaults increases the chances of this kind of bug cropping up.
Possible solution:
What's been requested previously is that management clients be able to
see the default values, without having to go read the resource
description metadata to find them. That request can be satisfied via the
read-resource and read-attribute handlers. There is no need to store the
default in the model; those handlers can read the resource description
metadata to find the default if the model doesn't have a value stored.
That will slow those handlers down a little bit since the description
has to be generated and read, but those handlers aren't called as part
of our internal operations (e.g. boot) so doing it that way won't slow
down boot, deployment etc.
An issue that doing it this way raises is a client calling read-resource
or read-attribute doesn't know if the returned value is the actual user
config or is a default. A solution to that is to have those operations
accept a new parameter "defaults" which if false does not include the
defaults.
I'm not sure what the best default value for that "default" param would
be. My instinct is "true".
WDYT?
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
12 years, 11 months
deprecate/remove or change ServerEnvironment.getModulesDir() which returns a single File representing the AS7 Modules directory path....
by Scott Marlow
I tried changing the testsuite/pom.xml to allow a hibernate3 test to
supply its own jars in the hibernate3 module (otherwise would be an
empty module), by adding a "testsuite" modules entry to the
module.path.
It looks like OSGi gets confused by multiple entries in
the module path.
module.path =
/home/smarlow/work/as7/testsuite/compat/target/jbossas:/home/smarlow/work/as7/testsuite/compat/../../build/target/jboss-as-7.1.0.Alpha1-SNAPSHOT/modules
server.log http://pastie.org/2278519 that shows what looks like an
OSGI error.
Earlier today on IRC, we discussed whether the modules directory should
be returned from ServerEnvironment. The concern being that the boot
module loader might not be filesystem accessible (returning as a File
instance could be wrong). The other concern is that the module path can
contain multiple paths (separated by native OS file separator).
The suggestion on IRC was for OSGi to use the server home directory
instead (ServerEnvironment.getHomeDir()).
How can/should we solve this? Change the AS7 OSGi integration code to
stop using ServerEnvironment.getModulesDir()? Can we remove the
ServerEnvironment.getModulesDir() or should we deprecate it? If we
deprecate it, perhaps it should return File[] to represent the possible
multiple module directories. Does anyone know of any external caller
into ServerEnvironment.getModulesDir()?
Scott
12 years, 11 months
Subsystem testing harness
by Kabir Khan
There is now a testing harness for testing subsystem parsing, that the operations work, that the model gets updated and services get installed in the service container as expected.
If your subsystem is not totally self contained, the harness provided makes it easy to
* Install services your subsystem depends on manually
* Add socket bindings, paths and system properties used by your subsystem
* Add parsers and other subsystem extensions required by your subsystem
It lives in https://github.com/jbossas/jboss-as/tree/master/subsystem-test and contains some examples/tests of the harness itself in https://github.com/jbossas/jboss-as/tree/master/subsystem-test/src/test.
To see it used in the wild, take a look at https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jbo.... As you can see here it
* checks that the model exists:
https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jbo...
* actually bootstraps the controller and uses the services installed by the JMX service (the jmx connector in this case):
https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jbo...
The JMX subsystem is trivial, but when writing this test I found a few minor bugs. So if you are a subsystem maintainer, I'd highly recommend using this to test your subsystem properly in isolation.
This is based on the stuff that was in the subsystem maven artifact, which now in turn will be based on jboss-as-subsystem-test instead. So, if you find some problems with it try to add to the API rather than changing it, or check with me.
12 years, 12 months
