Hobione's Weblog

Living & Breathing in Web 2.0 Era

Oracle Database 10g Express Edition

I have downloaded Oralce 10g Express edition (Free) and installed Express edition on my laptop so I can replicate my work development environment in it and make it portable. It is very easy to use as well.

I also installed Acuqa Data Studio 4.7.2 (Free). It is an Integrated Development Environment (IDE) like Toad for database developer.

Oracle list of command: http://www.ss64.com/ora/ 

Advertisements

January 24, 2008 Posted by | Databases: Oracle,MySql | Leave a comment

Glassfish docroot for “Root” application in the server

Glassfish docroot for “Root” application in the server so url would be

http://atowus2:41877/ instead of http://atowus2:41877/root

If you put a webapp under glassfish-v2\domains\domain1\docroot, only jsp/html files will render. If there is a servlet call (http://atowus:41877/service?svc=upload&action=list&uploadPath&…) from jsp/html, it wont work and you will get a 404, because of by putting a webapp under docroot wont register to server.xml.

Suggestion:

  1. Copy all files from Netbean project, for C:\buildLocal\Root\build\web

to glassfish-v2\domains\domain1\docroot

1.jpg

2. Log in to Admin GUI and choose option

    Local packaged file or directory that is accessible from the Application Server

    3. Under General: Context Root: / (just like the picture in the bottom)

    2.jpg

     

     

    3.jpg Now I am able to access my root app just like it should be http://atowus:41877/                             Thanks to David W Burns for his help :)

    ———————————–Episode 2 —————————————————————————

    Make sure read about alternate doc root issue before do this for your glass fish.

    January 15, 2008 Posted by | GlassFish | 3 Comments

    JSF life cycle in depth

    http://johnderinger.wordpress.com/2008/01/05/jsf-life-cycle/

    http://balusc.blogspot.com/2006/09/debug-jsf-lifecycle.html 

    January 12, 2008 Posted by | Java Server Faces | Leave a comment

    How can I disable directory listings for my web application?

    In your domain’s default-web.xml, search for the definition of the servlet whose servlet-name is equal to default, and set the value of its init parameter with name listings to false. Redeploy your web application if it has already been deployed, in order for the new setting to take effect.

    > Just change in default-web.xml true to false for listing param:
    <init-param>
    <param-name>listings</param-name>
    <param-value>false</param-value>
    </init-param>

    Yes, the setting is global. There is no per-directory granularity. Then I guess install Apache in front solve the issue.

    * GlassFish Wiki, GlassFish Forum, Documentations and many more …..
    https://glassfish.dev.java.net/ 

    January 12, 2008 Posted by | GlassFish | 1 Comment

    Glassfish and Apache – some simple advice

    Running a web server in front of a java application server makes sense in almost all production scenarios, where end users from the internet connect directly to your site. The web server offers you much more configuration, security and performance features than the integrated http connector of any java application server. http://www.wiik.de/blog/2007/05/27/glassfish-and-apache/

    ———————————————————————————–

    Moving ALL sites and apps to Glassfish V2! Need some simple advice

    1. Use JPA for database access

    2. Cluster for load balancing

    3. GlassFish can deliver static page just fine

    4. Take your “heavy” database based application(s), create WAR files for them and bundle them with the EAR with your back end EJBs. This lets them rely on the local interface for performance and such.

    5. For simple application, I would simply make then independent WAR files, but NOT bundled within the EAR. If they need any DB access, it’s most likely lightweight access. They can get their services from the same EJBs that are in your EAR, but you’ll use the remote interface to support them rather than the local.

    6. The reason I would pull them out, is that you can trivially create a skeleton web app directory structure, put the files and folders in the structure, and then deploy the directory (rather than a WAR file) in place in to the app server. The users can then simply upload static content or JSPs all day long without having to do a redeploy. It also keeps their content out of your EAR, giving you more flexibility on how it’s deployed and what not.

    7. You can also just dump everything in to one large directory stucture, all within the same EAR, and simply deploy the structure. But I like the separation and modularity of the “micro sites” being in their own deployment structure. Marketing folks move faster than back office folks, so if they want to add some servlet or make some tweak, it’s not big deal to redeploy their little piece of the server. In GF you can’t redeploy a WAR individually within a EAR, you need to deploy the entire app. With seperate WARs, you can bring them up and down independently. Again, if it’s mostly just static content, there’s no reason to redeploy, but it’s an option if they start wanting some local dynamic logic that needs a new jar or something.
    8. The overall key is to keep your EJB tier as stable and robust as practical so it doesn’t change as much.

    9. DO be careful talking to remote beans. Local interfaces can make you lazy and passing that “large list of stuff” is no big deal with a local interface, but with a remote interface it’ll beat you up. But certainly don’t be afraid of remote interfaces, used judiciously they give you a lot of flexibility (like when you want to, say, move the brochure sites to their own server, they can still access the EJBs from the main server — amazing!).

    10. Also, you can play with the virtual hosts if you like, and make simple static sites with those. Then you can have, say, “brochure.example.com”. Set up a bunch of those and you can run them in the same server or on different servers. Do a static site, or a simple WAR based site. Whatever you want. It’s all straightforward.

    http://forums.java.net/jive/message.jspa?messageID=244328

    January 11, 2008 Posted by | GlassFish | 1 Comment

    Alternate/Additional Docroots in GlassFish V2

    On window, just type in one line: asadmin set server.http-service.virtual-server.server.property.alternatedocroot_1=”from=/user_document/* dir=c:\ ”
    (put a space after the last back-slash, otherwise you will get syntax error)

    If you are more familiar with the admin console, you can do this by going to the virtual server page.
    Select tree node: Configuration -> HTTP-Service -> Virtual Server -> server
    on the right panel, add a row to the property table,
    property name: alternatedocroot_1
    property value: from=/user_documents/* dir=c:\

    You can then access your test.pdf which is put under /user_documents
    http://localhost:8080/user_documents/test.pdf

    1. Keep this in mind that if you have your dir listing disable, you are not able to access dir listing without sending a file name. http://localhost:8080/user_documents (You will get a 404)

    2. Make sure there are no context name in the url like this http://localhost:8080/ajw_141/user_documents/test.txt

    Full Thread: http://forums.java.net/jive/thread.jspa?messageID=253560
    Jan Lueh’s Blog: http://blogs.sun.com/jluehe/entry/alternate_docroots_in_web_applications

    ——————————————-Episode 2 ———– 01/29/08————————————–

    Here how it install in our Sun Solaris:
    Glassfish docroot from: /app01/SUNappserver/domains/domain1/docroot
    Static content docroot: web/docs

    Above example works great in Solaris as well.
    property name: alternatedocroot_1
    property value: from=/user_documents/* dir=/web/docs

    But when I set up my root application to the alternatedocroot, I could not access any of /web/docs directories like user_documents, fileUpload etc. http://atowus2:41877/user_documents/test.txt –> It wont work.

    The reason I could not access my /user_documents/test.txt is because, I set up my application root c ontext (/) to glassfish docroot, although I added additional property (alternatedocroot_1), it still kept looking at the glassfish original docroot instead of alternate docroot.

    I had couple conditions that I was trying to work with so everything would work seamless like it had been.

    1. I wanted to access my homepage page like http://atowus2:41877/ instead of http://atowus2:41877/root

    2. I wanted to access my static contents like this: http://atowus2:41877/user_documents/test.pdf

    Work around: I kept my root application contents (body, images, WEB-INF, index.jsp etc) under web/docs with other directories, like user_documents, uploadFiles, cm etc.

    So instead of previous example, I did the following steps and it seems to be working.

    root.jpg

    So far, I have resolved these following issues:

    1. template path
    2. root application path, like http://atowus2:41877/
    3. static content path so user should be able to access like this; http://atowus2:41877/user_documents/test.pdf

    January 7, 2008 Posted by | GlassFish | 3 Comments