Working with the parsers for the core config has become increasingly
cryptic, we are now at the point where we have three different major
versions which diverge and converge as we work on them. Most recent
changes have resulted in large sections of the config converging for 1.x
and 3.x leaving 2.x independent.
So that I can add references to Elytron I am starting to add support for
One think that I have learned is that each major version tends to belong
to one branch of the codebase, all changes to that version happen on
that branch first: -
1.x - Maintained only for EAP
2.x - WildFly 8.x branch
3.x - WildFly Core master branch
I would expect if further changes are made to core for WildFly 9
releases we will end up with 1.x branch of core and and 4.x version of
the schema will be owned by the master branch.
To make things less cryptic I am proposing that until we find a better
solution for all subsequent major schema versions we just fork the
parser and all related classes.
This will simplify the code being modified for the upstream development.
Forward porting parsing changes will also become a simple copy and paste.
For the current cryptic approach I think almost every engineer (and I am
finding it really hard to think of exceptions) that has worked in-depth
in this area has introduced at least one bug and I don't think the test
coverage is high enough to protect against this.
I updated my workspace today and did a new build using Java 8.
But on startup of Wildfly it identifies itself still as WildFly Full
10.05. 21:26:15,923 INFO [org.jboss.as#done] WFLYSRV0025: WildFly Full
9.0.0.CR2-SNAPSHOT (WildFly Core 1.0.0.CR1) started in 9023ms - Started
518 of 722 services (265 services are lazy, passive or on-demand)
It seems that
need to be updated too.
I am happy to announce the first candidate release of WildFly 9! WildFly 9 builds off of WildFly 8’s Java EE7 support, and adds many new capabilities, including intelligent load balancing, HTTP/2 support, a new offline CLI mode, graceful single node shutdown, and a new Servlet-only distribution.
For more details, check out the release notes:
As always, you can download it here:
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
This afternoon I released version 1.0.0.CR2 of WildFly Core. It has been
integrated into the 9.x branch of full WildFly.
Senior Principal Software Engineer
JBoss by Red Hat
And now it's time for WildFly Full to move to Java 8. Sames
rules/warnings about WildFly Core's move to Java 8. Please no just
refactor PR's to things like lambdas, diamond operators, etc. If you're
fixing compile warnings please keep commits small and concise. Likely
one commit per maven module. Though we don't want to get into just
refactoring because we can.
James R. Perkins
JBoss by Red Hat
A while back I reported https://issues.jboss.org/browse/SECURITY-746 and
746 has been open for a long time, while 876 is relatively new.
Both concern propagation of the authenticated identity from Servlet to EJB,
something which unfortunately has seen bugs in some form of the other for
several years now.
Would really be great if this can be fixed. I provided a possible
workaround for 876, and a reproducer test for both issues. If needed I can
Before it was called jboss-cli,sh the script was called jboss-admin.sh
IMO the latter was always a more obvious name for users to call but as
it was only a CLI the name was changed. Then we added a GUI mode.
I would think we could then add more to it: -
- Give our admin tool the ability to start jconsole.
- Add the user maintenance and SSL maintenance features to it.
- Give it the ability to start your web browser for the admin console?
For the latter I wonder if we could benefit from the tool having a
connection to the server, maybe make use of KeyCloak to obtain an SSO
token that is included in the URL to start the browser and we could
possibly achieve a form of local auth for web.
Not sure what other thoughts are but these are just a couple of points
on my mind.
just wondering if wildfly-arquillian-container-embedded was discontinued
with split of 9.x:
When working on a re-enablement, I found out that even though arq adapter
now depends on wildfly-core/embedded, particularly
on EmbeddedServerFactory, this class has its counterpart in
wildfly/embedded as well.
Question is, should be embedded arquillian container still available for
If yes, I can continue and provide a PR, just I will need a bit of guidance
with what EmbeddedServerFactory it should actually use (if that matters).
AeroGear Core Developer
The output doesn't contain a single org.jboss class being loaded. Also it
does not contain the jar itself.
So, technically speaking this can't work. But why? The command isn't
Any further ideas?
> On May 6, 2015 2:12 PM, "Jaikiran Pai" <jai.forums2013(a)gmail.com> wrote:
>> A quick debugging option is to try:
>> java -verbose:class -jar swarm-sample-1.0-SNAPSHOT-swarm.jar
>> That will dump out some information of where the classes are being
loaded from. It might give a hint on what's going on. You might want to
redirect the output to a file since with that -verbose:class option, the
output can potentially be huge.
>> On Wednesday 06 May 2015 04:22 PM, Markus Eisele wrote:
>>> It is around 30 Meg and does contain the class. Indeed.
>>> I have a pretty straight forward JDK setup and tried to run with both
1.7.0_65 and 1.8.0_20.
>>> Only difference is that I run on Windows?
>>> Is the maven version an issue? I'm running 3.3.3?
>>> Anything I can do to provide more debug information?
>>> On May 6, 2015 12:40 PM, "Ken Finnigan" <ken(a)kenfinnigan.me> wrote:
>>>> Hi Markus,
>>>> That's weird, as I was able to clone your repo, build it, and run it
without any problems.
>>>> Is your fat jar around 30.1Mb in size? Does
org.wildfly.swarm.bootstrap.Main exist in that jar?
>>>> On Wed, May 6, 2015 at 6:17 AM, Markus Eisele <myfear(a)web.de> wrote:
>>>>> I've been playing around with swarm today and here is the source:
>>>>> Very simple project. JAX-RS and nothing else.
>>>>> mvn package produces the jar. Execution results in:
>>>>> java -jar swarm-sample-1.0-SNAPSHOT-swarm.jar
>>>>> Error: Could not find or load main class
>>>>> Any help appreciated!
>>>>> wildfly-dev mailing list
>>> wildfly-dev mailing list
>> wildfly-dev mailing list
I've been playing around with swarm today and here is the source:
Very simple project. JAX-RS and nothing else.
mvn package produces the jar. Execution results in:
java -jar swarm-sample-1.0-SNAPSHOT-swarm.jar
Error: Could not find or load main class org.wildfly.swarm.bootstrap.Main
Any help appreciated!