8.0.0.Beta1 released
by Jason Greene
Hello Everyone,
As many of you have already noticed, on Friday we released our first Beta of WildFly 8. This is a significant release because all major features on the 8 plan have been implemented; most notably all user facing Java EE7 APIs.
As always you can download the latest release here:
http://wildfly.org/download
Our overall status of the primary features follows. You can find this information, along with additional details in the official release notes:
https://community.jboss.org/wiki/WildFly800Beta1ReleaseNotes
Java EE7
========
Java EE7 offers applications several productivity improving capabilities including support for the modern web, batch processing, simplified concurrent task processing, and improvements in dependency injection. At this point all user facing EE7 APIs have been implemented! Aside from achieving compliance certification, the only remaining work is to implement a few updates in the security integration SPIs, JASPIC and JACC.
High Performance Web Server (Undertow.io)
=========================================
Undertow, the new cutting-edge web server in WildFly 8 is designed for maximum throughput and scalability, including environments with over a million connections. It supports non-blocking and blocking handlers, traditional and asynchronous servlets, and JSR-356 web socket handlers. It is highly customizable, with the ability for applications to implement nearly anything from dynamic request routing to custom protocols. It can also function as a very efficient, pure non-blocking reverse proxy, allowing WildFly to delegate to other web servers with minimal impact to running applications. Undertow has been fully integrated for several releases now. This release finalizes the key features of this integration with the addition of reverse proxy support.
Port Reduction
==============
An important goal of WildFly 8 was to greatly reduce the number of ports used by multiplexing protocols over HTTP using HTTP Upgrade. This is a big benefit to cloud providers (such as OpenShift) who run hundreds to thousands of instances on a single server. Our default configuration now only has three ports, and will become two ports by final. We decided to preserve the original native management port for this Beta release to give those using legacy clients time to update before the final release.The native management port, 9999, is deprecated and will be removed by final.
Port Bound Interface Protocols
---- --------------- ---------
9990 management HTTP/JSON Management
HTTP Upgraded Remoting - (Native Management & JMX)
Web Administration Console
8080 application HTTP (Servlet, JAX-RPC)
Web Sockets
HTTP Upgraded Remoting (EJB Invocation, Remote JNDI)
9999 (deprecated) management Remoting - Native Management
Management Role Based Access Control (RBAC) & Auditing
======================================================
WildFly can now support organizations with separated management responsibilities and restrictions. Roles represent different sets of permissions such as runtime operation execution, configuration areas that can read or written, and the ability to audit changes and manage users. In addition a new restricted audit log can be enabled including the ability to offload to a secure syslog server.
Patching
========
The infrastructure to support the application of patches to an existing install has been implemented. This capability allows for a remote client to install and rollback new static modules and binary files using the WildFly management protocol.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
11 years
WildFly 8 subsystem transformers for 7.2.0 slaves
by Kabir Khan
Hi all,
We are late enough in the WildFly 8 release cycle that we need to start thinking about transformers against 7.2.0 slaves. I have opened https://issues.jboss.org/browse/WFLY-2218 scheduled for 8.0.0.CR1 (currently major, but should probably be a blocker), and will open sub-tasks for subsystems that need transformation for 7.2.0 over the next few days. The blurb from the Jira issue:
We have not tested the majority of subsystem transformers against AS 7.2.0. I have attempted to document why we need subsystem transformation here, and also how to use the framework: https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+https:/.... This document is WIP, and I will be updating it a bit more over the next few days.
https://gist.github.com/kabir/6825607 contains the difference of a running WildFly instance against AS 7.2.0 in domain mode (for subsystems you don't really need to bother about this one)
https://gist.github.com/kabir/6825559 contains the difference of a running WildFly instance against AS 7.2.0 in standalone mode, here you can see what has changed in the subsystems.
When creating a new subsystem transformers test against 7.2.0, you will need the resource definition for the ModelVersion your subsystem uses in 7.2.0. If this is not found, you need to add a test to your subsystem, which you can delete once you have the .dmr file containing the resource defintion. Here is what I did to generate the file for JMX
@Test
public void deleteMeWhenDone() throws Exception {
ModelTestControllerVersion controllerVersion = ModelTestControllerVersion.V7_2_0_FINAL;
ModelVersion modelVersion = ModelVersion.create(1, 1, 0); //Whatever version of your subsystem 7.2.0.Final has
KernelServicesBuilder builder = createKernelServicesBuilder(null);
builder.createLegacyKernelServicesBuilder(null, controllerVersion, modelVersion)
.addMavenResourceURL("org.jboss.as:jboss-as-jmx:" + controllerVersion.getMavenGavVersion());
KernelServices services = builder.build();
generateLegacySubsystemResourceRegistrationDmr(services, modelVersion);
}
Now run the test and delete it. The legacy .dmr file should be in target/test-classes/org/jboss/as/subsystem/test/<your-subsystem-name>-<your-version>.dmr. Copy this .dmr file to subsystem-test/framework/src/main/resources/org/jboss/as/subsystem/test.
You will likely also need to update org.jboss.as.subsystem.test.KnownVersions to include your latest subsystem version, once you start doing real testing.
Bear in mind that if you need to add some transformation to 7.2.0 due to some new feature in WildFly 8, you will probably also need to add the same transformation to 7.1.x as well!
-------
Thanks to Richard Achamatowicz for 'forcing me' to write the mentioned document ;-) It explains a fair bit of background of why transformation is needed, and serves as a reference for the APIs. I hope to find the time to update it to include a more use-case oriented section as well.
Cheers,
Kabir
11 years
FW: [jboss-as7-dev] Enhancement of bundled UI with jboss
by Indranil Majumder (imajumde)
Forwarding to the right mailer. Question below.
From: Heiko Braun [mailto:hbraun@redhat.com]
Sent: Tuesday, October 08, 2013 12:54 PM
To: Indranil Majumder (imajumde)
Cc: jboss-as7-dev(a)lists.jboss.org
Subject: Re: [jboss-as7-dev] Enhancement of bundled UI with jboss
Please note that any former as7 development now takes place on [1]
I would suggest you repost your question there.
[1] https://lists.jboss.org/mailman/listinfo/wildfly-dev
On Oct 8, 2013, at 7:27 AM, "Indranil Majumder (imajumde)" <imajumde(a)cisco.com<mailto:imajumde@cisco.com>> wrote:
Where can I get the latest updates on the UI console development bundled with the community version? Is there a separate mailer for the UI development?
Thanks & Regards,
Indranil
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org<mailto:jboss-as7-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
11 years
Patching WSDL4J (or perhaps forking?)
by Alessio Soldano
Folks,
when running the jbossws testsuite against WFLY master with security
manager enabled, I've noticed that the following permission is required
to build up JAXWS clients (actually to be able to parse any WSDL):
<permission class="java.io.FilePermission"
name="/usr/java/jdk1.7.0_17/jre/lib/wsdl.properties" actions="read"/>
That's basically a non existing file in my java.home. The reason is in
WSDL4J, which seems to be missing a SecurityException catch block in
javax.wsdl.factory.WSDLFactory#findFactoryImplName().
I thought about reporting the issue, but afaics the project "lives" at
sourceforge.net (on cvs scm...) and, more important, since Oct 2011
there's already a patch proposal [1] for the issue which has never been
commented / considered.
How should we move forward here? Suggestions / proposals? Anybody here
is in the JSR-110 EG and can get in touch with the WSDL4J devs?
Alessio
[1] http://sourceforge.net/p/wsdl4j/patches/1/
--
Alessio Soldano
Web Service Lead, JBoss
11 years