I'm an happy user of JBoss AS 7 and I'm waiting for a Wildfly release.
I've heard that Fuse license has evolved and it can only be used for
dev. License must be purchased to use it in production.
Is same evolution will be applied to JBoss AS 7 and/or Wildfly in the
First I should introduce myself for those who don't know me, as I have not participated in wildfly dev discussions before. I am a security response engineer working for Red Hat, handling security patches for the commercial JBoss products. Recently some colleagues and I have been working on a tool called 'victims'. The victims tool aims to provide a canonical database of known-vulnerable JAR files, along with tools that allow developers and system administrator to determine whether their projects and systems contain any known-vulnerable JARs. The project's about page contains a more detailed explanation:
enforce-victims-rule is a maven plugin that walks the dependency tree at build time, and uses the victims database to check whether a project is including any known-vulnerable JARs as dependencies. The plugin is available on maven central:
Please see the README.md and sample app here for configuration details:
I think there would be great value in incorporating this plugin into the wildfly POM(s). It can catch security flaws at build time, eliminating the need for much more work to ship patches for flaws later down the line. It is also designed such that it should not trigger any false positives. There will be false negatives where there are gaps in the database.
What do people think? Is this something you'd consider implementing?
David Jorm / Red Hat Security Response Team
I would suggest if the user should not do that, then such situation should be detected and should trigger an error, otherwise user is left in the wild. If it is allowed, than it should be documented and the order defined
----- Original Message -----
From: "Jaikiran Pai" <jpai(a)redhat.com>
To: "Rebecca Searls" <rsearls(a)redhat.com>
Sent: Friday, August 16, 2013 5:12:08 AM
Subject: Re: [wildfly-dev] manifest.mf jboss-deployment-structure.xml order of precedence
I think what Stuart meant in his mail was that the order is "undefined"
for such cases from an end user point of view. i.e. don't do that, since
we do not guarantee the ordering or such.
On Friday 16 August 2013 01:20 AM, Rebecca Searls wrote:
> I'm trying to understand the nature of how this works. I have not found any information in the documentation about
> the rules under which these 2 files are processed by AS7/WildFly. If MANIFEST.MF is present is it always processed
> first? Who wins when there are conflicting rules like the one I described?
> ----- Original Message -----
>> From: "Stuart Douglas" <stuart.w.douglas(a)gmail.com>
>> To: "Rebecca Searls" <rsearls(a)redhat.com>
>> Cc: wildfly-dev(a)lists.jboss.org
>> Sent: Thursday, August 15, 2013 3:41:55 PM
>> Subject: Re: [wildfly-dev] manifest.mf jboss-deployment-structure.xml order of precedence
>> Don't do that.
>> Pretty sure the remove will take precedence but I don't think this is
>> something we should consider supported behavior.
>> On Thu, Aug 15, 2013 at 5:51 PM, Rebecca Searls <rsearls(a)redhat.com> wrote:
>>> What if manifest.mf adds a dependency and jboss-deployment-structure.xml
>>> removes it?
>>> Is manifest.mf processes first?
>>> ----- Original Message -----
>>>> From: "Stuart Douglas" <stuart.w.douglas(a)gmail.com>
>>>> To: "Rebecca Searls" <rsearls(a)redhat.com>
>>>> Cc: wildfly-dev(a)lists.jboss.org
>>>> Sent: Thursday, August 15, 2013 11:37:19 AM
>>>> Subject: Re: [wildfly-dev] manifest.mf jboss-deployment-structure.xml
>>> order of precedence
>>>> If both are present both sets of dependencies will be added to the
>>>> On Thu, Aug 15, 2013 at 5:32 PM, Rebecca Searls <rsearls(a)redhat.com>
>>>>> Is there are order of precedence if both a manifest.mf
>>>>> are present in an archive? Does one override the other?
>>>>> wildfly-dev mailing list
> wildfly-dev mailing list
wildfly-dev mailing list
Ha, yes it's been a couple of years now :) I'm enjoying Red Hat a lot
and I hope you are too.
Thanks. I'll see what Google turns up with that. Maybe we could at least
get some ideas from it.
On 08/14/2013 11:51 AM, Rob Cernich wrote:
>> The problem with filtering comes in parsing the log file. While I have
>> had some success doing this with I tool I was playing with for Jesper,
>> once you get a stack trace you have to start making guesses. I tend to
>> agree with dmlloyd in that log files tend to be a one way write. You can
>> do some parsing with a best guess, but well we all know what happens
>> when we start assuming and guessing :)
>> That said I do like the challenge of trying to parse log files. I did
>> start a project to do it in my spare time I just haven't found time to
>> put into working on it lately.
> Hey James, long time since orientation...
> Eclipse used to have a project called TPTP which did some of this. It was architected with a "collector" that received events from various "agents" associated with servers running in your system. I believe the events were typed as Common Base Events which included fields to help correlate events across multiple servers. I don't recall whether or not the source for the server components (collector and agent) was open sourced or not (the binaries were available from Eclipse). The Eclipse side provided tooling for viewing and analyzing these CBE messages, which included the capability for creating rules that could be used to diagnose common problems when applied across a set of events.
> Hope you've been enjoying your time at Red Hat!
James R. Perkins
Red Hat JBoss Middleware
I am happy to announce WildFLy 8.0.0.Alpha4!
Get it here:
• RBAC support for management (standalone mode only this iteration)
• Audit logging
• Initial JMS 2.0 support
• Improved CDI 1.1 integration
• Introduction of Undertow development mode
• Web subsystem with JBossWeb was removed from WildFly, leaving Undertow as only Web server.
• 62 issues were resolved since Alpha3, including a serious redeployment memory leak
• Weld 2.0.3
• Undertow Beta 7
• Console 2.0.0.Beta2
• JBoss Modules 1.3.0.Beta3
• HornetQ 2.4.0.Alpha1
• aesh 0.33.7
• Jipijapa 1.0.0.Alpha5
• Javassist 3.18.1-Beta1
• Remoting JMX 2.0.0.Beta2
• JBoss WS 4.2.0.Final
• Jgroups 3.3.4.Final
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
I'm trying to fix the broken logout in the console (https://issues.jboss.org/browse/HAL-60). With the switch to undertow, the redirects in LogoutHandler do not longer work in Chrome and Safari. I came up with a solution that adds a call to SecurityContext.logout() before doing the redirects.
My changes are in PR #4879: https://github.com/wildfly/wildfly/pull/4897. Can you take a look at my solution. I don't know if that's an appropriate solution to get rid of the digest authentication information. At least it does work across common browsers.
JBoss by Red Hat
I 'm writting this to try to explain my position on WILDFLY 1650.
I don't know how to change the PR
(https://github.com/wildfly/wildfly/pull/4749) to have it intergated.
Currently I can't build EAP nor Wildfly with all tests on a French
On GNU/Linux I can do it by changing the LANG in my shell but on Windows
I just had to forget about it.
This problem happens because of the assumption that the default locale
is English so some messages in tet are using 'hardcoded' string instead
og I18n message.
Second, which affects EAP only (but which is still an issue in Wildfly
even if it is hidden), some tests which check for model
retro-compatibility will use 'old' version of JBoss AS which contains
translated logger messages in generated classes. Alas for French you
have old versions without any French and new with French, because of an
issue with the classloader we happens to be casting a $Logger to a
Logger which wasn't loaded by the same classloader.
I have tried to replicate this behaviour in Wildlfy, using the codehaus
mojo annotation processor to generate the translated loggers using the
main source code for the test source code.
While this complicated test maybe too much I think it should be possible
to make Wildlfy fully buildable on a French Windows computer (even if we
know Windows sucks and French rules ;o) )
So I'm asking here about how we should tackle this issue.