Is there a single maven BOM artifact I can use to get/build the entire wildfly ee server?
by Eric B
I'm trying to debug some code, and I am often hitting classes in
Wildfly/Undertow/etc in my stack that I don't have the source code for.
I'd love to be able to add a dependency in my pom.xml so that Eclipse will
automatically d/l the sources from maven central for me and add them to my
debugger. I'm looking for an artifact that I'd be able to list something
like:
<dependency>
<artifactId>wildfly</artifactId>
<groupId>org.wildfly</groupId>
<version>10.1.0</version>
<scope>provided</scope>
<type>pom</type>
</dependency>
That would then download all the sources for me, and I'd be in business.
Is there something like this BOM available for wildfly?
Thanks,
Eric
6 years, 7 months
WildFly 12 Plans, EE8, and Move to Quarterly Iterative Releases
by Jason Greene
Hello Everyone,
Release Model Changes
————————————————————-
In order to bring new capabilities to the community quicker, we plan to move to a more iterative time-boxed approach, starting with WildFly 12 (and continuing with 13, 14, etc). By time-boxed, I mean the each release aims to have a fixed and reliable delivery window that approximates a calendar quarter. Since these time-frames are fixed, it’s important that any given feature or improvement not hold up a release. To facilitate this we need to make major changes to our development process. Currently development for any enhancement is merged in chunks, as it progresses from inception to completion. This means to have something worthy of release, we must either block for its completion or roll it back. The latter is often difficult, since at any given moment there are many features under active development, and their respective implementations can become co-dependent. Additionally, its common for component dependencies to start off as Alphas and/or Betas, and we end up needing to wait for those components to hit Final before we can cut the release.
The solution to this problem is to rely more on topic branches, and only merge fully completed work to master. By fully complete, I mean all PRs on master should be fully developed, tested, and documented[1]. Additionally any updated dependencies must only be against Final/GA components.
This has a number of advantages:
A. Master becomes always stable, always releasable. So at any given moment we can decided to cut a release[1]
B. Nightly builds become way more usable, and a great feedback channel (a release starts to have less importance)
C. If a feature takes longer than expected, no big deal, it will be picked up in the next cycle[2]
D. Should anything cause a major regression, not caught in testing it will be easier to revert, since the history will be cleaner
Since in-progress work will need to be based on topic branches, custom jobs on ci.wildfly.org will need to be relied upon instead of the automated CI that happens when you submit a PR (although that’s still important and still staying). Additionally if two changes/improvements are interrelated, then they will need to either share a topic branch, or find a way to construct the work independently (potentially adding and removing a temporary construct until both are merged).
[1] To make it easier to associate documentation with the PR, we are looking to move to an asciidoc based solution instead of confluence like we utilize today.
[2] While this is generally the case, there are some activities we can’t avoid before releasing, such as ensuring a TCK run has completed.
[3] An important aspect of C is that iterations have a short enough cycle, such that the pressure to make a particular iteration is low enough to avoid the urge to try and cram something in, and potentially compromise quality (e.g. no docs etc).
Java EE8
————————
As part of adopting this model, we aim to deliver Java EE8 in incremental chunks. Adding support for specs individually in batches. As an example for WildFly 12, I propose we target Servlet 4, JSON-B, and CDI. Due to unfortunate restrictions in EE certification, we will need to have a separate configuration profile or property to enable these additional APIs until we complete full EE8 certification.
Proposed WildFly 12 Goals [Target Release Date = Feb 28, 2018]
————————————————————————
+ Adopt new release model
+ Java 9 improvements
+ Servlet 4
+ JSON-B (incorporating Yasoon)
+ CDI 2
+ JSF 2.3
+ Metaspace usage improvements
+ early/initial changes to accommodate the new provisioning effort (easy slimming, updates, etc)
Proposed WildFly 13 Goals (Very Tentative) [May 2018]
———————————————————————————-
+ New EE Security Spec
+ Adoption of provisioning
+ JPA 2.2
+ JAX-RS 2.1
+ BV 2.0
+ Agroal inclusion
Just to highlight that with this new model, that these goals I am proposing are not something we would block on, any given item might be deferred to the next release if it’s not quite ready. Let me know if you have any additional major items you are planning to contribute towards 12.
Thanks!
-Jason
6 years, 10 months
Re: [wildfly-dev] WFLY-9574 - Distribution files does not have POSIX permissions perfectly set
by Brian Stansberry
Seems I forgot to "Reply to All" yesterday. The following was meant to be
sent to wildfly-dev.
On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
> Before getting into the specifics, first a general note re: perms.
>
> Our general permission set for is rwxr-xr-x for directories and rwxr--r--
> for files. If someone thinks that's wrong in general; speak up. ;).
> Otherwise I think any deviation from that we should justify. Not that
> deviations are wrong, just that they need to have a reason.
>
> On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse <belaran(a)redhat.com>
> wrote:
>
>> Well, the diff is between the RPM and the zipfile is pretty long, but it
>> boils down to the 3 set of differences I've pointed out on WFLY-9574:
>> <https://issues.jboss.org/browse/WFLY-9574>
>>
>> - *.properties and .jar* files are associated with the mask rw-rw-r--
>> giving access to it to any other users and allowing group member to modify
>> the file - the RPM distribution fixes that by removing the write privileges
>> for the group (rw-r--r--). I personnaly don't see the value of letting the
>> group members modify those files, I just can see how this could be
>> exploited, so I would say it falls into "clearly wrong and not our intent".
>> A case might be made for the .properties files, but for jars file I really
>> don't see a valid use case (unless of course, any of you know one) ;
>>
>> There are a few different things here, so let's deal with them separately.
>
> For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them as
> rwxr--r--. Which seems correct to me. In case I'm seeing something wrong, I
> don't see why they should vary from the general standard. And the
> module.xml file should be consistent, since there's not much point in
> locking people from touching jars but letting them change what jars get
> loaded.
>
> For properties files, let's consider them on a more fine-grained basis.
> For example, the properties files used by the security realms have
> different kinds of data than logging.properties does.
>
> The perms on the security realm property files are rw-------, not
> rw-rw-r--.
>
> The logging.properties files are rw-r--r-- which is consistent with the
> domain|host|standalone.xml files and with the general standard.
>
>
>>
>> -
>> - *some directories* like 'domain/tmp/auth' have too restrictive mask
>> like rwx------ and RPMS to turned them into rwxrwxr-x (that I don't really
>> agree with) and
>>
>>
>> - *other directories*, likes 'domain' have again a too permissive
>> mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make senses.
>>
>> In the unzip I see these directories as rwxr-xr-x, which I think is fine.
>
> Are you concerned with any other directories besides $JBOSS_HOME/domain
> and $JBOSS_HOME/standalone?
>
>> So we need to find an agreement on those three items, and then see how we
>> proceed to implement the fix (if needed).
>>
>> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry <
>> brian.stansberry(a)redhat.com> wrote:
>>
>>> I think we need to start with the assumption that the permissions we
>>> have in the zip are the way they are for a reason and evaluate possible
>>> changes based on discussion here of each type of change. Maybe the RPM
>>> settings are better, maybe they are not. Or maybe they are better but the
>>> improvement is not worth the disruption a change may cause to our end
>>> users, who may rely on the current zip settings. Or maybe what we have in
>>> the zip is clearly wrong and doesn't follow our own intent. I expect we'll
>>> probably see a little of each category, although hopefully some changes for
>>> WF 11 removed the "clearly wrong and doesn't follow our intent" cases. :)
>>>
>>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse <belaran(a)redhat.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> As reported on JBEAP-12374[1], there is some discrepancies between the
>>>> ZIP file we provided for Widlfy/EAP and the RPM generate. Most of those
>>>> discrepancies - or the most relevant ones, are some fine tuning performed
>>>> on the (POSIX) privileges (things such as removing the write privilege for
>>>> member of the same group as the owner of the file).
>>>>
>>>> I've looked into this and because those files are produced by our own
>>>> Maven plugin (as part of wildfly-build-tools), we can not simply modify the
>>>> assembly.xml. Which actually is probably for the best, as it would made the
>>>> assembly file quite cumbersome.
>>>>
>>>> Anyhow, I've worked on a proposal[2] for the wildfly-build-tools, but
>>>> when I reported the problem on WFLY-9574[3], Brian suggested I started a
>>>> discussion here. So does anyone have a (strong) opinion about this issue
>>>> and/or how to resolve it ? :)
>>>>
>>>> (For the record, I do think it is best to fix the privileges to follow
>>>> what the RPM does for us for now, but if you feel this issue should not be
>>>> addressed, and dev- the issue, I'm certainly not opposed to it either).
>>>>
>>>> [1] https://issues.jboss.org/browse/JBEAP-12374
>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40
>>>> [3] https://issues.jboss.org/browse/WFLY-9574
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Manager, Senior Principal Software Engineer
>>> Red Hat
>>>
>>
>>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
6 years, 11 months
How to configure Wildfly to use the InMemorySessionManager instead of DistributableSessionManager?
by Eric B
Further to a previous post for session problems in my application, I
believe some of my issues relate to the DistributableSessions that are
being used by Wildfly. However, in my configuration file, I have my web
cache defined as a local cache:
<subsystem xmlns="urn:jboss:domain:infinispan:4.0">
<cache-container name="server" aliases="singleton cluster"
default-cache="default" module="org.wildfly.clustering.server">
<transport lock-timeout="60000"/>
<replicated-cache name="default" mode="SYNC">
<transaction mode="BATCH"/>
</replicated-cache>
</cache-container>
<cache-container name="web" default-cache="passivation"
module="org.wildfly.clustering.web.infinispan">
<local-cache name="passivation">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store passivation="true" purge="false"/>
</local-cache>
<local-cache name="persistent">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store passivation="false" purge="false"/>
</local-cache>
</cache-container>
...
...
I see that undertow comes with an InMemorySessionManager, but not entirely
sure how to enable it. Do I have to go through the effort of creating my
own ServletExtension and configuring it in the
META-INF/services/io.undertow.servlet.ServletExtension or is there an
out-of-the-box way of enable functionality that already exists via the
config file?
Thanks,
Eric
6 years, 11 months
GRPC subsystem proof of concept
by Stuart Douglas
Hi everyone,
I have done up a proof of concept of GRPC support in Wildfly, which can be
found at [1]. GRPC is an RPC protocol designed by Google, that allows for
easy cross platform invocations.
My proof of concept uses an Undertow based port of GRPC [2] and basically
works as follows:
- At deployment time Jandex is used to find all non-abstract classes that
implement io.grpc.BindableService
- I scan the class hierarchy of these classes to find the protobuf
generated base class, and create a subclass of this class using
ProxyFactory, overriding every method except bindService().
- An instance/proxy is created using the ComponentRegistry to do the
creation, and the generated proxy delegates all incoming calls to this
instance
- At runtime any incoming HTTP/2 requests with a type of application/grpc
are intercepted, and passed through this newly created proxy.
Basically this means that all you need to do as an application developer is
define your GRPC endpoints using protobuf, implement the classes generated
by the protobuf compiler and then include them in your application, and
Wildfly will do the rest. CDI and EJB annotations on your GRPC services
should work as normal, for example if you put @Stateless on an endpoint it
should work as expected with a SFSB handling all invocations.
Note that this is a very early stage POC, and lots of stuff is missing
(most notably security).
Before I go to much further though I though that I should get some
feedback, e.g.
- Do we actually want this? I am not sure how much interest there is, but
it seems like GRPC could be very useful in a polyglot microservice
environment.
- Is the current implementation the best way of actually registering GRPC
services, or should we require some kind of defining annotation
- What security mechanisms should we support? Out of the box standard GRPC
is fairly limited
- What do we do about transactions? I am leaning towards not supporting
them over GRPC, as we already have solutions for Java invocation in the
form of our EJB protocol, and I think non-Java clients are unlikely to want
to use this.
Stuart
[1] https://github.com/stuartwdouglas/wildfly/tree/grpc
[2] https://github.com/stuartwdouglas/undertow-grpc
6 years, 12 months
How to connect to a wildfly port
by Michael Musgrove
The wildfly server config contains various socket bindings such as:
<socket-binding name="txn-status-manager" port="4713"/>
When I run netstat -plnt to see which ports wildfly listens on I only see
the http and management port because WildFly is using http upgrade:
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 163/java
tcp 0 0 0.0.0.0:9990 0.0.0.0:* LISTEN 163/java
Is there a way for me to open the txn-status-manager (port 4713) and write
some data to it.
Mike
--
Michael Musgrove
Transactions Team
email: mmusgrov(a)redhat.com
Our mission:To be the catalyst in communities of customers, contributors,
and partners creating better technology the open source way.
JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale
Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell
Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill,
Keith Phelan, Matt Parson (USA)
6 years, 12 months
Logging Changes
by James Perkins
Hello All,
For WildFly 12 (maybe not until 13 at this stage) there are some thoughts
on significantly changing the way logging is configured. Currently logging
is initialized by reading a logging.properties file when JBoss Modules
boots. While this works okay there are a few issues with this approach.
1. For boot logging (before the logging subsystem is initialized) you
can't use property expressions. This means when the logging subsystem
rewrites the logging.properties file with all expressions expanded.
2. Logging objects, such as handlers, cannot use resources from other
subsystems. For example there is a need for a socket-handler. With the
socket handler we need a way to get an SSL context from Elytron. There is
no way for this to be done using a logging.properties file for the boot log
configuration.
3. If the user want to manually change the logging configuration by
editing the XML they also have to edit the logging.properties. If not the
old configuration will be used until the next boot.
It would be useful to introduce a way to queue log messages during boot
[1]. Once the logging subsystem boot is complete the messages would be
drained and sent to the new configuration. This of course isn't without
it's own issues.
1. Messages appeared delayed when WildFly is booting. Essentially all
the boot messages are written at once so you see no messages, then all of
them at once.
2. A shutdown hook would have to be used in order to ensure errors that
cause a boot failure are logged.
3. This could get a little tricky with offline CLI as currently logging
is configured based on the logging.properties file
4. If users remove the logging subsystem there are more steps than just
removing logging subsystem to get logging working.
5. There will be a slight performance impact during boot. This can be
greatly reduced if the caller calculation is disabled. This can be done in
normal cases, but we likely can't make it the default. Note too this is
only a boot impact. Once the logging subsystem takes over, the performance
should be exactly the same as it was before.
There is some good however too. This does open the door allowing users to
more easily replace the log manager implementation for standalone servers.
Currently we still, and maybe always will, require the JBoss Log Manager to
be used for domain servers, the host controller and process controller.
It also removes the need for a logging.properties for servers. I think this
is a big bonus to the changes as logging for servers will only be
configured in one place now. Domain will be a bit different, but we should
likely introduce a logging subsystem on the host controller as well. I just
don't think it makes much sense until we can sort out the issues above.
The current idea is that boot logging will be configurable via system
properties. These properties would have to be set in the JAVA_OPTS.
I'm curious to hear any concerns others might have about this. This feels
like a rather significant change so I'd rather get it right the first time.
I have started a design doc, but it's not finalized yet. If you're curious
however you can have at look at it on my topic branch [2]. You can also see
some of the small changes I've made to get it working on WildFly Core on
that branch.
[1]: https://issues.jboss.org/browse/LOGMGR-177
[2]:
https://github.com/jamezp/wildfly-core/blob/bootstrap-logging/logging/boo...
--
James R. Perkins
JBoss by Red Hat
6 years, 12 months
Add persistend store to infinispan via CLI fail
by Domenico Briganti
Hi all!
I'm trying to configure a persistent file for a local-cache in
widlfly-11 via CLI but fail, it however works if I put the
configuration directly on standalone.xml:
<local-cache...
<file-store path="authtoken.dat" relative-to="jboss.home.dir"
passivation="false" preload="true" purge="false"/>
I try this CLI command in a fresh wildfly-11 installation, and the last
fail:
[standalone@localhost:9990 /] /subsystem=infinispan/cache-
container=reservation:add
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=infinispan/cache-
container=reservation/local-cache=authtoken:add(statistics-
enabled=true)
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=infinispan/cache-
container=reservation/local-
cache=authtoken/store=file:add(path=authtoken.dat,relative-
to=jboss.home.dir,passivation=false,preload=true,purge=true)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed:
org.jboss.msc.service.DuplicateServiceException: Service
org.wildfly.clustering.infinispan.cache.store.reservation.authtoken is
already registered",
"rolled-back" => true
}
Maybe I submit a wrong CLI command?
Thanks,
Domenico Briganti
6 years, 12 months
some JMX APIs cannot obtain an MBean that exists
by John Mazzitelli
I'm seeing odd behavior with the JMX API implementation in Wildfly 11.
If you grab this Makefile and two .java files I use for testing you can see it yourself - just put these in a tmp directory somewhere:
wget https://raw.githubusercontent.com/jmazzitelli/test/master/javaagent/Makefile
wget https://raw.githubusercontent.com/jmazzitelli/test/master/javaagent/TestJ...
wget https://raw.githubusercontent.com/jmazzitelli/test/master/javaagent/TestJ...
Then just run "make download-wildfly unzip-wildfly compile run" (make sure you don't have other WildFly servers running to avoid port conflicts)
This runs WF 11 with a -javaagent attached. In the server output, you will see this:
16:31:05,290 INFO [stdout] (Test Java Agent Thread) =============================================================
16:31:05,291 INFO [stdout] (Test Java Agent Thread) FIND INFORMATION ABOUT MBEAN: jboss.as:management-root=server
16:31:05,291 INFO [stdout] (Test Java Agent Thread) =============================================================
16:31:05,291 INFO [stdout] (Test Java Agent Thread) isRegistered:
16:31:05,291 INFO [stdout] (Test Java Agent Thread) true
16:31:05,291 INFO [stdout] (Test Java Agent Thread) getMBeanInfo:
16:31:05,291 INFO [stdout] (Test Java Agent Thread) description: The root node of the server-level management model.
16:31:05,291 INFO [stdout] (Test Java Agent Thread) #attributes: 19
16:31:05,291 INFO [stdout] (Test Java Agent Thread) getAttribute:
16:31:05,291 INFO [stdout] (Test Java Agent Thread) serverState=reload-required
16:31:05,291 INFO [stdout] (Test Java Agent Thread) queryNames:
16:31:05,291 INFO [stdout] (Test Java Agent Thread) []
16:31:05,291 INFO [stdout] (Test Java Agent Thread) queryMBeans:
16:31:05,291 INFO [stdout] (Test Java Agent Thread) []
16:31:05,291 INFO [stdout] (Test Java Agent Thread) queryNames(null, null):
16:31:05,291 INFO [stdout] (Test Java Agent Thread) FOUND IT: jboss.as:management-root=server
16:31:05,291 INFO [stdout] (Test Java Agent Thread) =============================================================
You will see SOME JMX APIs can see the MBean "jboss.as:management-root=server",
but queryMBeans and queryNames canNOT (note the empty arrays []).
But notice getMBeanInfo CAN see it - I can even get the serverState attribute value from that (you can see it is in reload-required state - I see the same behavior even if it was in "running" state).
But again, queryMBeans returns nothing.
Oddly, queryNames(null, null) DOES return it in the list (see the "FOUND IT" line). It is only if I specifically ask for it does it fail in the query API.
Finally, note that it seems this MBean "jboss.as:management-root=server" is special - because it is specifically broke - if i switch to querying for "jboss.as:subsystem=transactions" it all works fine, even the query APIs:
17:16:39,541 INFO [stdout] (Test Java Agent Thread) queryNames:
17:16:39,541 INFO [stdout] (Test Java Agent Thread) [jboss.as:subsystem=transactions]
17:16:39,541 INFO [stdout] (Test Java Agent Thread) queryMBeans:
17:16:39,541 INFO [stdout] (Test Java Agent Thread) [org.jboss.as.controller.ModelController[jboss.as:subsystem=transactions]]
This problem was seen by others as well (with the same MBean I'm trying to get) - see:
https://github.com/prometheus/jmx_exporter/issues/89
The person there claims queryNames is broke but queryMBeans is OK - that does not work in my example either. Neither query API works.
I searched JIRA, found nothing related to this MBean not being queryable.
6 years, 12 months
