This is still very much work in progress but I just wanted to share some
of my work capturing configuration requirements for the HTTP management
interface so far: -
I am capturing all current requests for flexibility regarding the
management interface although this does not mean they will all be
implemented at once, instead it is so we know where the configuration
can live if an when these capabilities are added.
I am still thinking about this but I may remove references to the
security realms and instead reference security/ssl policies - initial
policies would still be based around the existing realms but the
policies would enable us to migrate to subsequent security solutions
without affecting the configuration of the interface.
Now would also be a very good time to speak up if you have any
additional items where you think it would nice if we could configure on
the http management interface.
What are the differences between the JBoss EE6 API and the Oracle EE6
API as specified by the below maven dependencies? What issues, if any,
are there in using the oracle javax api spec? Since the spec is final,
wouldn't there be no differences to expect?
reference info below:
The official bundles contained classes with empty methods, causing errors
in some use cases, such as Arquillian tests.
See this post:
>From this blog:
"Sun/Oracle stripped out the code from classes that are classified as
"implementations". So all the interfaces are code complete, yet any
abstract class or implementation class has no code in it"
For piece of mind, I would suggest using the same version of jars shipped
with the application server you are using. If you are using JBoss/WildFly,
stick to the jboss bundles.
> Message: 7
> Date: Wed, 21 May 2014 03:03:44 -0500
> From: "hanasaki(a)gmail.com" <hanasaki(a)gmail.com>
> Subject: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs
> To: wildfly-dev(a)lists.jboss.org
> Message-ID: <537C5DE0.8010505(a)gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> What are the differences between the JBoss EE6 API and the Oracle EE6
> API as specified by the below maven dependencies? What issues, if any,
> are there in using the oracle javax api spec? Since the spec is final,
> wouldn't there be no differences to expect?
> Thank you.
> reference info below:
> Message: 8
> Date: Wed, 21 May 2014 10:26:05 +0200
> From: Emmanuel Bernard <emmanuel(a)hibernate.org>
> Subject: Re: [wildfly-dev] API differences javax EE6 vs JBoss EE6
> To: "hanasaki(a)gmail.com" <hanasaki(a)gmail.com>
> Cc: wildfly-dev(a)lists.jboss.org
> Message-ID: <20140521082605.GD12589(a)hibernate.org>
> Content-Type: text/plain; charset=us-ascii
> They are binary identical as it is checked by the TCK.
> The reason we have our own AFAIR is that
> - when we work on a preview of the spec, we need to write our own
> anyways as the Oracle teams don't necessarily have the same timeframe
> - there is some license subtleties involved and we prefer to write our
> own from a clean room.
> - some APIs have actual code - and thus bugs - and we want to be able to
> fix them - and have.
> On Wed 2014-05-21 3:03, hanasaki(a)gmail.com wrote:
> > What are the differences between the JBoss EE6 API and the Oracle EE6
> > API as specified by the below maven dependencies? What issues, if any,
> > are there in using the oracle javax api spec? Since the spec is final,
> > wouldn't there be no differences to expect?
> > Thank you.
> > reference info below:
> > <dependency>
> > <groupId>javax</groupId>
> > <artifactId>javaee-api</artifactId>
> > <version>6.0</version>
> > <scope>compile</scope>
> > </dependency>
> > <groupId>org.jboss.spec</groupId>
> > <artifactId>jboss-javaee-6.0</artifactId>
> > <artifactId>jboss-javaee-all-6.0</artifactId>
> > <version>3.0.2.Final</version>
> > </dependency>
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> wildfly-dev mailing list
> End of wildfly-dev Digest, Vol 14, Issue 7
We have a number of additional maven projects that are pulled into
WildFly where in general their predominant purpose is for use within
For these kinds of projects I am wondering if it would make more sense
to drop using a version qualifier, this is compatible with our agreed
The major and minor numbers are still available for us to be able to
branch off for maintenance, the micro then just becomes a tag counter.
At the moment we end up in situations where components need to move from
Beta to CR to Final at the appropriate time for a WildFly release even
though the modules are not actually being pushed as independent
projects, this creates additional work tagging and then processing the
A couple of projects where this would make sense to me are JBoss
Negotiation and JBoss SASL, both of these are tied so closely to the
WildFly release that having their own qualifier does not add much.
An example project where retaining the qualifier is good would be JBoss
Remoting where it could easily be conceived that the chances are higher
it would be used as a stand alone project.
I recently try to find out how to stress testing and benchmark testing
wildfly, and as the document (
there should be two folders called "stress" and "benchmark"
respectively under testsuite folder.
but I can't find them in the latest source code.
I wonder if they are not available for community or the document doesn't
match the actual code.
Just pulling together some related HTTP management interface changes and
I see this one is still pending: -
Are we interested in addressing this one?
Personally I am not convinced we need to be going beyond just using
appropriate codes from the existing set of status codes, anything else
would mean HTTP users get specific information that native users do not.
However one thought, could we add some form of category to the actual
failure response? That way we would have something we can use to map a
status code, we already have another case in the code base that checks
the error code to decide which status code to use!! If we added a
category to a failure clients would then also potentially be able to use
It's right there in the topic. James and I have carried out the change
discussed in  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 .
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".
I wanna manage my websocket connection or session when to connecttoserver
at undertow by java client and when the server is not available , the
client try to connect without exception and there is not any timeout to
Please help me
After the tag of CR2, master is now officially 9.x. Only blocker level patches for 8.1.0.Final will be accepted for the new 8.x branch.
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat