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, 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
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
Upcoming WF10 Dates (Reminder)
by Jason Greene
Hello Everyone,
First off, I just wanted to say thank you everyone for hitting the major deliverables for the WF10 Beta release that went out over the weekend!
The remaining schedule for WF10 is as follows:
WildFly 10 CR1 - September 9th
WildFly 10 CR2 (if needed) - September 16th
WildFly 10 Final - October 8th (contigent on certification)
So that means we have 26 days (17 workdays left) to:
- Stabilize features brought in during Alpha/Beta cycle
- Finish/polish compatibility (transformers, management ops, etc)
- Upgrade all components to Final (preferable) or CR (exceptional)
- Fix broken and/or intermittent tests relating to the above
- Address any other loose ends
We should avoid (if possible) introducing new major features to allow for enough time to do the above. Let me know ASAP if thats a problem.
Thanks!
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
9 years, 3 months
Perf tip for folks writing management code
by Brian Stansberry
If you're writing code that manipulates potentially large chunks of the
management model, be cautious of the following:
1) org.jboss.as.controller.Registry.Tools.readModel(final Resource resource)
This makes a deep clone of all the DMR model nodes in the given resource
tree. That may be a good thing, but is expensive with large trees, so be
aware.
2) org.jboss.dmr.ModelNode.asPropertyList()
For each Property in the returned list, the 'value' member is a deep
clone of the corresponding element in the original model node. So, again
expensive with large trees, so be aware.
You can replace this:
for (Property prop : node.asPropertyList() {
String name = prop.getName();
ModelNode value = prop.getValue();
... do something with name and value
}
with
for (String name : node.keys()) {
ModelNode value = node.get(name);
... do something with name and value
}
I'll fix a few high impact cases of this usage.
Please resist the urge to send in lots of refactoring PRs until WF 10 is
done. ;)
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
9 years, 3 months
Number of possible capabilities registered on resource and number of runtime capabilities don't match for path: ???
by Frank Langelage
After todays upgrade to WildFly Core 2.0.0.Beta5 I see a couple of new
warings:
22:19:23,926 INFO [org.jboss.as] (MSC service thread 1-4) WFLYSRV0049:
WildFly Full 10.0.0.CR1-SNAPSHOT (WildFly Core 2.0.0.Beta5) starting
22:19:32,277 WARN [org.jboss.as.controller] (Controller Boot Thread)
Number of possible capabilities registered on resource and number of
runtime capabilities don't match for path: [("interface" => "management")]
22:19:32,284 WARN [org.jboss.as.controller] (Controller Boot Thread)
Number of possible capabilities registered on resource and number of
runtime capabilities don't match for path: [("interface" => "public")]
22:19:32,287 WARN [org.jboss.as.controller] (Controller Boot Thread)
Number of possible capabilities registered on resource and number of
runtime capabilities don't match for path: [("interface" => "unsecure")]
22:19:32,450 WARN [org.jboss.as.controller] (ServerService Thread Pool
-- 26) Number of possible capabilities registered on resource and number
of runtime capabilities don't match for path: [("subsystem" =>
"batch-jberet")]
22:19:32,454 WARN [org.jboss.as.controller] (ServerService Thread Pool
-- 26) Number of possible capabilities registered on resource and number
of runtime capabilities don't match for path: [
("subsystem" => "batch-jberet"),
("in-memory-job-repository" => "in-memory")
]
22:19:32,501 WARN [org.jboss.as.controller] (ServerService Thread Pool
-- 3) Number of possible capabilities registered on resource and number
of runtime capabilities don't match for path: [("subsystem" => "jsr77")]
22:19:32,551 WARN [org.jboss.as.controller] (ServerService Thread Pool
-- 18) Number of possible capabilities registered on resource and number
of runtime capabilities don't match for path: [("subsystem" =>
"transactions")]
22:19:32,557 WARN [org.jboss.as.controller] (ServerService Thread Pool
-- 8) Number of possible capabilities registered on resource and number
of runtime capabilities don't match for path: [("subsystem" => "security")]
22:19:32,581 WARN [org.jboss.as.controller] (ServerService Thread Pool
-- 13) Number of possible capabilities registered on resource and number
of runtime capabilities don't match for path: [("subsystem" => "sar")]
What's this?
9 years, 3 months
unable to join irc channel
by ivange larry
Hi all
My name is Ivange Larry and am new to wildfly. I have tried to join
#wildfly on irc using xchat with no success. When i run /join #wildfly, i
get something like cannot join this channel, need to be identified with
services. How can i fix this.
Thanks
9 years, 3 months
