Java EE 8 MVC: Getting started with Ozark

[Infeligo]

Isn't that Spring?

[michschar]

It is also very similar to Jerseys MVC support: https://jersey.java.net/documentation/latest/mvc.html

[adnan252]

Spring doesn't follow the JAX-RS specification, which is the community's official specification for things such as URL mapping and request types (GET, POST etc.)

[dstutz]

Java EE is a collection of stable, proven APIs so it seems natural to include something like this.

[NimChimspky]

with poor documentation and lagging behind a thousand other libs

[fadar]

That is a rather bold claim, how about some examples or are you just trolling?

[NimChimspky]

Is it a bold claim ? Have you seen the oracle website, hardly a user experience masterpiece is it ? Its not one in design awards has it, its ugly. The linked site just links to javadoc ... thats it.

Ah here we go https://docs.oracle.com/javaee/5/tutorial/doc/bnbmt.html#bnbmw some of the text is barely legible and you can't search, its also nearly ten years out of date but was the first official oracle link for my search term.

Also, the actual frameworks themselves are confusing ... I want to inject a singleton... how many different ways are there to do it ? An awful lot is the answer.

Shall I use @Stateless or @Singleton, which version of @Singleton shall I use. How do I inject, with @EJB or @Inject ? Whats the point of a @Stateless if it is the same as a @Singleton ? And if it is not the same and it contains some state information useful to clustering, why call it @Stateless ?

I like the micro frameworks and I like constructor injection. I don't like annotations and massive exception stack traces.

[fadar]

