Skip to main content

JBoss - know more about the JBoss directory structure

Fundamentally, the JBoss architecture consists of the JMX MBean server, the microkernel, and a set of pluggable component services - the MBeans.

The JBoss Application Server ships with three different server configurations. Within the <JBoss_Home>/server directory, you will find three subdirectories: minimal, default and all. The default configuration is the one used if you don’t specify another one when starting up the server.

If you want to know which services are configured in each of these instances, look at the jboss-service.xml file in the <JBoss_Home>/server/<instance-name>/conf/ directory and also the configuration files in the <JBoss_Home>/server/<instance-name>/deploy directory.

JBoss 4.0 features an embedded Apache Tomcat 5.5 servlet container.
  • conf --> The conf directory contains the jboss-service.xml bootstrap descriptor file for a given server configuration. This has the jboss-log4j.xml file which configures the Apache log4j framework category priorities and appenders used by the JBoss server code.  
  • data --> The data directory is available for use by services that want to store content in the file system. It holds persistent data for services intended to survive a server restart. Serveral JBoss services, such as the embedded Hypersonic database instance, store data here. 
  • deploy --> The deploy directory contains the hot-deployable services (those which can be added to or removed from the running server). You deploy your application code by placing application packages (JAR, WAR and EAR files) in the deploy directory. The directory is constantly scanned for updates, and any modified components will be re-deployed automatically.  
  • lib --> This directory contains JAR files (Java libraries that should not be hot deployed) needed by this server configuration. You can add required library files here for JDBC drivers etc. All JARs in this directory are loaded into the shared classpath at startup.  
  • log --> This is where the log files are written. JBoss uses the Jakarta log4j package for logging and you can also use it directly in your own applications from within the server. This may be overridden through the conf/jboss-log4j.xml configuration file. The file boot.log logs the JBoss startup and shut down notifications. This log is overwritten each time JBoss is (re)started. 
  • tmp --> The tmp directory is used for temporary storage by JBoss services. The deployer, for example, expands application archives in this directory.  
  • work --> This directory is used by Tomcat for compilation of JSPs. 

Labels:

Comments

Post a Comment

Popular posts from this blog

ATG CA - BCC home screen : how to add a new link

          Activity source is the property which controls the links on the left nav on the BCC home screen. All activity sources are registered with the ActivityManager component at /atg/bizui/activity/ActivityManager . When rendering the BCC home page, the ActivityManager cycles through all the registered ActivitySource components and displays left navigation links for each of them on the BCC home page. For example if I want to add a new link "My New Link" , below screen shots exaplins how this can be done 1. Add  activityManager.properties to specify the activityresources. In this  activityManager, I specified one MyActivitySource. 2. Add  MyActivitySource.properties  to specify the name of the link and the other details . Here it refers to a bundle properties file.  3. Add  the bundle properties file  to specify the name of the link.  4. Now you could see the new link...
6 comments
Read more

How the ATG Order flow manages a transaction

See more about ATG  Tx management @ http://tips4ufromsony.blogspot.com/2012/05/atg-how-to-use-transaction-manager.html Most of the ATG Commerce form handlers extend atg.commerce.order.purchase.PurchaseProcessFormHandler. The transaction management pattern in order flow is implemented through this form handler’s beforeSet, afterSet, and handler methods. The transaction will be started @ beforeSet method and is ended @ afterSet method. In general, the design pattern for updating an order is as follows: Acquire lock-manager write lock on profile id from the /atg/commerce/order/LocalLockManager Begin Transaction Synchronize on the Order object. Modify Order Call ((OrderImpl) pOrder).updateVersion(); --> atg.commerce.order.InvalidVersionException is thrown based on this Call OrderManager.updateOrder() Release Order synchronization End Transaction Release lock-manager write lock on profile id from the /atg/commerce/order/LocalLockManager     ...
Post a Comment
Read more

ATG Product Catalog schema ER diagram

Check out the O rder schema ER-Diagram @   http://tips4ufromsony.blogspot.in/2012/02/atg-order-schema-er-diagram.html Check out the User Profile  schema ER-Diagram @ http://tips4ufromsony.blogspot.in/2012/03/atg-user-profile-schema-er-diagram.html If you would like to know the relationship between different Product Catalog tables, please find below screen shots of  Product Catalog schema ER Diagrams.
3 comments
Read more

How to simulate Browser back button

When someone asks how to simulate a back button, they really mean to ask how to create a link that points to the previously visited page. Most browsers tend to keep a list of which websites the user has visited and in what order they have done so. The DOM window object provides access to the browser's history through the history object. Moving backward and forward through the user's history is done using the   back(), forward(), and go() methods of the  history  object. To move backward through history, just do window.history.back() ; This will act exactly like the user clicked on the Back button in their browser toolbar. Find below a sample html code: <html> <head> <script type="text/javascript"> function goBack(){  window.history.back() } </script> </head> <body>    <input type="button" value="Back" onclick="goBack()" /> </body> </html>
Post a Comment
Read more

ATG - how to prevent Cross-Site attacks using _dynSessConf parameter

Cross-site scripting attacks take advantage of a vulnerability that enables a malicious site to use your browser to submit form requests to another site. In order to protect forms from cross-site attacks in ATG, you can enable form submissions to automatically supply the request parameter _dynSessConf , which identifies the current session through a randomly generated long number. On submission of a form (using dsp:form tag) or activation of a property setting (using dsp:a tag), the request-handling pipeline ( DAFDropletEventServlet ) validates _dynSessConf  against its session confirmation identifier. If it detects a mismatch or missing number, it can block form processing and return an error. To disable this functionality, we could give the following properties (@ /atg/dynamo/Configuration to disable it globally) enforceSessionConfirmation  = false -->  specifies whether the request-handling pipeline requires session confirmation in order to proc...
1 comment
Read more