My company has developed a web application (J2EE environment/Tomcat server) and wants to sell it as a product. Customers can avail this product as basic edition or premium edition. In the premium edition the customers have some extra functionalities (may be some extra links). This distinction is made based on the serial key.
I was just a listener when the above thing was discussed.
Is doing the above problem possible? How do we convert a war file into an exe file and embed logic to distinguish premium or basic version.
How do we convert a war file into an exe file and embed logic to distinguish premium or basic version.
These are 2 distinct requirements which have nothing to do with each other.
If you have a web application you can either enter the serial key using a web page (like Jira does for instance), or you could perhaps let the key (or the filename of the keyfile) be written in Context.xml, and let a servlet read that context parameter. Based on the key the application could then allow or not allow some functionality.
As for converting to an executable, there are multiple interpretations to the word executable. I for one think "war" file is executable enough - dump it in a tomcat and it runs.
If you want it standalone you could provide a tomcat distribution with your app predeployed (again, like Jira does), or use a Jetty embedded container. Although that may not be appropriate for heavy workloads.
You could even try to convert jetty + your web app to a native exe using gjc (Gnu Java Compiler) though I doubt it will work as well as the normally deployed version.
I'd advise you to either inject the key via context parameters, or create an admin page n which you can enter the key.
A WAR is a web application archive. It's supposed to be executed on a webserver with a servlet container. An executabele JAR requires a class with a main() method, but a web application normally doesn't have any since that's the responsibility of the servlet container, not the web application. Normally, a WAR is to be distributed as-is, it's the serveradmin's responsibility to deploy it to a servlet container. You can if necessary include some documentation which describes how to do it for various containers.
If you really intend to sell a web application as a desktop application for some unobvious reason, then your best bet is really to include an embeddable servlet container like Jetty and ship a class with a main() method along it which creates an instance of the embedded servlet container, deploys the WAR file to it and runs the servlet container. This can in turn be wrapped in an executabele JAR.
Alternatively, you can also host it somewhere on the internet and provide a specific login.
Related
I have a Java EE application, running under WebLogic 10.3.5 and Java 6.
I used to have a pdf help file, embedded in my war file, but I need to extract it from there and put it in an external directory (it can be in my same WebLogic domain directory).
I tried to put it in my WebLogic domain and then to < a href > it, but it seems that browsers have limitation and for security reason will not allow to download local file with a href or javascript.
This used to work only on a static HTML file saved on my computer but one the HTML page is deployed on the server, it seems not be possible.
Any idea how I can externalize my help.pdf file from my war file?
#limc is right
you should put this static file outside of Weblogic altogether as a file on an Apache web server
However, in Weblogic there is a feature of virtual directory mapping which allows you to declare a folder outside of the weblogic domain as a content store for any static stuff.
http://docs.oracle.com/cd/E11035_01/wls100/webapp/weblogic_xml.html#wp1039396
This entry goes in WEB-INF/weblogic.xml
<virtual-directory-mapping>
<local-path>c:/usr/mypdfs</local-path>
<url-pattern>/pdf/*</url-pattern>
</virtual-directory-mapping>
Although some application servers allow a Java EE app to reference a file outside the web container, in reality, your web app shouldn't have any knowledge about anything outside the web container, and as you have mentioned, it is indeed a huge security concern.
Depending on what you are trying to accomplish with this PDF file, if you merely want to expose this file on the web, do what #duffmo said and it will work fine. If you want the flexibility to modify this PDF file frequently without recreating the war file again and again, you may want to consider hosting this PDF file in some HTTP web server (Apache2, IIS, etc) and now you reference that link from your web app.
You need to put it at the root of your web context, in exactly the same place as HTML pages. Your web server will be able to find it there.
I have an existing Java application (Spring based) that currently does NOT have a web interface, nor does it run in a web container. It packages up nicely with a start program and just works.
What I need to do is add an administrative web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs to give the users a warm fuzzy feeling knowing that everything is working. As we are a Spring shop, and some of our web applications already use Spring MVC it only makes sense to us, however, I'm not happy with the suggestions I've had from our internal Spring folks on how I should procede.
What would be the ideal way to bolt on this web interface?
Convert my application to a web application and have a web container launch the application. I not too keen on this approach is the web tier is really secondary to the primary application.
Create a separate project that packages as a war, embed Jetty in my existing app and have it load the war. I think I can use the context loader listener to make the root context of my application the parent to the web application spring context. This would involve breaking up my Maven project into 2 projects I believe. I can't use an existing web technology for communication between the web tier and the primary application as my primary application is not web enabled.
Embed Jetty and put the Spring MVC stuff directly in my app. While I've done this approach before, it does involve some ugliness - for instance exploding the JSP tag libs into my jar.
Any thoughts on some clean separation here?
Also of note, my current jar contains some utility applications which some shell scripts launch. Going a pure WAR route would make this not so easy, since I can't juse point java at my war file and choose a class to execute.
Thanks.
If it's true that web is just a minor addition the application, migrating it to WAR and deploying in servlet container might be an overkill. Embedding web server/servlet container looks much simpler, although it doesn't have to be Jetty or Tomcat. You can use web server built into JDK or write one on top of netty or even raw sockets. But that's a hell to maintain.
Yet another solution to springs to mymind when reading:
web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs
Maybe you don't need an interface, but monitoring infrastructure instead? Check out JMX (Spring has great support for JMX) - and write a second web application that simply connects to your standalone Java app via JMX and displays the metrics in fancy way. Another approach is to expose JMX via Jolokia, which translates JMX to REST services.
This approach has several advantages:
monitoring API is universal, and you get it for free
you don't have to use web client, monitoring application is completely decoupled,
finally changes to your original application are minimal. Check out this proof of concept: 1, 2.
It really depends on the structure of your existing Java/Spring app and how much of an API it provides. I've done something similar to this and I approached it by creating a separate Spring MVC project and then specified the existing Java app as a JAR dependency.
This is easy with Maven (or Ivy, etc) and provides nice decoupling. The trick is to be able to write service classes in the Spring MVC app which then access data via your dependent Spring app via a simple DAO class. That's why I stated at the beginning, that it depends on the structure of your original Java app. It has to be able to provide an API for data access that you can then plug your DAO (impl) into.
If this is not easily done, then the next option I'd suggest is simply converting your Spring app to a Spring MVC app. I've worked on another app where we did this. Using Maven, its possible to specify that the build can create either a war file or a jar file (or both). So it can be deployed as either a webapp (via war) or a normal app (via jar). Yes, the jar version has a bit of bloat but its a worthwhile compromise.
The question of embedding Jetty or using Tomcat via a war file is a completely separate issue that has its pros and cons. It shouldn't affect the approach you take in architecting the web app in the first place.
I have some deployment model question for a Java EE web application. Currently we are deploying our web application as a WAR file in Tomcat 6. All the content is packaged with the WAR file including the static content like images, static html pages and so on. But i want to deploy these static content in a HTTP server and use the Application server only for retrieving the dynamic content. How do i split these things? Does any one has done any thing of this sort and have a good deployment model for my scenario. Help will be appreciated.
Is it a good idea to make 2 WAR files one with only static content and deploy that WAR in HTTP server and the rest as a different WAR file and deploy it in the Application server? But this approach will have impact on all the pages where the static content is currently referred and requires code changes which is very cumbersome since our project is Huge and the code based is very very big.
Any strategy and ideas are welcome.
This can be something interesting to do for performance reasons.
You should have separate deployment scripts / deployment files to do this.
Having multiple file/WAR/folder/scripts to deploy for one project is not an issue. We have the same thing when you have to deploy your WAR and to update your database.
I would have a WAR file and a folder with your static content to deploy.
Edit
Deploying the static content in a HTTP server depends on the server.
If you want to use Apache on a Linux server, you have to set up a Virtual Host.
<VirtualHost *:80>
# This first-listed virtual host is also the default for *:80
ServerName www.example.com
DocumentRoot /www/domain
</VirtualHost>
In this example, you have the a virtual host that listens on 80 port, for any IP address and for the server name www.example.com. Then this is redirected to the /www/domain path.
You will find much more examples and configuration options in the documentation.
You can not deploy WAR file into HTTP server. A WAR is used for Java web applications it must be deployed into application server or servlet container (like Tomcat). I don't think that its a good idea to separate static content in a separate web application. If this is one project it should be one web application, besides:
A WAR file has a special folder structure and contains special files
in addition to JSP pages, Java servlets, Java classes, HTML pages etc.
which combined forms a Web Application.
You can hold your static contents in your one application and there is really nothing bad about it.
If your project is very huge and has a lot of files it is no problem, you just need to use the project structure like that, that it should be easily understandable and readable and the application server or servlet container will take care of deploying as many contents as there is.
Up to version 4, Tomcat has been quite slow in serving static content. This is why it was frequently recommended to split dynamic from static content and serve the latter using a regular web server (the book you mentioned was issued in 2002...). Recent Tomcat versions do not face this problem, thus you can IMHO refrain from splitting, which can be a nightmare for both organization and security.
For static resources, you might rather focus on configuring proper caching, so they will not be transferred more often than necessary.
I am currently developing an application for some researchers in my university.It's a small java program that you can use by command line. The next step is to package that program and deploy it to an application server. Some clients program will submit requests to the server who will call the tool that I wrote. Lately, we will add more tools to the server and he has to dispatch the requests to the right tool.
Which application server fits my needs ? I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Is it possible to use those servers in some context different from web context? Which package archive should i use (jar, war) ?
Any advice?
Some clients program will submit requests to the server who will call the tool that I wrote.
The big question is what server-side technology and what communication protocol can you use between the clients and the server. You basically have two major options: HTTP and web services (in that case, consider using either JAX-WS or JAX-RS) or RMI-IIOP and EJBs (in that case, you'll have to use a Java EE compliant server like GlassFish).
I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Not really. As I said, they can also be used for web services oriented applications. And GlassFish can be used for EJBs applications.
Which package archive should i use (jar, war)
The packaging will depend on the type of application you'll write, it's not something that you choose upfront, it's just a consequence. EJBs are packaged in an EJB JAR and typically deployed inside an EAR; Servlet based web services are deployed inside a WAR.
You really need to think about what technology to use first (with the current level of detail, I can't provide more guidance).
Do you even need an application server? There's nothing stopping you from adding the necessary network bindings and deploying it on its own.
Of the servers you mention, you've got 2 different categories: servlet containers and full-stack Java EE servers
Tomcat and Jetty are servlet containers. That doesn't mean that you can only do web stuff with them and you could manually add the required libraries to get a full Java EE server.
Glassfish is a full-stack Java EE server and can be compared with JBoss (both are open source) or the commercial rivals Weblogic and Websphere.
Sometimes this question is simple as the environment you are working in mandates a particular flavour of app server. You should check this first.
If you're not forced to use an app server, I'd ask why you think you need to use an app server?
I don't see why you would want to use tomcat, glassfish or jetty for a command line program.
If it's command-line based, and you want it to run server-side, you could write a little program that allows users to, for instance, telnet to your server, which in turn starts the CLI-application in question, and relays input / output to the client.
You may also want to look into Java Webstart, which makes deployment of new versions a breeze.
Actually we can't answer with so few elements.
- What are you planning to do
- With what technologies
- Where are you planning to host your application (have you got budget?)
- In which language are written the clients (even the future ones)?
- Could clients be on mobile phones (add some technlogy constraints...)
....
It would also be great to know what kind of request the clients will do, and what kind of response the server will provide...
Actually with what you tell us, all those application servers can do what you want...
I have looked for Tomcat, Jetty and
Glassfish but it seems that they are
only used for web application
You could even make a webapplication (servlet) and on the clientside use a httpclient to call that servlet... there are so many options :)
vive Paris!
The Web Start Developers Guide states
All application resources must be retrieved from the JAR files specified
in the resources section of the JNLP file, or retrieved explicitly
using an HTTP request to the Web server.
Storing resources in JAR files is recommended, since they will be cached
on the local machine by Java Web Start.
Now, I have some resources I want to dynamically load after my application has been started (for example OSGi bundles). I can do this using plain HTTP, but I would like to make use of Web Start's support for local caching and versioned/architecture-specific resources.
Is there a way to download additional jar files from the original code base (as specified in the application's jnlp file) using the Web Start infrastructure?
Or alternatively: is there already an established way to integrate OSGi and Web Start that would relieve me of the task to install bundles from the Web Start server?
If you make your application in itself an Equinox-based OSGI application, you can web-start it with all the addition bundles you need.
This article "WebStarting Equinox OSGi Apps" can give you a good introduction on the required settings.
All bundles have to be deployed as signed JAR files
You need a feature that contains all the necessary bundles
When exporting the feature, make sure that PDE creates a JNLP (Java Network Lauching Protocol) file (a checkbox in the export wizard) for this feature
Provide a root JNLP file for you application
Deploy your application to a web server and make sure that the web server is aware of the application/x-java-jnlp-file mime type
He also has an OSGI demo.
I haven't tried it but look at the javax.jnlp.DownloadService API