28thAirhacksQ&A.md

28thAirhacksQ&A.md

Ask questions and see you at July, 13th (exceptionally, this time at wednesday) at 6.PM. CET: http://www.ustream.tv/channel/adambien Also see archives: airhacks.tv

1. Java EE 8 News
2. Discussion around http://microprofile.io (http://www.adam-bien.com/roller/abien/entry/the_enterprise_java_future_is)

Questions from anonymous:

3. Java EE status – during my studies, I utilized Java EE 6 for creating distributed system to monitor IT infrastructure. Now is 2016 and situation of Java EE is not in bright colors – Oracle reluctant to invest in Java EE standard, concern expressed in formation of “Java EE Guardians” that you are part of. I learned much from it and gave me ability to think “at scale”, distributed manner. But recent developments around standard, started my evaluation - if Java EE is worth pursuing in long term.
4. Java EE Backend Development – I find great joy in creating backend software – RESTful web services in JAX-RS or Restlet, business logic or database integration using ORM (JPA or Hibernate). Not mentioning Big Data “movement” with Apache Hadoop and Spark frameworks. But Java EE offers I was looking up, almost always require Angular or other JS libraries. More and more employers require “Full-stack” engineers. Is simply market for specialized backend engineers is shrinking and should I adapt to it or is it simply reality of software development – backend can be reused and GUI trends (Desktop or Web) change all the time ? 

5. Java and JavaScript – In my projects, I always used statically typed languages – benefit for compile time checks (C/C++ or Java/C#) is undisputed. What would be your advice for Java engineer in regard to JavaScript ? Unavoidable future or majority of development but not all ?
6. Thoughts on Golang ?
7. ForkJoin and Java EE 8

Topics:

1. Java EE 8 News
2. ...YOUR QUESTIONS

Hello Adam,
What are your thoughts about wildfly-swarm for microservices??
In my opinion I still prefer to use application servers with docker, but what is your opinion about it, what is the future??
Greets
Julio Cesar

Hello Adam,

How to control the life cycle of stateless ejbs ? Actually i'm injection some services with @produces and in case the configuration changes i want ejbs with the new configuration only.

Thank you so much!

Hello Adam
i am implementing an eCommerce application using java ee 7, glassfish server 4.1, MySQL databases, jsf 2.2 for the front end.
My preoccupation is to know how to handle ViewExpiedException(javax.faces.application.ViewExpiredException) .

Here is the error message display in my netbeans IDE consol

javax.faces.application.ViewExpiredException: viewId:/client/catalog.xhtml - La vue «/client/catalog.xhtml» n’a pas pu être restaurée.
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:210)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:415)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:744)

Hi Adam,

I have a Big monolithic Java EE + Java 8 application running on Wildfly 10 and we have some Rest Integrations and I'm using JaxRs Clients to communicate with some external resources.

The Client documentation says:

Clients are heavy-weight objects that manage the client-side communication infrastructure. Initialization as well as disposal of a Client instance may be a rather expensive operation. It is therefore advised to construct only a small number of Client instances in the application. Client instances must be properly closed before being disposed to avoid leaking resources.

I tried use application scoped CDI Producer:

@ApplicationScoped
public class JaxRsClientProducer {

    @Produces
    @ApplicationScoped
    public Client produceClient(){
        System.out.println("JaxRsClientProducer.produceClient()");
        return ClientBuilder.newClient();
    }

    public void clientDispose(@Disposes Client client){
        System.out.println("JaxRsClientProducer.clientDispose()");
        if(client!=null){
            client.close();
        }
    }

}

But if some request don't cleanup the resources the client is invalidated for future requests :

Invalid use of BasicClientConnManager: connection still allocated. Make sure to release the connection before allocating another one.

What is the best practices to use JaxRs 2.0 Clients on Java EE applications?

Let's say I have a webapp on a Glassfish 4 server, which logs under ${com.sun.aas.instanceRoot}/logs/Application in webapp.log.
How can I serve this log file in the browser?

I can serve it easily if I have for instance a REST endpoint and return

new File("${com.sun.aas.instanceRoot}/logs/Application/webapp.log");,

but I want to also access it if I don't have a .war with such an endpoint on the server - I only have an EJB jar which logs into that file and I want to serve it in the browser.

Overuse of CDI a bad smell?

I work on a web application were almost every class is a CDI bean (no EJBs allowed because CDI is regarded as more "lightweight" from our architects...no comment). For instance we have simple classes like this annotated with @ApplicationScoped:

@ApplicationScoped
public class FooConverter {

    public Bar convert(Foo foo) {
        Bar bar = new Bar();
        // mapping code here
        return bar;
    }

}

With usages like this

@RequestScoped
public class BusinessLogicClass {

    @Inject
    private FooConverter fooConverter;

    public void someMethod(Foo foo){
        fooConverter.convert(foo);
    }

}

