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
Remove PL from WFLY
by Pedro Igor Silva
Hi,
On the last few days I've been discussing with Tomaz about the possibility to remove PL from WFLY.
The reasons for that are:
- PicketLink was deprecated in favor of Keycloak. See [1] and [2].
- Fixes are only being done to product version by GSS/SEG teams.
- Most PL IdM and Federation capabilities such as SAML (plus a plenty of other things) are now available from Keycloak.
I think we can still provide an installer (we already have that) that could be used to enable PL to a WFLY installation. That would help people using PL to continue with their designs. But for PL Federation and Subsystem, Keycloak should be the best way to go.
Any comments ?
Regards.
Pedro Igor
[1] http://picketlink.org/news/2015/03/10/PicketLink-and-Keycloak-project-merge/
[2] http://picketlink.org/keycloak-merge-faq/
8 years, 2 months
question 2 sec boot time of WISE
by Rebecca Searls
Wise was pulled from wfly because it was adding 2 sec to boot time.
Wise is a utility with a GWT interface. It was added to wfly as an extension.
It is provided as a WAR file.
Is there any more detail of the boot of this app?
Here are a few options we have thought of.
What would be the best way to address this so that the user can have access to this tool?
1. lazy deployment of the utility
2. Only provide it in standalone-full.xml
3. Handle it the way xts subsystem was with a standalone-xts conf
8 years, 3 months
Fwd: ContainerStateMonitor
by Martin Stefanko
Forwarding to the mailing list.
---------- Forwarded message ----------
From: Martin Stefanko <mstefank(a)redhat.com>
Date: Thu, Aug 25, 2016 at 1:07 PM
Subject: ContainerStateMonitor
To: david.lloyd(a)redhat.com
Hello David,
For my issue [1] I need to propagate log massage from
the ContainerStateMonitor [2] to the HAL console. As I have no experience
with the wildfly-core may I ask if there is some easy way to this? What I
see in HAL we are using operations directly on CLI. I would like to use
something in style of events and listeners if it is possible.
Thank you.
[1] https://issues.jboss.org/browse/JBEAP-5036
[2] https://github.com/xstefank/wildfly-core/blob/
master/controller/src/main/java/org/jboss/as/controller/
ContainerStateMonitor.java#L72
Martin Stefanko
Associate Software Engineer
JBoss Sustaining Engineering Team
Red Hat Czech s.r.o.
8 years, 3 months
use EL in wildfly module
by Carl Harris
This may not be the right place to ask this question -- feel free to redirect me as appropriate.
I have a CDI extension packaged as a Wildfly module. The extension evaluates some EL expressions. In order to evaluate the expressions it calls javax.el.ExpressionFactory.newInstance() to get an ExpressionFactory. However, when calling this method an exception is thrown:
Caused by: javax.el.ELException: Provider com.sun.el.ExpressionFactoryImpl not found
at javax.el.FactoryFinder.newInstance(FactoryFinder.java:102)
at javax.el.FactoryFinder.find(FactoryFinder.java:186)
at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:197)
at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:168)
at javax.el.ELUtil.<clinit>(ELUtil.java:99)
... 50 more
Caused by: java.lang.ClassNotFoundException: com.sun.el.ExpressionFactoryImpl from [Module \"javax.el.api:main\" from local module loader @18ef96 (finder: local module finder @6956de9 (roots: /tmp/wildfly-10.0.0.Final/modules,/tmp/wildfly-10.0.0.Final/modules/system/layers/base))]
I *think* the module descriptor has the right dependencies, but evidently I’m missing something.
<module xmlns="urn:jboss:module:1.0" name="org.soulwing.pinject" slot="main">
<resources>
<resource-root path="pinject-extension-1.2.0-SNAPSHOT.jar" />
</resources>
<dependencies>
<module name="org.soulwing.pinject.api" />
<module name="org.glassfish.javax.el" />
<module name="javax.inject.api" />
<module name="javax.enterprise.api"/>
<module name="javax.mail.api" />
<module name="javax.el.api" />
<module name="javax.api" />
</dependencies>
</module>
I’ve looked at some other Wildfly modules that use EL (e.g. Hibernate Validator), but I haven’t been able to discern what they’re doing differently.
carl
8 years, 3 months
10.1.0.CR1 is available! Try it out!
by Jason Greene
Some of you may have noticed that 10.1.0.CR1 was released yesterday:
http://wildfly.org/downloads/
Please give it a try and report any major issues. Provided nothing critical comes up, we will release Final next week.
Major new features include:
- Out of the box HTTP/2 support
- TLS cert auto-generation
- Load-balancing profile is now in our default domain.xml config
- Support for clustering node discovery on Azure (jgroups AZURE_PING)
Overall there are 308 issues resolved in this release:
https://issues.jboss.org/secure/ReleaseNote.jspa?version=12329499&styleNa...
Thanks again!
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
8 years, 4 months
JACCAuthorizationManager only passes roles or caller (not both) to JACC module
by arjan tijms
Hi,
I noticed that JBoss' JACCAuthorizationManager only passes the role
principals (if any) into a JACC module, as per the following code:
// create a protection domain with the user roles (or account principal if
no roles are found)
final Map<String, Set<String>> principalVersusRolesMap =
deployment.getDeploymentInfo().getPrincipalVersusRolesMap();
final Principal[] principals = this.getPrincipals(account,
principalVersusRolesMap);
final CodeSource codeSource =
servletInfo.getServletClass().getProtectionDomain().getCodeSource();
final ProtectionDomain protectionDomain = new
ProtectionDomain(codeSource, null, null, principals);
If there happen to be no roles, then and only then is the caller principal
passed to the JACC module.
I wonder if there was any specific idea here. The comment explicitly
indicates this, so it doesn't just seem a bug. But this is quite, unusual,
and also a bit confusing for a JACC module to work with.
As far as I know, no other server does this (at least GF, Payara, Geronimo,
JEUS and TomEE don't do this). You always see all the principals from the
Subject being passed in.
A JACC module can work around this by obtaining the subject directly using
"PolicyContext.getContext("javax.security.auth.Subject.container")", but
still wondering why JBoss doesn't just pass all principals here.
Any insight would be appreciated.
Kind regards,
Arjan Tijms
8 years, 4 months
Authorization manager configurable in jboss-web.xml?
by arjan tijms
Hi,
In org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.handleJACCAuthorization
I found the following comment:
// TODO make the authorization manager implementation configurable in
Undertow or jboss-web.xml
Wonder if that TODO is still on the radar.
Would be quite an improvement if an application could declare itself that
it wanted to use the Java EE authorization module (JACC), which would hold
for either the default JACC module that JBoss/WildFly ships (and
initializes) or a user provide one.
Thoughts?
Kind regards,
Arjan Tijms
8 years, 4 months
