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
9 years, 1 month
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.
9 years, 8 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
9 years, 10 months
integration-tests scripts failure
by Eduardo Sant´Ana da Silva
I'm trying to reproduce some issues, but a lot of them could not be done
since integration-tests.sh script is claiming about the latest
wildfly-testsuite-shared on the nexus repository 10.1.0.Final-SNAPSHOT, the
latest over there is: 10.0.0.Alpha1
--
__________________________
Eduardo Sant'Ana da Silva - Ph.D.
Researcher / IT Conultant
10 years
WildFly Arquillian 2.0.0
by James Perkins
Hello All,
In WildFly Core the embedded standalone server factory was renamed from
EmbeddedStandAloneServerFactory to EmbeddedStandaloneServerFactory. This
caused an issue with wildfly-arquillian-embedded not being able to work
with WildFly 10 (WildFly Core 2). As a result of this WildFly Arquillian
was bumped to version 2.0.0, now requires Java 8 and WIldFly Core 2.
Both 2.x and 1.x versions should work with WildFly 8.x and higher with the
exception of wildfly-arquillian-embedded. This means that if embedded is
required 1.x needs to be used for WildFly 9 where as 2.x needs to be used
for WildFly 10+.
I've released a 2.0.0.Alpha1 version of wildfly-arquillian that can be used
with WildFly 10. We'll move into an Alpha2 after some work is done with the
managed domain container.
--
James R. Perkins
JBoss by Red Hat
10 years
private packaging Javassist jar in Hibernate ORM, so applications can have their own Javassist jar...
by Scott Marlow
As previously discussed, Hibernate applications need access to the
Javassist runtime classes (see example [1] enhanced application entity
if you didn't know this :). A proposal was discussed on the
hibernate-dev mailing list that I think is the best short term solution.
I wanted to raise this issue here also, as I would like to later
create a pull request to bring in a new Hibernate ORM that includes this
change. So, getting early feedback before we create JIRAs for the work,
is important.
The proposal is to private package (or shade), the Javassist classes, so
that Hibernate ORM has its own copy of the Javassist classes. On
WildFly, we still would include Javassist for the other components that
use it and for Hibernate applications that have "build-time enhanced
entity classes" by an earlier Hibernate release.
One downside of this change is that Hibernate applications cannot easily
switch to a different version of the Javassist classes.
Another downside is that applications that depend on an older Hibernate
ORM version that includes "build-time enhanced entity classes", will
need to be cracked open, to add dependencies on the Javassist module
(since we will stop automatically adding Javassist to JPA application
deployments).
The advantage of this change, is that Hibernate applications can include
their own version of Javassist.
This will also have an impact on Hibernate build-time enhancing of
entity classes (e.g. enhanced bytecode will no longer depend on the
public Javassist classes).
Scott
[1] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
10 years
Build failed in MessagingSubsystem30TestCase
by gathila harischandra
Hi all,
I ‘m trying to run build.bat and this build failure occurred test set
org.jboss.as.messaging.test.MessagingSubsystem30TestCase
java.lang.RuntimeException:
org.eclipse.aether.resolution.ArtifactResolutionException: Could not
transfer artifact org.jboss.as:jboss-as-messaging:jar:7.3.0.Final-redhat-14
from/to product-repository
10 years
How to use CNCtxFactory from WildFly
by Michael Musgrove
I am attempting to lookup a remote EJB from WildFly to WLS.
If I use COSNaming as required by [1] (by setting INITIAL_CONTEXT_FACTORY
to "com.sun.jndi.cosnaming.CNCtxFactory") I get the following error on the
WildFly end:
"ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory"
If I use the default wildfly name service (new
InitialContext().lookup("corbaname:iiop:localhost:7001/NameService#SessionBean"))
I get the following error on the WLS end (presumably because I am not
using CNCtxFactory):
"A RuntimeException was generated by the RMI server:
weblogic.corba.cos.naming.RootNamingContextImpl.resolve([Lorg.omg.CosNaming.NameComponent"
I did try adding the CosNaming dependency (<path
name="com/sun/jndi/cosnaming"/>) to
modules/system/layers/base/sun/jdk/main/module.xml or to
jboss-deployment-structure.xml in my deployment but that approach did not
work.
[1] row 3 of Table 2-1 in
https://docs.oracle.com/cd/E13222_01/wls/docs81/rmi_iiop/rmiiiop2.html
--
Michael Musgrove
Transactions Team
e: mmusgrov(a)redhat.com
t: +44 191 243 0870
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
(US), Charles Peters (US)
Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
O'Neill(Ireland)
10 years
