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, 11 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, 8 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, 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, 2 months
Wildfly Redis infinispan cache store
by Simon Paulger
Hi,
My company uses JBoss AS 7 (before Wildfly I know). We also use Redis cache
store for PHP stacks and I'd like to be able to do the same for Wildfly
(I'm considering upgrade paths).
I see there is an old JIRA enhancement issue raised here:
https://issues.jboss.org/browse/ISPN-3465
I was wondering what the appetite for creating a Redis cache store is. If
this were something I were to develop in both inifinispan and wildfly,
would it be well received by the JBoss community?
Regards,
Simon
9 years, 2 months
Project Jigsaw: Early-Access Builds available on jdk9.java.net/jigsaw
by Rory O'Donnell
Hi Jason/Tomaz,
Early-access builds of JDK 9 with Project Jigsaw are available for
download at jdk9.java.net/jigsaw <http://jdk9.java.net/jigsaw>.
The EA builds contain the latest prototype implementation of JSR 376
<http://openjdk.java.net/projects/jigsaw/spec>, the Java Platform Module
System,
as well as that of the JDK-specific APIs and tools described in JEP 261
<http://openjdk.java.net/jeps/261>.
If you'd like to try out the EA builds, by far the most helpful things
you can do are:
*
Try to run existing applications, without change, on these builds to
see whether the module system, or the modularization of the
platform, breaks your code or identifies code that depends upon
JDK-internal APIs or other unspecified aspects of the platform.
*
Experiment with the module system itself, perhaps by following the
quick start guide
<http://openjdk.java.net/projects/jigsaw/quick-start>, and start
thinking about how to migrate existing libraries and application
components to modules. We hope to publish some specific migration
tips shortly.
Please send usage questions and experience reports to the jigsaw-dev
<http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev> list.
Specific suggestions about the design of the module system should be
sent to the JSR 376 Expert Group's comments list
<mailto:jpms-spec-comments@openjdk.java.net>.
For more information please seen Mark Reinhold's mail [1]
Rgds,Rory
[1]http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-September/004480...
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
9 years, 2 months
Powershell scripts
by Tomaž Cerar
Hey guys,
just heads up, I've managed to prepare[1] all powershell scripts to replace
the aging .bat ones.
New scripts unify most of the shared "code" that all scripts use by
including common.ps1,
and each script only has the code that differs from common behavior they
all share.
As result of move we now have much more reliable and faster scripts that
share common code,
which helps with maintaining a lot.
New scripts (domain.ps1 & standalone.ps1) now support --background (also
controllable via .conf.ps1)
option that runs the process in background and remembers its pid and as
such add support for
feature that until now was only in *nix version of scripts.
I would like to propose this PR for inclusion to WildFly 10. As it doesn't
alter any existing behavior
but just adds & improve the script experience on Windows.
As we get to test and verify that new scripts don't break/include any
currently available option/action
I would also like to remove the batch scripts[2], so they would just do
call out to their .ps1 counter parts.
Once this scripts get merged, I will send PR to also add PS scripts for
WildFly full defined scripts,
given that most of the functionally is already in "common.ps1" new scripts
will be just simple 5 liners [3]
--
tomaz
[1] https://github.com/wildfly/wildfly-core/pull/1118
[2] https://github.com/wildfly/wildfly-core/pull/1126
[3]
https://github.com/ctomc/wildfly-core/blob/powershell/core-feature-pack/s...
9 years, 3 months
issues with IBM JVM on Linux
by Alexey Loubyansky
I've been trying to narrow down sporadic failures in the wfcore patching
tests on the IBM JVM on Linux (version info below) for the last few
days. I wanted to share this because what I see doesn't make sense to
me. And I am not sure whether other modules have similar issues.
So, in patching tests the (sporadic) problem appears when parsing XML
attributes. E.g. if there is an element with attributes 'name' and
'add-on', sometimes the value of name will end up containing the value
of add-on attribute. Here is the actual code for this (Attribute is an
enum) from org.jboss.as.patching.metadata.PatchXmlUtils:
String name = null;
boolean isAddOn = false;
final int count = reader.getAttributeCount();
for (int i = 0; i < count; i++) {
final String value = reader.getAttributeValue(i);
final Attribute attribute =
Attribute.forName(reader.getAttributeLocalName(i));
if(Attribute.NAME == attribute) {
name = value;
} else if (Attribute.ADD_ON == attribute) {
isAddOn = Boolean.valueOf(value);
} else {
throw unexpectedAttribute(reader, i);
}
}
So, sometimes the tests fail because the value of name is 'true',
apparently. This is just one example. It affects parsing attributes in
general in this class.
I noticed that if I do anything with variable 'value' in the loop (or
pass it as an argument to some method and actually do something with it
in that method), e.g. System.err.println("value=" + value); the problem
goes away.
Another workaround I've found is to inline the variable, i.e. use
reader.getAttributeValue(i) directly instead of using a variable.
By the "problem goes away" I mean that I haven't seen these kind of
failures anymore with the changes I mentioned. To give some statistics,
with the original code the tests would fail from 2 to 5 times out of 10
runs.
With the inlined variable value they pass 100%. I've be running them for
3 days now.
Here is the JVM info.
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxi3280-20150129_02)
IBM J9 VM (build 2.8, JRE 1.8.0 Linux x86-32 20150116_231420 (JIT
enabled, AOT enabled)
J9VM - R28_Java8_GA_20150116_2030_B231420
JIT - tr.r14.java_20150109_82886.02
GC - R28_Java8_GA_20150116_2030_B231420
J9CL - 20150116_231420)
JCL - 20150123_01 based on Oracle jdk8u31-b12
Any ideas or suggestions?
Thanks,
Alexey
9 years, 3 months