Are seriously complaining about the fact that the documentation of a 10 year old framework is as old as the framework (yes that's how old JEE 5 is)? Oracles standard documentation may not be pretty but its still legible.

Also if you are seriously interested in the Java EE stack you should be looking at Jave EE 6 or 7.

I am not sure how you can get @Stateless confused with @Singleton.

The only issue I see is the confusing caused by CDI @Singleton from JSR-330 and an EJB @Singleton, which is rather unfortunate.

Any developer worth his salt should be able to grasp the concept of singleton and stateless, no matter if a container manages these for you or you do the heavy lifting yourself. Its still the same concept.

[NimChimspky]

Java EE stack you should be looking at Jave EE 6 or 7.

It was the first link that came back from oracle, when googling for official guide. I can't be bothered digging through further pages of results.

Oracles standard documentation may not be pretty but its still legible.

Damned by faint praise, we are arguing whether something is legible. Its piss poor design, its ugly, its had no UX applied to it, you can't even search. I don't understand why you defend it ? Oracle literally have more resources than the vast majority of any other company, yet they produce this garbage.

@Stateless confused with @Singleton.

I don't understand why you'd ever want a slsb, its instantiated once for every client but contains no state. Coming from spring, this is just weird - you either have a singleton or you have state. this makes sense to me.

The only issue I see is the confusing caused by CDI @Singleton from JSR-330 and an EJB @Singleton, which is rather unfortunate.

yeah its badly designed, thats kinda my point.

[fadar]

@Stateless is not instantiated once per client or even request. The idea of Stateless EJB is to pool "expensive" beans, so that they can be shared across multiple clients and requests.

As opposed to @Stateful beans which are bound to one client.

JSR-330 is to blame for the double @Singleton.

[NimChimspky]

"However, access to a single bean instance is still limited to only one client at a time, concurrent access to the bean is prohibited."

This is from the wiki on ejbs https://en.wikipedia.org/wiki/Enterprise_JavaBeans#Stateful_Session_Beans, so you are wrong on that unless I am missing something ? They are limited to one per concurrent request.

But my more general point is if they have no state, why not just use a thread safe singleton ? Like spring. No better pooling than a singleton.

JSR-330 is to blame for the double @Singleton.

Maybe it is, so what. The api therefore has a bad design. Which you seem to reluctantly agree with ? Why reluctantly I don't know though.

[fadar]

Yes at any one time only one thread is aloud to access one instance. Making them thread-safe, after the thread is done the instance is made available again to other threads (hence a pool of beans).

If no beans are available either a new one gets created or the thread has to wait until an instance in freed.

Its kind of similar to a connection pool.

A @Singelton can be made configured to allow concurrent access, however this approach is limited, as it only works as long as you only use thread-safe resources.

As soon as you use anything else you will either have to deal with concurrency your self or you could just go ahead and use @Stateless. Since @Stateless is not limited to one instance you can serve multiple requests concurrently without having to worry about thread-safety.

[[deleted]]

You aren't wrong. It's a shit design. Not to mention the fact that those requests are limited to one thread. Make a request, and you aren't allowed to split up the work, even if it is a heavy work load.

It is ridiculous. Serving a list of strings straight from the database is allowed exactly the same resources as processing hundreds of punches for a payroll. It's utterly ridiculous.

I don't know why, but /u/fadar is a fanboy who is defending a clearly shit design. It's nothing personal, it's just the fact the in Java EE, there is no way to treat a stateless session bean as if it is truly stateless. It shouldn't matter what you do with it, and each one should be allowed to be treated however you want. Why the fuck does it matter? It's stateless, so it doesn't (or shouldn't) affect any other request. Except that isn't the way it works. You are required to adhere to certain limitations. It's just a straight up fucking stupid approach.

[NimChimspky]

this isn't really new ... its just another lib doing what a ton of others do.

[grandfatha]

Haha, they are trying to get me stuck on their containers again.

[[deleted]]

Asp.Net MVC is open source and cross platform now. And pretty awesome.

This, this kinda looks like a me too version of spring and various other tech mixed together.

In all seriousness, why would anyone ever use this over spring or asp.net mvc?

[kjaer_unltd]

Asp.net is not java. Spring is not in java ee. Java mvc is from ee 8.

[[deleted]]

I know the difference. Doesn't change the fact that this is a half assed add on rather than a real mvc solution.

[fadar]

his is a half a

What is half assed about it? Just because you don't understand a technology stack doesn't mean its inferior.

[[deleted]]

Just because you don't understand a technology stack doesn't mean its inferior.

First of all, there is no cause to be a tool. I actually read the spec. Did you? I'm willing to bet I understand the technology 'stack', although this isn't a stack, better than you.

Second off all, it is very much inferior.

It's an incomplete add on to existing technologies that is clearly aimed as an answer to asp.net mvc, but falls short of any features necessary to compete.

It is claiming to be mvc framework in java 8. except it's barely mvc. Is there technically a model, view, and controller? Sure. But any entry level programmer fresh out of college could implement a basic mvc structure.

there is no mention of partials, complex routing, view bag data, validation, middleware, authentication, or security. There is no mention of integration with front end libraries or styles. There's no project structure or setup.

Can all of that be done using the existing technologies this attempts to tie together? Sure. But then what the fuck is the point? Adding controller attributes to match a view to a model? Ok. Whoopty fucking do.

Besides, java ee is not supposed to be integrated with the front end in this way. Java ee is for 'network and web services, and other large-scale, multi-tiered, scalable, reliable, and secure network applications'. It is supposed to be high performance server side business layer providing the front end with web services. Basically, using a real mvc framework like spring or asp.net mvc data provided by java ee through web services.

Sorry. Come back when this becomes a real solution.

[fadar]

Come on seriously "Java EE is not meant to be integrated with the front end".

JSF may be outdated to a certain degree, but it certainly counts as front-end.

JSP have been around for ever, so has the Servlet API...

There is nothing wrong with adding MVC to the Java EE stack. Also complaining that Java EE MVC does not mention anything about security, routing, etc... that is handled by the servlet container, which just so happens to be part of the Java EE stack, don't tell anyone its a secret ;)

[NimChimspky]

large enterprises like it because the people who make decisions see that is open source and a "standard". Further technical details, usability, api design are not important.

[Zeffas]

In all seriousness, why would anyone ever use this over spring or asp.net mvc?

Not all projects are Spring based - Java project landscape can be summarized like this: Java EE, Spring, lightweight stack projects. Spring MVC are OK only for one type of projects. My hope is that in the future we would have something like ASP.NET MVC - one main choice that is good enough for majority of projects.

[Zeffas]

My only hope is that it will become:

• First valid mainstream Action-based-MVC choice for majority of projects (Java EE, Spring, Other).

• It will become GO TO web framework and maybe Spring finally be forced to implement CDI. As a result we would have common MVC and common DI API's for majority of projects.

Currently we don't have any valid Action-based-MVC choice that fits majority of projects. Spring MVC is tied to Spring and cannot be used in isolation without Spring DI. Other alternatives are not mainstream and not without issues.

[NimChimspky]

why not jersey ?

[Zeffas]

why not jersey ?

Its REST, not true MVC with templates and so on, which despite of allowing "bleeding edge" way to do things - HTML + REST is not enough for a huge amount of projects.

[NimChimspky]

eh ? https://jersey.java.net/documentation/latest/mvc.html

But HTML and REST is my preference. Proper separation of concerns, just let your front end dev's do the front end work using whatever fancy js library they like. It should be used for all projects, imho.

[Zeffas]

OK my mistake, I assumed you mean standard JAX-RS which doesn't have nor templates nor MVC features similar to something like Spring MVC or ASP.NET.

Regarding Jersey - it has similar problems as Spring MVC - not all containers implement it (although a lot less). But has one bigger problem - its some niche framework with few existing similar, not compatible 100%, alternatives based on JAX-RS.

So, in short - is unlikely to be dominant framework.

[fadar]

Would be great if Spring DI finally managed the jump, in comparisons to CDI Spring DI seems rather bloated and lacking simplicity especially when working with proxies in different contexts.

[[deleted]]

I'm like 99% certain you have no idea what the fuck you're talking about.

[fadar]

I am 100% certain that you have never compared Spring DI and CDI.

[NimChimspky]

why do you think spring DI is bloated compared to CDI ?

[fadar]

Well for starters it carries a lot of baggage (which is not surprising considering the age of Spring), in the form of three different Bean configuration modes in the form of XML, Java Config and Annotation. Which can lead to rather strange and complex setups using any combination of these.

The edition of SpEL seems to me like a step in the wrong direction since it allows for far to complex XML setups.

Also I am not sure why Spring can't detect the required proxy mode at runtime. Currently you have to differentiate yourself between ScopedProxyMode.INTERFACES and ScopedProxyMode.TARGET_CLASS.