The Big Log ID Change: https://github.com/wildfly/wildfly/pull/5906
by David M. Lloyd
It's right there in the topic. James and I have carried out the change
discussed in [1] and elsewhere, and have split all the old "JBAS" codes
into specific "WFLYxxx" codes. The pull request is divided into one
commit per Maven module for easier review.
I request that every subsystem or component maintainer please review the
part of the commit that pertains to their piece, and please post
comments on the PR itself [2].
In addition, I want to discuss a few cases where modules are using
message bundles and loggers from neighboring modules. This is going to
become a problem when we do the distribution split-up.
Finally, one small matter I want to sort out is that we have several
modules which use a project-specific code for IllegalArugmentExceptions
that pertain specifically to null parameters, whereas some do not use a
code for this case and just throw the exception.
My feeling is we should either (a) don't use a code for this kind of
thing, or (b) come up with a "common" module or code space+project code
which every project can reuse, so we just have one code that universally
means "the parameter can't be null".
[1] http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000428.html
[2] https://github.com/wildfly/wildfly/pull/5906
--
- DML
11 years, 12 months
Adding timeout section to datasource management GUI
by Philippe Marschall
Hi
We would like to have the <timeout> section from datasource
configuration available in the web based management interface. We tried
to implement it ourselves and then submit submit a pull request. We got
as far as this commit [1] on github. The section and widgets show up in
the management interface but they don't seem connected to the underlying
values. They don't display or update the underlying values. Also the
help does not seem to work. We're still willing to create a pull request
should we be able to get it to work.
[1]
https://github.com/marschall/core/commit/89df3cb84e26ef5fc525858e3529095a...
Cheers
Philippe
11 years, 12 months
8.1.0.Final Criteria
by Jason Greene
In order to keep the release window small, I am requesting that only blocker level fixes be allowed into 8.1.0.Final at this time. If you believe you have one, please raise the status on the Jira issue and let me know about it.
We are in the process of shifting master to 9, and so these will be applied to a separate branch. Expect a further announcement on that.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
12 years
IMPORTANT - Intermittent Test Ban Redux
by Jason Greene
Hi Everyone,
Almost 2 years ago we agreed to disable all intermittent tests[1]; however, this is still a major problem today, and is still a major hassle for everyone that submits a PR (“retest this please” is now a common part of our process).
I think it’s finally time to enforce this policy, and disallow all tests that lead to even occasional intermittent failures, even if that leads to loss of coverage. The most fundamental need of our test suite, is to catch regressions, and right now it’s not really serving that purpose.
So I propose that after 8.1.0.Final is shipped that we immediately disable all tests with a failing history, and create a JIRA issue for the component author to fix them or the bug that is producing the failure. If after 3 weeks, a JIRA issue has for this has made no progress, I propose we completely remove the test from our codebase.
In addition, I propose that any repaired test be shown to be intermittent free using a custom CI job (Tomaz can set them) for several runs before accepting them back in.
Thanks!
[1] http://wildfly-development.1055759.n5.nabble.com/IMPORTANT-New-Policy-Pro...
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
12 years
css files path
by Jim McGuinness
A WAR-based facelet reference a syle sheet with something like ...
<h:outputStylesheet library="css" name="default.css" />
... is supposed to send Wildfly looking in "resources/css" for the style
sheet, but instead it appears to be looking in "css". Was there a change in
the Web container specs?
12 years
my 2 cents on Security Manager discussion
by Bill Burke
Late to the discussion, but this came up in conversations at DevNation.
Are you sure you guys want to fully enable the Java security manager
going forward? Jboss has been around for, what 14 years now? How many
users/customers actually desire the Java Security Manager to be on by
default? Could it be a possibility that the majority of our
customers/users might freak out if they found that all of a sudden the
Java Security Manager is on when it has been off the last 14 years?
I don't know. Just seems to me that there is a lot of other cool ideas
that you guys have been discussing that might be more interesting to
wildfly's user base.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
Re: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
by Jim McGuinness
Farah,
I've been looking at this some more, and the marker for Java just toggles
back and forth between Java 6 and Java 7. If the Java 7 marker is not
present, then a cartridge just defaults back to Java 6.
But you still have to have the version of Java installed on the gear in
order to toggle back and forth.
Here are the contents of the /usr/lib/jvm directory on the gear where
OpenShift online installed my Wildfly 8.1
cartridge ...
lrwxrwxrwx. 1 root root 26 Apr 22 13:19 java ->
/etc/alternatives/java_sdk
drwxr-xr-x. 3 root root 4.0K Feb 18 2013 java-1.5.0-gcj-1.5.0.0
lrwxrwxrwx. 1 root root 32 Apr 22 13:19 java-1.6.0 ->
/etc/alternatives/java_sdk_1.6.0
lrwxrwxrwx. 1 root root 26 Apr 22 13:19 java-1.6.0-openjdk ->
java-1.6.0-openjdk-1.6.0.0
drwxr-xr-x. 7 root root 4.0K Apr 11 06:57 java-1.6.0-openjdk-1.6.0.0
lrwxrwxrwx. 1 root root 32 Apr 22 13:18 java-1.7.0 ->
/etc/alternatives/java_sdk_1.7.0
lrwxrwxrwx. 1 root root 27 Apr 22 13:18 java-1.7.0-openjdk ->
java-1.7.0-openjdk-1.7.0.55
drwxr-xr-x. 3 root root 4.0K Feb 3 17:06 java-1.7.0-openjdk-1.7.0.45
drwxr-xr-x. 3 root root 4.0K Apr 22 13:19 java-1.7.0-openjdk-1.7.0.51
drwxr-xr-x. 7 root root 4.0K Apr 22 13:18 java-1.7.0-openjdk-1.7.0.55
drwxr-xr-x. 3 root root 4.0K May 1 2013 java-1.7.0-openjdk-1.7.0.9
lrwxrwxrwx. 1 root root 34 Apr 22 13:19 java-openjdk ->
/etc/alternatives/java_sdk_openjdk
lrwxrwxrwx. 1 root root 21 Apr 22 13:19 jre -> /etc/alternatives/jre
lrwxrwxrwx. 1 root root 27 Feb 18 2013 jre-1.5.0 ->
/etc/alternatives/jre_1.5.0
lrwxrwxrwx. 1 root root 26 Feb 18 2013 jre-1.5.0-gcj ->
java-1.5.0-gcj-1.5.0.0/jre
lrwxrwxrwx. 1 root root 27 Apr 22 13:19 jre-1.6.0 ->
/etc/alternatives/jre_1.6.0
lrwxrwxrwx. 1 root root 30 Apr 22 13:19 jre-1.6.0-openjdk ->
java-1.6.0-openjdk-1.6.0.0/jre
lrwxrwxrwx. 1 root root 27 Apr 22 13:18 jre-1.7.0 ->
/etc/alternatives/jre_1.7.0
lrwxrwxrwx. 1 root root 31 Apr 22 13:18 jre-1.7.0-openjdk ->
java-1.7.0-openjdk-1.7.0.55/jre
lrwxrwxrwx. 1 root root 25 Feb 18 2013 jre-gcj ->
/etc/alternatives/jre_gcj
lrwxrwxrwx. 1 root root 29 Apr 22 13:19 jre-openjdk ->
/etc/alternatives/jre_openjdk
I truly think the answer is that the gear needs to add Java 8 SE in order
for the Wildfly cartridge to be able to use it. And the Wildfly cartridge
will then need to be updated to respond to a Java 8 marker..
On Tue, Apr 22, 2014 at 6:57 PM, Jim McGuinness <dador92(a)gmail.com> wrote:
> Doesn't the marker just indicate the JDK version(s) used/usable by the app
> (in this case wildfly)? The gear still has to have a JDK 8 installed
> doesn't it?
>
>
> On Tue, Apr 22, 2014 at 6:00 PM, Farah Juma <fjuma(a)redhat.com> wrote:
>
>>
>> > From: "Jim McGuinness" <dador92(a)gmail.com>
>> > To: "Farah Juma" <fjuma(a)redhat.com>
>> > Sent: Tuesday, April 22, 2014 5:57:07 PM
>> > Subject: Re: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
>> >
>> > Would it be better to create a JDK 8 cartridge which could be deployed
>> in
>> > the same gear as the Wildfly 8.1 cartridge? Ideally you'll want to use
>> the
>> > JDK 8 for more than just Wildfly.
>>
>> Support for different JDK versions is added using marker files (e.g.,
>> this post describes how JDK7 support was added:
>> https://www.openshift.com/blogs/new-openshift-release-aug-8-2012-java-7-c...
>> ).
>>
>> > Is the gear's lack of a JDK 8 caused by the requirements of SELinux?
>>
>> It just hasn't been added by OpenShift yet.
>>
>> >
>> > On Tue, Apr 22, 2014 at 2:35 PM, Farah Juma <fjuma(a)redhat.com> wrote:
>> >
>> > > OpenShift hasn't added support for JDK8 yet but it should be possible
>> for
>> > > us to add it into the WildFly cartridge. I'll look into this.
>> > >
>> > > Farah
>> > >
>> > > ----- Original Message -----
>> > > > From: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
>> > > > To: "Farah Juma" <fjuma(a)redhat.com>
>> > > > Cc: "WildFly Dev" <wildfly-dev(a)lists.jboss.org>
>> > > > Sent: Tuesday, April 22, 2014 3:22:45 PM
>> > > > Subject: Re: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
>> > > >
>> > > > Great news!
>> > > >
>> > > > Btw, did you manage to add support for JDK8 yet?
>> > > > Not sure how far is openshift in this area but it would be great if
>> we
>> > > > would have JDK8 with WildFly on OpenShift.
>> > > >
>> > > > --
>> > > > tomaz
>> > > >
>> > > >
>> > > > On Tue, Apr 22, 2014 at 9:17 PM, Farah Juma <fjuma(a)redhat.com>
>> wrote:
>> > > >
>> > > > > Since WildFly 8.1.0.CR1 was released last week, the OpenShift
>> WildFly
>> > > > > cartridge has been updated as well.
>> > > > >
>> > > > > See
>> > > > >
>> > >
>> https://community.jboss.org/people/fjuma/blog/2014/04/22/wildfly-810cr1-o...
>> > > > > more details on how to get started. Please try it out and provide
>> > > > > feedback.
>> > > > >
>> > > > > _______________________________________________
>> > > > > wildfly-dev mailing list
>> > > > > wildfly-dev(a)lists.jboss.org
>> > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> > > > >
>> > > >
>> > >
>> > > _______________________________________________
>> > > wildfly-dev mailing list
>> > > wildfly-dev(a)lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> > >
>> >
>>
>
>
12 years
