Develop Reference

Can you implement Vue.js in a Java EE web application?

I just develop a tool with my classmates and we want to use Vue.js as Web interface.
For Description what we programmed. We developed a Java EE web application in Eclipse. We use Tomcat 7 as web server. I search a long time and i found nothing.

Vue.js is a javascript front-end framework. There is nothing to stop you from using that with a middle-layer/back-end technology like Java EE.
In your HTML pages(or JSP) just include the Vue.js file as mentioned in the documentation, and other .js files that you create as part of your vue.js frontend application.
The library can then interface with any HTTP-based backend methods that you expose (using Servlets, Controllers, etc.) depending on how your Java EE project is structured and what frameworks it uses.

While investigating the same question, I found this good blog that has a git repository too
https://blog.codecentric.de/en/2018/04/spring-boot-vuejs/
From a glance it looks like a read solid implementation, however it has some sticky setup i haven't come across before.
It dose however seem like a professional and scalable solution i will definitely
give a try.
https://github.com/jonashackt/spring-boot-vuejs
Thankyou 04/24/18 by Jonas Hecht

For sure you can.
Your java application, which is your "backend", has to expose its functionalities as Web services (REST Json WS should be the easiest for what you are trying to do).
To expose your services as Web services, you need to find the easiest framework fitting your need. You will probably need to dive into Maven if you haven't yet, because these frameworks tend to have tons of dependencies.
Your Vue.js interface will make calls to the backend via HTTP requests each time necessary (get a resource, update a resource, ...).

learning java/spring from python/django

I am required to pick up java (with basic previous experiences) + 1 specific application framework, having spending most of my times in Python and Django. Chose Spring mainly due to my requirements.
May I know what could be the equivalent of Django's development server in Java so I can easily run and check my Java code?

You can deploy a web app using Spring to any Java EE app server. I'd say that the simplest choice would be Tomcat, the Apache servlet/JSP engine.

I would also suggest Jetty which is a lightweight servlet container like Tomcat, but keep in mind the problems regarding deployment of Java EE applications mentioned in this thread Can Jetty be used as a Java EE lightweight application server?.
Another alternative is Glassfish.

If you are working with netbeans then Glassfish is a good fit since there is very good integration between the two.

A Java HTTP Server

I want to implement a Java HTTP server locally, I mean the server computer would be in my control. I'm expecting not more than 20 clients to send requests to it.
I was wondering how to go about it:
Should I use a J2EE servlet container, like Apache Tomcat?
Could I use J2SE classes and just build it using them?
Are there any existing alternatives?
What does your experience suggest?

There's a simple HTTP server embedded in the Sun 1.6 JRE. It's not JavaEE or servlet-compliant, it's very lightweight, but it might be good enough for your requirements. No need to download any 3rd party stuff if this is all you need.
The javadocs, rather bizarrely, are out on their own, here.

Embed Jetty in your application. Aside from performing quite well, it is delightfully easy to use and configure

You've got many options, not the least of which are Jetty, Grizzly, and TTiny.
I would strongly urge against writing your own web server, unless you've got time to kill and want to spend it writing things that are already available to you for free.

Seriously, reuse an existing solution. Why the hell are you even thinking rolling your own?
Now, 1. I don't understand your question as being about embedding a container. 2. You mentioned long polling several time. So I'd suggest to use GlassFish v3 / Grizzly (because there are many samples, e.g. have a look at the Dead Simple Comet Example on Glassfish v3 / Grizzly).
If you don't want to rely on the way a container implemented Comet support, use atmosphere and any of the container mentioned on the web site:
Atmosphere is a POJO based framework using Inversion of Control (IoC) to bring push/Comet to the masses! Finally a framework which can run on any Java based Web Server, including Google App Engine, Tomcat, Jetty, GlassFish, Weblogic, Grizzly, JBossWeb and JBoss, Resin, etc. without having to wait for Servlet 3.0 Async support or without the needs to learn how Comet support has been differently implemented by all those Containers.
If this is not a concern, just stick with the suggested option (GlassFish v3 / Grizzly).
For a concrete and recent comparison between Comet server implementation, checkout this awesome Comet Maturity comparison grid view (source: Comet Gazing: Maturity). It might help you to make your final choice... or not :)

I guess the biggest question is: why do you want to build this?
If it is for the purpose of personal development, I'd stick to whatever standard libraries come with your JDK and build it on top of that.
If on the other hand you have a particular application that needs a dedicated HTTP server I would try to take one of the open source servlet containers, like Jetty or Tomcat and build on those.

Perhaps look at the list of 26 open source web servers at http://java-source.net/open-source/web-servers.
http://java.sun.com/developer/technicalArticles/Networking/Webserver/WebServercode.html is actual code in a single file implementing a multi threaded webserver. For your requirements, such as they are, this should suffice.
http://java.sun.com/developer/technicalArticles/Networking/Webserver/ is an analysis of the code.

If you will write your own HttpServer you will have to implement all the methods of the HTTP protocol. Tomcat can be easily used locally.

Is it for practice, fun, to implement special requirements or why don't you just embed an existing solution?

Do you really want to build a HTTP server that deals with the protocol directly, or do you just want to write web apps? If all you care about is writing the web apps, then just use Tomcat, or Jetty, or Glassfish, or another server -- it will save you a ton of work.
If you really are interested in writing your own server from scratch, then the best way would be to just use Java SE, and not use any existing server technology.

Ad your 3) option: Try JBoss Netty.
http://fisheye.jboss.org/browse/Netty/trunk/src/main/java/org/jboss/netty/example/http/websocket

Advantages and Disadvantages of Java EE vs. Servlets

