Re: [wildfly-dev] WildFly domain on OpenShift Origin
by Thomas Diesler
/reducing the cc noise
Yes, I was hoping to hear that this has already been thought about.
Is there a design document for this JMX aggregation?
What are the possible target environments and functional requirements?
Would this be reusable in a plain WildFly domain?
cheers
—thomas
> On 17 Dec 2014, at 10:35, Rob Davies <rdavies(a)redhat.com> wrote:
>
> Hi Thomas,
>
> it would be great to see this as an example quickstart in fabric8 - then you could pick up the jmx aggregation etc for free :)
>
>> Thomas Diesler <mailto:tdiesler@redhat.com> 17 December 2014 09:28
>> Folks,
>>
>> following up on this topic, I worked a little more on WildFly-Camel in Kubernetes/OpenShift.
>>
>> These doc pages are targeted for the upcoming 2.1.0 release (01-Feb-2015)
>>
>> WildFly-Camel on Docker <https://github.com/wildfly-extras/wildfly-camel-book/blob/2.1/cloud/docke...>
>> WildFly-Camel on OpenShift <https://github.com/wildfly-extras/wildfly-camel-book/blob/2.1/cloud/opens...>
>>
>> The setup looks like this
>>
>>
>>
>> We can now manage these individual wildfly nodes. The domain controller (DC) is replicated once, the host definition is replicated three times.
>> Theoretically, this means that there is no single point of failure with the domain controller any more - kube would respawn the DC on failure
>>
>> Here some ideas for improvement …
>>
>> In a kube env we should be able to swap out containers based on some criteria. It should be possible to define these criteria, emit events based on them create/remove/replace containers automatically.
>> Additionally a human should be able to make qualified decisions through a console and create/remove/replace containers easily.
>> Much of the needed information is in jmx. Heiko told me that there is a project that can push events to influx db - something to look at.
>>
>> If information display contained in jmx in a console has value (e.g in hawtio) that information must be aggregated and visible for each node.
>> Currently, we have a round robin service on 8080 which would show a different hawtio instance on every request - this is nonsense.
>>
>> I can see a number of high level items:
>>
>> #1 a thing that aggregates jmx content - possibly multiple MBeanServers in the DC VM that delegate to respective MBeanServers on other hosts, so that a management client can pickup the info from one service
>> #2 look at the existing inluxdb thing and research into how to automate the replacement of containers
>> #3 from the usability perspective, there may need to be an openshift profile in the console(s) because some operations may not make sense in that env
>>
>> cheers
>> —thomas
>>
>> PS: looking forward to an exiting ride in 2015
>>
>> <image.jpg>
>>
>>
>> Thomas Diesler <mailto:tdiesler@redhat.com> 5 December 2014 13:36
>> Folks,
>>
>> I’ve recently been looking at WildFly container deployments on OpenShift V3. The following setup is documented here <https://github.com/wildfly-extras/wildfly-camel-book/blob/2.1/cloud/fabri...>
>>
>> This approach comes with a number of benefits, which are sufficiently explained in various OpenShift <https://blog.openshift.com/openshift-v3-platform-combines-docker-kubernet...>, Kubernetes <https://github.com/GoogleCloudPlatform/kubernetes/blob/master/README.md> and Docker <https://docs.docker.com/> materials, but also with a number of challenges. Lets look at those in more detail …
>>
>> In the example above Kubernetes replicates a number of standalone containers and isolates them in a Pod each with limited access from the outside world.
>>
>> * The management interfaces are not accessible
>> * The management consoles are not visible
>>
>> With WildFly-Camel we have a Hawt.io <http://wildflyext.gitbooks.io/wildfly-camel/content/features/hawtio.html> console that allows us to manage Camel Routes configured or deployed to the WildFly runtime.
>> The WildFly console manages aspects of the appserver.
>>
>> In a more general sense, I was wondering how the WildFly domain model maps to the Kubernetes runtime environment and how these server instances are managed and information about them relayed back to the sysadmin
>>
>> a) Should these individual wildfly instances somehow be connected to each other (i.e. notion of domain)?
>> b) How would an HA singleton service work?
>> c) What level of management should be exposed to the outside?
>> d) Should it be possible to modify runtime behaviour of these servers (i.e. write access to config)?
>> e) Should deployment be supported at all?
>> f) How can a server be detected that has gone bad?
>> g) Should logs be aggregated?
>> h) Should there be a common management view (i.e. console) for these servers?
>> i) etc …
>>
>> Are these concerns already being addressed for WildFly?
>>
>> Is there perhaps even an already existing design that I could look at?
>>
>> Can such an effort be connected to the work that is going on in Fabric8?
>>
>> cheers
>> —thomas
>>
>> PS: it would be area that we @ wildfly-camel were interested to work on
>>
9 years, 4 months
Early Access builds for JDK 9 b42, JDK 8 b18 & JDK 7 b03 are available on java.net
by Rory O'Donnell
Hi Jason/Tomaz,
Now that JDK 9 Early Access build images are modular [1], there is a fresh
Early Access build for JDK 9 b42 <https://jdk9.java.net/download/>
available on java.net. The summary of
changes are listed here
<http://www.java.net/download/jdk9/changes/jdk9-b42.html>
In addition, there are new Early Access builds for the ongoing update
releases.
The Early Access build for JDK 8u40 b18
<http://jdk8.java.net/download.html> is available on java.net, with the
summary of changes listed here.
<http://www.java.net/download/jdk8u40/changes/jdk8u40-b18.html>
Finally, the Early Access build for JDK 7u80 b03
<https://jdk7.java.net/download.html>is available on java.net,
with the summary of changes listed here.
<http://download.java.net/jdk7u80/changes/jdk7u80-b03.html>
As we enter the later phases of development for JDK 7u80 & JDK 8u40,
please log any show stoppers as soon as possible.
Rgds,Rory
[1] http://mreinhold.org/blog/jigsaw-modular-images
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
9 years, 4 months
the WildFly 9 org.jboss.metadata.common module is missing javax.persistence...
by Scott Marlow
Some of the WildFly 9 TCK tests are failing because
javax.persistence.api is missing from the org.jboss.metadata.common
module. In WildFly 8.2, we had [1] org.jboss.metadata which had various
javax APIs. In WildFly 9, org.jboss.metadata.ejb has the different
javax APIs but org.jboss.metadata.common [2] does not.
How should this be fixed?
Scott
[1]
https://github.com/wildfly/wildfly/blob/8.x/build/src/main/resources/modu...
<module xmlns="urn:jboss:module:1.3" name="org.jboss.metadata">
<properties>
<property name="jboss.api" value="private"/>
</properties>
<resources>
<!-- Insert resources here -->
</resources>
<dependencies>
<module name="javax.annotation.api"/>
<module name="javax.api"/>
<module name="javax.ejb.api" optional="true"/>
<module name="javax.interceptor.api" optional="true"/>
<module name="javax.jws.api" optional="true"/>
<module name="javax.persistence.api" optional="true"/>
<module name="javax.servlet.api" optional="true"/>
<module name="javax.servlet.jsp.api" optional="true"/>
<module name="javax.xml.bind.api" optional="true"/>
<module name="javax.xml.ws.api" optional="true"/>
<module name="org.jboss.ejb3" optional="true"/>
<module name="org.jboss.staxmapper"/>
<module name="org.jboss.logging"/>
</dependencies>
</module>
[2]
dist/target/wildfly-9.0.0.Alpha2-SNAPSHOT/modules/system/layers/base/org/jboss/metadata/common/main/module.xml
<module xmlns="urn:jboss:module:1.3" name="org.jboss.metadata.common">
<properties>
<property name="jboss.api" value="private"/>
</properties>
<resources>
<resource-root path="jboss-metadata-common-8.1.2.Final.jar"/>
</resources>
<dependencies>
<module name="javax.annotation.api"/>
<module name="javax.api"/>
<module name="org.jboss.staxmapper"/>
<module name="org.jboss.logging"/>
</dependencies>
</module>
9 years, 4 months
Management console web application
by Dev Ops
Hi all,
where do I find the source of the web application which provides the
Management console?
I need to add something to it, but I don't know where to get the source.
TIA,
DevOps guy
9 years, 4 months
WildFly 9 roadmap
by Dev Ops
Hi all,
does anybody know when WildFly 9 will be released, more or less???
TIA,
DevOps guy
9 years, 5 months
Change WebServices subsystem to use PersistentResourceXMLDescription
by Claudio Miranda
Hi, to better understand subsystem api, I am changing the WS subsystem
to use the PersistentResourceXMLDescription, more in line with the
other subsystem api.
There are some wsdl settings, they are xml elements.
<subsystem xmlns="urn:jboss:domain:webservices:2.0">
<modify-wsdl-address>${ws.modify-wsdl-address:true}</modify-wsdl-address>
<wsdl-host>${jboss.bind.address:localhost}</wsdl-host>
<wsdl-port>${ws.wsdl-port:9090}</wsdl-port>
<wsdl-secure-port>${ws.wsdl-secure-port:9443}</wsdl-secure-port>
<wsdl-uri-scheme>https</wsdl-uri-scheme>
<wsdl-path-rewrite-rule>s/jaxws-jbws2150-codefirst/xx\/jaxws-jbws2150-codefirst/g</wsdl-path-rewrite-rule>
What do you think of those settings as attributes ?
<subsystem xmlns="urn:jboss:domain:webservices:2.0">
<wsdl-settings modify-wsdl-address="${ws.modify-wsdl-address:true}"
wsdl-host="${jboss.bind.address:localhost}"
wsdl-port="${ws.wsdl-port:9090}"
wsdl-secure-port="${ws.wsdl-secure-port:9443}"
wsdl-uri-scheme="https"
wsdl-path-rewrite-rule="s/jaxws-jbws2150-codefirst/xx\/jaxws-jbws2150-codefirst/g"/>
Later I can submit it for review if is of interest.
Kind regards
--
Claudio Miranda
claudio(a)claudius.com.br
http://www.claudius.com.br
9 years, 5 months
JDK 9 images are now modular with JDK 9 Early Access build 41
by Rory O'Donnell
Hi Jason/Tomaz,
The initial changesets for JEP 220: Modular Run-Time Images [1] are
available
with JDK 9 early-access build 41 [2].
To summarize (please see the JEP for details):
- The "jre" subdirectory is no longer present in JDK images.
- The user-editable configuration files in the "lib" subdirectory
have been moved to the new "conf" directory.
- The endorsed-standards override mechanism has been removed.
- The extension mechanism has been removed.
- rt.jar, tools.jar, and dt.jar have been removed.
- A new URI scheme for naming stored modules, classes, and resources
has been defined.
- For tools that previously accessed rt.jar directly, a built-in NIO
file-system provider has been defined to provide access to the
class
and resource files within a run-time image.
More details are available at Mark Reinhold's latest blog entry [3]
Rgds, Rory
[1] http://openjdk.java.net/jeps/220
[2] https://jdk9.java.net/download/
[3] http://mreinhold.org/blog/jigsaw-modular-images
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
9 years, 5 months
[INFO] WildFly: Infinispan Subsystem ...................... FAILURE [01:53 min]
by Frank Langelage
Running build with current master sources from github fails for me, if
tests are enabled. Only smoke or more.
See more detail below
Anyone else seeing this problem?
Running org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase
Tests run: 18, Failures: 0, Errors: 2, Skipped: 16, Time elapsed: 17.593
sec <<< FAILURE! - in
org.jboss.as.clustering.infinispan.subsystem.TransformersTestCasetestRejections720(org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase)
Time elapsed: 9.824 sec <<< ERROR!
java.lang.RuntimeException:
org.eclipse.aether.resolution.ArtifactResolutionException: Could not
transfer artifact org.infinispan:infinispan-core:jar:5.3.0.Final from/to
jboss-developer
(http://repository.jboss.org/nexus/content/groups/developer/): Invalid
Content-Range header for partial download: 580752-2662427/2662427
at
org.eclipse.aether.transport.http.HttpTransporter$EntityGetter.handle(HttpTransporter.java:496)
at
org.eclipse.aether.transport.http.HttpTransporter.execute(HttpTransporter.java:286)
at
org.eclipse.aether.transport.http.HttpTransporter.implGet(HttpTransporter.java:235)
at
org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:59)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:447)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:350)
at
org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294)
at
org.jboss.as.model.test.MavenUtil.createMavenGavURL(MavenUtil.java:132)
at
org.jboss.as.model.test.ChildFirstClassLoaderBuilder.addMavenResourceURL(ChildFirstClassLoaderBuilder.java:197)
at
org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.addMavenResourceURL(SubsystemTestDelegate.java:800)
at
org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testRejections(TransformersTestCase.java:356)
at
org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testRejections720(TransformersTestCase.java:291)
testTransformer720(org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase)
Time elapsed: 7.617 sec <<< ERROR!
java.lang.RuntimeException:
org.eclipse.aether.resolution.ArtifactResolutionException: Could not
transfer artifact org.infinispan:infinispan-core:jar:5.3.0.Final from/to
jboss-developer
(http://repository.jboss.org/nexus/content/groups/developer/): Invalid
Content-Range header for partial download: 580752-2662427/2662427
at
org.eclipse.aether.transport.http.HttpTransporter$EntityGetter.handle(HttpTransporter.java:496)
at
org.eclipse.aether.transport.http.HttpTransporter.execute(HttpTransporter.java:286)
at
org.eclipse.aether.transport.http.HttpTransporter.implGet(HttpTransporter.java:235)
at
org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:59)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:447)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:350)
at
org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294)
at
org.jboss.as.model.test.MavenUtil.createMavenGavURL(MavenUtil.java:132)
at
org.jboss.as.model.test.ChildFirstClassLoaderBuilder.addMavenResourceURL(ChildFirstClassLoaderBuilder.java:197)
at
org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.addMavenResourceURL(SubsystemTestDelegate.java:800)
at
org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.buildKernelServices(TransformersTestCase.java:183)
at
org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.buildKernelServices(TransformersTestCase.java:177)
at
org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testTransformation(TransformersTestCase.java:196)
at
org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testTransformer720(TransformersTestCase.java:110)
9 years, 5 months
