Tag: java ee

Posted on

Deploying a Jersey based web app to WildFly 8 (part 1)

I’ve been resuscitating a personal Amateur Radio related project from a few years back that I previously had hosted on RedHat’s OpenShift. It was previously deployed on WildFly 8, so before I start making changes I want to get it deployed again locally on WildFly 8.

First up I got this error:

org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type ServiceLocator with qualifiers @Default at injection point [BackedAnnotatedField] @Inject private org.glassfish.jersey.internal.inject.ContextInjectionResolver.serviceLocator

This error appears to be pretty common. From the suggestions posted in reply to a similar post to WildFly forum here, the suggestion was to include Glassfish dependencies. I never had these included before, so not sure why I need these now, but these did the job:

<!-- kh added for error: WELD-001408: Unsatisfied dependencies for type Set<Service> with qualifiers @Default -->
<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>17.0</version>
</dependency>

<!-- kh: added per: https://developer.jboss.org/thread/240847 -->
<dependency
  <groupId>org.glassfish.jersey.containers.glassfish</groupId>
  <artifactId>jersey-gf-cdi</artifactId>
  <version>2.14</version>
</dependency>

<dependency>
  <groupId>org.glassfish.jersey.containers</groupId>
  <artifactId>jersey-container-servlet</artifactId>       
  <version>2.14</version>
</dependency>

The odd thing is if I deploy to WildFly 8.2 I don’t get this error or need these additional dependencies. Anyway, all set for now. I just tested deploying to 17.0.1 with no additional changes needed either.

Posted on

Major changes underway at Oracle: SPARC and Solaris teams laid off, Java EE oversight goes to Eclipse Foundation, future Java SE major releases proposed for twice a year

Oracle has been rather busy last few weeks. First, news that the Solaris and SPARC teams from Oracle’s acquisition of Sun Microsystems have reached the end of the road, and the majority of the teams have been laid off. The layoffs started at the start of this year, and the recent round apparently leaves only a small team left.

Last month there was a blog post to The Aquarium suggesting that Oracle would be open for another group or organization to drive stewardship for the Java EE spec. Looking back at past events, it’s no surprise that some significant changes were coming. Things started changing with the layoffs of the majority of the Java evangelists back in September 2015 and the letter assumed to be from one of the evangelists to InfoWorld stating that “… Java has no interest to them anymore”. Oracle’s lack of involvement in the development of Java EE started to gain notice by the other JCP members in minutes of the JCP Executive Committee in May and June 2016 leading to statements in the public minutes such as:

“…concern that Oracle, despite its role as steward of Java, has not made any public statements or explanations for the apparent lack of activity on Java EE”

There was also a formal statement by the JCR Executive Committee directed to Oracle formally voicing their concern with recent lack of JSR activity and involvement by Oracle:

“EC members expressed their serious concerns about the lack of progress on Java EE. They believe that Java EE is critical to the Java ecosystem and to their organizations and customers. They fully accept Oracle’s right to direct its investment where it wishes, but expressed the hope that they and other members of the Java community be permitted to step in and help with the ongoing development of the platform, particularly in areas where Oracle wishes to reduce its investment. They therefore requested a dialog with Oracle about how to make such a transition.”

This was followed in June 2016 by a statement by ‘Oracle spokesman’ Mike Moeller that Oracle were still committed to Java EE and were planning on a proposal to the community a t JavaOne 2016. This proposal turned out to be a ‘refocusing’ of the changes in the Java EE 8 proposal, namely dropping new features and changes that were not aligned with current industry trends (particularly microservices, so the MVC spec and a number of other proposals got dropped from the EE8 JSR).

From last month’s post that Oracle was open to consider another organization to drive future development of Java EE, yesterday it was announced (more here) that the Eclipse Foundation will be the new stewards of Java EE. Given Oracle’s recent lack of involvement, it’s great that they even considered this move, and hopefully the future of EE will be in good hands with the Eclipse Foundation.

If that news was not enough, Mark Reinhold also posted recently that after the slow release schedule of the past few major Java SE releases, they’re considering a twice yearly major release cycle moving forward after the planned release of Java 9 on September 21 (after many delays already). Two major releases a year is a massive change compared to the 3 year current release cycle (between Java 7 to Java 8 and between 8 and the upcoming Java 9 releases). Hopefully this means some good things are going to be coming to Java across the board, SE and EE, in the near future.

Posted on

JavaOne 2016: Oracle’s ‘refocusing’ of the EE8 proposal

Oracle’s planned Java EE ‘announcement‘ at JavaOne 2016 turned out to be (based on the announcement from the Sunday keynote and the Java EE 8 roadmap session by Linda Demichiel, EE spec lead for EE JSRs) a ‘refocusing’, a realignment to bring Java EE more in line with current trends, particularly to support deploying EE applications to the cloud and the development of microservices.

So what exactly is going to change? For the new EE8 spec proposal, with finalization now planned for 2017,  some previously proposed features for inclusion are now going to be dropped, namely:

  • MVC 1.0
  • JMS 2.1
  • EE Management apis 2.0

Given than MVC 1.0 was a new EE web framework as an alternative to JSF (not adding new technology but built on top of what we already have with a Reference Implementation already built out), this is perhaps the most surprising removal. Given the new focus of cloud and microservices however, this makes sense, as it doesn’t really add anything towards supporting the new goals.

Everything else in the original EE8 JSR 366 is going to remain in the new EE8 proposal.

New features to be added include a new feature for supporting Health Checks, and a new Configuration proposal to standardize external configuration of deployments – both of which will be useful to support deployments to the cloud.

Is this ‘refocusing’ enough? Is it going to be finalized soon enough? For an EE8 target of 2017, and EE9 of 2018, is it too little, too late?

Given that you can use current EE features today with frameworks like Spring Boot and Dropwizard to build and deploy microservices, is a standardized cloud/microservice focused EE platform still relevant?

Alternative runtimes like WildFly Swarm and IBM’s Liberty Profile are giving runtime flexibility and allow you to pick just the features your app needs at runtime (and are available today). Rather than an all-in-one EE runtime container, is a ‘pick n mix’ type approach more relevant to support the current popularity of microservices?

Posted on

Oracle have something to announce re. Java EE 8 at JavaOne this year?

Oracle have been quiet on the Java EE front since around November 2015 according to public minutes from recent JCP Executive Committee meetings,  which has led to the forming of the Java EE Guardians group forming to rally community awareness and promote the future of Java EE.

This story on The Register just popped up in my feed this evening, with an interesting quote from ‘Oracle spokesman’ Mike Moeller, stating:

“Oracle is committed to Java and has a very well defined proposal for the next version of the Java EE specification – Java EE 8 – that will support developers as they seek to build new applications that are designed using micro-services on large-scale distributed computing and container-based environments on the Cloud … Oracle is working closely with key partners in the Java community to finalize the proposal and will share the full details with the broader Java community at JavaOne in September.”

So there you go. Given that there is already an EE8 JSR in flight (JSR 366) encompassing many other JSRs that were planned to be included in EE8, this statement sounds suspiciously like Oracle has “something else” planned for EE8 that is not the EE8 JSR (“a very well defined proposal for the next version of the Java EE specification”).

In a thread on the Java EE Guardians Google Group, seems like no-one over there has any other insight into this news at this point.

Interestingly, microservices, large-scale distributed computing and containers… this is all very much on target for where EE needs to be heading.

If this is all Oracle is willing (or able) to share at this point, then it will definitely be interesting to hear what they have to share at this year’s JavaOne conference.

Proudly powered by WordPress