WFLYCTL0218: A node is already registered at '/deployment=*/subsystem=datasources/xa-data-source=*/statistics=jdbc'
by Frank Langelage
I have a Deja-Vu, I'm very I saw this some months ago. Not it reappears.
Possibly due to the commit #7605 with changes for "WFLY-4429 Refactor
JCA subsystem".
26.06. 00:25:37,390 INFO
[org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer#deployXADataSource]
IJ020018: Enabling <validate-on-match> for
java:jboss/datasources/maj2e-langfr-dev
26.06. 00:25:37,445 INFO
[org.jboss.as.connector.subsystems.datasources#transition] WFLYJCA0001:
Bound data source [java:jboss/datasources/DefaultDS]
26.06. 00:25:37,501 INFO
[org.jboss.as.connector.deployers.RaXmlDeployer#createObjectsAndInjectValue]
IJ020018: Enabling <validate-on-match> for
java:/eis/maj2e-langfr-dev/ControllerConnector
26.06. 00:25:37,509 INFO
[org.jboss.as.connector.deployment#bindConnectionFactory] WFLYJCA0007:
Registered connection factory java:/eis/maj2e-langfr-dev/ControllerConnector
26.06. 00:25:37,514 INFO
[org.jboss.as.connector.deployers.RaXmlDeployer#createObjectsAndInjectValue]
IJ020002: Deployed:
file:/mbi/tools/jboss/10.0/standalone/tmp/vfs/temp/temp91b455ac091637f0/content-9d63fac1b393fd1c/contents/
26.06. 00:25:37,801 INFO
[org.jboss.as.connector.subsystems.datasources#transition] WFLYJCA0001:
Bound data source [java:jboss/datasources/maj2e-langfr-dev]
26.06. 00:25:37,990 ERROR [org.jboss.msc.service.fail#startFailed]
MSC000001: Failed to start service
jboss.data-source.java:jboss/datasources/maj2e-langfr-dev.statistics:
org.jboss.msc.service.StartException in service
jboss.data-source.java:jboss/datasources/maj2e-langfr-dev.statistics:
Failed to start service
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalArgumentException: WFLYCTL0218: A node is
already registered at
'/deployment=*/subsystem=datasources/xa-data-source=*/statistics=jdbc'
at
org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:147)
at
org.jboss.as.connector.services.datasources.statistics.DataSourceStatisticsService.start(DataSourceStatisticsService.java:83)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
... 3 more
9 years, 5 months
Capability naming conventions
by Brian Stansberry
The capability and requirement stuff[1] is far enough along that real
usage is happening, so actual capability names are being created.[2] I
wanted to get some input regarding naming conventions for capability
names so it doesn't devovle into chaos, and so I don't end up making up
a lot of names people hate.
The key thing is capabilities need to be namespaced to avoid collisions
between capability creators. Beyond that the names should be "good",
whatever that means (user friendly, properly targeted, not overly tied
to implementation, etc).
My initial thinking on this was:
1) The WildFly family projects own the "org.wildfly" namespace. So all
capabilities we create fit in that namespace, and no one else puts
things there. This I think is a must.
2) Capabilities not used by or provided by the WildFly kernel go in
subspace org.wildfly.extension.<name_of_extension>. Idea there was just
to avoid naming collisions between different extensions.
I don't think 2) is such a great idea any more. A given capability be
provided by more than one extension, so there isn't a clean conceptual
mapping. And the word "extension" is really an implementation detail.
So, I'm inclined to drop the "extension" bit.
Any thoughts on this, or other aspects of how to name capabilities?
FYI, see [3] for some names of capabilities that will be used by the kernel.
[1] The "Runtime" aspect of https://developer.jboss.org/docs/DOC-52712
[2] https://github.com/wildfly/wildfly/pull/7596
[3] https://developer.jboss.org/docs/DOC-53383
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
9 years, 5 months
Early Access builds for JDK 8u60 b21 and JDK 9 b70 are available on java.net
by Rory O'Donnell
Hi Jason/Tomaz,
Early Access build for JDK 8u60 b21 <http://jdk8.java.net/download.html>
is available on java.net, summary of changes are listed here.
<http://www.java.net/download/jdk8u60/changes/jdk8u60-b21.html>
As we enter the later phases of development for JDK 8u60, please log any
show stoppers as soon as possible.
Early Access build for JDK 9 b70 <https://jdk9.java.net/download/> is
available on java.net, summary of changes are listed here
<http://www.java.net/download/jdk9/changes/jdk9-b70.html>.
The JDK 9 schedule of record is available on the JDK 9 Project page:
http://openjdk.java.net/projects/jdk9
At https://wiki.openjdk.java.net/display/Adoption/JDK+9+Outreach you can
find a (preliminary) list of other
changes that might affect your project's code in JDK 9, and other things
to consider when testing with JDK 9.
I'd be curious to know if there is anything on that list you'd consider
to have an effect on your project.
Please keep in mind that as JEPs and others changes are integrated into
(or out of) JDK 9, the list will change
over time.
Rgds,Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
9 years, 5 months
Wildfly 9 BOM changes
by Thomas Segismont
Hi everyone,
While working on upgrading Hawkular to Wildfly 9 CR2, we have noticed
that the Wildfly BOM now declares provided scope for some dependencies.
I guess the goal is to help users which forget to set the provided scope
in their POM to end up with all the libraries in their WAR.
On the other hand, if you use some libraries in your tests, then
dependency resolution can be broken. For example, if you add
org.jboss.resteasy::resteasy-client in test scope, your tests fail due
to a missing class from commons-io, because commons-io should be
resolved as a transitive dependency of
org.jboss.resteasy::resteasy-jaxrs, but it's now in scope provided,
instead of test.
Have you considered this use case? Are there other motivations than
helping Maven beginners?
Best regards,
Thomas
9 years, 5 months
Discarding the changed management model during operation rollback
by Brian Stansberry
tl;dr;
When an operation that has changed the management model is rolling back,
the OperationStepHandlers processing the rollback see the model as it
was at the arbitrary point when the rollback began. I propose changing
this so they see things as they were prior to the first change to the model.
Long version:
When an operation mutates either the management Resource tree, or the
registry of capabilities (together known as the management model), we
clone the management model and thereafter that operation works on the
clone. The clone is invisible to other callers until the operations
successfully commits. When the operation commits, it publishes the clone
and that becomes the official model.
I call this copy-on-write, publish-on-commit.
If the operation rolls back, the changed model is never published and
the clone is just discarded when the operation execution returns.
However, while the operation is rolling back, all the
OperationStepHandlers that are processing the rollback see the modified
clone, not the original model. They are seeing arbitrarily incorrect data.
This hasn't been a problem up to now, as our standard OSHs get a copy of
whatever part of the Resource tree they are going to modify and keep it
for use in rollback. They don't need to re-read the management model to
perform rollback.
But this doesn't work for the capability registry. If an OSH removes a
capability and removes a service, and then in rollback tries to use the
capability to figure out how to restore the service, it fails, as
management model it can see still shows the capability as being removed.
To fix this, I propose discarding the cloned management model as soon as
rollback begins. Thereafter, an OSH processing rollback will see the
model as it was before the first modification. The removed capability
will still be present.
I have a commit that does this at [1]. Running the testsuite with it
shows no regressions. This doesn't surprise me, as our standard OSHs up
to now have had no need to re-read the model during rollback.
[1]
https://github.com/bstansberry/wildfly-core/commit/419f350931d5b7e345cf9a...
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
9 years, 5 months
Capabilit integration from services and DeploymentUnitProcessors
by Brian Stansberry
tl;dr; DUPs may need access to the integration APIs provided by
capabilities. I've got a first cut solution to that, but there are edge
cases that don't work well and we may need to restrict how capabilities
work a bit.
Long version.
WildFly Core capabilities are meant to provide a standardized way for
parts of the server to integrate with each other.[1]
Use of these is proceeding pretty nicely in the OperationStepHandlers
the kernel and subsystems use for executing management operations. But
in some cases, the code that needs to integrate with a capability isn't
in an OSH. It can be in a service start method, particularly in a
DeploymentUnitProcessor. (DUPs run in a service start method.)
A simple example would be a deployment descriptor or annotation includes
a chunk of config that specifies the use of a subsystem-provided
resource, say a cache. The DUP then wants to figure out the service name
of that resource, using capabilities.
So I've started to give some thought to how to handle that. See
https://github.com/bstansberry/wildfly-core/commit/ba7321bc30374b2d0aa99c...
for a first cut.
Basically the OperationContext exposes a "CapabilityServiceSupport"
object that OSHs can provide to services they install. The services can
then use that to look up service names and any custom runtime API
provided by a capability.
Typical pattern would be the OSH for a "deploy" op would make the
CapabilityServiceSupport available to RootDeploymentUnitService, which
would expose it to DUPs via a DeploymentPhaseContext attachment. DUPs,
as they install services would use the CapabilityServiceSupport to look
up service names and add dependencies to that new service.
The service doesn't register any requirement for the capability. If it
tries to use a non-existent capability, an exception is thrown and the
service has to deal with it. *This is the main problem.* The caller is
unable to register a dependency (since it can't get the service name) so
the MSC behavior of letting the service be installed but fail to start
due to a missing dependency is short circuited.
In most cases, if a service is installed but fails to start due to a
missing dependency, the management op that installed it is rolled back,
so the end result is the same. But we do support the
"rollback-on-runtime-failure=false" management op header, and if that's
used our behavior would be changed for the worse.
A possible partial solution to this would be to tighten down the rules
for how service names are created from capability names. Basically, any
capability could only provide 1 service, and the name of the service
would be the result of passing the name of the capability to
ServiceName.parse(name). That's the default behavior now, but we support
other options.
That would fix the service name discovery problem, by making the name
discovery algorithm completely static. It wouldn't help with a case
where a DUP needs access to a custom runtime API exposed by a
capability. But that is much more of a corner case. Probably better to
discuss on a sub branch of this thread. :)
What would we lose if we tightened down the service name rules?
1) Capabilities would not be able to tell the service name discovery
logic to produce some legacy service naming pattern (i.e. keep service
names as they were in earlier releases.)
This one I don't think is a big deal, as the capability can always
register an alias for the service that uses the legacy service name.
2) A capability cannot provide services of > 1 value type. It's nice if
capabilities can represent something that's meaningful to an end user,
and there's no reason why something that's meaningful to an end user
might not expose more than one service to other capabilities. If we
limit capabilities to exposing a single service, then we may end up with
multiple capabilities. See [2] for an example case, where a proposed
"org.wildfly.iiop" (nice and simple for an end user to understand)
installs two services, an ORB and a NamingContextExt.
At this point though, capability names aren't really exposed to end
users, so perhaps we can put this problem aside for now. If it becomes
an issue later, there are solutions, e.g. a user-friendly
"org.wildfly.iiop" capability automatically registers the detailed
"org.wildfly.iiop.orb" and "org.wildfly.iiop.naming" capabilities,
helping the user ignore the details.
Sorry for the long tome; by now I expect folks are used to it!
[1] Specifically, to validate that references to other parts of the
configuration are valid, to determine the names of MSC services provided
by other parts of the system, and to access any custom runtime
integration API exposed by another part of the system.
[2]
https://github.com/bstansberry/wildfly/commit/b9de64e046404531df466288cf4...
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
9 years, 5 months
