I have a web app built in GWT running in tomcat that accesses the database. On the same server, I have some server-side Java applications running that need to use the same database connection. These applications will be deployed as a war file alongside the GWT app.
Is there a way I can send the connection from the GWT app to these server-side apps?
This isn't a whole lot of information, I understand. To me, the problem is easy enough to understand, though I haven't found a solution yet. If you need anymore information, I'll be happy to provide.
Do you mean, that the applications have to use the same jdbc connection string or is it more like a shared connection pool.
Is it a solution for you to have a datasource in the local jndi and use this in your applications as well as in the servlets?
Actually this has nothing to do with GWT.
Have a look at this answer
ServletContext provides a way of sharing objects among different servlets and even among diffrenet webapps
this.getServletConfig().getServletContext().setAttribute("sharedObject", shared);
this.getServletConfig().getServletContext().getAttribute("sharedObject");
You cannot use the same connection in two different web apps. But if you mean to use same connection pool form which both the GWT and the other web app will fetch connections, then you need to configure the datasource at the application server level using JNDI
There are lots of JNDI tutorials using servlet in the internet.
Following is a link I found on using JNDI in GWT
http://humblecode.blogspot.in/2009/05/gwt-16-using-jndi-datasource.html
Related
I am trying to configure the Java Mail Sessions Resource in the Netty server Play config and loop up this resource using JNDI in my application. I couldnt find this in Play framework documentation nor any articles for this set up. I also looked up on the Play code, but no luck.
https://github.com/playframework/playframework/blob/master/framework/src/play-netty-server/src/main/resources/reference.conf
https://github.com/playframework/playframework/blob/master/framework/src/play-netty-server/src/main/scala/play/core/server/NettyServer.scala
Play Version: 2.4.6
HTTPmail.setMailSessionFromJNDI("java:comp/env/mail/myemailserver");
Could anyone guide me to some articles or share the knowledge?
We are deploying our play applications in tomcat environment and the resources are expected to looked up from server configurations through JNDI. As a first step, I am trying to make the application work in Netty during development and move to TOMCAT later. thank you for the guidence.
If you want to use the sessions in the same way as in Tomcat's HttpSession, you should forget it immediately. Play Framework can store only String instances. In additionally, session data can take only 4kb of data because data is stored in the cookie called PLAY_SESSION. This kind of constraint a little bit logical. If enhances stateless character of the application, so also its scalability. For more complex use of Play sessions (shopping carts), you should think about alternatives as NoSQL, file system or database.
Read this
I'm a Java EE developer and we typically use Weblogic to deploy our apps. Now I'm faced with a new desktop application which requires logging, database connectivity and mail.
After some investigation I'm realizing that desktop apps are a completely new world to me and I'm not sure if I'm choosing the right libraries to support my app.
These are my questions:
In our Weblogic projects we used Log4j and I want to use it again in my desktop app. Is it a bad idea? Should I use a better logging framework?
In Weblogic we retrieve database connections with JNDI but now it seems impossible to do the same. How do I perform the same action in a desktop application so I can connect with a remote database? Is the combination c3p0 + database driver a good approach for this?
Is there any framework/JAR which provides all this stuff (log + ddbb + mail) as an integrated solution? Workmates told me Spring could help. I also found Warework.
In our Weblogic projects we used Log4j and I want to use it again in
my desktop app. Is it a bad idea? Should I use a better logging
framework?
No, it is not a bad idea and perfectly works. Personally, I'd go with java.util.logging as it does the job fairly well and it reduces your applications' footprint (storage). Although, it's configuration is a bit tricky.
In Weblogic we retrieve database connections with JNDI but now it
seems impossible to do the same. How do I perform the same action in a
desktop application so I can connect with a remote database? Is the
combination c3p0 + database driver a good approach for this?
You can directly connect to your database using pure java.sql JDBC API (tons of examples available in the internet), but always have to distribute the proprietary database drivers as part of your application (mySQL, Oracle, DB2, etc.). Furthermore it's possible to directly use connection pools provided with those drivers by using their proprietary APIs (fairly easy to encapsulate). Nevertheless, there are a number of issues:
latency; database protocols are fairly sensitive when it comes to latency (distance between client and database server). Having a database in the UK and desktop clients in US is probably not a good idea.
security 1; you have to distribute database user credentials to each and every desktop client. Be aware of that.
security 2; your database security requirements may demand for transport security (packet encryption).
change management; applying non-backward compatible updates to your database requires you to update all desktop clients (believe me - it's not fun).
network; depending on your environment, certain ports and/or protocols may be blocked.
Is there any framework/JAR which provides all this stuff (log + ddbb +
mail) as an integrated solution? Workmates told me Spring could help.
I also found Warework.
Logging and database access are not an issue and work fairly well without any third-party framework. Of course, those frameworks might provide value regarding other aspects (abstraction, DI, JDBC abstraction, etc.), but this is a topic of detailed software design. Sending emails directly from a desktop application might become an issue, regardless of the framework in use. Just some things to keep in mind:
which SMTP relay server do you want to use?
in case of an enterprise environment, your IT operations teams might not allow you to use their SMTP server from each desktop (keep spam in mind).
Conclusion: In desktop scenarios an application server is not a bad idea either. You should have your desktop application to communicate with an application server only by using e.g. JSON, XML, SOAP over HTTP/HTTPS or RMI, etc. The application should be responsible for the complex tasks like database access, transaction management, fine grained security, email, etc.
I am a little confused about the roles of a java application server and its differences from a web server.
I found many sites explaining the same difference between the two but not to my satisfaction.
So please explain me about the two following cases:-
1)App. Server and its difference with web server:
From these two links:
Difference between an application server and a servlet container?
What is the difference between application server and web server?
web server: It handles everything through http protocol by accepting requests from clients and sending
responses to them with the help of its servlet container(e.g Apache Tomcat)
App. Server: An application server supports the whole of JavaEE like JMS,JPA,RPC etc.
Now what I am confused with is that how can I use a lot of JavaEE APIs like JMS,JPA etc. with my Tomcat
by adding their jar files in my web application ?
Does that mean that if I use an appliation server I don't have to add those jar files?(I don't think so)
2)The roles of an appl. server (This is very important to me)
From Wikipedia
http://en.wikipedia.org/wiki/Application_Server
An application server provides services such as security,transaction support etc.
"The term is often used for web servers which support the JavaEE" -- It sounds like if we add the required jar files of JavaEE APIs a web server becomes an appl. server.What about it.
Now my question is how an application server performs the tasks of security control or transaction management by itself ?
E.g. in my web application using Spring framework I am providing security by using spring-security and transaction management by using #Transactional annotation and all those things you know.
So does the appl. server have anything to do with my security or transaction management or it has its own ways ?
Forgive my ignorance.
Using Spring, you're in fact embedding some kind of Java EE container inside your application. But even when using Spring, if you need JTA support (because you need distributed XA transactions), you'll need to use an additional transaction manager. If you need JMS, you'll need to install an additional JMS broker. If you need connection pooling, you'll need to use an additional connection pool. Sometimes it's as simple as adding additional jars to the classpath and properties or XML files. Sometimes it's harder.
A Java EE app server comes with everything bundled. You have less flexibility, but you don't need to install, configure and make everything work by yourself.
When you use the Java EE framework, that is a specification. So the application server, if it is Java EE compliant, needs to implement this. So once it is implemented the specification, then it will address Security,transaction etc because it is mentioned in the spec. So it is a contract. Whereas, in a web server, it will just pull out your static resource. There is no need for handling other stuff.
In case of the Spring framework, the framework knows how to handle transaction, security etc. So particularly the developer need not look into these aspects which are implemented by the Application Server in the other scenario.
how an application server performs the tasks of security control or transaction management by itself
It is rather the specification that address these issues, not the application server. So, the duty of the app server is to implement these.
So, if your application is Java EE compliant, then these areas will be addressed and the implementation would have been done by the app server.
May be this is oversimplification,
A web server is basically a HTTP server serving contents over http protocol. So a web server is simply about serving the contents over http protocol. A typical example would be Apache web server. This is simply a file server.
Now the question is where does the web server gets the contents from ? Possible sources are
Static contents (the contents like images/css etc) which are not generated on request but statically served.
Dynamic contents: Simply put, the contents to be served are generated upon the user request.
For the static contents, the web server does not need anything as it simply reads the file and serves it.
For dynamic contents, the web server might need help of additional components which will generate the contents to be served.
Here the Application Server comes into picture.
Now these additional components referred earlier, might interact with database or some other system etc.
In a web environment where your website is exposed to huge number of users (intended/unintended), you need typical services like transaction/security/concurrency etc. so that the user get expected responses and do not see inconsistencies in the behavior of the application.
An application server has inbuilt abilities to manage transaction/security/concurrency/resource management. generally these are referred as Managed services and environment offered by them is called Managed Environment where these basic services are managed by the application server and programmer does not have be bother for them.
Application Server needs web servers or we can say Web servers use Application server's services to generate dynamic contents.
For example, JBoss uses Tomcat as inbuilt web server. Whereas web logic has its own web server. Tomcat again can be called as application server (in principle) as it also offers managed environment for servlets (it manages concurrency and instance pool of servlets/JSPs ).
Coming your your example of Spring:
An Application server will come inbuilt with transaction/security etc whether you need it or not. The Spring offers a very nice way handling this. Spring has all these things BUT you use what you need. Not just these, but just a Java Web Sever like Tomcat is sufficient to build a full fledged services that needs an application server.
The title pretty much says it all, but here's some background.
We have a database configured in glassfish accessed by a website deployed on glassfish, we also access the database from an external java application, it occurred to me that this could be somewhat inefficient since we open quite a few connections to the database from our external app. So I was wondering if we could somehow access he database through glassfish's connection pool?
Thanks in advance.
Piers
You'll have to try this.
http://javahowto.blogspot.com/2006/08/access-glassfish-datasource-remotely.html suggests it is possible to look up the connection pool via JNDI from a standalone client. An actual client code example is given at http://javahowto.blogspot.com/2006/08/access-jboss-datasource-remotely-from.html#client
That would only be possible if your external application was running in the same VM as glassfish. The word "external" says: Nope, not possible.
Note that databases are designed to handle lots of connections. That's one of the main reasons why they exist: To allow several programs at once to work on the same data.
I don't think you can access the pool, if your program does not run on glassfish.
A few connections to the database shouldn't matter too much, at least if the aren't created and destroyed very often. You could build a pool in your external application as well, if that is the case.
Well I'm answering my own question, and it's not a brilliant answer but it does sort of fulfil the requirements of my question.
What you can do is connect to an EJB from an external java application, if the bean provides access to your database then by using it you will be making use of the connection pooling provided by glassfish.
You can find info on how to do this
here - https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html
In terms of efficiency I'm not sure if this is a good idea since it may put excess strain on your web application, in my initial idea I was thinking to bypass the webapp completely and communicate directly with glassfish, any comments on this would be appreciated.
Another option is to add a web service to your Glassfish data access object.
You could then access the database with SOAP or REST calls.
I'm looking for a simple open source, or reference application that I could use for testing some Java servers. The primary server would be Tomcat, and the database backend is MySQL. Are there some reasonable sample applications out there that are fairly easy to get up and running with?
The ideal application would be fairly stateless in nature and be accessible without authentication so that it could be easily used for stress testing.
There are spring examples, PetClinic and JPetStore. In these links you can find some more applications.