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, 8 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
security/elytron CLI commands
by Jean-Francois Denise
Hi,
discussing with Darran on how to extend the CLI to help configure
elytron, he suggested that we should move the discussion to this list. I
have started a document [1] in order to collect feedbacks on new CLI
commands to address security configuration. Feel free to comment on the
document.
Thank-you.
JF
[1] https://developer.jboss.org/wiki/SSLCommandsForCLI
7 years
Policies for merging PRs on master
by Alessio Soldano
As suggested by Brian, I'd like to draw attention to the discussion on
https://github.com/wildfly/wildfly/pull/10604 .
The PR is an upgrade of the webservices stack, including JBossWS, Apache
CXF, JAXB-RI and JAXB API. In particular, the JAXB upgrade is for EE8 and
better JDK 9 compatibility.
Now, due to the upgrade of the JAXB API spec jar, the PR is essentially
stalled since 20 days; the new spec is released as an alpha (as it's been
tested within JBossWS only) and that does not satisfy a rule that requires
any artifact being pulled to be Final.
We're talking about a spec jar, we could simply re-tag that as Final,
chances are we won't need changes any time soon there anyway, but as Tomaz
pointed out, in principle that would be dishonest.
While I see the point in requiring that only sufficiently stable upgrades
are applied to the codebase, I'm wondering whether, maybe, we're going a
bit too far with the rules. Brian wrote on this topic: "how to determine
that something is good enough to go in without using master as a test bed" ?
Opinions?
Cheers
Alessio
7 years
WildFly 11 and JDK9
by Tomaž Cerar
Hey guys,
during development of WF11 we have done lots of work on making it build &
run on JDK9.
as release nears I would like to summarize what the current state is and
how to move on.
Currently most of our core [1] & full [2] testsuite passes on latest builds
of JDK9.
Remaining failures are already addressed by [3] and [4]
**But** passing testsuite on JDK9 is not the same as using our binary
distribution under JDK9.
Currently as part of running build / testsuite we override version of
javassit to 3.22.0-CR2
which is currently the only version that works properly on JDK9.
As there is no .GA version of javassit that work on JDK9 avalible we
currently do not have it as default.
On top of that, hibernate as main user of javassit is not tested enough
with this version of javassist
unless hibernate / JPA team says otherwise.
That would in practice mean that users running WF11 on JDK9 would have
issues with JPA/Hibernate
based applications.
Currently I see two options how to address this:
- upgrade javassist to 3.22.x in server, preferably ask for .GA release.
- produce additional WildFly.x.x.x-jdk9 zip that would include the newer
javassist.
So question is do we even want to have working JDK9 build of WildFly 11
.Final
or should we postpone this for next update release.
--
tomaz
[1]
https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_MasterLinuxJdk9
[2] https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea
[3] https://github.com/wildfly/wildfly-core/pull/2738
[4] https://github.com/wildfly/wildfly-core/pull/2751
7 years
feature pack domain host.xml override
by John Mazzitelli
How I can get a domain "host.xml" found in a feature pack to get placed in the domain/configuration/host.xml location of the generated WF distro?
I have this:
https://github.com/hawkular/hawkular-agent/blob/master/hawkular-javaagent...
and I want the "host.xml" that is in that hawkular feature pack's "configuration/domain/host.xml" location to be deployed properly (in the correct spot in the final WF distro that gets laid down).
As a side question: is it possible to take the existing WF feature pack's host.xml and simple inject things in its <jvm> settings but leaving the rest alone?
The idea is that I want the slave servers to start with a -javagent cmdline option (e.g. to get the Prometheus JMX Exporter agent or the Jolokia agent to run in all slave servers spawned by the host controller).
[this message was sent on November 29, 2017 at 9:33 EST - these mailing lists have had huge delays in delivering things recently, let's see how long it takes this one to get delivered]
7 years
WFLY-9574 - Distribution files does not have POSIX permissions perfectly set
by Romain Pelisse
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
7 years
kube-ping in distro?
by Bill Burke
Are you guys planning on including kube-ping in future releases of Wildfly?
--
Bill Burke
Red Hat
7 years
strange JMX attribute values for domain servers
by John Mazzitelli
I'm seeing strange JMX attributes when looking at domain mode and its MBeans.
In short, if a host wildfly server is up and running, there is no status in the "server" MBean but there is status in the "server-config" MBean. When the server is down, there is serverStatus in the "server" MBean as well as in the "server-config" MBean.
Running a stock, out-of-box WildFly 11.0.0.Final using "domain.sh":
1. SERVER-ONE:
1a. MBean "jboss.as:host=master,server-config=server-one" has attribute "status" of value "STARTED".
1b. MBean "jboss.as:host=master,server=server-one" has no attributes at all - jconsole shows me no attributes for this MBean
2. SERVER-TWO:
2a. MBean "jboss.as:host=master,server-config=server-two" has attribute "status" of value "STARTED".
2b. MBean "jboss.as:host=master,server=server-two" has no attributes at all - jconsole shows me no attributes for this MBean
3. SERVER-THREE:
3a. MBean "jboss.as:host=master,server-config=server-three" has attribute "status" of value "DISABLED".
3b. MBean "jboss.as:host=master,server=server-three" interestingly has attribute "serverState" of value "STOPPED"
This doesn't make sense to me. I believe the "server" MBean for a started server should have a serverState of values something like "running" or "restart-required" or "reload-required". But instead, they don't have any attributes at all.
Thoughts?
7 years
Reads of subsystem resources under a /deployment=x resource
by Brian Stansberry
Hi Harald,
Does HAL always include the "include-runtime=true" param when doing a read
of resources under a /deployment=x resource?
I'm asking because I noticed an annoying problem when trying to do some
cleanup of whether runtime-only resources correctly report themselves as
such.[1] It turns out we have a bug where must subsystem resources under
/deployment=* don't report themselves as runtime-only, which means they
show up in an op like this, even though they should not:
https://paste.fedoraproject.org/paste/4WGJ7~UpeJvR0tqtEDYfNg
The "subsystem=undertow" child should not appear because the op used
"include-runtime=false". So that's a bug.
I probably won't fix that bug any time soon, because
"include-runtime=false" is the default behavior. Which mean this is a bug
that some users may be counting on. :( One example being Arquillian -- see
[2]. But I'm wondering whether HAL is an example of that. If it is, it's
something that should be corrected. At some point we may have to correct
this.
Jean-Francois Denise, I have the same question for you re: CLI.
Emmanuel Hugonnet -- I'm hoping this isn't a significant problem for your
provisioning feature-spec work. If it is maybe we can find a way to work
around. These resource types are not relevant on an admin-only server and
my guess any feature-spec generation would use an admin-only process.
[1] https://issues.jboss.org/browse/WFCORE-3432.
[2] https://issues.jboss.org/browse/WFARQ-35
Cheers,
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
7 years
