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
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, 7 months
WFLY-4200 WAR MDB cannot obtain superclass on module classpath
by Eduardo Sant´Ana da Silva
I was looking at :WFLY-4200 WAR MDB cannot obtain superclass on module
classpath
This is what I posted about it:
"I believe that the problem is because
AnnotatedEJBComponentDescriptionDeploymentUnitProcessor executes in the
parse phase:
Phase.PARSE,Phase.PARSE_CREATE_COMPONENT_DESCRIPTIONS
Since the dependencies will be resolved at Phase.DEPENDENCIES, your build
will not work.
Regarding WFLY, my suggestion is not throw the
EjbLogger.ROOT_LOGGER.mdbDoesNotImplementNorSpecifyMessageListener(beanClass)
only bring up some flag that the required interfaces were not yet resolved,
some attachment could be useful, just to retain the super class name. When
the dependencies were solved, the class will be present on the class index
and the test against the annotation should be performed again. Since that
work will be done twice, to verify the required interfaces, this requires
some experts advice."
Thanks,
--
__________________________
Eduardo Sant'Ana da Silva
9 years
SimpleRoleGroup#roles
by Philippe Marschall
Hi
I’m aware this may no technically be the right list to discuss this but
this list is impacted by this and fairly active.
During load testing of our application we found a case we spend 10% of
your CPU time in SimpleRole#equals (see attachment). This is because
SimpleRoleGroup uses an ArrayList to maintain a unique set of roles. As
a result it has to call ArrayList#contains a lot, which is itself O(n).
In fact because that’s done when iterating over all the roles it becomes
O(n^2). In our case our principals can have up to 200 roles. I don’t
know if this is exceptionally many or a common case.
We would like to work on a patch but we need your guidance. There are
several possible solutions and it all comes down to whether we can
change the List in the RoleGroup interface to a Collection. All the
users we searched for in WildFly only used the return value for
iterating over, nobody used the index. In fact they all used it an a
for-each loop so the change would even be source compatible but
unfortunately not binary compatible. If we can change the interface then
we can just change the ArrayList in SimpleRoleGroup to a HashSet and be
done with it. If the order is important the we can either use a TreeSet
or a LinkedHashSet.
If changing the RoleGroup interface is not possible then there are two
other possibilities. The first is only internally using a Set but in
getRoles perform a copy. This would produce more garbage. The second
option would be a having a Set and List (to avoid having to do copies)
in SimpleRoleGroup. This would avoid having to do a copy and the Set can
be used for contains checks. Only removeRole would still be O(n) due to
the scan over ArrayList. The only user we found was
OptionsRoleMappingProvider.
All of these would change the serialized form. If it is important to
support reading old instances that could be added as well.
Cheers
Philippe
9 years
Adding additional security domain to standalone.xml?
by arjan tijms
Hi,
Currently one has to "activate" JASPIC in WildFly by doing two things:
1. Adding a generic "dummy" security domain to standalone.xml
2. Referencing this domain from a jboss-web.xml within the application
archive
I wonder if it would make sense to put the generic jaspic security domain
by default in standalone.xml. It's always the same anyway. With the domain
present in a stock WildFly it's much easier for people to start with JASPIC
on WildFly.
It concerns this fragment:
<security-domain name="jaspitest" cache-type="default">
<authentication-jaspi>
<login-module-stack name="dummy">
<login-module code="Dummy" flag="optional"/>
</login-module-stack>
<auth-module code="Dummy"/>
</authentication-jaspi>
</security-domain>
Kind regards,
Arjan Tijms
9 years
Early Access builds for JDK 8u72 b05 , JDK 9 b88 and JDK 9 with Project Jigsaw build b86 are available on java.net
by Rory O'Donnell
Hi Jason/Tomaz,
Early Access build for JDK 8u72 b05 <http://jdk8.java.net/download.html>
is available on java.net, summary of changes are listed here.
<http://download.java.net/jdk8u72/changes/jdk8u72-b05.html?q=download/jdk8...>
Early Access build for JDK 9 b88 <https://jdk9.java.net/download/> is
available on java.net, summary of changes are listed here
<http://download.java.net/jdk9/changes/jdk9-b88.html?q=download/jdk9/chang...>.
Early Access build for JDK 9 with Project Jigsaw b86
<https://jdk9.java.net/jigsaw/> is available on java.net.
Changes for JDK 9 with Project Jigsaw b86 : -
* New options for the jdeps tool: -genmoduleinfo to generate draft
module-info.java files, and -ct to do a compile-time analysis of
references (i.e., follow all references leaving all classes in each
referenced JAR file) rather than the default run-time analysis
(which only follows references leaving referenced classes).
* jlink no longer does service binding by default.
* Class::getPackage fixed to return null for array types, primitives,
and void (bug reported by Chris Newland).
* Improved messages in IllegalAccessExceptions thrown by core reflection.
* java -verbose now works with -Xpatch .
* The special token ALL-SYSTEM can be used with the -addmods option to
add all system modules.
* New methods Module::{addUses,canUse}, which are dynamic equivalents
of service-use clauses in module declarations.
Rgds, Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
9 years, 1 month
WF 10 Last Call
by Jason T. Greene
I plan to cut CR4 early tomorrow, which baring a major blocker, will be our last CR. After CR4, only PRs which are blockers, or are part of the Final version update will be merged. After Final is released, master will be slated for post release bug fixes, and non blocking bugs can once again be merged.
WF11 will open up most likely around a month after the release, at the latest, to give adequate time for engaging the community and resolving issues discovered.
If you have any critical bug fixes, today would be the day to get them in.
Thanks,
-Jason
9 years, 1 month
Regression after WFLY-5298; request#authenticate does nothing now
by arjan tijms
Hi,
It looks like that after WFLY-5298 (this commit specifically
https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099d...)
HttpServletRequest#authenticate does not longer do anything.
HttpServletRequest#authenticate calls though to
JASPIAuthenticationMechanism#authenticate.
There it now obtains the attachment that was set by the new
JASPICInitialHandler, which calls the SAM at the beginning of the
request. And then uses the stored "isValid" outcome directly, without
calling the SAM again.
See the code below:
public AuthenticationMechanismOutcome authenticate(final
HttpServerExchange exchange, final SecurityContext sc) {
JASPICAttachment attachment =
exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
AuthenticationMechanismOutcome outcome;
Account authenticatedAccount = null;
boolean isValid = attachment.isValid();
final ServletRequestContext requestContext =
attachment.getRequestContext();
final JASPIServerAuthenticationManager sam = attachment.getSam();
final JASPICallbackHandler cbh = attachment.getCbh();
GenericMessageInfo messageInfo = attachment.getMessageInfo();
if (isValid) {
// The CBH filled in the JBOSS SecurityContext, we need to
create an Undertow account based on that
org.jboss.security.SecurityContext jbossSct =
SecurityActions.getSecurityContext();
authenticatedAccount =
createAccount(attachment.getCachedAccount(), jbossSct);
}
This is not correct I think. The code should call the SAM once again
and use the outcome from that call.
Am I missing something, or was the new call to the SAM simply
forgotten at this point?
Kind regards,
Arjan Tijms
9 years, 1 month
Feature pack maven plugins question
by James Netherton
Hello everyone,
Consider the following.
Feature pack 'A' has a dependency on the WildFly 9 feature pack. E.g:
<dependencies>
<artifact name="org.wildfly:wildfly-feature-pack:9.0.1.Final" />
</dependencies>
Feature pack 'B' has a dependency on the WildFly 10 feature pack and also on feature pack 'A'. E.g:
<dependencies>
<artifact name="org.wildfly:wildfly-feature-pack:10.0.0.CR3" />
<artifact name="org.foo:feature-pack-A" />
</dependencies>
Leaving the sanity and validity of doing this aside, should the feature-pack-build or server-provisioning-plugin be detecting this as an error condition, given that you'll have overlapping and possibly problematic non-overlapping file paths coming from the conflicting WildFly versions?
At the moment the plugins allow this scenario.
Cheers,
James
9 years, 1 month
