Early Access builds for JDK 9 b13, JDK 8u20 b15 and JDK 7u60 b15 are available on java.net
by Rory O'Donnell Oracle, Dublin Ireland
Hi Guys,
Early Access builds for JDK 9 b13 <https://jdk9.java.net/download/>, JDK
8u20 b15 <https://jdk8.java.net/download.html> and JDK 7u60 b15
<https://jdk7.java.net/download.html> are available on java.net.
As we enter the later phases of development for JDK 7u60 & JDK 8u20 ,
please log any show
stoppers as soon as possible.
Hi Tomaz,
Regarding the regression in JDK 8 , Can you please log a bug at bugs.sun.com
and let us know the incident number, we will chase it up on this end.
Rgds, Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
11 years, 10 months
Updates to HTTP Management Interface Configuration
by Darran Lofthouse
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: -
https://community.jboss.org/wiki/WildFly9-HTTPManagementInterfaceConfigur...
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.
Regards,
Darran Lofthouse.
11 years, 11 months
API differences javax EE6 vs JBoss EE6 specs
by hanasaki＠gmail.com
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>
11 years, 11 months
Re: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs
by Chris Ritchie
The official bundles contained classes with empty methods, causing errors
in some use cases, such as Arquillian tests.
See this post:
https://community.jboss.org/wiki/WhatsTheCauseOfThisExceptionJavalangClas...
>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.
Cheers
Chris
> 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:
>
> <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>
>
>
> ------------------------------
>
> 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
> specs
> 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.
>
> Emmanuel
>
> 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
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> End of wildfly-dev Digest, Vol 14, Issue 7
> ******************************************
>
11 years, 11 months
Dropping Qualifier from Version Number for utility artefacts
by Darran Lofthouse
We have a number of additional maven projects that are pulled into
WildFly where in general their predominant purpose is for use within
WildFly.
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
scheme: -
https://community.jboss.org/wiki/JBossProjectVersioning
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
component upgrades.
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.
Regards,
Darran Lofthouse.
11 years, 11 months
Failed operations over HTTP Interface : 500 Internal Server Error
by Darran Lofthouse
Just pulling together some related HTTP management interface changes and
I see this one is still pending: -
https://issues.jboss.org/browse/WFLY-907
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
this themselves.
Regards,
Darran Lofthouse.
11 years, 11 months
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, 11 months
Websocket at undertow
by Hamed Hatami
Hi,
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
handle it
Please help me
Regards,
Hamed Hatami
11 years, 11 months
Master is now 9.x!
by Jason Greene
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.
Thanks!
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
11 years, 11 months
