Paul Clapham wrote:You can't have your applet spy on keystrokes which are meant to be received by other applications running on the same computer.
However it seems to me that your actual requirements don't involve listening to the keyboard, but to events generated by some other hardware. Am I right? You didn't describe these devices, nor did you describe the events you want to listen to. If the events aren't keystrokes then your test which tries to work with keystrokes isn't very useful. So perhaps you could describe your requirements more clearly.
Jayesh A Lalwani wrote:WHat's your end goal? DO you want to learn how to build a web application with Spring? You might want to go through the SPring tutorial if you haven't already
The reason why you don't see Hello world is this:- For SPring to load your bean and call it, something has to ask Spring to load the application context. Spring won;t do it just because you have it in class path. Someone has to call the correct API that tells Spring to load the XML file. Normally, in an SPring MVC application, you declare a DispatcherServlet in your web.xml. This is a servlet provided by Spring. WHen the DispatcherServlet initializes, it loads the Spring XML file.
Your problem will be fixed by including DIspatcherservlet in web.xml. However, you will be better off going through the SPring tutorial
Jaikiran Pai wrote:Injection is only supported in container managed classes. Random classes like an implementation of Runnable do not have Java EE injection support. Plain JNDI lookup is your alternative to such cases.
Steve Luke wrote:Yes, that is correct. I see no reason why you couldn't use it with JBoss, the Java client is rather simple, with no pre-reqs that are standard Java. A quick google brought up JBoss Fuse which appears to have an MQTT layer, but I am not exactly sure what Fuse actually is. But it does indicate they are compatible I think. I think you would be using a separate broker.
Steve Luke wrote:Another option is something like MQTT, a light weight messaging protocol (look at mosquitto.org for an implementation). It is another bit of infrastructure (a broker both the computer and mobile device talk to) but you install and run the broker yourself, so your data doesn't go through 'the cloud'. It also allows two way communication (computer posts a message requesting info, then starts listening on a topic to receive it, mobile listens for the request and posts info on another topic) and is cross-platform - there is a Java client (Eclipse Paho) which works well on Android, there are C (which works with iOS) and Python clients as well.