Skip to main content

Posts

Showing posts from July, 2014

Jersey 2.x 404 error web.xml setting

For Jersey 2.x In web.xml. The <servlet-classs> and <init-param> <param-name> must match! That is,    " org.glassfish.jersey.servlet.ServletContainer " must correspond to       "  jersey.config.server.provider.packages " Sample snippet from web.xml file .... <servlet>         <servlet-name>XYZ123</servlet-name>         <servlet-class>               org.glassfish.jersey.servlet.ServletContainer         </servlet-class>         <init-param>             <param-name>             jersey.config.server.provider.packages            </param-name>             <param-value>YOU PACKAGE</param-value>         </init-param>         <load-on-startup>1</load-on-startup>        </servlet> ...

Deploying Jersey resources on Servlet 3.0 container

The common way to deploy a Jersey REST resource is to configure the  web.xml  file so that there is a servlet container responsible to delegate requests from a specific URL pattern to resource classes. If you use a Servlet 3.0 container, for example Tomcat 7, it is possible to use Java annotations rather than a web.xml  file. Oddly enough, there is not much information available on how to configure Jersey by using annotations. First, you need a class that extends class  Application  and that has to be annotated with  @ApplicationPath . The value of the annotation is the base path of the REST service that is to be managed by this class. This class must override method  getClasses  that returns a set of classes that provide the implementation of the endpoints of this REST service. This is comparable to the declaration of packages that was used previously in the  web.xml  file. 1 2 3 4 5 6 7 8 9 10 11 12 13 @ApplicationPath ( "rest" ) public class RestService extends

JAX-RS

JAX-RS is a standard that makes it easy to create a RESTful service that can be deployed to any Java application server: GlassFish, WebLogic, WebSphere, JBoss, etc. JAX-RS is part of Java EE, and when JAX-RS is used with other Java EE technologies it becomes even easier to create your RESTful service: EJB  - A session bean is used as the service implementation and also handles the transaction semantics. JAX-RS  - Used to expose the session bean as a RESTful service JPA  - Used to persist the POJOs to the database. Note how the EntityManager is injected onto the session bean. JAXB  - Used to convert the POJO to/from XML (in GlassFish it can also be used to convert the POJO to/from JSON). JAX-RS by default handles the interaction with the JAXB implementation.

Git a lot of files

# For the next commit $ git add . # add to index only files created/modified and not those deleted $ git add - u # add to index only files deleted/modified and not those created $ git add - A # do both operation at once, add to index all files

su and sudo command

Su vs. Sudo The su command switches to the super user – or root user – when you execute it with no additional options. You’ll have to enter the root account’s password. This isn’t all the su command does, though – you can use it to switch to any user account. If you execute the  su bob command, you’ll be prompted to enter Bob’s password and the shell will switch to Bob’s user account. Once you’re done running commands in the root shell, you should type  exit  to leave the root shell and go back to limited-privileges mode. Sudo runs a single command with root privileges. When you execute  sudo command , the system prompts you for your current user account’s password before running  command  as the root user. By default, Ubuntu remembers the password for fifteen minutes and won’t ask for a password again until the fifteen minutes are up. This is a key difference between su and sudo. Su switches you to the root user account and requires the root account’s password. Sudo runs a