Or even two or three inheritance levels higher like this:

@RequestScoped
public class AdvancedBusinessLogicClass extends BusinessLogicClass {

    public void someOtherMethod(Foo foo){
        super.someMethod(foo);
    }

}

This (ab-)use of CDI features don't make sense to me at all. I thought I only would use @ApplicationsScoped for classes that have attributes for application-wide use. I would go for direct instantiation for FooConverter via new. Even a static method would make more sense here and would be thread safe.

Hi Adam:
I'm trying to post a List into a jax-rs sub-resource with annotation @javax.ejb.Singleton, but always I got: HTTP Status 415 - Unsupported Media Type

I have another problem also, when I try to make a get request on the same jax-rs subresource I got MessageBodyWriter not found for media type=application/json, type=class java.util.ArrayList, genericType=interface java.util.List. this not happen when I remove the @javax.ejb.Singleton annotation

This two bugs are just present on glassfish or payara servers, on wildfly 10 works 100%

Thanks,

@julio-rocha-coderoad-com, isn't the solution to the problem you posted what Adam mentions in http://www.adam-bien.com/roller/abien/entry/jax_rs_returning_a_list ? I know it bothered me a lot until I stumbled upon that post and it solved my life since then, been using it with Payara and Wildly without any problem.

---

Now my own question: @adam, during the last session you had in JUG Nürnberg, you said that in your projects logging were only done when the necessity was there or if it was a requirement.
Let's say that it is with requests going through 5 different microservices, how do you implement your logging in that case: do you

1. make the logging from the individual services (the downside being that it requires each service to implement its own logging methods, which is not only is this redundant, but it also adds complexity and increases the difficulty of changing logging behavior across multiple services) or
2. do your services forward their logs to a logging service (services still need a way to generate logs, but the logging service is responsible for processing, storing, or sending logs to a centralized logging service) ?

Simply said, what would be in your opinion the better approach to that? Just made an application where logging was not my top priority and now the client would like to have some logging mechanism, by keeping it simple but clean (every microservice is only 75 KB so I wouldn't want to put some overhead on it).

Thanks for your answers, there are always appreciated and unbeknown to you, they always bring my projects a step closer to simplicity.

Hi Adam,

I hope it's allowed to ask 2 questions :) my second question has to do with monitoring an application as it came up at one of my clients today: how do you monitor the time elapsed during the execution of a method (the method is part of a call done in a micro service architecture)? Some of the methods (not all of them) have to be monitored and their execution evaluated.
One of the people during the meeting mentioned Java Simon (https://github.com/virgo47/javasimon) that I didn't knew about but as I had my computer with me during the meeting, I made a small check and using it for one of my methods moved it from a 2-liners to a 9-liners and I don't like to have things in my methods that make them explode.
What could you recommend for such a thing? And trying the add the monitoring and the logging by calling a logging service (case 2. of my previous question), the 2-liners method moved to be a 11-liners.

Thanks for your answer.

@dwamara yes it is, and I see that solution for the first part, but since 2014 to now, do I have to still using that solution?

Hi Adam,

Question regarding BCE

BCE is fine to organize "modules" and providing a common package structure. As far as i understood, the boundary is used as a kind of entry point (transaction startpoint, ...) to use the modules. Correct? CDI seems to be the "tool" to put everything together and building the application structure e.g. adding cross funcitonalities with interceptors.

But adding @stateless to the boundaries prevents them to be processed by CDI Extensions (because they are EJBs and not CDI Objects). This, for example, makes it impossible to add interceptors programmaticaly by a CDI Extension to @Stateless-Objects. I think this is a big disadvantage of the BCE pattern because the boundary plays a central role in this pattern and in application design and i want to have full CDI feature support here. What is your opinion about that? Do you have a solution for that? Or, should it work and do i make some kind of mistakes or conceptual faults (i am using JEE6 at the moment)?

regards
Karsten

(Currently, i am using a CDI Extension to add interceptors to arbitrary CDI classes but does not work with EJBs. Yes, adding interceptor annotation in code works well but this is not what i want to do. Its like adding some functionallity (temporary) to CDIs without byte-code-manipulation)

Hi Adam,

could you comment on this presentation?

Nine Neins - where Java EE will never take you (slides |video)

Points from presentation:

1. Java EE helps building distributed moniliths
2. Java EE has a threading-model that isn't ideal for microservices
3. Java EE doesn't support the notion of data in motion (streams)
4. Java EE doesn't support resilency
5. Java EE is implemented as containers - no service elasticity
6. No notion of immutability
7. Choice of data stores, use of transactions and evental consistency
8. No outer architecture - while still calling it a platform
9. Java EE doesn't know services

Thanks

hello Adam, About Monitoring Java EE, it is possible do use wildfly in the same way as you used on glassfish (like in your project lightfish). if it is not, can you talk about the diferences.