Fwd: Camel 2.14-SNAPSHOT / JMX / JAXB / Classloading
by Markus Eisele
Hi all,
I've been playing around with latest Camel 2.14 which introduces a new
metrics-component. The information get exposed via JMX/XML.
They use JAXB and bootstrapping Camel in a war on latest WildFly 8.1
(I used this a base: https://github.com/myfear/CamelEE7).
If you use JConsole or hawtio+jolokia to access the relevant mbeans
you get the following exception:
NoClassDefFoundError: Could not initialize class
com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl
Root cause is this:
public static JAXBContext createJaxbContext() throws JAXBException {
// must use classloader from CamelContext to have JAXB working
return JAXBContext.newInstance(Constants.JAXB_CONTEXT_PACKAGES,
CamelContext.class.getClassLoader());
}
(https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/...)
Full stack: https://gist.github.com/myfear/7d95388bb22e313e5f4b
Google lead me to some results about AS7 .. nothing worked so far. I tried:
1) MANIFEST.MF (expot services com.sun.xml.bind)
2) jboss-deployment-structure.xml <module name="com.sun.xml.bind"
services="export" />
3) packaging JAXB 2.2.6 in the war
WildFly is the only server with those issues. It works on plain
servlet containers like Tomcat and jetty.
Any hints highly appreciated
Thanks,
Markus
10 years, 3 months
Resolve your JIRAs
by Brian Stansberry
Please resolve your JIRAs in "Pull Request Sent" state once the pull
request is merged.
Use Workflow -> Pull Request Closed to move the issue to Resolved state.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
10 years, 4 months
No more metadata main?
by Stan Silvert
The org.jboss.metadata main module has gone away in WildFly 9. This
used to include all the jboss metadata resources but has now been broken up.
However, this breaks the Keycloak subsystem and any other module that
used to reference it as a dependency. Should we restore this module
for backward compatibility?
Stan
10 years, 4 months
Console and feature packs
by Stuart Douglas
Hi everyone,
Now that we have the initial feature pack and provisioning stuff working
I have been thinking a bit about what we should do with the console. I
think it makes the most sense to just have the console as a separate
feature pack, as this gives us the maximum amount of flexibility. In
particular this will make it easy to provision Wildfly-core and
Wildfly-web instances with or without the console as required.
Assuming we go down this route this gives us a few options as to where
this should live:
- Wildfly Core repo - This would not be part of a standard core build,
but would just build another feature pack with only the console (like
this:
https://github.com/stuartwdouglas/wildfly-core/compare/console-feature-pack).
- Its own repo - We could create a new repo just for this, but it seems
like overkill.
- The console project - This would mean that the feature pack would then
be versioned using the same scheme as the console, every time the
console was released the feature pack should be ready immediately.
- Somewhere else - The full WF distro, or the upcoming wildfly-web repo
for instance.
For what it is worth I think that it would make the most sense for this
to live in the console project, as this gives us the maximum flexibility.
Stuart
10 years, 4 months
Wildfly provisioning tools and packaging format
by Stuart Douglas
Hi all,
So now that the core split has happened, I want to start work on the new
tooling for creating Wildfly feature packs.
At the moment the build is using a simple maven plugin that I created,
that will take an existing server (e.g. the core server), layer some
extra modules over the top of it, build the config files, and perform
any other build tasks that are required. It can also turn a 'thin'
server into a traditional fat server.
This is going to change to having two separate tools, the build tool and
the provisioning tool. The build tool will be used to create Wildfly
feature packs. A feature pack is kinda similar to what is already
produced, but with some major differences:
- It does not contain the contents of any feature packs it was built on.
For example at the moment the results of web-build also contains the
server core. The web-build feature pack will only contain modules
provided by the web-build pack.
- It is not a server, in that it cannot just be unzipped and ran, the
provisioning tool must be used first to create a runnable server from a
set of feature packs.
Once the build tool has created the feature packs, it is then up to the
provisioning tool to use them to assemble a working server. The
provision tool will be written as a library, with multiple front ends.
At the very least we will provide a standalone version and a maven plugin.
The provisioning tool takes a server descriptor, and uses that to
download all the relevant feature packs and assemble them into a server.
This process will give the user a lot of flexibility over how the server
is configured, including:
- The ability to specify only the subsystems they are after, and a cut
down subsystem with just these subsystems and their dependents will be
installed.
- The ability to override versions, e.g. to provision a server with an
updated version of Resteasy.
- The ability to install deployments into the server by specifying the
deployments GAV.
- The ability to customise the default config (not sure how this will
work yet. A yuck solution would be xslt, but no one likes that. A nicer
solution could be some kind of CLI script that is run on first boot).
This provisioning tool will also be used to build our server for our
traditional distribution and test suite. Basically as part of the build
process the maven plugin will be run to provision a server from the
constituent feature packs.
The feature pack layout will look like below:
------
versions.properties
wildfly-pack.xml
modules/
com/acme/mymodule
module.xml
...
repository (optional)
com/acme/myartifact/my-artifact.jar
...
configuration
standalone.xml
standalone-full.xml
domain.xml
...
content
bin/README.txt
bin/LICENSE.txt
...
------
The contents of these files and directories is as follows:
versions.properties - properties file with the format G:A(:C)=V, e.g.
org.jboss.resteasy:resteasy-jaxrs=3.0.0.Final
wildfly-pack.xml - This contains all additional pack metadata:
pack name: The name of the feature pack, must not contain spaces
pack description: Self explanatory
packaging version: This is inferred from the schema
required tool version: The minimum version of the provisioning tool
that is required to handle this pack
permissions: A section to set unix file permissions
version overrides: A section that allows for specific overrides of
versions in the base system
dependencies: Information on the feature packs this pack depends on
modules:
Similar to the modules dir we have today, with some exceptions:
- only artifact references are used, and these artifacts just refer to
group and artifact, without the version number. See the modules.xml
files in the current build for an example.
repository:
Contains maven artifacts in the maven repository layout. This allows
for the creation of 'offline' feature packs, where the pack
does not need access to an external maven repository. This is not
required, and in most cases will not be used.
I am not 100% sure if we actually want this.
configuration:
contains configuration template files, e.g. standalone.xml template
content:
anything in this directory will be copied directly into the server
Comments? It is expected that work will be started on this tooling very
shortly to replace the current build plugin. I am going to create a
wildfly-build-tools repository to hold these new plugins.
Stuart
10 years, 4 months
