IRC transcript of #jboss-as7?
by Dimitris Andreadis
Can we setup an automatic way to record & publish daily (email to this mailing list) the IRC
transcript from #jboss-as7?
We need to be able to accommodate people that can't participate synchronously in the
development of JBoss AS.
/Dimitris
14 years
Detyped and REST configuration API
by Brian Stansberry
Apologies in advance for the long message. I want to kick off a
discussion of the detyped and REST API for domain/host/server
configuration. Much of the following will end up in a wiki, but I wanted
some initial discussion first.
Goals:
A "detyped" Java version of the configuration API. Detyped in the sense
that the entire model can be represented using a few general usage
classes on the client classpath,
a la the jboss-meta project used in AS 5/6.
A REST version of the API. Even less strongly typed, since in the end
clients will fundamentally be consuming the model as text (xml or json).
Concepts:
"Addressable" Model Elements
An "addressable" model element is one that can be uniquely identified
within it's overall model.
It either:
** is the only element of its type under its parent element (i.e.
maxOccurs=1 in its schema)
** or has a single attribute whose value is unique among all elements of
its type under it's parent element
and it is either
** the child of an addressable model element
** or is the root element of the model
An addressable model element can easily be treated as a resource in a
REST interface. A particular element can be represented in a URL path
either via its element name or via a simple combination of its element
name and the single attribute value.
It's also easy to create a simple java object to represent the element's
address for use in the "detyped" Java API. For a draft see:
https://github.com/bstansberry/jboss-as/commit/36763f82e6d82631370adcc154...
https://github.com/bstansberry/jboss-as/commit/36763f82e6d82631370adcc154...
We should strive to have the vast majority of elements in the
domain/host/server models be addressable. This makes it easy to have
highly targeted updates; e.g. a REST PUT can specify the values for a
few attributes in a single element rather than needing to describe a
large portion of the model. So far we have largely met this goal.
Updates via differencing:
A model update consists of a client sending a detyped representation of
a part of the model. The update will include all of that portion of the
model; both modified and unmodified properties. The server compares that
detyped representation to the current state of the model and generates
the AbstractModelUpdate objects needed to bring the model up to the
desired state.
See the DetypedModelElement class for a draft detyped representation of
an addressable model element:
https://github.com/bstansberry/jboss-as/commit/36763f82e6d82631370adcc154...
At this point I used the CompositeValue class from AS 5/6 jboss-meta
library for representing the element's properties. That's certainly open
for discussion.
"Id-Only" Elements
The detyped representation of a part or all of the model can include
"id-only" elements. These represent addressable elements but only
include the information necessary to determine the element address, plus
a flag indicating the element is "id-only". These serve as placeholders
within a representation of a larger portion of the model. The purpose of
an id-only element is to allow the client to avoid dealing with
uninteresting portions of the model state, while still being aware of
their existence. They also allow the server to distinguish an update
that removes an element from one that doesn't modify it at all, without
forcing the client to send the entire state of the unmodified element.
How useful this "id-only" concept will be, I'm not sure. The main use
cases I can see are, for reads, being able to read a client-specified
number of levels of the model without having to consume the whole thing
(imagine a huge domain). For writes the main use case would be an update
that touches a few parts of the model (e.g. add an extension, the
subsystem config for it, a new thread pool for it, a new socket binding
for it) without having to specify all the unrelated stuff in between.
Issues:
Meta-information about Configuration Elements:
Where should this be stored? Basic things like the primitive types of
various properties, plus more complex things like whether changing a
property requires a restart to take effect. The "detyped" Java version
can include a fair amount of meta-information, but this isn't readily
available via REST. Much of this information also can be (and is) stored
in the domain model schemas themselves, but this forces clients to
access and interpret the schemas to obtain the information. Putting
things like whether a property requires restart to take effect in the
various domain model schemas would also create a tighter coupling
between the schemas; i.e. they should all use the same mechanism to
indicate this, which would imply some common included schema that
defines that mechanism.
Obtaining a DetypedModelElement
This seems fairly straightforward. Any AbstractModelElement that is
addressable should be able to expose its state as a DetypedModelElement.
See AbstractAddressableModelElement for an rough implementation of that:
https://github.com/bstansberry/jboss-as/commit/36763f82e6d82631370adcc154...
Determining differences and generating AbstractModelUpdate objects
If the client passes back a DetypedModelElement to the domain
controller, we need logic to determine the difference between that
detyped representation and the current model and then generate the
needed update objects. A possibility is to have each
AbstractAddressableModelElement be responsible for doing that. A problem
I've seen with that is the class hierarchy for the update classes versus
the model element classes is not clean.
For example, a method like this in AbstractAddressableModelElement won't
work:
protected abstract void addUpdatesToMatchView(DetypedModelElement
updatedView, List<AbstractModelElementUpdate<?>> updates);
It won't work because not all model elements are updated via
AbstractModelElementUpdate; some are done via AbstractDomainModelUpdate,
some via AbstractHostModelUpdate etc.
Marshalling to from XML/JSON
The REST API requires the ability to marshall to/from whatever XML and
JSON formats we use for exchanging data with clients. JSON of course is
going to be different from anything we have right now. We need to think
about the XML format. We could just provide and receive snippets that
follow the same schema we use in the domain/host/standalone.xml
documents themselves. However, there are problems with that. The
"id-only" notion described above is not part of those schemas. Any Atom
links we include in response documents (see Chapter 9 in Bill Burke's
RESTful Java book) will violate the schema as well. As will any metadata
we decide to include. We may be better off with a more generic
representation that more directly maps to something like
DetypedModelElement.
Any and all comments on this are appreciated.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
14 years
Embedded and split packages between modules and sun.boot.class.path
by Kabir Khan
I've got most of our demos ported across to use Arquillian, but came across a problem when running the ds example embedded:
org.jboss.util.NestedSQLException: Error checking for a transaction.; - nested throwable: (java.lang.reflect.UndeclaredThrowableException); - nested throwable: (org.jboss.jca.common.JBossResourceException: Error checking for a transaction.; - nested throwable: (java.lang.reflect.UndeclaredThrowableException))
at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:115)
at org.jboss.as.test.demos.ds.DsTestCase.testDatasource(DsTestCase.java:61)
Arquillian in container
...
Caused by: org.jboss.jca.common.JBossResourceException: Error checking for a transaction.; - nested throwable: (java.lang.reflect.UndeclaredThrowableException)
at org.jboss.jca.common.JBossResourceException.rethrowAsResourceException(JBossResourceException.java:60)
at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:363)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:428)
at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:109)
... 81 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at org.jboss.jca.common.JBossResourceException.process(JBossResourceException.java:216)
at org.jboss.jca.common.JBossResourceException.<init>(JBossResourceException.java:112)
... 85 more
Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of org/jboss/modules/ModuleClassLoader) previously initiated loading for a different type with name "javax/transaction/TransactionManager"
at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:350)
... 83 more
This does not occur when running it normally using demos against a normal standalone instance.
In embedded on startup javax.transaction.TransactionManager gets loaded twice on startup
1) module:org.jboss.jts:main
2) org.jboss.jts.integration:main
In both these cases the defining classloader is the system classloader.
Then when running the deployed example it gets loaded using module:org.jboss.ironjacamar.impl:main which in turn gets the class from module:javax.transaction.api:main which has its own resource loader.
When starting up a normal standalone instance, in all cases the defining classloader is the javax.transaction.api module classloader. In both embedded and standalone scenarios, loading this class from the javax.transaction.api module gets two resource loaders. The SystemLocalLoader, and a module local loader for javax.transaction.api. The javax/transaction path is added to SystemLocalLoader since the JDK includes a few classes there (InvalidTransactionException, TransactionRequiredException, TransactionRolledbackException), so it is added from -Dsun.boot.class.path.
-In the standalone case the SystemLocalLoader is not able to load the TM class since it was never on the system classpath, so it loads it from the module loader.
-In the embedded case the SystemLocalLoader is able to load the TM class since it is on the app classpath, so the module loader never gets hit.
Before initializing modules -Djava.class.path is set to null, and org.jboss.modules and org.jboss.logging is added to Module.systemPackages.
I have patched jboss-modules to create a filter for this case here: https://github.com/kabir/jboss-modules/tree/Beta11-patch-filter but David might have a better idea?
If I start the embedded server with this snapshot and the following system properties, the ds testcase works fine
SecurityActions.setSystemProperty("module.include.path", "javax/transaction/InvalidTransactionException,javax/transaction/TransactionRequiredException,javax/transaction/TransactionRolledbackException");
SecurityActions.setSystemProperty("module.exclude.path", "javax/transaction/**");
This fix is only required for embedded, and will not have any effect during runtime of the standalone server (apart from an extra == null check).
A simpler way to configure this might be to just specify the names of filtered packages, e.g.
-Dmodule.filtered.paths=javax.transaction,javax.transaction.xa
and then let the SystemLocalLoader intialization internally build up the excludes/includes depending on what it finds on
the bootstrap path, so the module.filtered.paths becomes the following filter
{
excludes={javax/transaction,javax/transaction/},
includes={javax/transaction/InvalidTransactionException,javax/transaction/TransactionRequiredException,javax/transaction/TransactionRolledbackException}
}
Apart from these packages split between sun.boot.class.path and the modules classpath, embedded modules is exactly the same as standalone modules.
Cheers,
Kabir
14 years
Fwd: Re: OSGi subsystem dependencies
by David Bosschaert
Forwarding an response from Thomas that doesn't seem to have made it to
the mailing list...
David
-------- Original Message --------
Subject: Re: [jboss-as7-dev] OSGi subsystem dependencies
Date: Tue, 30 Nov 2010 09:42:56 +0100
From: Thomas Diesler <thomas.diesler(a)jboss.com>
To: Jason T. Greene <jason.greene(a)redhat.com>
CC: jboss-as7-dev(a)lists.jboss.org <jboss-as7-dev(a)lists.jboss.org>
> In addition we already have a module dependency from
> domain to osgi.
This is a bug.
Fixed in
https://github.com/jbosgi/jboss-as/commit/c68e62ec2662ecb6253c03eabc98ef7...
----
IMHO it boils down to what you choose as the promoted service
integration layer. As it is with most AS7 subsystems today they
integrate via jboss-msc services. For system integration this is a
direct and efficient approach. For user deployments however, the uptake
of this is questionable. More likely we want to promote the integration
via standard OSGi services. I take the benefit of using an open standard
is generally accepted so I won't go into that much more.
With respect to the (standard OSGi) Tx and JNDI services I said
"The OSGi subsystem provides the OSGi service registry. Subsystem
Foo may choose to publish a service in that registry which would
then readily be available for installed bundles to use. The OSGi
subsystem does not need to know about Foo."
http://community.jboss.org/thread/158822
So if the OSGi service registry is the standard view of the MSC service
registry, It should readily be available whenever you want to publish a
service in a standard way.
From my perspective #2 would be a bad choice for the same reason that
you want to keep the MSC service registry generic (i.e. it does not know
about any specific service)
The current implementation uses #1 because I believe the OSGi service
registry should indeed be available to all subsystems that wish to
publish services that can be used by user deployments. As an alternative
I'd think #3 is reasonable. Every subsystem provides an OSGi bundle that
makes the respective subsystem services available in the OSGi service
registry.
For simplicity reasons, I thought the abstraction in separate Service
classes is "good enough" and we won't need an additional mvn module. In
reality, the folks that maintain MSC service Foo would also provide the
OSGi Foo service. Hence, one mvn module.
cheers
-thomas
On 11/29/2010 07:07 PM, Jason T. Greene wrote:
> This was talked about briefly on the pull request list, but no
> resolution was made.
>
> The issue is that JBAS-8585 and JBAS-8599 both add module dependencies
> from some of the core subsystems on to the osgi subsystem (naming and
> transactions). In addition we already have a module dependency from
> domain to osgi. So for all intents and purposes, we are moving towards
> AS7 having osgi as a required base level component. Before progressing
> much further in this direction we should evaluate whether this is the
> right thing to do, and how this solution compares to alternative
> approaches. I can think of three approaches right off the bat.
>
> 1. Continue as is, osgi is a core required component
> Pros: OSGi subsystem module is simpler, no additional subsystems or
> modules needed
> Cons: AS7 must always have OSGi binaries no matter the configuration
>
> 2. Change the osgi subsystem to use optional dependencies on all of the
> subsystems it maps.
> Pros: No additional subsystems are needed
> AS7 no longer requires OSGi binaries
> Cons: osgi subsystem code will need to do a lot of conditional
> checking for handling different subsystems being available
>
> 3. Create an osgi subsystem per subsystem it wraps (e.g. osgi-naming,
> osgi-transactions, etc)
> Pros: OSGi subsystem code is simpler
> AS7 no longer requires OSGi binaries
> Cons: More subsystems are introduced, almost one per functional
> subsystem.
>
> Let the debate begin :)
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years
Re: [jboss-as7-dev] OSGi subsystem dependencies
by Jason T. Greene
On 11/30/10 2:42 AM, Thomas Diesler wrote:
> > In addition we already have a module dependency from
> > domain to osgi.
>
> This is a bug.
> Fixed in
> https://github.com/jbosgi/jboss-as/commit/c68e62ec2662ecb6253c03eabc98ef7...
>
> ----
>
> IMHO it boils down to what you choose as the promoted service
> integration layer. As it is with most AS7 subsystems today they
> integrate via jboss-msc services. For system integration this is a
> direct and efficient approach. For user deployments however, the uptake
> of this is questionable. More likely we want to promote the integration
> via standard OSGi services. I take the benefit of using an open standard
> is generally accepted so I won't go into that much more.
If you mean extending the AS, as in what we ourselves do, or what an ISV
would do, I would expect they would be using our API/SPIs, that way they
get the maximum capabilities. Those developing against an OSGi runtime,
will of course prefer keeping it that way and relying on our OSGi
support. EE deployments though should have options. They can either use
our technologies, or they can intermix OSGi. Ultimately it's a question
of using the best tool for the job at hand. Although, in most cases I
suspect EE standard technologies (like CDI, or EJB singletons) will win
out over using MSC *OR* OSGi. Class-loading is a different story though,
and it's something that's traditionally always been a vendor defined thing.
Although that while supporting OSGi is a good thing, we shouldn't overly
constrain ourselves to it. Especially considering that Java 8 will be
directly competing with it.
>
> With respect to the (standard OSGi) Tx and JNDI services I said
>
> "The OSGi subsystem provides the OSGi service registry. Subsystem
> Foo may choose to publish a service in that registry which would
> then readily be available for installed bundles to use. The OSGi
> subsystem does not need to know about Foo."
>
> http://community.jboss.org/thread/158822
>
> So if the OSGi service registry is the standard view of the MSC service
> registry, It should readily be available whenever you want to publish a
> service in a standard way.
>
>
> From my perspective #2 would be a bad choice for the same reason that
> you want to keep the MSC service registry generic (i.e. it does not know
> about any specific service)
I can see your point here. By the same argument it would prevent a
trimmed AS using just osgi, something that would likely be valuable to some.
>
> The current implementation uses #1 because I believe the OSGi service
> registry should indeed be available to all subsystems that wish to
> publish services that can be used by user deployments. As an alternative
> I'd think #3 is reasonable. Every subsystem provides an OSGi bundle that
> makes the respective subsystem services available in the OSGi service
> registry.
We could also do a hybrid approach that was suggested before, like
having a few bundle groups for commonly combined services (e.g. EE web
profile stuff, which by spec is already intermingled), but essentially
keeping the osgi module "pure".
> For simplicity reasons, I thought the abstraction in separate Service
> classes is "good enough" and we won't need an additional mvn module. In
> reality, the folks that maintain MSC service Foo would also provide the
> OSGi Foo service. Hence, one mvn module.
Sure, that certainly was the simplest to develop.
--
Jason T. Greene
JBoss, a division of Red Hat
14 years
