Pages

Tuesday, 24 April 2012

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. 

Monday, 23 April 2012

ATG CA --> Different activity sources used @ BCC

Read about how a new link can be added in BCC home page @ http://tips4ufromsony.blogspot.com/2012/03/atg-ca-bcc-home-screen-how-to-add-new.html

Normally an ActivitySource.properties file define the set of actions that it supports under a genericActivityDefinitionFile. But some ActivitySource.properties  define the actions  using the workflowActivityDefinitionFiles.

For example consider the default "Content Administration" ,  "SearchAdministration",  " Merchanding "  and "Personalization" options in BCC homepage. Below I listed the ActivitySource.properties and other properties for these links. To get all these activitysource names, just take the /atg/bizui/activity/ActivityManager component @ dyn/admin.



Content Administration
ActivitySource  --> /atg/bizui/activity/PublishingActivitySource
genericActivityDefinitionFile


Search Administration
ActivitySource  --> /atg/bizui/activity/SearchingActivitySource
genericActivityDefinitionFile

Personalization
ActivitySource  -->  /atg/web/personalization/activity/PersonalizationActivitySource
workflowActivityDefinitionFiles  and genericActivityDefinitionFile

Merchanding
ActivitySource  -->  /atg/commerce/web/CommerceActivitySource
workflowActivityDefinitionFile

Consider the tasks under Merchandising,  Administer Commerce Search  and Manage Commerse Assets and a Browse option. These are defined in the workflowActivityDefinitionFile @ /atg/commerce/web/CommerceActivitySource. You could find the details in the below screen shot.



Also consider the tasks under Search Administration , these are defined  in the genericActivityDefinitionFile @ /atg/bizui/activity/SearchingActivitySource. You could find the details in the below screen shot.


The PublishingActivities.xml file is checked at intervals for modifications, so you can make changes to it without needing to restart the server. The interval is set to 5 minutes by default and is defined by the genericActivityFileModificationInterval property in the /atg/bizui/activity/PublishingActivitySource.properties component.

When you create a workflow in the ATG Control Center, it automatically displays in the ATG Business Control Center under Merchandising in the Operations list as long as you save the workflow in the /atg/registry/data/epubworkflows/Commerce directory. If you’d prefer to keep the workflow in a different directory, you need to update the /atg/commerce/web/CommerceActivitySource component workflowDirectories property to with the new directory name and path.

Monday, 9 April 2012

ATG Search --> High level overview of product-catalog-output-config.xml and XHTMLs

  • The definition file format begins with a top-level item element that specifies the repository and item descriptor to use, and then lists the properties of that item type to include.
  • The top-level item element has the is-document attribute set to true. This attribute specifies that an XHTML document should be generated for each item of that type (in this case, each user item).
  • Property values that come from standard JavaBean properties of the RepositoryItem object (rather than dynamic bean properties) are specified using a dollar-sign ($) prefix.
  • The item element has an is-multi attribute for specifying multi-value properties. If a property is an Array, Collection or Map  you should set this attribute to true.
  • Eeach ATG Search document is uniquely identified by a URL (typically the path name of the file on the file system).
  • In the XHTML documents that the ATG platform generates from repository items, meta properties are represented by meta tags in the head of the document, while text properties are represented by div tags in the body of the document.
  • ATG uses a URL of the following form to uniquely identify each document:       atgrep:/repository-name/item-descriptor-name/repository-id
  • In addition to the properties you specify in the definition file, the output document also includes certain properties that provide sufficient information to identify the repository items represented in the document. The output for each item automatically includes the properties $repositoryId, $repository.repositoryName, and $itemDescriptor.itemDescriptorName.
  • The output for the document-level item also includes a $url property and a $baseUrl property, where each contain the URL representing this repository item. (The difference between these properties is that if a VariantProducer( Eg: locale specific) is used to generate multiple documents from the same repository item, the $url property for each document will include unique query arguments to distinguish the document from the others.)
  • At a minimum, you need to set the following properties on each IndexingOutputConfig component: bulkLoader , definitionFile.
  • The IncrementalLoader component uses an implementation of the PropertiesChangedListener interface to monitor the repository for add, update, and delete events. It then analyzes these events to determine which ones necessitate updating XHTML documents and creates a queue of the affected repository items. When a new incremental update is triggered, the IncrementalLoader processes the items in the queue, generating and loading a new XHTML document for each changed repository item.
  • PropertyAccessor defines how the document loaders obtain property values
  • VariantProducer specifies logic for creating multiple XHTML documents from the same repository item.

Tuesday, 3 April 2012

ATG Search --> How to configure multiple language search

Here I am going to explain the steps involved in configuring the multi-language ATG Search if your site support multiple language. I have given the different steps in indexing and search flows.

Indexing flow :
  1. You could configure different search projects for different locales to support parallel search indexing for each locale.
  2. You could setup search environment for the search projects so that the indexing host is different for the two projects.
  3. Configure the LocaleVariantProducer @ ProductCatalogOutputConfig to specify the locale for the new language.
  4. Include the language dictionaries you need in Search Admin on the Search Projects which can be used for indexing and searching in multiple languages.
  5. Specify the locales @ \atg\search\config\LanguageDimensionService so that you could configure the search configurations for each language.
  6. When you create the search configuration tree, specify the "Contents vary by" as Language, to configure the search configurations like search redirection, result exclusion,... for each language.
  7. You need to configure the facet values as locale specific.
Search flow : 
  1. Search Formhandlers must ensure that the correct language is specified in the query requests, that it submits to Search Routing.
  2. The language input to the search engine is set in the search request from the OOB ParserOptionsXMLBuilder class. It gets the locale from the /atg/dynamo/servlet/RequestLocale and gets the language associated with the locale. The RequestLocale component is a session-scoped component that attaches locale information to the requests of the session. 
  3. In eStore (commerce) FormHandlers/Droplets set the corresponding siteName based on the current locale in /atg/dynamo/servlet/RequestLocale.
  4. You need to configure the Facet Labels specific to the locales.