JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net
by Rory O'Donnell
Hi Jason/Tomaz,
*JDK 10 Early Access build 33 is available at : - **jdk.java.net/10/*
Notable changes since previous email.
<http://bugs.openjdk.java.net/browse/JDK-8175094>JDK-8180019
<http://bugs.openjdk.java.net/browse/JDK-8180019> - *javadoc treats
failure to access a URL as an error , not a warning.*
If javadoc cannot access the contents of a URL provided with the -link
or -linkoffline options,the tool will now report an error.
Previously, the tool continued with a warning, producing incorrect
documentation output.
JDK-8175094 <http://bugs.openjdk.java.net/browse/JDK-8175094>*- **The
java.security.acl APIs are deprecated, for removal****
* The deprecated java.security.acl APIs are now marked with
forRemoval=true and are subject to removal in a future version of Java SE.
JDK-8175091 <http://bugs.openjdk.java.net/browse/JDK-8175091> *- The
java.security.{Certificate,Identity,IdentityScope,Signer} APIs are
deprecated, for removal*
The deprecated java.security.{Certificate, Identity, IdentityScope,
Signer} classes are now marked with forRemoval=true and are subject to
removal in a future version of Java SE.
JDK 10 Schedule, Status & Features are available [1]
Notes
* OpenJDK EA binaries will be available at a later date.
* Oracle has proposed: Newer version-string scheme for the Java SE
Platform and the JDK
o Please see Mark Reinhold's proposal [2]
*JDK 8u162 Early Access build 03 is available at :- http://jdk.java.net/8/*
<http://openjdk.java.net/projects/jdk8u/releases/8u162.html>
*Feedback* - If you have suggestions or encounter bugs, please submit
them using the usual Java SE bug-reporting channel.
Be sure to include complete version information from the output of the
|java --version| command.
Regards,
Rory
[1] http://openjdk.java.net/projects/jdk/10/
[2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
6 years, 11 months
Registering a WS handler to deal with error at Narayana/XTS/WFTC integration
by Ondra Chaloupka
Hi guys,
I wonder if there is somebody to help me with this issue[1]?
Issue:
Any call leaving EJB is checked if there is no active transaction[2]. WFLY
code communicate with WFTC which maintains its own notion about active
transactions (and Narayana code maintains its own too).
If there is a transaction imported from incoming WS call (XTS trasaction)
then Narayana code suspends transactions at its side before EJB checker is
called. But in case of WFTC the notion about the transaction status is
untouched. Thus EJB checker then throws exceptions.
Solution:
I'm thinking to create a new WS handler which would suspend the WFTC
transaction similar how Narayana code does so[3]. But I need to add a new
WS handler as dependency to the app deployment for that works[4]. Thus I
would need a special WFLY module containing the handler, depending on WFTC,
Narayana, XTS and WS modules.
There is no such module having that kind of dependencies currently.
Creating a special module for single java class sounds me wrong.
Would have somebody an idea of handling this type of situation?
I would think is there some option to create a dynamic module
programmatically to register the WS handler? I was checking about options
to register WS handler in instance but that seems not possible in WFLY
integration code.
Thank you for any thought
Ondra
[1] https://issues.jboss.org/browse/WFLY-9455: Unable to roll back active
transaction thrown for EJB bridge transactions
[2]
https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java...
[3]
https://github.com/jbosstm/narayana/blob/master/txbridge/src/main/java/or...
[4]
https://github.com/wildfly/wildfly/blob/master/xts/src/main/java/org/jbos...
7 years
WildFly asciidoc based documentation
by Tomaž Cerar
Hey guys,
TL;DR
I've converted confluence docs asciidoc [1] [2] ones that will be part of
WildFly codebase,
take a look at them and let me know if there are any big issues.
----
full version:
as most of you already know, I was working on moving our confluence based
[1] documentation to asciidoc based one.
result can be seen at [7] or rendered to html at [8]
A good side effect of conversion is that now docs are also browsable
directly on GitHub.
For example [2] or [3]
Currently I kept same structure as we had in confluence, which in practice
means
we have set of "guides" that than have lots of sub pages / includes that
produce "big" guides.
Currently such guides are:
- Admin Guide
- Developer Guide
- Getting started guide
- Getting Started Developing Applications Guide
- High Availability Guide
- Extending WildFly guide
- JavaEE 7(6 actually) Tutorial
- Elytron security guide
- quickstarts
- Testsuite
Problem is that some of this guide as such make sense, but not all of them
do.
In some cases we have duplicated docs for same thing, in others we content
in wrong segment.
For example instead of having all subsystem reference docs under admin
guide,
some are under Developer Guide and some even under HA guide.
Going forward we should "refactor" docs a bit, so we would end up with 3-4
high quality guides.
We should also go trough all docs and remove/update the outdated content.
Plan is also to have documentation now part of WildFly codebase.
So when we would submit PR with new feature, it would also include
documentation for it as well.
Rendered docs can be build as part of our build / release process and can
be rendered to different formats.
for example default is HTML [5] or PDF [6]
I've send experimental PR to show how docs would fit into WildFly build [4]
Please take look at current docs and if you have any comments / suggestions
what we can improve before merging it let me know.
At this point I've not done much content-wise changes but just conversion +
formatting ones.
Content updates can come after this is merged.
--
tomaz
[1] https://docs.jboss.org/author/display/WFLY/Documentation
[2]
https://github.com/ctomc/docs-playground/blob/master/admin-guide/Operatin...
[3]
https://github.com/ctomc/docs-playground/blob/master/developer-guide/EJB3...
[4] https://github.com/wildfly/wildfly/pull/10523
[5] https://ctomc.github.io/docs-playground/Admin_Guide.html
[6] https://ctomc.github.io/docs-playground/Admin_Guide.pdf
[7] https://github.com/ctomc/docs-playground
[8] https://ctomc.github.io/docs-playground/
7 years
Incorrect log message about allowed elements in configuration files?
by Jaikiran Pai
I was experimenting with something on the just released WildFly 11 and
lazily added the "system-properties" element within the server element,
after the socket-binding-group in standalone.xml. Something like this:
<server xmlns="urn:jboss:domain:5.0">
.....
<socket-binding-group>
...
....
</socket-binding-group>
<system-properties>
<property name="test.wfly" value="hello world"/>
</system-properties>
</server>
Then booted the standalone server and ran into this improved error
message at startup:
17:51:32,950 ERROR [org.jboss.as.controller] (Controller Boot Thread)
OPVDX001: Validation error in standalone.xml
-----------------------------------
|
| 510: </socket-binding-group>
| 511:
| 512: *<system-properties>**
**| ^^^^ 'system-properties' isn't an allowed element here*
|
| *Elements allowed here are: *
| deployment-overlays management *system-properties*
| deployments paths vault
| extensions profile
| interfaces socket-binding-group
|
| 513: <property name="test.wfly" value="hello world"/>
| 514: </system-properties>
| 515:
|
| 'system-properties' is allowed in elements:
| - server
| "
|
| The primary underlying error message was:
| > ParseError at [row,col]:[512,5]
| > Message: WFLYCTL0198: Unexpected element
| > '{urn:jboss:domain:5.0}system-properties' encountered
|
I understand why it errored out (it expects the system-properties to be
after the "extensions" element, than at the end) and I fixed the config
to get past it. However, the interesting bit is that the error message
that it threw states that "system-properties" isn't allowed at that
location and the elements that are allowed there displays a bunch of
elements which also includes "system-properties".
I haven't looked up the code to see how that log message is generated
and if it's just a logging issue or something more. Thought of noting it
here in the list.
-Jaikiran
7 years
Introducing a new thread pool implementation
by David Lloyd
For WildFly 12 I intend to introduce a new thread pool implementation
[1] [2] that will replace most, if not all, uses of ThreadPoolExecutor
in the main codebases of WildFly and WildFly Core, and also in several
support projects such as JBoss MSC and XNIO.
The thread pool has the following desirable characteristics:
• Idle threads are always reused before queueing tasks or starting new threads
• The most recently used idle thread is always preferred, which allows
the pool to shrink when it is not fully utilized
• Useful core/max thread pool size distinction
• API-equivalent to ThreadPoolExecutor
• Performance parity with common ThreadPoolExecutor configurations
• Suitable as a replacement for other jboss-threads thread pool types as well
In addition, it presents the following features:
• Configure via a builder API
• Configurable exception handler
• Integrated task queue with optional size limit
• Full complement of standard metrics, which can be disabled
• Configurable rejection handler in the form of a handoff executor
• An optional growth-resistance algorithm which can be applied to
larger pools to create growth resistance between the core and maximum
pool size
• An optional post-terminate task
• A few system property based adjustments that can be applied for
experimental purposes
• A global flag which can be set via system property to recommend that
the new thread pool should be disabled, allowing an emergency fallback
in case of an unexpected problem
Design-wise, the thread pool is based on a special lock-free/wait-free
combination FIFO/LIFO queue algorithm. See [3] for a more complete
explanation of internal operation, if you're curious about the gritty
details.
This change has a few implications with regards to the application server:
• Thread pools with a core- and max-size which were locked together
may now have these variables decoupled in a safe and useful manner
• Thread pool configurations in the management model which previously
featured only a max size can now have a core size attribute introduced
Most of the thread pools we use are built and configured within the
wildfly-core code base; that is where the first part of this change
will be done. Later on there will be a follow-up change for WildFly
proper, but this of course can not happen until the core change is
merged and a core release done, so expect that part somewhat later.
The initial WIP change to wildfly-core can be found here [4]. Note
that no pull request will be opened until all the components are
Final. I have done a good deal of testing already, but I will be
doing more CI testing on other platforms and configurations before
submitting the PR.
I've made an attempt to link up all the JIRAs that are related to this
effort from [1] (either directly or indirectly). If you find another
JIRA that you think is related, or if you have questions or concerns,
ask on this list, or you can ping me directly on HipChat or IRC.
Thanks!
[1] https://issues.jboss.org/browse/JBTHR-38 - Introduce new thread
pool implementation
[2] https://github.com/jbossas/jboss-threads/commit/be95b8d6b42128
[3] https://github.com/jbossas/jboss-threads/commit/be95b8d6b42128#diff-f5807...
[4] https://github.com/dmlloyd/wildfly-core/tree/threadpool
--
- DML
7 years
EE Features in WildFly Core
by Darran Lofthouse
Just sending this e-mail to check how we feel about EE APIs leaking into
WildFly Core. The WildFly Elytron subsystem already contains JACC related
configuration so has a dependency on the JACC APIs - JASPIC is about to be
added next which will also need a dependency on the JASPIC API so I wanted
to check if we are happy with this or if we want to get this corrected.
I see a few options but other inspiration is also welcome.
1 - Do Nothing
Just continue adding EE related security configuration to the WildFly
Elytron subsystem.
2 - Move the Elytron subsystem to WildFly
We have been over this in the past so I think we agree this would not work
for us.
3 - Dynamically exclude portions of the model if not being used for EE
management.
This would help the subsystem be specific for it's server process but TBH
does not solve the underlying problem as it would still be within WildFly
Core.
4 - Add an elytron-ee subsystem to WildFly
Capabilities allow two subsystems to work together well, main issue now
security related config could be across two subsystems although very minor
difference in the addres.
5 - Any other ideas?
Regards,
Darran Lofthouse.
7 years
