Study On Rejected Refactorings
by Jevgenija Pantiuchina
Dear developers,
As part of a research team from Università della Svizzera italiana (Switzerland) and University of Sannio (Italy), we have analyzed refactoring pull requests in wildfly/wildfly repository and are looking for developers for a short 5-10 min survey (https://usi.eu.qualtrics.com/jfe/form/SV_cO6Ayah0D6q4eSF). Would you please spare your time by answering some questions about refactoring-related contributions? We would greatly appreciate your input — it would help us understand how developers can improve the quality of refactoring contributions, and benefit the development process. The responses will be anonymized and handled confidentially! Thank you a lot!
If you consider this message to be spam, I'm very sorry! There will be no follow-up to bother you.
6 years
WFCORE-4807 - Log Routing
by James Perkins
Hello All,
I've got an open proposal for some changes with how log messages may be
routed [1]. There is some discussion on there with some concerns about
messages that the user may not expect to be routed to their own specific
log context. Feedback from a wider audience would be appreciated.
Currently I've got this enabled by default which would be a change in
behavior. However, as I've stated in a comment on the proposal, maybe it's
better to opt-in than opt-out. Either way any feedback would be appreciated.
Thanks in advance.
[1]: https://github.com/wildfly/wildfly-proposals/pull/281
--
James R. Perkins
JBoss by Red Hat
6 years
Progress on EE 9
by Brian Stansberry
Hi folks,
There's been quite a bit of progress recently on development of an EE 9
variant of WildFly so I'd like to provide an update.
For context, the goal is to produce in Sept/Oct a
tech-preview/beta/milestone release of a variant of WildFly that exposes EE
9 APIs, so the community can get a chance to try those out. Most of the
implementation libraries in that release will use EE 8 APIs internally
(javax.* packages instead of jakarta.*) so to make that work, when Galleon
provisions an EE9 server it will bytecode transform any artifacts that use
EE 8 APIs into ones that use EE 9 APIs.
For deployments the server management layer will, when it reads in managed
deployment content, transform EE 8 APIs to EE 9. This allows existing apps
to work, which is particularly important for our testsuite, which is full
of EE 8 apps.
Thanks to a lot of hard work from Richard Opalka, Scott Marlow and
Jean-Francois Denise and the folks on the Eclipse Transformer project I
have a branch[2] that does this. It is based on the current WildFly master,
but overrides most of the EE spec artifacts to use the ones that were
included in the June EE 9 milestone release of Glassfish. It also overrides
a few of the spec impls with native EE 9 artifacts that were used in that
release.
That branch adds a new "ee-9" maven with a few child modules, the most
important of which are 'feature-pack' and 'dist'. The 'feature-pack'
module produces a Galleon feature pack which is analogous to the wildfly-ee
feature pack, but provides EE 9 APIs. The 'dist' module then builds a dist
using that feature pack.
At this point there is no EE 9 equivalent to the top level 'wildfly'
feature pack, which adds in the Eclipse Microprofile JWT, Fault Tolerance
and Open API specs. Dealing with those is a todo.
If you do a normal 'mvn install' of this branch, the ee-9 modules will
build.
To run part of the testsuite against the EE 9 dist, do this:
mvn install -Dts.ee9 -Dts.basic
That runs testsuite/integration's 'smoke', 'web', 'ws' and 'basic' modules.
Don't include -Dts.basic if you don't want the basic module to run.
Not all tests run; some for known reasons, some for unknown ones. But a
whole lot do.
Over the course of the next few days I'll be working to get more testsuite
modules to run with the ts.ee9 profile. Once that is done I'd like us to
give some thought to producing an alpha release of WildFly so folks can
more easily try this out.
There are some important difference between this feature pack and the
regular wildfly-ee one:
1) It does not depend on the wildfly-servlet feature pack. That feature
pack IMO is a bit of a evolutionary appendix that serves little purpose in
a Galleon driven architecture; it just adds complexity. So for this EE 9
feature pack I'm directly incorporating the content that would have been in
wildfly-servlet, instead of having a dependency on an EE 9 variant of
wildfly-servlet.
It is tempting to do the same with the wildfly-core feature pack. Something
to discuss.
See [ <https://github.com/wildfly/wildfly/pull/13394>4] for more on this.
2) It does not include the legacy picketbox-based security subsystem. We
want to move to a purely Elytron-based security architecture so legacy
picketbox security is being left behind.
This brings some interesting challenges, as it surfaces a few places where
there's a default expectation for legacy security, with the user having to
do work they shouldn't have to to make that go away. Darran Lofthouse has
been looking at this.
It also brings some effort on the testing side, just because quite a few
tests expect legacy security. We've dealt with that before with running
tests with pure elytron configs.
Picketbox is still present, which means the security vault works, but I
expect at some point that will be removed. Right now it was easier to leave
it in place; otherwise it would have been removed as Picketbox is a barrier
to using JDK 14 or later.
3) The default messaging subsystem config does not include an embedded JMS
broker. Instead it is configured to point to a remote Artemis broker. Using
an external broker is a more cloud-native way to deploy an app, which is
why this variant is moving that way. The docs/examples/configs dir includes
a standalone-activemq-embedded.xml config that provides the embedded broker.
This definitely brings a big testing challenge as almost all of our tests
involving messaging, including EJB MDB tests, assume the embedded broker is
present. A quick workaround would be to run those against a server using
the example standalone-activemq-embedded.xml config, but we also need to
work out proper testing for the standard config that uses a remote broker.
4) The feature pack doesn't include various misc stuff that we either
intended to prune from WF in general at some point (JSR77, picketlink
extension, legacy subsystems that only provide domain-mode Domain
Controller support for AS 7 hosts) or where it wasn't clear what we'd do so
I left things behind just to reduce the initial scope (agroal, versions of
Hibernate other than 5.3).
5) As noted above, this is equivalent to a wildfly-ee feature pack so it
doesn't include MP FT, JWT or OpenAPI.
6) A 'thin server' (where JBoss Modules finds artifacts in maven, rather
than in the local modules dir) does not work really well, as the
transformed artifacts are not in the usual local or remote maven repos.
There are things you can do in this area, but that's too much of an
advanced case to get into here.
Besides what I noted above there are some known issues, just in case you
experiment and hit them:
a) Transforming unmanaged EE 8 apps to EE 9 is not supported. This likely
won't change for quite a while if ever. (Note: zipped apps deployed by the
deployment scanner *are* managed apps. This limitation primary relates to
exploded deployments.)
b) The transformation of the jastow library needs improvement so the
classes it generates from JSPs properly use the jakarta packages.
c) The JSF impl doesn't properly provide a jsf.js file.
I'm aiming to frequently merge master into this branch, so it keeps up to
date with changes in master. It might make sense to create an ee-9 branch
in the wildfly/wildfly github repo just to make it easier to coordinate
updates, run CI etc. But for now I'm happy to receive PRs against this
branch in my repo.
I encourage people to give this a spin.
If you're looking for things to do on this topic, please reach out to
myself or Scott Marlow or Richard Opalka. There's plenty to do but this
post is already way too long!
Best regards,
Brian
[1] https://wildfly.org/news/2020/06/23/WildFly-and-Jakarta-EE-9/
[2] https://github.com/wildfly/wildfly/pull/13453 and
https://github.com/bstansberry/wildfly/tree/ee-9
[3]
https://github.com/wildfly/wildfly/tree/master/ee-feature-pack/galleon-fe...
[4] https://github.com/wildfly/wildfly/pull/13394
6 years
gRPC in WildFly
by Ron Sigal
Recently the RESTEasy group has been looking at protobuf and gRPC and
discussing how they might fit into the JAX-RS world. We now have a
feature request (https://github.com/wildfly/wildfly-proposals/pull/326)
for exposing JAX-RS resources as gRPC servers
(https://issues.redhat.com/browse/WFLY-13530). Briefly, it would work as
follows. Compiling the proto file
service Greeter {
rpc SayHello (HelloRequest) returns (HelloReply) {}
...
}
will create a class GreeterGrpc, and a gRPC service can be created by
subclassing an inner class. Rather than implementing a gRPC service, we
propose passing the request to the appropriate JAX-RS resource,
something like this:
class GreeterImpl extends GreeterGrpc.GreeterImplBase {
@Override
public void sayHello(HelloRequest req, StreamObserver<HelloReply
responseObserver) {
JAXRSForwarderBuilder builder = new JAXRSForwarderBuilder();
builder.servlet("ResteasyServlet").pathTranslator((String s) ->
("test/" + s)); // Configure the JAXRSForwarder
JAXRSForwarder forwarder = builder.build();
forwarder.forward(req, (StreamObserver) responseObserver);
}
}
The gRPC infrasture would catch a request, dispatch it to GreeterImpl,
and the JAXRSForwarder would
1. create an HttpServletRequest and an HttpServletResponse
2. find and invoke the appropriate RESTEasy servlet
3. pass the result to the gRPC StreamObserver
The idea is to hide the complexity behind the JAXRSForwarder.
Now, this proposal is limited to extending RESTEasy. However, Darren
Lofthouse has been reading it carefully and has suggested that it could
be part of a larger discussion of how WildFly could incorporate gRPC.
Some discussion points:
1. Right now we're proposing to open a dedicated socket for the gRPC
infrastructure, which runs on top of Netty. When Undertow incorporates
Netty, maybe gRPC could share a socket with other subsystems.
2. Maybe there should be a separate gRPC subsystem.
3. Maybe we should go beyond servers and consider supporting gRPC
clients. For example, maybe gRPC clients could be injected into JAX-RS
resources the same as MicroProfile REST Clients.
4. Darren has suggested that Elytron should be involved.
In fact, I'm going to quote one of Darren's recent remarks:
> Starting to research gRPC myself it feels like the kind of thing
> where the general support / strategy within the application server
> should be defined, the individual subsystems such as JAX-RS and
> EJB which want to expose their existing deployments would then
> dynamically make their resources available through this. For areas
> such as security this would be provided consistently within the
> general support.
>
> For gRPC initially if feels like it could have a good fit with
> CDI, I don't know how practical that would be and if it would
> cause a lot of considerations that may make it a better fit as a
> SmallRye project. On one side if that gets too complex it may be
> something that makes more sense as a SmallRye project to define
> how gRPC deployments are handled, on the other side unless the
> exposing of JAX-RS endpoints is 100% automated including the
> protobuf generation it sounds like a level of user deployment may
> be necessary anyway which may mean deployment handling is required.
>
> I think the exposed socket is possibly less of an issue compared
> to the general strategy. Maybe it will be necessary to expose a
> separate server socket for now, I would have thought something
> like this could justify it's own subsystem which would mean it can
> be defined in it's own Galleon layer but that would mean as a
> subsystem it could follow a similar path the Remoting subsystem
> took i.e. exposing a port and once possible adding support to
> delegate through Undertow.
>
> Regarding the other comments about how this could integrate with
> Undertow, the main motivation for gRPC seems to be the use of this
> binary protocol we probably should be cautious that we are not
> adding too many layers on our side that requests need to be
> translated thought otherwise we may be negating the benefits from
> the outset.
>
> Recently the tasks I have been working through have involved a lot
> of DeploymentUnitProcessor refactoring to restore better
> collaboration between subsystems regarding how they share security
> policy information, so far it has been slow going and considering
> backwards compatibility there is still quite a long way to go.
> This is the reason for something like this I am interested in the
> overall architecture first so we can hopefully avoid this kind of
> retrospective refactoring as we need to enhance it further.
Any comments are welcome.
6 years
New WildFly Site
by James Perkins
Hello All,
The wildfly.org [1] will soon be changing to a new look. We are still in
the process of updating the DNS so currently the new site is not live.
However this is your heads up that it's coming. :)
For those that would like to add blog posts please see the instructions at
[2]. This is a bit different, but hopefully easier for all to build. If
there are any questions please feel free to contact me.
[1]: https://wildfly.org/
[2]: https://github.com/wildfly/wildfly.org#writing-a-news-post
--
James R. Perkins
JBoss by Red Hat
6 years
