Subsystem Inclusion Policy & Role of Feature Packs & Add-ons
by Jason Greene
Hello Everyone,
Recently there has been some confusion about how subsystems should be distributed, and whether or not they should be part of the WildFly repository.
There are three primary use-cases for distributing a subsystem.
#1 - Inclusion in an official WildFly distribution
#2 - A user installable "add-on distribution" which can be dropped on top of a WildFly Distribution (see [A])
#3 - A separate, independant, customized distribution, with a differing identity. Possibly build but not required as a layer (see [A])
If you are after #1, then the subsystem source code (defined as the portion of code which integrates with the server using the subsystem facilities) MUST be included in the WildFly repo. This is because subsystems heavily impact the stability of the server and our compliance with our strict management compatibility policy, and additionally it allows for us to keep all included subsystems up to date with core infrastructure changes such as capabilities and requirements, and the upcoming elytron security integration. Under this approach, a feature-pack is unlikely to be used, as it would likely just be part of the full feature-pack. It could very well be that we would introduce a different more expansive feature-pack in the future defining a larger distribution foot-print, however, there are currently no plans to do so.
If you are after #2, then you do not want a feature-pack, as feature-packs are just for building custom server distributions. If your use-case is #2 you are by definition not a custom server distribution, but rather a set of modules built the normal maven way.
If you are after #3, then you likely wish to use the feature-pack mechanism to make it easy to produce your custom distribution. This facility would allow you to keep your source repository limited to just the new subsystems you introduce, and pull the rest of the server bits via a maven dep. It is important, that you change the identity of the server (see [A]), such that patches for the official WildFly server are not accidentally installed.
Thanks!
[A] https://developer.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz...
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
7 years, 10 months
WildFly 11 Model and Schema Version Bumps
by Darran Lofthouse
Just a FYI,
In preparation for WildFly 11 I already have bumped the schema versions
and model for numerous parts of WildFly - if you plan to work on any
WildFly 11 changes that would also require a bump of any of these let me
know and I can point you to a branch where the changes have already been
made.
The models bumped so far are: -
- Core Management Model and Schema
- Remoting Subsystem
- Undertow Subsystem
- EJB Subsystem
- Security Subsystem
Regards,
Darran Lofthouse.
8 years, 4 months
Feature pack provisioning
by Marko Strukelj
Currently wildfly-server-provisioning-maven-plugin always generates a full Wildfly distribution. For Keycloak project we have three different cases of provisioning, and it would be great to be able to cover it with a common wildfly provided tool:
1) full server distribution
2) overlay distribution (unzip into existing OOTB Wildfly distribution - your problem if you use unsupported Wildfly version)
3) provision into existing Wildfly server detecting version mismatches, and configuring existing and additional subsystems for Keycloak to run properly.
First one is what’s currently supported, and what we use.
Second one is what we currently hack up by extracting modules directory from (1) - it would support this use case better if wildfly-server-provisioning-maven-plugin could generate 'modules only' for example.
The third one requires a CLI installer tool. I’m not aware that currently there is something for that, and we are loath to develop one from scratch.
Is it realistic to expect 2) and 3) in not so distant future?
- marko
8 years, 6 months
The EJB client and remote JTA transaction propagation
by David M. Lloyd
As you may know, WildFly supports a feature wherein an EJB client which
is invoking an EJB on a remote server has the option to propagate its
local transaction to the remote server, treating the remote server as a
subordinate and coordinating the transaction's two-phase commit among
the resultant graph of servers. This feature has always been limited in
that, when enabled, transactions are always propagated, regardless of
the peer EJB's transaction policy, or of whether the peer even has a
transaction manager.
So, for the invocation rework which I anticipate will be included in
WildFly 11, I've introduced a new client-side annotation intended to be
associated with the EJB interface which informs the client library what
to do for transaction propagation for that interface. In addition, I
intend to configuration strategies which will allow the default mode to
be specified in various ways (per-thread, globally, and by target
interface/method all come to mind), for cases where the EJB's remote
interface cannot be easily modified for some reason. I expect to also
broaden these configuration strategies to apply to all client-side EJB
interface/methods configuration items [3].
The first part of this change is the addition of a new annotation called
@ClientTransaction [1], which accepts as a value an enum called
ClientTransactionPolicy [2]. The latter specifies whether a local
transaction is required or forbidden for the method or interface, and
also specifies whether the transaction is propagated or not propagated.
I've added copious amounts of JavaDoc in order to establish exactly what
the behavior of each mode is, as well as to specify how each mode
interacts with the various modules that are configured via the standard
javax.ejb.TransactionAttributeType enum.
[1]
https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org...
[2]
https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org...
[2] (raw)
https://raw.githubusercontent.com/jbossas/jboss-ejb-client/master/src/mai...
[3] for a list, see:
https://github.com/jbossas/jboss-ejb-client/tree/master/src/main/java/org...
--
- DML
8 years, 9 months
Wildfly 10.0.0.Final and Infinispan subsystem model 4.0 - Got a local cache despite it is configured as distributed
by Pierrick HYMBERT
Dear Wildfly dev team,
I am blocked to deploy a test app that use a distributed infinispan cache
within 2 domain nodes and a cache entry producer deployed as clustered
singleton service.
Your feedback/advise are really appreciated!
Cache definition:
<cache-container name="my-cache-container">
<transport lock-timeout="60000"/>
<distributed-cache name="myAppCache" mode="SYNC">
<transaction mode="NONE"/>
<eviction strategy="NONE"/>
</distributed-cache>
</cache-container>
Sample code:
@Resource(lookup = "java:jboss/infinispan/container/my-cache-container")
private EmbeddedCacheManager cacheContainer;
private Cache<Long, Long> myAppCache;
@PostConstruct
public void startNotClustered() throws NamingException {
this.myAppCache = this.cacheContainer.getCache("myAppCache");
...
}
...
@Schedule(hour = "*", minute = "*", second = "*")
public void consume() {
logger.info("Cache size on node {} = {}",
System.getProperty("jboss.node.name"), myAppCache.size());
}
Server one sample logs:
2016-01-31 14:52:03,789 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 1) Produce
new cache entry 1454241123789 on node master:server-one
2016-01-31 14:52:04,005 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 2) Cache
size on node master:server-one = 35
2016-01-31 14:52:04,796 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 3) Produce
new cache entry 1454241124796 on node master:server-one
2016-01-31 14:52:05,006 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 4) Cache
size on node master:server-one = 36
2016-01-31 14:52:05,801 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 5) Produce
new cache entry 1454241125801 on node master:server-one
2016-01-31 14:52:06,007 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 6) Cache
size on node master:server-one = 37
2016-01-31 14:52:06,807 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 7) Produce
new cache entry 1454241126807 on node master:server-one
2016-01-31 14:52:07,005 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 8) Cache
size on node master:server-one = 38
2016-01-31 14:52:07,813 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 9) Produce
new cache entry 1454241127813 on node master:server-one
2016-01-31 14:52:08,006 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 10) Cache
size on node master:server-one = 39
2016-01-31 14:52:08,817 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 1) Produce
new cache entry 1454241128817 on node master:server-one
2016-01-31 14:52:09,007 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 2) *Cache
size on node master:server-one = 40*
Server two logs:
2016-01-31 14:51:56,006 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 4) Cache
size on node master:server-two = 0
2016-01-31 14:51:57,008 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 5) Cache
size on node master:server-two = 0
2016-01-31 14:51:58,007 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 6) Cache
size on node master:server-two = 0
2016-01-31 14:51:59,007 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 7) Cache
size on node master:server-two = 0
2016-01-31 14:52:00,006 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 8) Cache
size on node master:server-two = 0
2016-01-31 14:52:01,008 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 9) Cache
size on node master:server-two = 0
2016-01-31 14:52:02,007 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 10) Cache
size on node master:server-two = 0
2016-01-31 14:52:03,006 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 1) Cache
size on node master:server-two = 0
2016-01-31 14:52:04,007 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 2) Cache
size on node master:server-two = 0
2016-01-31 14:52:05,008 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 3) Cache
size on node master:server-two = 0
2016-01-31 14:52:06,006 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 4) Cache
size on node master:server-two = 0
2016-01-31 14:52:07,006 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 5) Cache
size on node master:server-two = 0
2016-01-31 14:52:08,007 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 6) Cache
size on node master:server-two = 0
2016-01-31 14:52:09,007 INFO
[org.hypik.test.jboss.eap7.server.TestService] (EJB default - 7) *Cache
size on node master:server-two = 0*
I have attached all necessary info to investigate, but I am not sure
attachement is allowed, so you can see source and logs here:
https://www.dropbox.com/s/l1uhmfg5tkjkikw/infinispan-issue-wildfly-10.0.0...
С уважением / Cordialement / Best regards,
*Pierrick **HYMBERT*
*pierrick.hymbert(a)gmail.com <pierrick.hymbert(a)gmail.com>*
*(+7)916.301-89-13 / (+33)6.87-52-91-37*
*+Pierrick <https://plus.google.com/u/0/105713262389092625238> /
**Skype / **LinkedIn
<http://www.linkedin.com/pub/pierrick-hymbert/51/506/357>*
8 years, 9 months
Is the BOM for 10.0.0.Final available already?
by Renann Prado
I tried to use
<dependency>
<groupId>org.wildfly.bom</groupId>
<artifactId>jboss-javaee-7.0-wildfly</artifactId>
<version>10.0.0.Final</version>
<type>pom</type>
<scope>import</scope>
</dependency>
But couldn't.
Renann Prado
8 years, 9 months
Timeout errors in JCA bits in testsuite
by Brian Stansberry
In the last day I've seen 3 different CI runs fail due to various JCA
related tests in testsuite/basic not completing. Does anyone have any
idea what might be causing this?
The ones I noticed were all PR tests of changes in core. It's hard to
imagine the PRs themselves were relevant. They do test a snapshot of
core though, so it's possible some change in core is relevant, in
addition to the simpler scenario of some issue in full.
1) Just now:
http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildTypeId=WildFlyCor...
[22:05:58][org.wildfly:wildfly-ts-integ-basic] Running
org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase
[22:06:00][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures:
0, Errors: 0, Skipped: 0, Time elapsed: 2.084 sec - in
org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase
[22:06:00][org.wildfly:wildfly-ts-integ-basic] Running
org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase
[22:06:02][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures:
0, Errors: 0, Skipped: 0, Time elapsed: 1.598 sec - in
org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase
[22:06:02][org.wildfly:wildfly-ts-integ-basic] Running
org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase
[22:30:48][org.wildfly:wildfly-ts-integ-basic]
[22:30:48][org.wildfly:wildfly-ts-integ-basic] Results :
[22:30:48][org.wildfly:wildfly-ts-integ-basic]
[22:30:48][org.wildfly:wildfly-ts-integ-basic] Tests run: 8, Failures:
0, Errors: 0, Skipped: 0
[22:30:48][org.wildfly:wildfly-ts-integ-basic]
[22:30:48][org.wildfly:wildfly-ts-integ-basic] [ERROR] There was a
timeout or other error in the fork
2) Yesterday:
http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=87585&tab=buil...
[14:48:42][org.wildfly:wildfly-ts-integ-basic] Running
org.jboss.as.test.integration.jca.beanvalidation.PositiveValidationTestCase
[14:48:43][org.wildfly:wildfly-ts-integ-basic] Tests run: 3, Failures:
0, Errors: 0, Skipped: 0, Time elapsed: 0.669 sec - in
org.jboss.as.test.integration.jca.beanvalidation.PositiveValidationTestCase
[14:48:43][org.wildfly:wildfly-ts-integ-basic] Running
org.jboss.as.test.integration.jca.capacitypolicies.DatasourceCapacityPoliciesTestCase
[14:48:44][org.wildfly:wildfly-ts-integ-basic] Tests run: 1, Failures:
0, Errors: 0, Skipped: 0, Time elapsed: 0.98 sec - in
org.jboss.as.test.integration.jca.capacitypolicies.DatasourceCapacityPoliciesTestCase
[14:48:44][org.wildfly:wildfly-ts-integ-basic] Running
org.jboss.as.test.integration.jca.capacitypolicies.ResourceAdapterCapacityPoliciesTestCase
[14:48:44][org.wildfly:wildfly-ts-integ-basic] Tests run: 1, Failures:
0, Errors: 0, Skipped: 0, Time elapsed: 0.766 sec - in
org.jboss.as.test.integration.jca.capacitypolicies.ResourceAdapterCapacityPoliciesTestCase
[14:48:44][org.wildfly:wildfly-ts-integ-basic] Running
org.jboss.as.test.integration.jca.capacitypolicies.XADatasourceCapacityPoliciesTestCase
[14:48:45][org.wildfly:wildfly-ts-integ-basic] Tests run: 1, Failures:
0, Errors: 0, Skipped: 0, Time elapsed: 0.718 sec - in
org.jboss.as.test.integration.jca.capacitypolicies.XADatasourceCapacityPoliciesTestCase
[14:48:45][org.wildfly:wildfly-ts-integ-basic] Running
org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestCase
[14:48:51][org.wildfly:wildfly-ts-integ-basic] Tests run: 6, Failures:
0, Errors: 0, Skipped: 0, Time elapsed: 5.881 sec - in
org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestCase
[14:48:51][org.wildfly:wildfly-ts-integ-basic] Running
org.jboss.as.test.integration.jca.datasource.DatasourceXaEnableAttributeTestCase
[15:07:51][org.wildfly:wildfly-ts-integ-basic]
[15:07:51][org.wildfly:wildfly-ts-integ-basic] Results :
[15:07:51][org.wildfly:wildfly-ts-integ-basic]
[15:07:51][org.wildfly:wildfly-ts-integ-basic] Tests run: 761, Failures:
0, Errors: 0, Skipped: 12
[15:07:51][org.wildfly:wildfly-ts-integ-basic]
[15:07:51][org.wildfly:wildfly-ts-integ-basic] [ERROR] There was a
timeout or other error in the fork
3) Yesterday:
http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=87425&tab=buil...
[01:38:34][org.wildfly:wildfly-ts-integ-basic] Running
org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase
[01:38:36][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures:
0, Errors: 0, Skipped: 0, Time elapsed: 1.583 sec - in
org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase
[01:38:36][org.wildfly:wildfly-ts-integ-basic] Running
org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase
[01:38:37][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures:
0, Errors: 0, Skipped: 0, Time elapsed: 1.215 sec - in
org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase
[01:38:37][org.wildfly:wildfly-ts-integ-basic] Running
org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase
[01:38:38][org.wildfly:wildfly-ts-integ-basic] Tests run: 2, Failures:
0, Errors: 0, Skipped: 0, Time elapsed: 1.23 sec - in
org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase
[01:38:38][org.wildfly:wildfly-ts-integ-basic] Running
org.jboss.as.test.integration.jca.moduledeployment.InflowJarTestCase
[01:38:40][org.wildfly:wildfly-ts-integ-basic] Tests run: 2, Failures:
0, Errors: 0, Skipped: 0, Time elapsed: 1.086 sec - in
org.jboss.as.test.integration.jca.moduledeployment.InflowJarTestCase
[01:38:40][org.wildfly:wildfly-ts-integ-basic] Running
org.jboss.as.test.integration.jca.moduledeployment.MultiActivationFlatTestCase
[01:38:41][org.wildfly:wildfly-ts-integ-basic] Tests run: 7, Failures:
0, Errors: 0, Skipped: 0, Time elapsed: 1.165 sec - in
org.jboss.as.test.integration.jca.moduledeployment.MultiActivationFlatTestCase
[01:38:41][org.wildfly:wildfly-ts-integ-basic] Running
org.jboss.as.test.integration.jca.moduledeployment.MultiActivationJarTestCase
[01:38:42][org.wildfly:wildfly-ts-integ-basic] Tests run: 7, Failures:
0, Errors: 0, Skipped: 0, Time elapsed: 1.111 sec - in
org.jboss.as.test.integration.jca.moduledeployment.MultiActivationJarTestCase
[01:38:42][org.wildfly:wildfly-ts-integ-basic] Running
org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationFlatTestCase
[01:38:43][org.wildfly:wildfly-ts-integ-basic] Tests run: 5, Failures:
0, Errors: 0, Skipped: 0, Time elapsed: 1.694 sec - in
org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationFlatTestCase
[01:38:43][org.wildfly:wildfly-ts-integ-basic] Running
org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationJarTestCase
[01:38:45][org.wildfly:wildfly-ts-integ-basic] Tests run: 5, Failures:
0, Errors: 0, Skipped: 0, Time elapsed: 1.24 sec - in
org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationJarTestCase
[01:38:45][org.wildfly:wildfly-ts-integ-basic] Running
org.jboss.as.test.integration.jca.moduledeployment.PartialObjectActivationFlatTestCase
[02:03:26][org.wildfly:wildfly-ts-integ-basic]
[02:03:26][org.wildfly:wildfly-ts-integ-basic] Results :
[02:03:26][org.wildfly:wildfly-ts-integ-basic]
[02:03:26][org.wildfly:wildfly-ts-integ-basic] Tests run: 36, Failures:
0, Errors: 0, Skipped: 0
[02:03:26][org.wildfly:wildfly-ts-integ-basic]
[02:03:26][org.wildfly:wildfly-ts-integ-basic] [ERROR] There was a
timeout or other error in the fork
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
8 years, 9 months