What are the primary reasons for using the Java EE (EJBs) over just a simple Servlet implementation?
I am working on developing a new project that will primarily be a web service that must be very fast and scalable.
Sorry for any confusion, Although I am experienced in Java, I am very new to the Java Web world, and may not be asking this question well.

Servlets are HTTP request listeners; they can't respond to anything else.
If you embed a great deal of logic in servlets it won't be available to any other clients.
Write your app in POJOs. Get it thoroughly tested without an app server involved. Then worry about how you'd like to package and deploy it. Servlet? EJB? Web service? Something else? No problem - those are just packaging and deployment issues. Get the behavior that you want working properly in POJOs first.
Spring can give you a lot of options here. I'd recommend it.

EJB's specification 1.x and 2.x added complexity that for most webapps was not needed.
Due this complexities the new frameworks appeared to simplify the development and the runtime architecture ( Hibernate / Spring / other microcontainers / others ORM frameworks ) .
EJB's 3.x matches this changes ( through JDO and JPA ) and now, using Servlets with these enhanced frameworks or Java EE with EJB 3 + would give you basically the same results.
Using a Java EE Application Server would add you a number of administrative advantages ( GUI to manage pools, logs, monitoring, transactions etc. ) With out them you may have the same result but you would have to do it all by hand ( editing configuration files that is ) Which may not seem too problematic, but if you plan to have an administrator for your webapp It would be better to use the admin tools that come out of the box with this servers.

Is the web service stateless? If so, I don't see any real advantage in using a full blown Java EE server over something lightweight like Tomcat or Jetty. You can deploy a jax-ws implementation with either of those, and do what you need pretty easily. If there's some kind of state involved, and you end up wanting to share that across multiple machines, that is where having Java EE can come in handy.
With that said, I don't think Java EE would decrease performance any at all. The app servers generally take longer to boot, and take more effort to manage, but once they are up and running the performance should be similar.

If your web services are likely to need any degree of "enterprise" features such as per-method security or transactions use EJBs.
With EJB 3 this is not actually very hard at all, a couple of annotations and you're done.
Otherwise simple POJOs behind a servlet are enough.

Java Web Service framework/library, which is a better one and why?

Currently I am evaluating number of web service frameworks in Java. I need web service framework that will help me to expose some functionality of existent application running on JBoss, The application is mostly developed using Spring and POJOs (no EJBs).
What I need is a framework having following properties:
It should provide tools for automatic generation of boilerplate code and save time by eliminating repetitive tasks, for example tools generating WSDL from Java (java2wsdl), tools generating endpoints etc.
Applications should be easily deployed on existent J2EE platform (JBoss), this means that it should contain as less as possible configuration files (like axis2.xml in axis2 framework).
Also it is preferred to be able to deploy web service within .war archive of existent application. (it seems that Axis2 need a separate archive for web service app.)
It will be very cool to use a combination of POJOs and Spring.
Generally, the framework should have clean structure and design (for example Spring-WS lacks it), good documentation and whatever else characterizes a good piece of software.
It is preferred that framework incorporates some standard features like JAX-WS etc. instead of vendor specific methods.
I have briefly examined
Axis2
Apache CXF
and Sun's Metro
Spring WS
But still it is difficult to decide what to use in my case:
Axis2 seems to be so low level, it requires separate application archive and lots of configurations
Spring WS seems to be too opaque and "sophisticated for impression purposes (?)"
Apache CXF and Metro probably are two frameworks that I prefer to chose from but still
I need your opinion and experience about usage of some of them in a real-world applications.

I've used CXF's forerunner, XFire, for a while now and it's not been too bad. At the time, we migrated from Axis for two major reasons: performance and ease of development. At the time (don't know if this is true now), the performance of XFire was much better than anything out there, and with annotation-driven development, instead of having to run stub generation, it was really really easy to add new web services.
CXF seems to be more of the same but better - we haven't migrated yet due to constraints on development time as well as not having a pressing reason to do so (plus the relative lack of documentation 6-12 months ago wasn't too encouraging). Additionally I haven't really evaluated the market of late, so I can't tell you how CXF stands up to its contemporary competitors.
Regarding your points:
There is no boilerplate code to be generated, the WSDL is automatically created from the service class' annotations and published by the server.
Deployment in Tomcat was relatively simple. Just define another servlet in web.xml and map a URL pattern to this servlet.
Our web services were deployed in WAR files, I'm not sure what the alternatives are in fact but this seemed to be the default and obvious way to do it.
POJOs work fine initially; we've now moved most of the web service object creation to Spring in order to wire more complex conditional dependencies in and have had no problems with this.
Documentation was a weak point with CXF originally, though having just had a look it seems to be better now. The general design and architecture seems relatively sane; slotting in one's own filters to modify the transmission details was not very painful, and extending existing classes has generally been considered (so sensible methods are marked protected instead of private, for example).
JAX-WS is full supported in CXF.
So I'm probably a little impartial as I haven't tried the other ones, but I'll give a thumbs up to having a look at CXF. It's pretty fast, relatively simple to get going with and fairly powerful if you need to tweak it.

We have tried Metro and CXF and kept CXF because Metro includes too many dependencies like Sun's APIs in its jar files which makes it difficult to integrate in another application server than Glassfish. CXF has a cleaner packaging with explicit external dependencies.
We also failed to enable Gzip compression with Metro while it worked like a charm with CXF.

I'd go with Spring WS first and XFire second. I'm a Spring user, so I'm used to the opacity.

XFire now Apache CXF was far away easier to use than Axis. I had something done very quickly using it where Axis seemed overly complicated. I didn't look at Spring WS.

I will use CXF. It is easy to use than Axis2

I have only used the Spring WS because that is what I was told to use, but it was a pretty easy use framework. If you have to go with soemthing else I would go with XFire due to the JAX-WS support.