they are both free but i think glassfish has some limitation or when you reach up to a certain nr of users (comet) then you have to pay? is that correct?
if true, could you use tomcat as a comet server?
if not, then which free comet servers are there supporting long polling and iframe?
They are both free but i think glassfish has some limitation or when you reach up to a certain nr of users (comet) then you have to pay? is that correct?
No, GlassFish doesn't have such limitation (where did you hear that?). You only have to pay if you want official support through a subscription.
if not, then which free comet servers are there supporting long polling and iframe?
Jetty has support for comet-style programming. Tomcat has a Comet Implementation (but I find more complains than positive feedback about it on Google). You could also embed StreamHub. But I'm not sure about what they support exactly.
Personally, I'd go with GlassFish v3 / Grizzly. The main reason is that you'll find lots of samples, tutorials, etc (not mentioning that you already have downloaded GlassFish and NetBeans). For example this one.
UPDATE: While googling a bit more on this topic, I discovered Atmosphere, a portable AjaxPush/Comet Framework for everyone (wasn't aware of this framework and wanted to mention it). Quoting its website:
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.
But still, I'd go the GlassFish v3 / Grizzly way (and let Atmosphere mature a bit).
Have a look at Jetty. Free to use and has a lot of Comet support.
Related
Can we have an implementation of websockets in j2se?
I mean something similar to the old and not usable but lovely websocket4j?
I'm the author of an application server built in j2se. I don't care j2ee, I primarily use arrays, sockets, threads, db connectivity and filesystem access and it's all for my line. I just need to open to the websockets clientside world.
I don't need j2ee application servers. I don't want to use j2ee web containers. I need only to expand my application server build in plain java to be able to manage websocket sockets (http-handshaked sockets) as well as socket.
damn, somebody forgot the j2se implementation of the websockets?
I read it is not on plans (or only the clientside implementation), but I think what I'm asking should be already available; considered the coming importance of websockets. Isn't it? Why in J2EE only?
hope on some feedback.
thank you.
Your core question of "why" is probably a better fit for the OpenSource SE, but...
As an early adopter of Java, I'm sorry to say that there just isn't a whole lot of interest in J2SE anymore. Some of my favorite J2SE libraries have been coasting on "good enough" since the Java 1.4 days, and libraries for newer technologies are hard to find, as you've discovered.
The good news is that it might not be too hard to write one. There's a decent (can't say good because it's missing Javadoc) Socket.IO client library for Android that would probably be easy to port to J2SE. There are also a couple of server implementations floating around that I think have fallen behind in their support for current versions of Socket.IO. You could bring one of those up to date and port it. Maintain Android compatibility and it would probably attract a lot of support that would benefit both Android and J2SE.
Atmosphere
You might find the Atmosphere ( the Asynchronous WebSocket/Comet Framework) open-source project interesting. See also the Async-IO.org site.
I believe this runs on Java SE, as I use it in Vaadin web apps on Apache Tomcat on Java SE on Mac OS X.
Servlet Containers
Apache Tomcat, Eclipse Jetty, and other open-source Servlet containers run on Java SE with WebSocket code you can use.
Java EE is basically Java SE plus a bunch of jars. You can pick and choose various libraries to run on Java SE.
Wikipedia has a comparison of WebSocket implementations.
right answer came from #Paul:
Are you looking for something like this?
github.com/TooTallNate/Java-WebSocket
exactly.
Can anyone tell me if it is currently possible to "glue together" a partial Java EE 6 Web Profile over Jetty?
I've found a lot of articles about integrating standalone EJB 3 containers, JTA providers, etc with older Jetty versions, so I wounder if I could make it all work together.
I would like to assemble a Servlet 3.0 + CDI + EJB 3.1 + JTA (if needed, all I really want is declarative transaction management) + JPA 2 environment over Jetty 8 (or Tomcat 7 if no Jetty alternatives are available).
My questions are: Can it be done? Has anyone managed to do that? Any articles about getting OpenEJB, Atomikos, Weld, EclipseLink and Jetty (or any other similar stack) working together? Any magical "do it all" pom.xml files out there?
PS: Yeah, I know I could just use GlassFish (which I like very much). I'm just wondering about how hard would it be to get something similar working with a Servlet Container, and how the two environments would compare in terms of complexity, performance, size, deploying speed, hardware resource consumption, etc.
I'd describe this as still in the early stages, but here is what we have so far:
http://svn.apache.org/repos/asf/openejb/trunk/openejb3/assembly/openejb-jetty/
Note, Apache TomEE lives at a similar path, i.e. 'assembly/openejb-tomcat'. Plan is to call the Jetty version Apache JetSet and have it be fully embeddable. Most people with commit are currently working on getting Apache TomEE to be officially Java EE 6 Web Profile certified. I'd describe that work to be in the late stages. We've a great setup in Amazon EC2 to run the web profile TCK against TomEE using a hundred EC2 t1.micro spot instances. It's pretty sweet. The TCK agreement with Apache and Oracle does not allow us to share access publicly. However, any Apache committer can sign an NDA to get access.
Ok, so I mention all that about TomEE because the plan is once we're done with the Tomcat version, to do it all over again with Jetty (JetSet). Many of us committers, myself and Jonathan Gallimore for example, actually prefer Jetty by a large margin. But as the Tomcat integration code was much further along and had more users, we decided to just finish that one first. There is an incredible amount of work that isn't Tomcat specific that we will be able to leverage in the Jetty version; getting access to the TCK legally, the heaps of code to get it to run, the more heaps of code to get it automated, and numerous integration bits which are generic and not specific to Tomcat.
All that said, there's no reason others have to wait to work on a Jetty version just because most of us are still finishing the Tomcat version. Apache projects should be viewed as individuals working together, not companies like Oracle or Redhat or VMWare. That can be both good and bad. The good part is that if you or anyone else wants to hack on the Jetty version you can do that right now. You'll have to submit patches for awhile till you earn commit, but having someone else do the actual commit command is not that bad. If you start small and stay active and open, it's usually pretty easy to earn commit. The key to getting patches in quickly is a steady stream of small to moderately sized patches. Any step forward or sideways with no steps backward is a good patch in my opinion. As long as people can see where you're going it's good enough. Certainly more Agile than the one-big-patch approach and allows for all the really fun and collaborative magic to happen along the way.
Some threads which would be good places to say hello. Step 1 is just to say hello. No need to have code in hand to talk on the dev list or be taken seriously:
http://openejb.979440.n4.nabble.com/Jetty-Integration-td1457408.html
http://openejb.979440.n4.nabble.com/Jetty-Integration-td2318962.html
Tomcat has that stack implemented in a server called TomEE(formerly TomTom).
These are the components it uses.
Connector Apache Geronimo Connector
CDI Apache OpenWebBeans
EJB Apache OpenEJB
Javamail Apache Geronimo JavaMail
JPA Apache OpenJPA
JSF Apache MyFaces
JSP Apache Tomcat
JSTL Apache Tomcat
JTA Apache Geronimo Transaction
Servlet Apache Tomcat
As far as Jetty I'm not sure. OpenEJB is your only option for EJB outside of a JavaEE6 container(AFAIK) and I'm not sure Jetty is 100% tested with this. For CDI you can always use something like Seam.
In my opinion I believe the Spring framework would be your best option for the Jetty container(that's just my opinion though). In my experience after trying to get Tomcat working with Open EJB, Spring is a lot easier to set up.
You also have to remember Open EJB doesn't implement the entire EJB 3.1 stack at this point.
Also Open EJB is not tested on Tomcat 7 either. So you have to stay with Tomcat 6 if you go that route.
OpenEjb has not released a version with JPA2 support, although their development version supports JPA2 fine AFAIK.
I'm using embedded OpenEjb in Jetty6, because I could not get my app working in newer jetties yet. I think there is work under way to get an OpenEJB tightly integrated with Jetty like TomEE, but that may be some way off..
Geronimo is a complete J2EE stack which runs on top of Jetty.
There's a document on its setup on https://cwiki.apache.org/GMOxDOC30/configuring-virtual-host-in-jetty.html
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
Alright, the question might be broad. We've been looking at Jboss and a few other similar app. servers.
From the feature list it would be perfect for replacing our soon to be outdated homegrown reporting application on the server side. But at this point, for 2 developers, just grasping all the setup, configuration, administration, tuning,testing not to mention the APIs and programming itself just seems way too much, too big, too complex.
What path does people take to become familiar and productive with such application servers ?
Start with a simple one, and only use a more complex one if you really need the features.
For example, Do you really need the full JBoss stack? Would Tomcat not be sufficient? It's much less of a handful.
I would approach this the same way I approach anything new.
Start with the documentation - read the introduction and basic setup/configuration documents. Then move on to tutorials and maybe some simple apps that I find interesting. In your case, maybe port a few features over to the new system. As time goes on, you should get better with the tools at hand.
From my experience using one is the best way to learn what you like/dislike about it. Once you have a project set up for one application server it should not be too much work to migrate it to another. I am currently working on an application that we develop & test daily using a simple Tomcat v6 server, but which runs in production on both Websphere Application Server and JBoss.
As a side note for your development, I strongly recommend looking into integrating your Eclipse development environment with your chosen application server through server adapters - it will greatly speed up development tasks and simplify the debugging process.
I'd say that the minimum features for using Java EE are:
Servlets and JSPs, written using JSTL (no scriptlets)
JDBC
JNDI for pooling database connections (optional but recommended)
Basic authentication for security
You can accomplish a great deal knowing just those. If you want to minimize the learning curve, I'd recommend starting with those and staying away from EJBs, JMS, Struts, JSF, etc.
Another benefit is that this subset of features is common to both servlet/JSP engines, like Tomcat, Jetty, Resin, etc. and full-blown Java EE app servers like WebLogic, JBOSS, WebSphere, etc. An app that runs on one should be portable to any of the others, as long as you stay away from app engine-specific extensions.
You should realize that there's a trade-off here. You'll have to develop pieces that might be easier if you leverage the app server more. But hopefully you'll start with some simpler problems and work your way up once you're comfortable with the basics.
There's another approach: Hire an experienced guide to help you with training and mentoring for the first project. A six-month gig with a reputable consulting firm might get you started.
Last of all, I'd recommend Spring. It would also have a learning curve, but it's a good alternative to Java EE EJB development.
There seems to be multiple extremes when supporting embeddable Java HTTP servers. I have seen minimalist approaches such as NanoHTTPD and leveraging the com.sun.net.httpserver package to attempting to embed Jetty and Tomcat. The ideal embeddable HTTP server would be implemented such that it could be launched via Executor and come with Servlet/JSP support but otherwise should allow for using the logger of its parent and allow for integrating its JMX hooks.
Likewise, it should also be modular enough where you can have the option of NOT including certain pieces of functionality. Has anyone ran across any Java-based HTTP servers with this characteristic?
jetty:
JMX integration
configurable logging (both for request and debugging)
JSP 2.0 and 2.1
I think grizzly is an ideal solution for you. https://grizzly.dev.java.net/ . Out of box it's simply a NIO server, but there are different packages with support for HTTP, Servlets\JSP and etc.
I couldn't afford the overhead (in size) of even a minimal Jetty, so I wrote my own framework - I can't remember if Jetty had OSS licensing encumberances which ruled it out for us. But, at the time, I was highly impressed with Jetty's design and highly modular architecture - it was easily the best option I explored (back in 2001 or so) and I recommend it.
The question is how much functionality you need. The small ones typically only supports http requests, where you may want servlet API, https communications, web applications, etc. Jetty is very highly modular so you can put together what you want.