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
8 years, 4 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
9 years
Shall we limit size of the deployment in WildFly?
by Lin Gao
Hi,
WildFly does not limit the deployment file size, users with appropriate privilege(deployer) can select any file to deploy from both CLI and web console.
For the too big file, it may exhaust all available disk space, and in some cases, even small file can exhaust the disk space if the current disk space is not big enough.
So shall we limit file size of the deployment in WildFly? or shall we limit the available disk space? or shall we just show a warning message to users?
If we do, where in the management API configuration for this should be done, if it is done this way?
Arbitrary limits will break users, so if we have an arbitrary limit it needs to be easily adjusted.
In case of domain mode, different hosts may have different disk space, which means they are likely have different capacity to hold deployment files. For example, servers in server-group-A may have 2GB available disk space, servers in server-group-B may have 200MB available disk space. An unified limit for the whole domain seems not fair for the servers with more available disk space.
Also, WildFly does not limit type of the deployment file, but it might need a separate discussion if necessary?
Any thoughts?
FYI: https://issues.jboss.org/browse/WFCORE-1057
Best Regards
--
Lin Gao
Software Engineer
JBoss by Red Hat
9 years, 5 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, 5 months
Best practices for management API text descriptions
by Brian Stansberry
This thread is to flesh out some thinking about best practices for the
content of the free form text descriptions of the resources, attributes
and operations in the WildFly management model. Red Hat's user
experience team has been looking at some of the text in the admin
console, much of which comes from the server side management API
descriptions. As they start pinging subsystem authors looking for
improvements, I think it will be helpful if we use this thread to come
to some consensus around best practices.
There is a lot of information provided by the server about the
management API, going well beyond free form text descriptions. I
encourage people to review [1] and particularly sections [2] and [3].
Any management client that tries to read the text description of, say,
an attribute will automatically get the other descriptive data as well.
Type information, whether a value is required, legal values, affect on
the runtime of changing an attribute, etc.
Because the full set of descriptive data is available to a tool whenever
the text is, IMHO it makes sense *in general* to avoid repeating
information in the free form text that is already available elsewhere in
the descriptive data[4], for a number of reasons:
1) Whether or not particular bits of info will be added to the free form
text will be inconsistent, depending on what an author chose to do.
2) The language quality of the free form text will vary widely.
3) The size of our metadata payloads is already a concern. Duplicating
data by putting it in free form text increases this problem.
4) Duplicating data leads to maintenance troubles when details change,
since now the information needs to be updated in two places.
5) People doing localization need to translate more text.
Instead of duplicating data in the free form text, we're better off
looking into how our standard clients (admin console, CLI, JConsole
plugin) can best present the information present in the other descriptor
fields. For example, put a '*' next to required fields in a graphical
UI. (I think there's a HAL JIRA for that one!)
In some cases the right answer for a UI is to show a chunk of text, e.g.
in a tooltip. But even there I think the best way to show standard info
is to append standardized text to the free form text provided by the
server. So, if some attribute "max-size" has
restart-required=all-services and the free form text for "max-size"
reads "The maximum number of threads in the pool", then the console
could generate a tool tip that reads:
The maximum number of threads in the pool.
Servers must be reloaded for changes to take effect.
I think this kind of approach can work well for the "nillable",
"expressions-allowed", "min", "max", "default", "alternatives",
"requires" and "restart-required" descriptors.
For the "allowed" descriptor, the only reason to include the allowed
values in the free form text is if the meaning of the legal values isn't
clear and the free form text includes some explanation. Otherwise, a UI
can already use the "allowed" descriptor to show the legal values, e.g.
via a pull down in a GUI or tab completion in the CLI.
I'm not advocating we go off on a major expedition to change our
existing text. I do however want to avoid us adhoc adding a lot of
duplicate text, unless we come to a consensus that that's the best approach.
[1]
https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-Descr...
[2]
https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-Descr...
[3]
https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-Arbit...
[4] For example, the "restart-required" descriptor on an attribute
indicates what must happen for a change to the attribute to take effect.
So including "The server must be reloaded for a change to take effect"
in the free form text is duplication.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
9 years, 5 months
Early Access b93 is available for JDK 9 on java.net
by Rory O'Donnell
Hi Jason/Tomaz,
Thanks for confirming the fix , in addition to your fix a number of new
JEPs have been integrated into JDK 9 b93
I'd like to point you to a few that are now available for testing in
this JDK 9 Early Access build:
JEP 254: Compact Strings (http://openjdk.java.net/jeps/254)
This JEP adopts a more space-efficient internal representation for strings.
We propose to change the internal representation of the String class
from a UTF-16 char array to a byte array plus an encoding-flag field.
The new String class will store characters encoded either as
ISO-8859-1/Latin-1 (one byte per character), or as UTF-16 (two bytes per
character), based upon the contents of the string. The encoding flag
will indicate which encoding is used.
JEP 165: Compiler Control (http://openjdk.java.net/jeps/165)
This JEP proposes an improved way to control the JVM compilers. It
enables runtime manageable, method dependent compiler flags. (Immutable
for the duration of a compilation.)
Method-context dependent control of the compilation process is a
powerful tool for writing small contained JVM compiler tests that can be
run without restarting the entire JVM. It is also very useful for
creating workarounds for bugs in the JVM compilers.
JEP 243: Java-Level JVM Compiler Interface
(http://openjdk.java.net/jeps/243)
This JEP instruments the data flows within the JVM which are used by the
JIT compiler to allow Java code to observe, query, and affect the JVM's
compilation process and its associated metadata.
JEP 268: XML Catalog API (http://openjdk.java.net/jeps/268)
This JEP develops a standard XML Catalog API that supports the OASIS XML
Catalogs standard, v1.1. The API will define catalog and
catalog-resolver abstractions which can be used with the JAXP processors
that accept resolvers.
Existing libraries or applications that use the internal API will need
to migrate to the new API in order to take advantage of the new features.
Rgds, Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
9 years, 5 months
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, 5 months
Problem remoting connection with wildfly 10.0.0.CR4
by Thomas Frühbeck
Hi,
I wanted to experiment with Wildfly 10.0.0.CR4 and Remoting and got the
followin error on client side. I know, that my client works perfectly
with 9.0.2.Final.
Can you guide me to the relevant changes, is this a known problem?
WARN: Could not register a EJB receiver for connection to localhost:8080
java.lang.RuntimeException: java.io.IOException: For now upgrade
responses must have a content length of zero.
at
org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92)
at
org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77)
at
org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
at
org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:155)
at
org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115)
at
org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:47)
at
org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:271)
at
org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:281)
at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:200)
at
org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:216)
at
org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:193)
at
org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
Thanks,
Thomas
9 years, 5 months
