How can you run a servlet on a server without putting it in the web.xml. I want to start a server from main and pass what servlet it should run
Thank you
That depends entirely on the server you're using. If it's an embedded server like Jetty, then you can easily do that in flavor of a ServletHolder.
context.addServlet(new ServletHolder(new HelloServlet()),"/*");
If it's other, then you need to consult the documentation of the server in question. It's usually not possible in non-embeddable servers like Tomcat, Glassfish and so on.
See also:
Embedding Jetty tutorial - ServletContext.
Update: as per the comments on your question, you're after all looking for a solution in the wrong direction. Reread the MVC pattern and more specifically the front controller pattern. You shouldn't use servlets as domain objects, but just simple constructable Java classes which don't extend HttpServlet. Finally you just end up with a single servlet which constructs/picks the right domain object based on the current request. You can find some insights and a basic kickoff example in this answer.
Related
I have seen lot of examples for Servlet3.0, but I couldn't find a single answer with Servlet2.5. But I'm sure there should be a way to do it.
Can anyone tell me how to add a servlet programmatically with tomcat 6.
Thanks.
Of course you can write a servlet that takes all requests you might react on (maybe bound to *.do or the like) and that handles those registrations. But there is no support by the servlet standard and I don't think Tomcat 6 supports programmatic configuration out of the box. However, there might be a framework that does, but I'm not aware of.
I have an application currently running based on servlets (app server glassfish). External applications make an HTTP call to that servlet and get response once successfully achieved what its designed for.
I need now to shift the whole application to JSF2.0 as it needs a front end and sticking to servlet/jsp is not an option.
My questions are:
What's the recommended way to achieve the scenario of external applications getting things done through http calls in my JSF2.0 web app (that is currently I am achieving with servlets)
I need to maintain some counters in Application scope; Would you advise me to keep using servlets in my jsf app too and are the application scoped beans callable in servlets?
The way how you described the old application sounds much like a web service.
JSF is a component based MVC framework, not a web service framework. So JSF is basically the wrong tool for the job. If you want to continue with the standard Java EE stack, look at JAX-WS (SOAP) or JAX-RS (RESTful) instead. The latter is "the" standard web service framework these days.
See also:
Servlet vs RESTful
What's the recommended way to achieve the scenario of external applications getting things done through http calls in my JSF2.0 web app (that is currently I am achieving with servlets)
Like BalusC said, JSF is not exactly what you need and is not designed for what you intend to use it for, webservices are. That being said, you could achieve your goals using JSF if developing an effective web service is not in the cards for you ,either because of a lack of technical expertise on your team or the time factor or other technical constraints require you to serve your customers via a webapp (I honestly can't think of any but hey, you never know)
That being said, I'm assuming you already know your way around JSF2: take a look at this answer to a question somewhat similar to yours. Ultimately, since you're in the Java EE 5-6 stack, I'd strongly suggest you begin work on developing webservices (for basic requirements,they're fairly straightforward to develop). You can download a tutorial here or use oracle's tutorial
I need to maintain some counters in Application scope; Would you advise me to keep using servlets in my jsf app too and are the application scoped beans callable in servlets?
Unless you give us your specific use case, there are very few and far between reasons maintain a servlet within a JSF app. Yes, application,session and request scoped beans are accessible from within a servlet. They're simply stored as objects within the scopes they're named for, application scoped beans within the applicationScope, session scoped beans within the session and request scoped beans within the request.
You may use your JSF webapp to serve low level http requests, but it's a square peg in a round hole chief.
How do I browse a jackrabbit repository using a spring-mvc webapp?
How do I map incoming URL requests in the spring web controllers to nodes in the repository? I'd like the users to be able to open a word document in OpenOffice or Word by opening a URL like the following and save back to it via webdav.
http://localhost:8080/my-app/my-doc.doc
Thanks in advance for any ideas.
Éamonn
the Jackrabbit Repository and the associated JSR standard for Java Content Repositories alone provides a fairly low level persistency API, which you could probably use to build Repositories for Domain objects, mapping the data to repository structures such as JCR nodes/properties. You will use the JCR API located at the javax.jcr.* package to manipulate the repository (and for maximum portability). In a sentence, you can use Jackrabbit to replace your database.
A quick google search showed that there are indeed projects that aim to provide similar convenience wrappers to the ones you probably know and love for JDBC and Hibernate, only for JCRs. I found for example the Spring Modules project: http://java.net/projects/springmodules/ which was unfortunately last updated about two years ago, so it is still on JCR 1.0. For sample usage take a look at http://java.net/projects/springmodules/sources/svn/content/trunk/samples/jcr/src/org/springmodules/examples/jcr/JcrService.java?rev=2110
Still, you could probably write your own JCR2Template without a lot of effort, and encapsulate the repetitive tasks such as connection and exception handing by using the Template Method pattern.
So as for the request mapping, you can run the JCR on a separate server, just like you would with a relational database, and connect to it via RMI. Here's an example: http://dev.day.com/content/docs/en/crx/current/developing/accessing_jcr_connectors.html
I would consider this the "clean" way to use a JCR in Spring MVC applications.
As for the WebDAV saving part... I know Jackrabbit does indeed support the mounting of Repositories as WebDAV drives, but I don't really have any experience with it and I honestly can't imagine a way to tell Word to upload a file upon edit somewhere... But I am not a Word expert at all, sorry....
Now ... the Apache Sling Framework on the other hand provides an interesting approach to build RESTful applications, that integrate well with the repository model and some higher level abstractions of the Repository structure. The way Servlets are resolved in Sling, however is completely different from plain Spring MVC (see http://dev.day.com/content/ddc/blog/2008/07/cheatsheet/_jcr_content/par/download/file), so it would a bit of work to reconcile both approaches.
Hope there's some info in there you can use.
Cheers,
Johannes
How can I consume a webservice that hasn't explicitely created a crossdomain.xml?
I understand it's for security and to prevent cross-site scripting, but it does seem like a major limitation to the Flex framework.
For example, if I want to consume a webservice, which is suppose to be language agnostic, then I can't with Flex. The webservice/server has to be specifically prepared for Flex/Flash. If it's not, then it cannot be consumed.
That can't be right can it?
Use a proxy server like Apache or BlazeDS to forward requests from the host the SWF originated from to the host with the web services.
If your webservice is on another domain, you'll need a crossdomain file. Pure and simple.
I have found two ways around this:
Use an HTTPService
Use external interface calls to Javascript embedded on your flash file's container page, which will then call the web service
Option 2 is more complex, but I prefer it. This link should help you out with the ExternalInterface class: http://blog.flexexamples.com/2008/03/11/returning-values-from-javascript-in-your-flex-applications-using-the-externalinterface-api/#more-555
What I did was "put a middle man". So basically, I put a php script that reads from the other side what I need. Yes, unfortunately, that requires a "server". You could try a JavaScript as well.
I have a handful of ASP.NET websites which communicate with different instances of SQL Server 2005 via a web reference to the report server's web service. However, today I toyed with the notion of using the WSDL tool to create a proxy class from one of the SQL Server instances and, in turn, using the proxy to create a dll (before doing so, I modified the proxy's constructor to accept a URL - so that I could point the proxy to any of the web service instances).
I'm pretty sure that the web service should be pretty, if not completely, static, in terms of updates. So, my question is: are there any drawbacks for using the compiled proxy class (in the bin directory), as opposed to using the proxy class (auto-generated), itself? If not, what are some motivations for going one way or the other?
As to my knowledge, there is absolutely no difference between both of them. The Service Reference does exactly what the svcutil also does, but allows the user to do it in an easier way. Service Reference is just a warpper around the svcutil.exe and it does nothing more than what the basic svcutil.exe does.
Thanks