In Java, while using Glassfish Server, we could only save files relative to our web application root. Thus you cannot directly save file on eg c:\program files\abc.txt whereas with php this is working. Is it valid? One should not be able to refer any location on hard disk outside web application root (unless you are using Virtual directory). Why are there so contradictory principles?
It's a security feature of Glassfish (via the security features of the JVM). You can disable it if you really want, but the idea is that even if you've got some nasty security exploit in your web app, that shouldn't compromise the rest of the box if it can be stopped.
I don't know whether PHP has such a feature at all - web application containers can do this (and similar things) reasonably easily due to the rest of the sandboxing of Java and the security managers available.
In practical, any deployed applications should not be able to make modification outside its scope because that may allow malicious (or buggy) applications from messing up the hosted server. That being said, it really depends on the application server too, some servers maybe stricter than others. I know for sure Tomcat allows me to write directly to my C drive whereas Websphere server will bark at me if I do so (even though there has to be an option where I can turn it off).
PHP has two such security features. Neither are enabled by default.
open_basedir is a configuration setting that restricts file operations to the specified directory trees. To match how Glassfish is configured, it should be set to the document root in the web server's configuration (using php_admin_value if you're using Apache)
safe_mode is Deprecated (i.e. do not use). It restricts file operations to ones that the user running PHP owns... most likely the account the web server uses.
PHP's older than Java EE containers. It lets you get away with a lot that you can't get away with in newer, less "trusting" systems.
Related
I am trying to understand what are the use cases for using Java Web start. What are the advantages of it over a web application. Is Java web start still relevant today?
What are the advantages of Java WebStart over a web application
These two are very different approaches to implement an application:
A Web Application typically refers to an application which runs completely on the server side (keeping aside JavaScript, which executes inside the browser) and uses a web browser to visualize its user interface and handle user inputs. The main advantage of such an application is that no software needs to be installed on the client side, besides the browser (which is usually available on any system today). Sometimes this is referred to as "zero-deployment".
Java WebStart on the other hand is a deployment technology which allows to download applications and run them locally on the client. The starting point is again the everywhere-available browser (or more specifically a URL), but once clicked, the URL downloads binary components (.jar files, but also system dependent native binaries) to the local system and then they are run locally. This also requires a very low effort from deployment perspective, but at least a Java Runtime environment needs to be available locally. But still, it is much less effort to run an application than having to download a installer, launch the installer, choose an installation directory etc. Java WebStart does that for you. Additionally, it also automatically handles updates - when the url is clicked subsequently, WebStart checks if the files have changed since the last run and downloads them as necessary. Otherwise, it uses the files from a local cache.
Is Java web start still relevant today?
Yes, definitely. If you have a rich (Java) application which needs to run locally on the client, you can use WebStart to deploy it with very low effort - all you need to send to the users is a URL.
See also
https://stackoverflow.com/tags/java-web-start/info
Is it possible to use Java webstart execute .exe or dll?
Java Web Start and Web applications solve two very different problems. A Web Start program is a regular graphical application program that is downloaded to and run on the user's computer. It acts like any other downloaded program written in Java, and typically uses a toolkit like Swing for its interface. It'll need to be digitally signed and approved by the user, and the user will have to have a JRE installed on the client computer. Web Start is just a convenient way to get the jars for the application downloaded and kept up to date. Web Start is useful for applications that need quick response times, lots of computation, or to access files on the user's computer (e.g., a photo uploader).
Web applications, on the other hand, are Web sites with interactive features. Examples include everything from Google's search suggestions to Facebook to Stack Exchange. Java is a useful language to write Web applications in, with tools like Spring and Hibernate, but a Web application is just a Web site that's delivered to the user as HTML and Javascript and runs in a Web browser.
I've taken over maintenance of an old web application, which uses multiple applets embedded in the same web page. This used to work fine, but since the Next Generation Java plugin was introduced (~1.6.0_10) the individual applets are not guaranteed to load in the same JVM instance. If they load in different JVMs, they cannot communicate through AppletContext.getApplets() or through static variables.
Is there any way we can force the applets to load in the same JVM instance? I saw a workaround mentioned where specifying identical 'java_arguments' parameter may encourage the Java plugin to run applets in the same JVM instance, but this does not work for our application (and in any case is not officially supported by Oracle and hence may disappear any time in any case).
We've also tried replacing direct applet-to-applet communication with indirect applet-to-JavaScript-to-applet communication, but we can't use this approach as our clients use old web browser versions which prevent this from working. I'd be keen to avoid routing all local applet-to-applet communication through a non-local server if at all possible.
We had a similar problem and worked around it by disabling the "next-generation" Java plugin in Java control panel.
I work on a standalone Java application that is a command-and-control system for an assortment of hardware. The C&C software basically runs from a command line, and controls the system hardware which is spread out all over the place. It does not require a GUI to meet the business requirements. I have written a small swing GUI just so I can see what the overall status is of the system, but again, that is not essential.
Going forward, we would like to have a Administrative web GUI with system status and something that would give a user some level of control over the hardware. We were thinking that GWT might be a viable solution. Our GWT app would have to have some sort of IPC with the C&C software. I don't know how viable that is, I don't know that we want the C&C software bundled as a web app that has to run under application server.
I just don't have much experience with this. I was thinking that the GWT client would interact through RPC with the GWT server, and the GWT server would have some sort of RPC (RMI???) with the C&C.
Another option you have is to run a Java Applet that can interact with both GWT (using JSNI) and with the OS. A simple example would be to open a common file in the user's home folder and read/write to that file (with the C&C app doing the same as well).
You can embed embedded tomcat or Jetty into your application and let it run a simple servlet/JSP - based or GWT-based web UI. In fact, when you debug/run your GWT application from Eclipse, it starts in an embedded Tomcat instance.
I found a solution by using Spring. We have modified much of our Command and Control app to use Spring IoC, and then we used other Spring libraries to extend its functionality. To interact with GWT, we exposed services and used httpInvokers to make calls from the GWT server code.
Of course, this meant we needed to use Spring with our GWT application too in order to make the http calls from the GWT server code. But all is working.
you dont have direct control on the client system with JavaScript (which GWT is based on). in your use-case that wouldn't even make sense, why using an external server for a website controlling a local program?
If you reverse this (the app server is running on the same system as the C&C software, and the web client is available from everywhere) than that would be possible, but that wouldn't have much to do with GWT. On the server you can write normal java code. GWT just would be used for the web GUI and the RPC-calls to the server.
The call to the C&C software from the app server could be realised with the following line (windows example):
Runtime.getRuntime().exec("C:\\PathTo\\Program.exe")
This function return a instance of class Process which provides an Input- and OutputStream to simulate user input and to read and process the programs output.
Please note that you lose platform independence with this method, because the parameter for exec() looks different for every OS.
EDIT
After re-reading your question, it would even make more sense to integrate the C&C software into the server code directly, as the comment on your question suggests. you need a application server to use GWT-RPC, not a webserver, but thats hairsplitting.
Informations on how GWT-RPC generally works can be found here: (tutorial), (detailed description)
Why is there so much confusion in the java world with various servers like apache, tomcat, jboss, jetty, etc and in .Net world it is just IIS that does that job. I would like to understand the need and use of it and am not starting a java vs. .net.
There are several reasons.
A Java EE app server is a transaction monitor for distributed components. It provides a number of abstractions (e.g., naming, pooling, component lifecycle, persistence, messaging, etc.) to help accomplish this.
Lots of these services are part of the Windows operating system. Java EE needs the abstraction because it's independent of operating system.
It should also be said that the full Java EE specification isn't necessary for developing web applications. JDBC, the part of Java that deals with relational databases, is part of Java SE proper. Java EE adds on servlets, which are HTTP listeners, and Java Server Pages, which is a markup language for generating servlets. You can develop fully functional web applications using just these technologies and Java SE. Tomcat and Jetty are two servlet/JSP engines that can stand in for full Java EE app servers.
If you take note of the fact that .NET has HTTP listeners built into the System.Net module, you realize that it's as if .NET took a page from Java and folded the javax.servlet functionality into the framework.
If you add Spring and a messaging functionality like ActiveMQ or RabbitMQ, you can write complete applications without having to resort to WebLogic, WebSphere, JBoss, or Glassfish. You don't need EJBs or the full Java EE spec.
UPDATE:
Spring Boot offers the possibility of developing and running full-featured Java applications as an executable JAR file. There's no need for any Java EE app server, just JDK 8 or higher.
This is because Sun and Microsoft had very different goals with their software, and ways to reach that goal.
The Sun mantra for Java has been right from the beginning "Write once, run everywhere", and that has resulted in that much effort has been put into creating _API_s that specify how the environment should look like to allow a minimalistic piece of code do its job.
The API for "process a web request and return a web response" was named Servlets, and has been extremely successful due to it filling a void and being well specified. All mainstream Java based web servers I know of allow to run servlets. An early implementation of a complete servlet capable web server is only 1500 lines Later this was expanded to include JSP's to provide for HTML with server side code (like PHP).
For any solution to be truly scalable, including web solutions, it means that eventually the load is so high that one computer is not powerful enough to run it on its own anymore. A scalable solution MUST be able to spread over multiple computers aware of each other, and that single requirement brings a LOT of other things to the table:
Code must be able to invoke code running on a different computer (EJB's).
Data must be available to all computers in a consistent way (database).
Access to said database must be efficient (database connection pooling).
... and much much more
Sun then created API's for all of the functions they found were necessary for this to run, and named it "Java Enterprise Edition" (those days the word "Enterprise" was used for a lot of things), and created a system implementing all these API's which people could buy and use.
The difference between Microsoft and Sun now comes in play. Here Microsoft would just make IIS public, and say "use these API's" in clients but not actually want anybody to create another server providing these APIs. Because they want to sell Windows to run it!
Sun wanted people to use the language instead, so they made it possible for ANYONE to implement the Java EE specification, but they had to pass a rigorious test suite from Sun (and pay) to be allowed to use the Java EE brand. This has caused a large number of Java EE servers to be available where you usually can reuse the core business logic, but have to configure the Java EE server to provide the resources the application needs.
See http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition#Certified_application_servers for the state of servers today. Both commercial and open source are available based on your needs - pick the one that suits you best.
So, the reason is that Java EE is a set of well defined API's that anyone can implement, and they have.
First off, you can run .NET code off Apache using mod_mono, so it is not limited to IIS. There are also several other web servers (Cassini and XPS come to mind) that will run ASP.NET as well.
In order to run a dynamic web application you need both a web server and an application server. Sometimes these integrate so well they appear to be one and the same, sometimes not.
In regards to Java - it has always supported more platforms than .NET and has been more open, therefore got integrated to more web servers (on the Linux stack).
As both .NET and IIS are technologies that came from Microsoft, ASP.NET and the application server aspects of it (aspnet_isapi.dll) were bundled with IIS and the different .NET installers integrate with IIS. Of course, Microsoft only implemented it on their OS and for their web server.
Apache is very analogous to IIS, and doesn't have much to do with Java.
Application Servers in Java provide additional services that .NET provides in various ways, with different products or from the Windows operating system.
Apache is typically used in Java deployments as a proxy to an application server behind it, and potentially serves static content, or handles SSL, and similar concerns. It is entirely optional, although there are good reasons to use it.
Tomcat and Jetty are basically java web servers, which provide a defined framework (Servlets among other things) for creating dynamic web sites with Java code. They are often components of a larger application server, or can be deployed alone.
JBoss is an example of an application server (Glassfish and Weblogic are two very common others), which provides the full J2EE specification. The idea behind the J2EE specification is to allow a defined way to build an application server so that an application can be switched between different application servers from different vendors that comply with the spec. The specification is about how to interact with defined services that are useful for server-side program.
Because Java EE is a specification, not a product itself. Remember that Java is a lot more open than .NET (In the specification sense).
Each application server has different features, different performance, different target users/enterprises, different price tags, runs in different platforms, require different hardware. Differentiation is why those all application servers exists, one size does not fit all.
One reason is that writing a servlet is as easy as implementing the javax.servlet.Servlet interface in a concrete class. Servlet containers, then, only need to support a fairly simple API in order to call themselves web servers. This makes setting out to develop a servlet container extremely simple because of this limited contract of functionality.
The choices off tools are one of the advantages and disadvantages of Java, look at the available Java Web Developement Frameworks,you could evaluate them endlessly just to decide. in .Net it's pretty much MVC. With servers it's relatively simple. Most go to Tomcat if they need a web server and JBoss if they need a free application server though. The reasons for this have already been said, J2EE is a specification.
We develop Java Web-aps (Websphere, DB2) which display graphical and databased information. We would also like to offer the same application offline (distribution via CD/DVD) with online data-update. We have tried a number of alternatives in the past, but nothing has been really stable. What are the new best practices to take a Web ap plus data (in a small database) offline?
I don't know how well it works with the CD/DVD distribution front, but the first thing that comes to mind is Gears. On the .NET side of the fence there's Silverlight 2. Then there's the Mozilla Prism project, although I don't know how far advanced that is.
These are all designed for not just offline access, but mixed offline/online, talking to a server when it's available and working locally when necessary.
I'd suggest using Apache Derby as the database (also available as Sun's Java DB, and possibly still IBM Cloudscape (does that still have DB2 compatibility in place?)).
I'm sure there's plenty of Web servers/Servlet containers about. Apache Tomcat is the obvious one. An alternative approach would be to use an embedded native browser within a single Java process. That approach should be relatively hassle free for users and tech support, and you can just use WebStart to install and update.
If you're using EJBs and other nonsense, then there are similar freebies about. I understand Sun Glassfish is nice and fast starting.
You could create an image of your server as a VMware instance and distribute it with a copy of VMware player (licensing allowing of course). Personally I'd build it on top of a Linux distribution like CentOS5.
You can bundle a JRE along with JETTY server and use a different database e.g HSQLDB (that you can bundle inside the webapp itself).
If you are using an ORM tool to connect to database, you might not have to make many code changes for this.
A lot of Application server distribute their admin consoles like this.For e.g Weblogic admin console runs offline (it uses internal ldap server for its database)
Also as far as Google gears is concerned, they are also pretty much doing the same thing.
They have a server that is bundled along with SQLDB and they allow to synchronize the data between online offline app.
You can sync the data too (use webservices in the online app) and talk over https from the offline app to sync the data, if you need the sync feature.
Also you can check this link
http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-69700.pdf