WildFly Client Configuration 1.0.0.Alpha1
by David M. Lloyd
I've tagged and released version 1.0.0.Alpha1 of the WildFly Client
Configuration library. It is on GitHub [1] and in Maven as
org.wildfly.client:wildfly-client-config. It requires Java 8.
This library will be the basis of the common client configuration file
that will be shared by (at a minimum) Remoting, EJB, remote JNDI, remote
JTA, and Elytron. It is my hope that we will also migrate other clients
to this as well before the WildFly 10 release.
There are some similarities between this project and StAXMapper so it's
possible (but not necessary) that at some point in the future we may
want to try and combine the two projects. This can be a later discussion.
[1] https://github.com/wildfly/wildfly-client-config
--
- DML
10 years, 1 month
Administrator Encouragement
by Darran Lofthouse
Last week a few of us started talking about the possibility of adding a
capability to WildFly that for want of a better name I was calling
"Administrator Encouragement".
I am not looking for this to be a design thread, that can come later but
the general principal was that subsystems could register warnings with
some kind of central service that admin tools could then retrieve later
to advise administrators that some configuration could be required to
improve their installation. Warnings would potentially have a severity
level and tooling would potentially have the option to guide the user to
the correct place to resolve the issue.
Anyway the purpose of this thread is that I wanted to try and gather
together the kinds of warnings that we could be outputting, below is a
list of some I have thought of already but would be interested in
hearing any additional ideas.
- SSL is not configured.
- SSL certificates are due to expire.
- Plain text password detected in the configuration.
- Some form of file based storage in use but growing beyond intended size.
- Default node name has not been changed.
- Patches available but not applied, subsequent releases available.
Anyway these are just a few ideas and interested in hearing any more.
Regards,
Darran Lofthouse.
10 years, 1 month
Early Access builds for JDK 9 b48, JDK 8u40 b23 & JDK 7u80 b05 are available on java.net
by Rory O'Donnell
Hi Jason/Tomaz,
Now that JDK 9 Early Access build images are modular [1], there is a fresh
Early Access build for JDK 9 b48 <https://jdk9.java.net/download/>
available on java.net.
The summary of changes are listed here
<http://www.java.net/download/jdk9/changes/jdk9-b48.html>
In addition, there are new Early Access builds for the ongoing update
releases.
The Early Access build for JDK 8u40 b23
<http://jdk8.java.net/download.html> is available on java.net, with the
summary of changes listed here.
<http://www.java.net/download/jdk8u40/changes/jdk8u40-b23.html>
Finally, the Early Access build for JDK 7u80 b05
<https://jdk7.java.net/download.html>is available on java.net,
with the summary of changes listed here.
<http://download.java.net/jdk7u80/changes/jdk7u80-b05.html>
As we enter the later phases of development for JDK 7u80 & JDK 8u40,
please log any show stoppers as soon as possible.
Rgds,Rory
[1] http://mreinhold.org/blog/jigsaw-modular-images
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
10 years, 1 month
"Boot time" system props in the managed server's model
by Brian Stansberry
tl;dr
We have a minor anomaly in system property processing in domain mode
that we intend to ignore.
long version
While digging into a bug Emmanuel Hugonnet noticed an anomaly. When you
define a system-property resource in domain.xml or host.xml with
"boot-time=true", the HC does both of the following when it launches a
server:
1) Uses -D to set the prop when it starts the server process.
2) Adds an add system-property op to the server's set of boot ops, which
causes the system property to get set again later during boot.
Really, only 1) should happen; that's what "boot-time=true" means. The
purpose of boot-time=true is to ensure the value is set at JVM launch,
not waiting for management ops to execute, which may be too late for
props that are read early.
The other thing that happens is when you add such a prop to the domain
or host model, we immediately execute an add op on all relevant running
servers. This somewhat ignores a possible meaning of "boot-time=true",
which implies the prop needs to be set at boot. Since that hasn't
happened, really the server should be put into restart-required state.
But, at this point we intend to leave the behavior as is. It's been this
way for a long time and people may be unknowingly counting on the prop
being directly written and the server not going into restart-required.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
10 years, 1 month
Making JMX connections to wildfly over ip6
by Rob Stryker
Hey all:
JBoss Tools' code to connect to wildfly over JMX seems to work fine
except when using ip6. Code is simple:
JMXConnector connector = null;
try {
connector = JMXConnectorFactory.connect(new
JMXServiceURL(url), environment);
MBeanServerConnection connection =
connector.getMBeanServerConnection();
synchronized(this) {
this.connectionToConnector.put(connection, connector);
}
return connection;
} catch(IOException ioe) {
The environment is an empty HashMap<String,String>.
The url is: service:jmx:http-remoting-jmx://fe80::5e51:4fff:fee6:e7ea:9990
I've also tried an alternate url such as
service:jmx:http-remoting-jmx://[fe80::5e51:4fff:fee6:e7ea]:9990
The server was started with the following program args:
-mp
"/home/rob/apps/jboss/unzipped/wildfly-8.2.0.CR1-SNAPSHOT.zip.expanded/modules"
-jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b
fe80::5e51:4fff:fee6:e7ea --server-config=standalone.xml
-Djboss.server.base.dir=/home/rob/apps/jboss/unzipped/wildfly-8.2.0.CR1-SNAPSHOT.zip.expanded/standalone
And the following vm args:
"-Dprogram.name=JBossTools: WildFly 8.x (1)" -server -Xms64m -Xmx512m
-XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true
-Djava.net.preferIPv4Stack=false -Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000
-Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
"-Dorg.jboss.boot.log.file=/home/rob/apps/jboss/unzipped/wildfly-8.2.0.CR1-SNAPSHOT.zip.expanded/standalone/log/boot.log"
"-Dlogging.configuration=file:/home/rob/apps/jboss/unzipped/wildfly-8.2.0.CR1-SNAPSHOT.zip.expanded/standalone/configuration/logging.properties"
"-Djboss.home.dir=/home/rob/apps/jboss/unzipped/wildfly-8.2.0.CR1-SNAPSHOT.zip.expanded"
-Dorg.jboss.logmanager.nocolor=true
-Djboss.bind.address.management=fe80::5e51:4fff:fee6:e7ea
Thanks in advance.
- Rob Stryker
10 years, 1 month
Management model attribute groups - example fixed
by Tomasz Adamski
Sent once again because of broken examples in previous mail:
I would like to raise once again the issue of nested attribute groups.
I started rewriting iiop subsystem so that it uses attribute groups and I think that in many cases it would be covenient and more descriptive if we are able to nest attribute groups.
There are two models related to it: subsystem xml description and management api but I believe that both of them may benefit from nested attributes.
Example:
Currently ior-settings xml tag is used to group all ior releted configuration:
<ior-settings>
<as-context integrity="required" (...)/>
<sas-context auth-method="username_password" (...)/>
<transport-config caller-propagation="supported" (...)/>
</ior-settings>
After attribute group refactor it would currently turn to:
<as-context integrity="required" (...)/>
<sas-context auth-method="username_password" (...)/>
<transport-config caller-propagation="supported" (...)/>
It would be nice to be able to group them together once again. This may be achieved by adding methods to PersistentResourceXMLDescription which will make it possible to create more complex xml schema independent of attribute groups. On the other hand, what is beneficial from xml point of view may also be beneficial for management tools: if those three elements have all different groups there they could be displayed separately after sort but if we created a nested groups and do a nested sorting of them then they could be grouped together in management tools too. Moreover, all information about attribute will still be containted in its definition and subsystem creation using PersistentResourceXMLDescription will stay as simple as it is now.
Having that in mind I would suggest extending the group notion from flat to nested and create direct mapping between group parts and xml tags.
In the above example we would have:
AttributeDefinition INTEGRITY = (...).setAttributeGroup("ior-settings.as-context")(...)
AttributeDefinition AUTH_METHOD = (...).setAttributeGroup("ior-settings.sas-context")(...)
AttributeDefinition CALLER_PROPAGATION = (...).setAttributeGroup("ior-settings.transport-config")(...)
PersistentResourceXMLDescription xmlDescription = builder(IIOPResourceDefinition.INSTANCE).addAttributes(IIOPResourceDefinition.INTEGRITY,IIOPResourceDefinition.AUTH_METHOD,IIOPResourceDefinition.CALLER_PROPAGATION)(...)
This would create parser able of parsing:
<subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
(...)
<ior-settings>
<as-context integrity="required" (...)/>
<sas-context auth-method="username_password" (...)/>
<transport-config caller-propagation="supported" (...)/>
</ior-settings>
(...)
</subsystem>
Problems:
How to represent the group in management api?
LIST vs STRING
:read-attribute-group(group=foo.bar) vs :read-attribute-group(group=[foo,bar])
:read-attribute-group(group=foo) vs :read-attribute-group(group=[foo])
String seem more convenient but there are some consequences of keeping a LIST (which attribute group actually is) in the form of the STRING: some parts of management client code will have to do additional work because of that (f.e. string parsing), tab completion feature will have to hint string part by part which may be not consistent with other parts of api etc.
10 years, 1 month
Transactions in Batch (JSR 352)
by James R. Perkins
In the JSR 352 batch specification there are some issues around
transactions with JCA. These issues would mainly be seen with JDBC item
readers/writers.
Here is kind of a thought dump from a sit down I had with the JCA team.
If anyone has any opinions on how this should be handled let's talk it
out. I would imagine this is a fairly important issue as generally
speaking batch jobs will likely be legacy jobs and JDBC is probably
heavily used.
*Batch Transactions with JCA*
*Problem:*
Batch requires that a Transaction.begin() and a Transaction.commit() for
each open, close and chunk processed. This causes connections from JCA
to potentially cross transactional boundaries.
This requires that the JCA CachedConnectionManager (CCM) is enabled
for the resource in question (Jesper)
*Transaction code should be written like:*
Connection c
Transaction.begin()
c = DataSource.getConnection()
c.close()
Transaction.commit()
*Chunk Processing process:*
Transaction.begin()
ItemReader.open()
ItemWriter.open()
Transaction.commit()
repeat until item reader returns null
Transaction.begin()
repeat-on-chunk
ItemReader.readItem()
ItemProcessor.processItem()
ItemWriter.writeItems
Transaction.commit()
Transaction.begin()
ItemReader.close()
ItemWriter.close()
Transaction.commit()
Where seen:
* No errors in 8.1+
* Upstream with the tracking set to true and exception is thrown;
/subsystem=datasources/data-source=ExampleDS:write-attribute(name=tracking,
value=true)
* https://gist.github.com/jamezp/cf39f92913425c83929f
o This shows where the connection was allocated that is crossing
the transaction boundary, and hence killed (Jesper)
Questions:
* Will the tracking attribute be used often?
o The feature is meant to allow people to find where in their code
they are making assumptions that isn't true (Jesper)
+ The corner case is just the "c.close()" call (Jesper)
*Possible Fixes:*
* Leave batch as is. If the tracking attribute is set to true
exceptions will be thrown
o Remember that the underlying connection will be killed (Jesper)
* Add a property to jBeret to use local (fake) transactions. This is
what we currently do and I feel it's just wrong.
* Create a deployment descriptor (or possibly a property that can be
passed when starting the job) to allow different styles for transactions
Example JBoss Way
repeat until item reader returns null
Transaction.begin()
ItemReader.open()
ItemWriter.open()
repeat-on-chunk
ItemReader.readItem()
ItemProcessor.processItem()
ItemWriter.writeItems()
ItemReader.close()
ItemWriter.close()
Transaction.commit()
--
James R. Perkins
JBoss by Red Hat
10 years, 1 month
Management model attribute groups
by Brian Stansberry
Off and on we've had discussions around the idea of "attribute groups".
We've got some use cases that are crying out for such a thing[1], so I'd
like to propose doing something concrete but simple for these for WF 9,
ideally in the next month.
A big part of my goal here is to ensure that whatever we do doesn't
preclude something more advanced in any next generation management
stuff, e.g. David's stuff.
PART I Concepts
1) What is an attribute group?
The "attribute group" concept I propose is simply a collection of
attributes associated with the same resource type that are independently
configurable but are statically declared to be conceptually related. The
group has a name, and members. The name provides a brief indication of
the nature of the relationship.
The goal is to provide information to the user to help them better
understand the relationship between attributes. In particular,
management tools could use this information to visually present related
attributes together, e.g. in a tab or other grouping widget in the web
console.
2) What isn't an attribute group?
Something relevant to writes.
3) Why would I use a child resource instead of an attribute group?
Because the attributes control a discrete piece of functionality and you
need to be able to turn that on or off as a unit. So you add/remove the
resource.
4) Why would I use a complex attribute with a bunch of fields instead of
n>1 simple attributes in a group.
a) Because the attributes control a discrete piece of functionality and
you need to be able to turn that off as a unit. So users can undefine
the complex attribute.
b) Because it's a common use case that modifications to n>1 of the
fields should be done atomically and you don't want to force users to
use a CLI batch. So you let them use write-attribute and specify the
value of all the fields.
5) Why would I use an attribute group instead of a child resource?
Because requiring users to add a child resource just to set a bunch of
values that are really part of the config of the parent resource forces
them to use a CLI batch to correctly configure the parent resource.
6) Why would I use an attribute group instead a complex attribute?
Because the various attributes should be independently configurable. In
particular, wiping out the config for all of them by simply undefining
the complex attribute isn't appropriate.
PART II Proposed Work
1) The basics
We add a piece of metadata to the read-resource-description output for
an attribute. Name is 'attribute-group', value type is ModelType.STRING,
value is the name of the group, with 'undefined' allowed.
The group is simply the set of attributes that share the same string.
To implement this, we add public String
AttributeDefinition.getAttributeGroup() and add support for setting it
to the relevant Builder. ReadResourceDescriptionHandler outputs the value.
2) XML parsing/marshalling
Modify PersistentResourceXMLDescription such that attributes in an
attribute group get persisted in their own child element, whose name is
the name of the group.
PersistentResourceXMLBuilder exposes a setter to allow users to turn
this on/off for that resource. Turning it off will allow the addition of
attribute group settings for a resource without requiring an immediate
corresponding xsd change.
3) Web console
HAL can make use of the additional metadata at its leisure, and as it
becomes available.
4) Low level management API
The output of read-resource and read-resource-description is modified
such that attributes are sorted by group name and then by attribute name.
5) CLI
I'm not clear on exactly what to do here, but my instinct is the output
of the 'ls -l' command should be modified. Probably add a GROUP column
to the right and sort the order of attributes by group and then by
attribute name.
PART III Other possible things to do
A :read-attribute-group(name=<groupname>) operation or an
"attribute-groups=[<groupname>*]" param to :read-resource, to make it
convenient to read a set of attributes without needing to read the
entire resource.
We could also consider adding an "attribute-groups" section to the
read-resource-description output, where a fuller i18n text description
of the meaning of the group could be written. If we do this we should
probably do it in WF 9 as it will likely add some sort of requirement to
subsystem authors that we expose right from the start.
If you're still awake, comments as always are appreciated.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
[1] For example, the JDKORB pull request at
https://github.com/wildfly/wildfly/pull/7008 uses child resources in a
number of places where it seems like attribute groups are a better fit.
10 years, 1 month
Propagation of user credentials or user session between two WildFly servers
by Manikanta Vasu
Hi,
I have two WildFly 8.1.0 instances (A and B) secured by the same custom
SecurityDomain.
Client authenticates on 'server A' and performs invocation of Stateless
Bean on that server. Then, bean on 'server A' performs remote invocation of
a Bean on 'server B'. So the invocation looks like this: Client -> server A
-> server B. All communication is done via http-remoting connection, scoped
EJB client context.
The question is how to propagate client credentials or user session to the
server B?
Is it possible to configure Wildfly server A in the way that context of the
logged user is passed from the client further to the server B? Any ideas?
Is it possible or just bad idea?
I'm not sure if some kind of SSO should be applied here. what are your
thoughts?
10 years, 1 month
Need ideas. Calling REST endpoint from a subsystem
by Stan Silvert
* I need to call Keycloak's REST endpoints from a WildFly 9/10 subsystem.
* The endpoints can be local or remote
* Before I make the call, I do know if it is local or remote.
What is the best way to do this? I'd like to do something better than
using Apache HTTP Client.
It is also possible that we change Keycloak to expose itself in a
different way. I'm just looking for the best overall solution.
Any ideas?
Stan
10 years, 1 month
