Latest WildFly Elytron Test Results - 2017-03-05
by Darran Lofthouse
Here are the latest test results after the most recent round of merges: -
https://ci.wildfly.org/viewLog.html?buildId=48664&buildTypeId=WF_MasterNe...
We currently have 27 test failures, this is an increase on the last
count but is also expected due to recent changes. These additional
failures are in tests that were failing at the time of the original
invocation merge and are not new tests.
org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase.testNoTxEPCPropagation
org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testDir
org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testLdap
org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testNotAuthorizedClient
org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testAuthorizedClient
org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testNotAuthorizedClient
org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testAuthorizedClient
org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnlyBeforeCompletion
org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationSucceeded
org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnly
org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationFailed
org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateful
org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase(SYNC-tcp).test
org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp).test
org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp).test
org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testGracefulShutdownConcurrentFailover
org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatelessFailover
org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatefulFailover
org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testSecureStatelessFailover
org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testClientException
org.jboss.as.test.clustering.single.provider.ServiceProviderRegistrationTestCase.test
org.jboss.as.test.clustering.single.dispatcher.CommandDispatcherTestCase.test
org.jboss.as.test.clustering.single.registry.RegistryTestCase.test
org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnlyBeforeCompletion
org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationSucceeded
org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBInvocation
org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances
7 years, 9 months
Moving Elytron Subsystem into WildFly Core
by Darran Lofthouse
I am about to start the process of moving the WildFly Elytron Subsystem
into WildFly Core.
https://issues.jboss.org/browse/WFCORE-2352
For now I would suggest if you are working on changes to continue to
submit PRs against the subsystem directly but be prepared that any that
miss the cut off may need resubmitting against WildFly Core.
Resubmission should not be a big task as the structure of the subsystem
project should be largely unchanged.
Regards,
Darran Lofthouse.
7 years, 9 months
Prototype of Eclipse MicroProfile Config API in WildFly / Swarm
by Jeff Mesnil
(I’m crossposting to wildfly-dev and widfly-swarm as both communities could be interested by this)
TL;DR
---
Out of curiosity, I’m working on a WildFly subsystem to expose the Eclipse MicroProfile Config API to applications deployed in WildFly and Swarm and I’m gauging interest for it.
---
The Eclipse MicroProfile Config API[1] defines an API to access properties from various sources (OS, JVM, application, containers, etc.) using an uniform API.
@Inject
Config config
...
String value = config.getString(“os.name”);
The specification and API are in early stages but I’m considering supporting it in WildFly (and by extension in Swarm).
I’ve written a prototype[2] that:
* provides a basic Config implementation which reads properties from various sources:
* OS / containers
* JVM
* application properties (backed by META-INF/microprofile-config.properties file in deployed application)
* config-source resources (more on that below)
* the Config API can be accessed using CDI or programmatically
The implementation is very basic and buggy and I’m not sure if WildFly is the best place to provide an implementation (if we can integrate it from another project that provides it, that’d be fine).
In any case, WildFly would support the Config API and expose it to deployed applications.
I’ve added some fancy features to the WildFly subsystem to highlight a few use cases:
* store properties directly in WildFly subsystem configuration
* provide and HTTP access to config sources
The WildFly subsystem can store directly properties that would be available for any deployed applications:
<subsystem xmlns="urn:net.jmesnil:microprofile-config:1.0">
<config-source name="myConfigSource" ordinal="200">
<property name="foo" value="12345"/>
</config-source>
<config-source name="remoteConfigSource" http-enabled="true">
<property name="my.super.property" value="123456"/>
</config-source>
</subsystem>
This provides a centralized way to store properties accessed by different deployed applications.
This also leverage WildFly management API to manage the properties (add/remove/update them).
These config-sources can also be accessed using HTTP with a simple GET request:
http://localhost:8080/wildfly-services/config-source/<config-source name>/<property name>
We could then imagine having clients on other nodes accessing these “HTTP”-enabled config sources through the Config API.
In a swarm of applications, this would allow to have some nodes serving as properties “repository" and accessed by other nodes.
I’ve written a companion example, a simple Web app, that uses CDI to access the Config API and lists all the properties from the various config sources.[3]
The prototype I wrote is in very early stage (but already offers all the features above).
The API and spec are also in very early stages and will likely change before they reaches 1.0.
At this stage, before going any further, I’m interested to know:
* who is interested by this Config API?
* who is interested to *implement* this config API?
* more specifically for WildFly and Swarm developers, is there already any other effort around this spec?
cheers,
jeff
[1] https://github.com/microprofile/microprofile-config
[2] https://github.com/jmesnil/microprofile-config-extension
[3] https://github.com/jmesnil/microprofile-config-example/
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
7 years, 9 months
Apache Lucene modules for WildFly : evolution
by Sanne Grinovero
# Context
historically the Hibernate Search project released modules for
WildFly, so that people could use the latest version of it w/o having
to wait for WildFly to upgrade it and release.
This zip we distribute would also include updated modules for Apache Lucene.
We have now separated the Lucene modules into their own repository, so
that other projects (e.g. Infinispan) can use the same modules.
In case you want to have a look, the POC is hosted at:
- https://github.com/hibernate/lucene-modules
We planned to deploy this zip file as a Maven artifact under
coordinates "org.hibernate.lucene-modules:lucene-modules:lucene-modules".
# I have three questions:
## Would it be useful to make this a "Feature Pack" ?
Ideally we would like future versions of WildFly to use the same
structure (and same content) of these modules, when it will come to
upgrade the Lucene version within WildFly.
That's because we will have already tested these in (at least) the
Hibernate and Infinispan projects, while replicating the same
structure within the WildFly build would not guarantee the same
output, and would not be covered by the same amount and quality of
integration tests.
## Would you prefer this to be hosted as github.com/wildfly ?
We'd be happy to transfer ownership and still maintain it: having this
under "Hibernate" probably sends the wrong message.
It contains no Hibernate code and we'd like to encourage other people
possibly using Lucene on WildFly to use the same modules, again for
consistency reasons.
## Should we use a WildFly flavoured organization id?
For the same reasons as in the previous question, yet I ask this
separately as I guess we could still keep it on github/hibernate if
you prefer, yet distribute it as "org.wildfly:lucene-modules" or
something else you might want to suggest.
Thanks,
Sanne
7 years, 9 months
DMR -> JMX bridge ?
by John Mazzitelli
I was just informed that WildFly has a DMR -> JMX bridge, but I can't find anything on it. Is there such a thing or did I misunderstand?
Particularly, is it true that for each DMR resource in the WildFly resource tree there is an associated JMX MBean with analogous JMX attributes/operations as you see in DMR?
Can I do everything I want over JMX that I can do over the DMR management interface (I doubt deployments can be done over JMX, but maybe I'm wrong with that, too?) ???
I'm thinking I just misunderstand - wouldn't be the first time I was confused :)
7 years, 9 months
how a -javaagent can use logging and not blow up WildFly
by John Mazzitelli
Regarding this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1037970
and the exception message:
JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
How would one go about working around this when you have a -javaagent deployed in WildFly/EAP and that agent code actually uses logging?
I've tried a bunch of stuff such as setting the sysprop java.util.logging.manager=org.jboss.logmanager.LogManager (both in standalone.conf and passing in via standalone.sh); in the agent code, first thing is call System.setProperty("java.util.logging.manager", "org.jboss.logmanager.LogManager"); I've tried getting the agent code to sleep and not even do any work until WildFly starts booting (though I'm not sure if some of my classes are getting loaded at the time premain() is called, but I can't see where its importing any logging stuff - unless its happening in low-level Java API code and setting java.util.logging itself?)
There has to be a way to do this - I'm thinking of things like byteman which probably ran into the same thing. I'm hoping there is a simple "oh, you just do this magical step and it works around the problem."
7 years, 9 months
