@edvin In your paper, are you limited to just a Singleton service? Don't you want WildFly to create multiple -at-Stateless objects for pooling?

@carlw No, not at all. The rest resources will ask for a new service on each request, so if the bean I inject is Stateless, I will get a bean from the session pool. In singleton beans I would use the instance.get pattern and ask for a new bean for each method invocation, so I would always get the right scope. I didn't really think about this before you said it though, but I don't see any issues 🙂

@edvin I've been packaging the RESTful web services with the EJBs in deployable WARs. If there is an unavailable period where the services are redeploying, the HTTP client uses the known error code to handle this.

@edvin It looks like your article is the ServiceLocator pattern plus a busy loop. One problem I've seen with the JNDI lookups in general is that there can be cycles, particularly at startup.

@edvin Also, the modules technique will be specific to WF. Have you actually modified something in the modules folder? I don't recall my changes to this folder immediately taking effect. With the WAR approach, the spec dictates how the components are going to come up (EJBs, referenced EJBs, web app, etc)

@ron Hi Ron. I saw some typesafe builder changes in your branch. If you'd like to send me a pull request, I'll merge in my changes and we should be ready for a final review.

@carlw Yeah, as long as the rest service and the EJBs are in the same module you will only see a small period where the clients will receive 404. That is solved in my approach, but further more, it is possible for the rest endpoint to call EJBs in other modules, and restart them without the rest interface going down as well. If you declare module dependencies between them, the container will restart the rest module if you just redeploy the service module. You are right in that I solve this with a busy loop, but the important takeaway is that I avoid the restart of the Rest module. This is not a big issue for rest, but it is giant for a JSF application with SessionScoped or ViewScoped beans. A restart there is catastrofic compared to restarting a rest interface, as it kills or view state etc. Hm.. maybe I should mention that in the article.

@carlw I'm not sure I understand what you mean by modifying something in the modules folder. I specifically deploy the modules using the service api of wildfly, there is no file polling or something like that involved in the redeployment, so it happens while I wait for an http deploy request to run - if that's what you meant?

@carlw Looking forward to looking at what you guys did with the builders etc, would love to look at it tonight 🙂

@edvin I use the exploded WAR in IntelliJ to push class updates when I'm working. You've added a build step to push the module out?

@carlw Yeah, I'm using the maven-wildfly-plugin to deploy. But the IDEA plugin also pushes redeploys via the http interface to Wildfly.

@edvin I'll have to check it out. I've only used WF modules for data sources.

Ah.. I primarily used them to push common dependencies to Wildfly so I didn't have to redeploy the libs with my business logic, but this works really well :))

@edvin Regarding the pure RESTful deployment...I just listened to a 2016 JavaOne session on JAX-RS which establishes a protocol for this sort of thing. There is something in the spec called a "circuit breaker" which will define a protocol for this, handling requests as a service is unavailable. (see 42:23)

@carlw I know, I mentioned in the post that I specifically didn't add a circuit breaker to keep the example simple, but that a production version probably would need to add it 🙂

Adam Bien did a nice circuit breaker implementation for Java EE a while back I think.

@edvin I wasn't sure if you meant a circuit breaker for preventing an infinite loop or the Circuit Breaker that lets the caller know about a degraded state.

Ah. I meant the latter. I will try to clarify. Thanks 🙂 I see that this blog post might spike a lot of controversy.. hehe

I added a link to Adam's circuit breaker implementation.

I like WF a lot. I'm supporting an OpenShift deployment and one deployed on client infrastructure.

I'm looking over the OpenShift deployment. The best deployments go through Git and there is a .openshift/config/modules folder.

The main problem I've seen with ServiceLocator is that with larger apps, you get EJBs referring to other EJBs which can ruin the startup sequence.

And you don't always know about problems upfront. You may have to wait for the getService() call to know if your deployment is working.

@carlw I will push it later tonight, around 22:00 I hope to be home

@ron Great. I'll look for it then.

I started adding the Stylesheet using the typesafe builders, but css and me are not friends

Was there a problem with the CSS provided by the parent project?

@ron What kind of problems? If you like, I can convert the css from the parent project directly and you can just add the classes and ids?

Not real problems @edvin just my lack of deep CSS knowledge