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, 7 months
One Doc to Rule Them All
by James Perkins
I've been reading the WildFly documentation [1] quite a bit lately and
noticing a lot of issues. Sometimes it references WildFly 8 in the WildFly
10 (or 9) documentation. Sometimes it references JBoss AS 7. Links take you
to old documentation, e.g. a WFLY10 doc takes you to a page for WFLY8.
Sometimes documentation is just plain out of date referencing behavior that
has possibly been removed or replaced by something better.
This has happened because we keep copying the documentation over each time
we have a new version. Overall this makes sense as a lot of it doesn't need
to be changed. However it leaves reading the documentation confusing.
Reading documentation for WildFly 10 and seeing WildFly 8 in the text with
a link for AS72 isn't very user friendly as I'm sure we can all agree.
There's a few different ways we could go with this.
Approach 1:
One, probably the easiest, is to use a single confluence project. We'd need
to remove the version numbers from the text, which I think we should do
anyway. Instead of referencing WildFly 10 we just reference it as WildFly.
An issue I can think of with this approach is some how annotating or
referencing that parts of the documentation only work with ${version}. For
example new features would have to be noted they only work with ${version}+.
Approach 2:
Essentially he same as approach 1 only do allow different Confluence
projects for the different Java EE target version. So WIldFly 8, 9 and 10
would all be documented under something like WFLYEE7.
Approach 3
Switch to using something like asciidoc which can use variables and
generate links to the correct content. While this approach is probably
takes the most work up front, it seems like like it would be easier to
maintain between releases.
Any other suggestions are welcome.
[1]: https://docs.jboss.org/author/display/WFLY10/Documentation
--
James R. Perkins
JBoss by Red Hat
10 years
update on WildFly NoSQL prototype integration...
by Scott Marlow
Hi,
Below is an update on the WildFly NoSQL integration project. The goal
is for deployed applications to have access to NoSQL databases (via
Hibernate OGM or native APIs). Items 1-4, should be finished in our
first pass, with as much of the others items as we can do as well.
1. connection management will deal with obtaining NoSQL connections for
application use.
- borrow/share Hibernate OGM connection configuration setup code
- authentication integration
- support transport level security
2. CDI programming simplifications will make it easy to inject NoSQL
data into your application classes.
- https://github.com/antoinesd/javaee-nosql is initial idea
3. You will easily get a native NoSQL connection from the specified
NoSQL profile and use the native NOSQL (Cassandra/MongoDB/other) API in
your application.
4. You will also be able to easily use Hibernate OGM with the defined
NoSQL profiles (exactly how is TBD but will be awesome :-).
- Hibernate OGM static module is included.
- need to align with OGM dependencies (e.g. Hibernate ORM + other
dependencies).
- as mentioned above, OGM already has some connection setup code,
which might be good to share for WildFly + standalone NoSQL use.
- once WildFly has a common NoSQLSource (not a DataSource) that OGM
can use, OGM will be enhanced to use it.
5. How best for the WildFly NoSQL subsystem to be optional?
- Is it enough to not run the wildfly/testsuite/nosql tests by default?
- Or do we need to start a separate https://github.com/wildfly/nosql
project for the NoSQL subsystems?
6. transaction enlistment
7. compensating transactions
8. runtime application monitoring
9. How soon can we make an evaluation distribution available for use on
OpenStack/OpenShift?
- Would be great if we could do some load testing with all NoSQL
components.
- Would be great if we could enable others to also test.
10. Are there any problems with our WildFly NoSQL subsystem injecting
MongoDatabase connections via:
@Resource(lookup = "java:jboss/mongodb/test") MongoDatabase db;
- No @Resource support expected for standalone Java, TBD is whether a
runtime library can be used.
- Any problems expected on other EE application servers if this
approach becomes popular?
11. WIP topic branch is at
https://github.com/scottmarlow/wildfly/tree/nosql-dev9. Note that every
once in a while, commits are squashed and pushed to nosql-devN+1.
12. Add proper unit tests
- multi-threaded NoSQL access to show that works at all.
- use NoSQL from different EE components (e.g. JAX-RS).
- other use cases that represent how NoSQL could be used from WildFly.
Feedback/help is welcome!
Thanks,
Scott
10 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.
10 years, 1 month
Proposal to improve resource description and registration
by Jeff Mesnil
TL;DR - I propose to simplify subsystem development by moving some of the validation logic from the resource definitions to the management resource registration. The goal is to provide a static representation of the resources and let the MMR dynamically pick the “meaningful” parts.
Last week an user complains that the messaging-activemq subsystem’s statistics were not updated in domain mode.
It turned out that he was reading the metrics on the DC (/profile=full/subsytem=messaging-activemq/…) instead of reading on the server (/host=master/server=server-one/subsystem=messaging-activemq/…)
It is a bug[1] in the messaging-activemq because its resources register their metrics without checking whether that makes sense. The correct check is to look at context.isRuntimeOnlyRegistrationValid() to check whether a resource can register its metrics (the same check applies also for runtime attributes/operations).
I looked at other subsystems and undertow has the same issue.
This check does not work well with the PersistentResourceDefinition that is used throughout the messaging-activemq and undertow subsystems. This API works best when the definition of the resources uses a bunch of static instances for the resource itself, its attributes, metrics, etc. These static instances are also used by the companion PersistentResourceXMLDescription to provide a static XML representation of the subsystem.
If I have to pass this context.isRuntimeOnlyRegistrationValid() boolean to every resources in the subsystem, I get rid of the static representations used by the PersistentResourceDefinition and PersistentResourceXMLDescription and I have to add a lot of simple but boilerplate code in all my resource definitions.
The datasources subsystem does not exhibit this issue. It works around it by installing a Service at RUNTIME step to register (resp. unregister) statistics resource definitions when the service is started (res. stopped). Since services are only installed when runtime is supported, it ensures that the datasources metrics are available only on server and not on the DC.
It looks correct but I’m not a big fan of this solution. It makes the subsystem definition more complex to understand and it also involves boilerplate code that every subsystem providing runtime should write.
I was wondering if we could simplify the development of the subsystems by moving some of the logic dealing with that use case in the ManagementResourceRegistration instead.
My proposal would be to have the resource definitions be “complete”. The resource always defines its attributes/metrics/operations.
When the MMR takes this definition and registers the different parts, it would only register the “meaningful” one depending on the ProcessType and RunningMode. E.g. the MRR of the DC or a admin-only server would not register metrics & runtime attributes/operations while the MMR on a normal server would register everything.
This increase the complexity of the MMR which has to figure out whether to actually register something or discard it but it makes writing subsystem simpler and more robust.
Brian told me there might some exceptions (e.g. a runtime op that could be invoked on the DC) but these case could be handled by adding metadata to the resource definitions.
This approach segues quite well with the idea to generate subsystem using annotations. All the subsystem developers has to do is describe extensively the subsystem resources (using static objects now, annotations in a future version) and let the MMR decides which parts of the resources are actually registered.
To sum up, the definition of a resource is static, while its registration is dynamic.
Do you see any issue with that proposal?
As a first step, I’ll start by creating the corresponding WFCORE issue to fix WFLY-6546 issue by ensuring the MMR does not register metric if the runtime registration is not valid. This should not have any API impact (but the behaviour will certainly change).
jeff
[1] https://issues.jboss.org/browse/WFLY-6546
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
10 years, 2 months
JavaMail provider module and jboss-deployment-structure.xml
by Carl Harris
I have a custom JavaMail provider installed as a module in Wildfly 10.
In the configuration, I specify a mail session using the custom provider like this:
<mail-session name="rcpt" jndi-name="FixedRecipient">
<custom-server name="FixedRecipient">
<!-- configuration properties hee -->
</custom-server>
</mail-session>
If I make the provider a global module in the configuration, a deployment can successfully use the provider.
However, if I specify the provider as module dependency in jboss-deployment-structure.xml, when trying to create a javax.mail.Session using the provider, a NoSuchProviderException is thrown (as though the base Session implementation cannot find a META-INF/javamail.providers mapping that identifies the custom provider).
I don't know whether specifying the provider as a deployment structure dependency should work or not, but it seems like it should.
Can someone please explain?
carl
10 years, 2 months
Proposal for improving the the static modules management in Wildfly
by Andrea Battaglia
Hi all,
I would like to bring to your attention a proposal for improving the the static modules management in wildfly.
After a deep discussion with Sanne Grinovero about the static modules management in wildfly and about some interesting use cases, we tried to design out an improvement that can help both testers and developers.
Here are a couple of use cases of great interest:
- Testing the new version of an existing module or testing its resources/dependencies: Sometimes it would be useful to test the integration of a different version of the new library into wildfly. Let's think about a patched version of hibernate-core or jgroups. This is supposed to be done without embedding the resource into the application, but delegating the library management to wildfly, instead.
- Provisioning the static resources for third party libraries dynamically: They asked me to create a lot of static modules for third party libraries a lot of times. This happens each time (always) a bunch of applications use the same, shared set of third party libraries and, of course, each time a developer avoids bundling the libraries inside the binaries (ear/war). Let's think about apache commons, security libraries, or hadoop client libraries (see my github: https://github.com/andreabattaglia/cloudera-eap-modules <https://github.com/andreabattaglia/cloudera-eap-modules>, there you can find a huge set of the static modules for wildfly used to connect to hadoop services without need of embedding the jars into the applications binaries). This usecase applies to the jdbc drivers as well.
My aim is to avoid wasting time to create the structure of each static module each time a developer needs brand new one or a different version of it and to avoid wasting time googling for an existing solution. Usually, this activity requires to put a lot of effort in testing the static module as well. Moreover, sometimes , the solution to the same problem can be found on different sites or blogs in different flavours, which is misleading most of all for developers who have no experience in the management of static modules in wildfly.
The idea: share the descriptor of the static module in a place accessible to all the developers. The tool used to save the descriptor files must be able to version them. Each time the wildfly deployer is asked for a static module which is not bunlded in the default package or is not already available locally, the module descriptor and its resource and dependencies will be built automatically.
The solution design: wildfly is already able to download the components of a static module from an artifact repository, but this feature strictly relates to the resources.
It would be useful to improve this feature in order to create a static module locally each time the module is requested by a subsystem or an application being deployed. The deployer should first check for the local module availability. If the module is not available locally, wildfly will first search for the module descriptor into the artifact repository (maven repo implementation), then create folder tree, download resources and repeat iteratively the algorithm for each dependency found in the module descriptor.
This behaviour will automate the dynamic creation of the static module starting from the module descriptor.
I'm keen to discuss the proposal with you and to help to design and develop a first implementation as well.
Thanks a lot in advance for your time,
Andrea
___________________________
Andrea Battaglia
EMEA Middleware Architect
Red Hat
Via Generale Gustavo Fara, 26
20124 MILANO
www.redhat.com
mobile: +39 328 1093652
fax: +39 02 6693111
email: andrea.battaglia(a)redhat.com
10 years, 2 months
