Re: [wildfly-dev] Starting/monitoring JSR 352 batch job through admin console
by Cheng Fang
That's good to know. If you need any change on jberet side, let James and
I know.
Thanks,
Cheng
On Fri, May 27, 2016 at 1:42 PM, Claudio Miranda <claudio(a)redhat.com> wrote:
> On Fri, May 27, 2016 at 2:33 PM, James Perkins <jperkins(a)redhat.com>
> wrote:
> > I'm not sure on the JIRA, but I know Claudio in CC is working on it now.
>
> Hi, I am working on it right now.
>
> https://issues.jboss.org/browse/HAL-1104
>
> --
> Claudio Miranda <claudio(a)redhat.com>
> Senior Software Engineer - Wildfly
>
8 years, 7 months
10.1 Thoughts and Call for Ready Features
by Jason Greene
Hello Everyone,
I’d like to cut a 10.1 fairly soon, preferably in the next 2-3 weeks. My thinking is to take everything that is not explicitly tagged as 11.x and merge it ASAP. Really this should just be anything that doesn’t add instability, or introduces a half-finished API that we then have to support (the obvious exception is experimental capabilities that we denote as such). This is a bit of a departure from what I was suggesting earlier, where we we would cherry-pick major items into a separate branch, so if you have any concerns now is the time to raise them.
This release would be a good opportunity to include features that are ready to go (suitable for a final release in 2-3 weeks) but didn’t make 10.0 (I have a feeling Sanne has been itching for some updates to search!). If you have something then send a PR (noting that you want it in 10.1) or raise your figurative hand :)..
Thoughts?
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
8 years, 7 months
Early Access builds of JDK 9 b118 & JDK 9 with Project Jigsaw, b118 (#4987) are available on java.net
by Rory O'Donnell
Hi Jason/Tomaz,
Early Access b118 <https://jdk9.java.net/download/> for JDK 9 is
available on java.net, summary of changes are listed here
<http://www.java.net/download/java/jdk9/changes/jdk-9+118.html>.
Early Access b118 <https://jdk9.java.net/jigsaw/> (#4913) for JDK 9 with
Project Jigsaw is available on java.net.
JDK 9 Build 118 includes a refresh of the module system.
There are several changes in this update, JDK 9 b118 has the updated
policy for root modules described
in JEP 261 [1]. This means that java.corba and the 6 EE modules aren't
resolved by default and so it will
look "as if" the types in these modules have been removed. More info on
the JDK 9 dev mailing list [2].
A change that went into JDK 9 b102 is worth mentioning:
JDK9: Remove stopThread RuntimePermission from the default java.policy
In previous releases, untrusted
code had the "stopThread" RuntimePermission granted by default. This
permission allows untrusted code
to call Thread.stop(), initiating an asynchronous ThreadDeath Error, on
threads in the same thread group.
Having a ThreadDeath Error thrown asynchronously is not something that
trusted code should be expected
to handle gracefully. The permission is no longer granted by default.
Rgds,Rory
[1] http://openjdk.java.net/jeps/261
[2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004309.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
8 years, 7 months
Specify algorithm and key-size for password vault in WildFly?
by Lin Gao
Hi,
There is a Jira: WFLY-6569[1] open about password vault, which asks for specifying KEY_SIZE to encrypt the sensitive data in vault data file.
The key size is bound up with the algorithm it uses, currently the vault.sh|.bat only allows AES(no place to specify other algorithm) to encrypt sensitive data, and uses key size of 128.
Alougth we can specify the key size after doing some fix, it needs extra set-up work for some JDKs(like Oracle JDKs) to be able to use key size of 192 and 256 for AES. This leads to that only specifying the key size is not so worthy.
Maybe we should specify both algorithm and key size to encrypt the vault data?
[1] https://issues.jboss.org/browse/WFLY-6569
--
Lin Gao
Software Engineer
JBoss by Red Hat
8 years, 7 months
Module aliases and deprecation
by Sanne Grinovero
Hello,
I'm renaming some modules intended for WildFly users. To minimize
impact on existing users, I'm including module-aliases using the old
name, to resolve to the new module ids.
Is there a way to mark such an alias as "deprecated" to encourage
people moving to the new naming scheme?
Thanks,
Sanne
8 years, 7 months
Speed Up Deployment
by Heiko Braun
Are there any recommendations for making the deployment faster on WF? One thing I was wondering about is whether certain subsystem support precomputed jandex indexes?
Regards, Heiko
8 years, 7 months
EJB over HTTP
by Stuart Douglas
Hi everyone,
I have started looking into support for service invocation over HTTP.
Unlike our existing HTTP upgrade support this will map EJB
requests/responses directly to HTTP requests and responses, which should
allow it to be used behind existing load balancers.
I have started an initial description of the protocol at:
https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wi...
The intention is to follow HTTP semantics as closely as possible.
Clustering will be provided in a similar manner to web clustering (i.e. it
will require a load balancer, and work in a similar manner to web
clustering).
There is still plenty work that needs to be done (especially around
security), so if anyone has any feedback let me know.
Stuart
8 years, 7 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
