[jboss-cvs] JBossAS SVN: r100952 - projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon Feb 15 01:35:28 EST 2010
Author: mospina
Date: 2010-02-15 01:35:28 -0500 (Mon, 15 Feb 2010)
New Revision: 100952
Removed:
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/About_JBoss.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/About_Open_Source.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/About_Professional_Open_Source.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Book_Example_Installation.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Cache.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Clustering_Guide.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Clustering_Guide_JBoss_Cache_JGroups.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/EJB3.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Feedback.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/General_Configuration.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/JGroups.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Revision_History.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Security.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Virtual_Deployment_Framework.po
Log:
PO automatic cleaning for ja-JP
Deleted: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/About_JBoss.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/About_JBoss.po 2010-02-15 06:25:47 UTC (rev 100951)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/About_JBoss.po 2010-02-15 06:35:28 UTC (rev 100952)
@@ -1,159 +0,0 @@
-#
-# AUTHOR <EMAIL at ADDRESS>, YEAR.
-#
-msgid ""
-msgstr ""
-"Project-Id-Version: 0\n"
-"POT-Creation-Date: 2010-02-15T06:18:50\n"
-"PO-Revision-Date: 2010-02-15T06:18:50\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: None\n"
-"MIME-Version: 1.0\n"
-"Content-Type: application/x-publican; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
-
-#. Tag: title
-#, no-c-format
-msgid "About JBoss"
-msgstr ""
-
-#. Tag: primary
-#, no-c-format
-msgid "JBoss"
-msgstr ""
-
-#. Tag: secondary
-#, no-c-format
-msgid "about"
-msgstr ""
-
-#. Tag: secondary
-#, no-c-format
-msgid "relation to Red Hat"
-msgstr ""
-
-#. Tag: indexterm
-#, no-c-format
-msgid "JBoss, a division of Red Hat, is the global leader in open source middleware software, combining enterprise-class JEMS open source software with the industry’s leading services and tools to provide simply a better way to transform your business to"
-msgstr ""
-
-#. Tag: primary
-#, no-c-format
-msgid "Service-Oriented Architecture"
-msgstr ""
-
-#. Tag: secondary
-#, no-c-format
-msgid "SOA"
-msgstr ""
-
-#. Tag: indexterm
-#, no-c-format
-msgid "Service-Oriented Architecture (SOA)."
-msgstr ""
-
-#. Tag: secondary
-#, no-c-format
-msgid "and Professional Open Source"
-msgstr ""
-
-#. Tag: primary
-#, no-c-format
-msgid "Professional Open Source"
-msgstr ""
-
-#. Tag: indexterm
-#, no-c-format
-msgid "JBoss, pioneered the disruptive Professional Open Source model, which combines the best of the open source and proprietary software worlds to make open source a safe choice for the enterprise and give CIOs peace of mind. This includes the royalty-free software, transparent development and active community inherent in open source and the accountability and professional support services expected of a traditional software vendor. The company finds innovative open source projects and professionalizes the project from a hobby into a livelihood by hiring the lead developer(s), often the founders themselves. JBoss provides the resources, core development and support services to enable popular open source projects to scale into enterprise-class software."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis>Coverage:</emphasis> North America and Europe on a direct basis. JBoss provides coverage worldwide via our extensive authorized partner network."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis>Mission Statement:</emphasis>"
-msgstr ""
-
-#. Tag: primary
-#, no-c-format
-msgid "Mission Statement"
-msgstr ""
-
-#. Tag: indexterm
-#, no-c-format
-msgid "JBoss' mission is to revolutionize the way enterprise middleware software is built, distributed, and supported through the Professional Open Source model. We are committed to delivering innovative and high quality technology and services that make JBoss the safe choice for enterprises and software providers."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis>Customers:</emphasis> Enterprise customers deploying JBoss technologies in mission-critical applications with professional services support from JBoss include Aviva Canada, Continental Airlines, La Quinta, NLG, MCI, Nielsen Media Research and Travelocity. For a current list of customer success stories, please visit the <ulink url=\"http://www.jboss.com/customers/index\">Customers</ulink> section of our website."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis>Partners:</emphasis> JBoss works with software and hardware vendors, systems integrators and OEMs to deliver implementation services, frontline support, and certification for products embedded with JBoss technologies. For more information on the JBoss Certified Partner Program, please visit the <ulink url=\"http://www.jboss.com/partners/index\">Partners</ulink> section of our website."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Professional Open Source™ from JBoss Inc. offers you:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Standards-based and stable Java Middleware technology"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "No cost open source product licenses"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Backed by a professional and expert support staff"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Comprehensive services including <ulink url=\"http://www.jboss.com/services/profsupport\">Professional Support</ulink>, <ulink url=\"http://www.jboss.com/services/certification\">Training</ulink>, and <ulink url=\"http://www.jboss.com/services/consulting\">Consulting</ulink>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "A very large and active community of developers"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "An extensive worldwide network of authorized and certified <ulink url=\"http://www.jboss.com/partners/index\">partners</ulink>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Benefits of Professional Open Source from JBoss Inc.:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Lowest possible total cost of ownership"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Reliable and safe technology"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Support, accountability, and trust from a stable company"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Expedited problem resolution compared to commercial software vendors"
-msgstr ""
-
Deleted: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/About_Open_Source.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/About_Open_Source.po 2010-02-15 06:25:47 UTC (rev 100951)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/About_Open_Source.po 2010-02-15 06:35:28 UTC (rev 100952)
@@ -1,64 +0,0 @@
-#
-# AUTHOR <EMAIL at ADDRESS>, YEAR.
-#
-msgid ""
-msgstr ""
-"Project-Id-Version: 0\n"
-"POT-Creation-Date: 2010-02-15T06:18:50\n"
-"PO-Revision-Date: 2010-02-15T06:18:50\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: None\n"
-"MIME-Version: 1.0\n"
-"Content-Type: application/x-publican; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
-
-#. Tag: title
-#, no-c-format
-msgid "About Open Source"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The basic idea behind open source is very simple: When programmers can read, redistribute, and modify the source code for a piece of software, the software evolves. People improve it, people adapt it, people fix bugs. And this can happen at a speed that, if one is used to the slow pace of conventional software development, seems astonishing. Open Source is an often-misunderstood term relating to free software. The Open Source Initiative"
-msgstr ""
-
-#. Tag: primary
-#, no-c-format
-msgid "OSI"
-msgstr ""
-
-#. Tag: indexterm
-#, no-c-format
-msgid "(OSI) web site provides a number of resources that define the various aspects of Open Source including an Open Source Definition"
-msgstr ""
-
-#. Tag: primary
-#, no-c-format
-msgid "Open Source Definition"
-msgstr ""
-
-#. Tag: indexterm
-#, no-c-format
-msgid "at: <ulink url=\"http://www.opensource.org/docs/definition.html\">http://www.opensource.org/docs/definition.html</ulink>. The following quote from the OSI home page summarizes the key aspects as they relate to JBoss nicely:"
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "The Open Source Initiative"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "We in the open source community have learned that this rapid evolutionary process produces better software than the traditional closed model, in which only very few programmers can see the source and everybody else must blindly use an opaque block of bits."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Open Source Initiative exists to make this case to the commercial world."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Open source software is an idea whose time has finally come. For twenty years it has been building momentum in the technical cultures that built the Internet and the World Wide Web. Now it's breaking out into the commercial world, and that's changing all the rules. Are you ready?"
-msgstr ""
-
Deleted: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/About_Professional_Open_Source.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/About_Professional_Open_Source.po 2010-02-15 06:25:47 UTC (rev 100951)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/About_Professional_Open_Source.po 2010-02-15 06:35:28 UTC (rev 100952)
@@ -1,64 +0,0 @@
-#
-# AUTHOR <EMAIL at ADDRESS>, YEAR.
-#
-msgid ""
-msgstr ""
-"Project-Id-Version: 0\n"
-"POT-Creation-Date: 2010-02-15T06:18:50\n"
-"PO-Revision-Date: 2010-02-15T06:18:50\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: None\n"
-"MIME-Version: 1.0\n"
-"Content-Type: application/x-publican; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
-
-#. Tag: title
-#, no-c-format
-msgid "About Professional Open Source"
-msgstr ""
-
-#. Tag: primary
-#, no-c-format
-msgid "Professional Open Source"
-msgstr ""
-
-#. Tag: secondary
-#, no-c-format
-msgid "methodology"
-msgstr ""
-
-#. Tag: primary
-#, no-c-format
-msgid "POS"
-msgstr ""
-
-#. Tag: indexterm
-#, no-c-format
-msgid "JBoss is the leader in the second generation of open source, which we have termed Professional Open Source. The Professional Open Source methodology is based on the following:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "We hire and pay experts in the open source community to write exceptional and innovative software full-time."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "We only use open source licenses that are friendly to end-user IT shops, independent software vendors, and the community itself."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Directly and through our authorized partners, we deliver the best support services available; all of which are backed up by the real product experts."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Unlike first generation open source providers, we control the direction and source code for our projects. We can ensure that all bug fixes and patches are rolled into future versions of our products."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "By combining enterprise-proven technology, business-friendly open source licenses, and world-class support services, we have made Professional Open Source the safe choice for end-user enterprises and independent software vendors alike."
-msgstr ""
-
Deleted: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Book_Example_Installation.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Book_Example_Installation.po 2010-02-15 06:25:47 UTC (rev 100951)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Book_Example_Installation.po 2010-02-15 06:35:28 UTC (rev 100952)
@@ -1,39 +0,0 @@
-#
-# AUTHOR <EMAIL at ADDRESS>, YEAR.
-#
-msgid ""
-msgstr ""
-"Project-Id-Version: 0\n"
-"POT-Creation-Date: 2010-02-15T06:18:51\n"
-"PO-Revision-Date: 2010-02-15T06:18:51\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: None\n"
-"MIME-Version: 1.0\n"
-"Content-Type: application/x-publican; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
-
-#. Tag: title
-#, no-c-format
-msgid "Book Example Installation"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The book comes with the source code for the examples discussed in the book. You can download the examples zip file from <ulink url=\"http://www.redhat.com/docs/manuals/jboss\">http://www.redhat.com/docs/manuals/jboss</ulink>. Unzipping the example code archive creates a JBoss <literal>jboss<version>guide</literal> directory that contains an <literal>examples</literal> subdirectory. This is the <literal>examples</literal> directory referred to by the book."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The only customization needed before the examples may be used is to set the location of the JBoss server distribution. This may be done by editing the <literal>examples/build.xml</literal> file and changing the <literal>jboss.dist</literal> property value. This is shown in bold below:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "or by creating an <literal>.ant.properties</literal> file in the examples directory that contains a definition for the <literal>jboss.dist</literal> property. For example:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Part of the verification process validates that the version you are running the examples against matches what the book examples were tested against. If you have a problem running the examples first look for the output of the validate target such as the following:"
-msgstr ""
-
Deleted: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Cache.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Cache.po 2010-02-15 06:25:47 UTC (rev 100951)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Cache.po 2010-02-15 06:35:28 UTC (rev 100952)
@@ -1,299 +0,0 @@
-#
-# AUTHOR <EMAIL at ADDRESS>, YEAR.
-#
-msgid ""
-msgstr ""
-"Project-Id-Version: 0\n"
-"POT-Creation-Date: 2010-02-15T06:18:51\n"
-"PO-Revision-Date: 2010-02-15T06:18:51\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: None\n"
-"MIME-Version: 1.0\n"
-"Content-Type: application/x-publican; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
-
-#. Tag: title
-#, no-c-format
-msgid "JBoss Cache"
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "What is JBoss Cache?"
-msgstr ""
-
-#. Tag: secondary
-#, no-c-format
-msgid "about"
-msgstr ""
-
-#. Tag: indexterm
-#, no-c-format
-msgid "JBoss Cache is a tree-structured, clustered, transactional cache. It is the backbone for many fundamental JBoss Enterprise Application Platform clustering services, including - in certain versions - clustering JNDI, HTTP and EJB sessions."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "JBoss Cache can also be used as a standalone transactional and clustered caching library or even an object oriented data store. It can even be embedded in other enterprise Java frameworks and application servers such as BEA WebLogic or IBM WebSphere, Tomcat, Spring, Hibernate, and many others. It is also very commonly used directly by standalone Java applications that do not run from within an application server, to maintain clustered state."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "And what is Pojo Cache?"
-msgstr ""
-
-#. Tag: secondary
-#, no-c-format
-msgid "Pojo Cache"
-msgstr ""
-
-#. Tag: indexterm
-#, no-c-format
-msgid "Pojo Cache is an extension of the core JBoss Cache API. Pojo Cache offers additional functionality such as:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "maintaining object references even after replication or persistence."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "fine grained replication, where only modified object fields are replicated."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "\"API-less\" clustering model where pojos are simply annotated as being clustered."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Pojo Cache has a complete and separate set of documentation, including a user guide, FAQ and tutorial and as such, Pojo Cache is not discussed further in this book."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Pojo Cache deployment in the JBoss Enterprise Application Platform5 is discussed more in <xref linkend=\"pojocachedeployment\" />"
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Summary of Features"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "JBoss Cache offers a simple and straightforward API, where data (simple Java objects) can be placed in the cache and, based on configuration options selected, this data may be one or all of:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "replicated to some or all cache instances in a cluster."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "persisted to disk and/or a remote cluster (\"far-cache\")."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "garbage collected from memory when memory runs low, and passivated to disk so state isn't lost."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "In addition, JBoss Cache offers a rich set of enterprise-class features:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "being able to participate in JTA transactions (works with Java EE compliant TransactionManagers)."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "attach to JMX servers and provide runtime statistics on the state of the cache."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "allow client code to attach listeners and receive notifications on cache events."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "A cache is organised as a tree, with a single root. Each node in the tree essentially contains a Map, which acts as a store for key/value pairs. The only requirement placed on objects that are cached is that they implement java.io.Serializable . Note that this requirement does not exist for Pojo Cache."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "JBoss Cache can be either local or replicated. Local trees exist only inside the JVM in which they are created, whereas replicated trees propagate any changes to some or all other trees in the same cluster. A cluster may span different hosts on a network or just different JVMs on a single host."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "When a change is made to an object in the cache and that change is done in the context of a transaction, the replication of changes is deferred until the transaction commits successfully. All modifications are kept in a list associated with the transaction for the caller. When the transaction commits, we replicate the changes. Otherwise, (on a rollback) we simply undo the changes locally resulting in zero network traffic and overhead. For example, if a caller makes 100 modifications and then rolls back the transaction, we will not replicate anything, resulting in no network traffic."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "If a caller has no transaction associated with it (and isolation level is not NONE - more about this later), we will replicate right after each modification, e.g. in the above case we would send 100 messages, plus an additional message for the rollback. In this sense, running without a transaction can be thought of as analogous as running with auto-commit switched on in JDBC terminology, where each operation is committed automatically."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "JBoss Cache works out of the box with most popular transaction managers, and even provides an API where custom transaction manager lookups can be written."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The cache is also completely thread-safe. It uses a pessimistic locking scheme for nodes in the tree by default, with an optimistic locking scheme as a configurable option. With pessimistic locking, the degree of concurrency can be tuned using a number of isolation levels, corresponding to database-style transaction isolation levels, i.e., SERIALIZABLE, REPEATABLE_READ, READ_COMMITTED, READ_UNCOMMITTED and NONE. Concurrency, locking and isolation levels will be discussed later."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Running JBoss Cache in the JBoss Application server"
-msgstr ""
-
-#. Tag: primary
-#, no-c-format
-msgid "JBoss Enterprise Application Platform"
-msgstr ""
-
-#. Tag: secondary
-#, no-c-format
-msgid "running JBoss Cache with JBoss Enterprise Application Platform"
-msgstr ""
-
-#. Tag: indexterm
-#, no-c-format
-msgid "JBoss Cache uses JGroups as a transport layer. More information on JGroups can be found on <xref linkend=\"jgroups\" />"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "In the JBoss Enterprise Application Platform 5, JBoss cache runs in the <emphasis>all</emphasis> configuration of the Enterprise Application Platform (for instance, <JBOSS_HOME>/server/all). All you need to do is start the server with this configuration. <screen><command><JBOSS_HOME>/bin/./run.sh -c all</command></screen> All required jars will be on the classpath. Otherwise, you will need to ensure jbosscache.jar and jgroups-all.jar are on the classpath. You may need to add other jars if you're using things like <filename>JdbmCacheLoader</filename>. The simplest way to do this is to copy the jars from the JBoss Cache distribution's <filename>lib</filename> directory to the server configurations <emphasis>all</emphasis> <filename>lib</filename> directory. You could also package the jars with the configuration file in Service Archive (.sar) file or an EAR."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Note in the <ulink url=\"http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/2.1.0.GA/userguide_en/html_single/index.html#sample_xml_file\">http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/2.1.0.GA/userguide_en/html_single/index.html#sample_xml_file</ulink> the value of the mbean element's code attribute: org.jboss.cache.jmx.CacheJmxWrapper . This is the class JBoss Cache uses to handle JMX integration; the Cache itself does not expose an MBean interface. See the <ulink url=\"http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/2.1.0.GA/userguide_en/html_single/index.html#jmx.mbeans\">JBoss Cache MBeans section</ulink> for more on the CacheJmxWrapper ."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Once your cache is deployed, in order to use it with an in-VM client such as a servlet, a JMX proxy can be used to get a reference to the cache:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<programlisting>MBeanServer server = MBeanServerLocator.locateJBoss(); ObjectName on = new ObjectName(\"jboss.cache:service=Cache\"); CacheJmxWrapperMBean cacheWrapper = (CacheJmxWrapperMBean) MBeanServerInvocationHandler.newProxyInstance(server, on, CacheJmxWrapperMBean.class, false); Cache cache = cacheWrapper.getCache(); Node root = cache.getRoot(); // etc etc</programlisting>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The MBeanServerLocator class is a helper to find the (only) JBoss MBean server inside the current JVM. The javax.management.MBeanServerInvocationHandler class' newProxyInstance method creates a dynamic proxy implementing the given interface and uses JMX to dynamically dispatch methods invoked against the generated interface to the MBean. The name used to look up the MBean is the same as defined in the cache's configuration file."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Once the proxy to the CacheJmxWrapper is obtained, the getCache() will return a reference to the Cache itself."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Pojo Cache Deployment Options"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "There are a number of ways to deploy POJO Cache:"
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Programatic Deployment"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Simply instantiate a PojoCacheFactory and invoke one of the overloaded createCache methods shown in the API Overview."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "JMX-Based Deployment in JBoss Enterprise Application Platform (JBoss Enterprise Application Platform 5.x and 4.x)"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "If PojoCache is run in JBoss Enterprise Application Platform then your cache can be deployed as an MBean simply by copying a standard cache configuration file to the server's deploy directory. The standard format of PojoCache's standard XML configuration file (as shown in the Appendix) is the same as a JBoss Enterprise Application Platform MBean deployment descriptor, so the Enterprise Application Platform's SAR Deployer has no trouble handling it. Also, you don't have to place the configuration file directly in deploy; you can package it along with other services or JEE components in a SAR or EAR."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "In Enterprise Application Platform 5, if you're using a server config based on the standard all config, then that's all you need to do; all required jars will be on the classpath. Otherwise, you will need to ensure pojocache.jar, jbosscache.jar and jgroups-all.jar are on the classpath. You may need to add other jars if you're using things like JdbmCacheLoader. The simplest way to do this is to copy the jars from the PojoCache distribution's lib directory to the server config's lib directory. You could also package the jars with the configuration file in Service Archive (.sar) file or an EAR."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Note in the example the value of the mbean element's code attribute: org.jboss.cache.pojo.jmx.PojoCacheJmxWrapper. This is the class JBoss Cache uses to handle JMX integration; the PojoCache itself does not expose an MBean interface. See the JBoss Cache MBeans section for more on the PojoCacheJmxWrapper."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Once the proxy to the PojoCacheJmxWrapper is obtained, the getPojoCache() will return a reference to the PojoCache itself."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Via JBoss Microcontainer (JBoss Enterprise Application Platform 5.x)"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Beginning with Enterprise Application Platform 5, JBoss Enterprise Application Platform also supports deployment of POJO services via deployment of a file whose name ends with -beans.xml. A POJO service is one whose implementation is via a \"Plain Old Java Object\", meaning a simple java bean that isn't required to implement any special interfaces or extend any particular superclass. A PojoCache is a POJO service, and all the components in a Configuration are also POJOS, so deploying a cache in this way is a natural step."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Deployment of the cache is done using the JBoss Microcontainer that forms the core of JBoss Enterprise Application Platform. JBoss Microcontainer is a sophisticated IOC framework (similar to Spring). A -beans.xml file is basically a descriptor that tells the IOC framework how to assemble the various beans that make up a POJO service."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The rules for how to deploy the file, how to package it, how to ensure the required jars are on the classpath, etc. are the same as for a JMX-based deployment."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Following is an abbreviated example -beans.xml file. The details of building up the Configuration are omitted; see the \"Deploying JBoss Cache\" chapter in the JBoss Cache User Guide for a more complete example. If you look in the <filename>server/all/deploy</filename> directory of an Enterprise Application Platform 5 installation, you can find several more examples."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "An interesting thing to note in the above example is the difference between POJO Cache and a plain Cache in the use of a factory to create the cache. (See the \"Deploying JBoss Cache\" chapter in the JBoss Cache User Guide for the comparable plain Cache example.) The PojoCacheFactory exposes static methods for creating a PojoCache; as a result there is no need to add a separate bean element for the factory. Core Cache's DefaultCacheFactory creates caches from a singleton instance, requiring a bit more boilerplate in the config file."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "References:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "More information on JBoss Cache can be obtained from the following resources:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<ulink url=\"http://labs.jboss.com/jbosscache/\">http://labs.jboss.com/jbosscache/</ulink>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<ulink url=\"http://labs.jboss.com/jgroups/\">http://labs.jboss.com/jgroups/</ulink>"
-msgstr ""
-
Deleted: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Clustering_Guide.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Clustering_Guide.po 2010-02-15 06:25:47 UTC (rev 100951)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Clustering_Guide.po 2010-02-15 06:35:28 UTC (rev 100952)
@@ -1,14 +0,0 @@
-#
-# AUTHOR <EMAIL at ADDRESS>, YEAR.
-#
-msgid ""
-msgstr ""
-"Project-Id-Version: 0\n"
-"POT-Creation-Date: 2010-02-15T06:18:51\n"
-"PO-Revision-Date: 2010-02-15T06:18:51\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: None\n"
-"MIME-Version: 1.0\n"
-"Content-Type: application/x-publican; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
-
Deleted: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Clustering_Guide_JBoss_Cache_JGroups.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Clustering_Guide_JBoss_Cache_JGroups.po 2010-02-15 06:25:47 UTC (rev 100951)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Clustering_Guide_JBoss_Cache_JGroups.po 2010-02-15 06:35:28 UTC (rev 100952)
@@ -1,1159 +0,0 @@
-#
-# AUTHOR <EMAIL at ADDRESS>, YEAR.
-#
-msgid ""
-msgstr ""
-"Project-Id-Version: 0\n"
-"POT-Creation-Date: 2010-02-15T06:18:52\n"
-"PO-Revision-Date: 2010-02-15T06:18:52\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: None\n"
-"MIME-Version: 1.0\n"
-"Content-Type: application/x-publican; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
-
-#. Tag: title
-#, no-c-format
-msgid "JBossCache and JGroups Services"
-msgstr ""
-
-#. Tag: primary
-#, no-c-format
-msgid "Clustering"
-msgstr ""
-
-#. Tag: indexterm
-#, no-c-format
-msgid "JGroups and JBossCache provide the underlying communication, node replication and caching services, for JBoss Enterprise Application Platform clusters. Those services are configured as MBeans. There is a set of JBossCache and JGroups MBeans for each type of clustering applications (e.g., the Stateful Session EJBs, HTTP session replication etc.)."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The JBoss Enterprise Application Platform ships with a reasonable set of default JGroups and JBossCache MBean configurations. Most applications just work out of the box with the default MBean configurations. You only need to tweak them when you are deploying an application that has special network or performance requirements."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "JGroups Configuration"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The JGroups framework provides services to enable peer-to-peer communications between nodes in a cluster. It is built on top a stack of network communication protocols that provide transport, discovery, reliability and failure detection, and cluster membership management services. <xref linkend=\"jbosscache-JGroupsStack.fig\" /> shows the protocol stack in JGroups."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Protocol stack in JGroups"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "JGroups configurations often appear as a nested attribute in cluster related MBean services, such as the <literal>PartitionConfig</literal> attribute in the <literal>ClusterPartition</literal> MBean or the <literal>ClusterConfig</literal> attribute in the <literal>TreeCache</literal> MBean. You can configure the behavior and properties of each protocol in JGroups via those MBean attributes. Below is an example JGroups configuration in the <literal>ClusterPartition</literal> MBean."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "All the JGroups configuration data is contained in the <Config> element under the JGroups config MBean attribute. This information is used to configure a JGroups Channel; the Channel is conceptually similar to a socket, and manages communication between peers in a cluster. Each element inside the <Config> element defines a particular JGroups Protocol; each Protocol performs one function, and the combination of those functions is what defines the characteristics of the overall Channel. In the next several sections, we will dig into the commonly used protocols and their options and explain exactly what they mean."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Common Configuration Properties"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The following common properties are exposed by all of the JGroups protocols discussed below:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<literal>down_thread</literal> whether the protocol should create an internal queue and a queue processing thread (aka the down_thread) for messages passed down from higher layers. The higher layer could be another protocol higher in the stack, or the application itself, if the protocol is the top one on the stack. If true (the default), when a message is passed down from a higher layer, the calling thread places the message in the protocol's queue, and then returns immediately. The protocol's down_thread is responsible for reading messages off the queue, doing whatever protocol-specific processing is required, and passing the message on to the next protocol in the stack."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<literal>up_thread</literal> is conceptually similar to down_thread, but here the queue and thread are for messages received from lower layers in the protocol stack."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Generally speaking, <literal>up_thread</literal> and <literal>down_thread</literal> should be set to false."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Transport Protocols"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The transport protocols send messages from one cluster node to another (unicast) or from cluster node to all other nodes in the cluster (mcast). JGroups supports UDP, TCP, and TUNNEL as transport protocols."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The <literal>UDP</literal>, <literal>TCP</literal>, and <literal>TUNNEL</literal> elements are mutually exclusive. You can only have one transport protocol in each JGroups <literal>Config</literal> element"
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "UDP configuration"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "UDP is the preferred protocol for JGroups. UDP uses multicast or multiple unicasts to send and receive messages. If you choose UDP as the transport protocol for your cluster service, you need to configure it in the <literal>UDP</literal> sub-element in the JGroups <literal>Config</literal> element. Here is an example."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The available attributes in the above JGroups configuration are listed below."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">ip_mcast</emphasis> specifies whether or not to use IP multicasting. The default is <literal>true</literal>. If set to false, it will send n unicast packets rather than 1 multicast packet. Either way, packets are UDP datagrams."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">mcast_addr</emphasis> specifies the multicast address (class D) for joining a group (i.e., the cluster). If omitted, the default is <literal>228.8.8.8 </literal>."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">mcast_port</emphasis> specifies the multicast port number. If omitted, the default is <literal>45566</literal>."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">bind_addr</emphasis> specifies the interface on which to receive and send multicasts (uses the <literal>-Djgroups.bind_address</literal> system property, if present). If you have a multihomed machine, set the <literal>bind_addr</literal> attribute or system property to the appropriate NIC IP address. By default, system property setting takes priority over XML attribute unless -Djgroups.ignore.bind_addr system property is set."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">receive_on_all_interfaces </emphasis> specifies whether this node should listen on all interfaces for multicasts. The default is <literal>false</literal>. It overrides the <literal>bind_addr</literal> property for receiving multicasts. However, <literal>bind_addr</literal> (if set) is still used to send multicasts."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">send_on_all_interfaces</emphasis> specifies whether this node send UDP packets via all the NICs if you have a multi NIC machine. This means that the same multicast message is sent N times, so use with care."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">receive_interfaces</emphasis> specifies a list of of interfaces to receive multicasts on. The multicast receive socket will listen on all of these interfaces. This is a comma-separated list of IP addresses or interface names. E.g. \"<literal>192.168.5.1,eth1,127.0.0.1</literal>\"."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">ip_ttl</emphasis> specifies time-to-live for IP Multicast packets. TTL is the commonly used term in multicast networking, but is actually something of a misnomer, since the value here refers to how many network hops a packet will be allowed to travel before networking equipment will drop it."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">use_incoming_packet_handler</emphasis> specifies whether to use a separate thread to process incoming messages. Sometimes receivers are overloaded (they have to handle de-serialization etc). Packet handler is a separate thread taking care of de-serialization, receiver thread(s) simply put packet in queue and return immediately. Setting this to true adds one more thread. The default is <literal>true</literal>."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">use_outgoing_packet_handler</emphasis> specifies whether to use a separate thread to process outgoing messages. The default is false."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">enable_bundling</emphasis> specifies whether to enable message bundling. If it is <literal>true</literal>, the node would queue outgoing messages until <literal>max_bundle_size</literal> bytes have accumulated, or <literal>max_bundle_time</literal> milliseconds have elapsed, whichever occurs first. Then bundle queued messages into a large message and send it. The messages are unbundled at the receiver. The default is <literal>false</literal>."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">loopback</emphasis> specifies whether to loop outgoing message back up the stack. In <literal>unicast</literal> mode, the messages are sent to self. In <literal>mcast</literal> mode, a copy of the mcast message is sent. The default is <literal>false</literal>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">discard_incompatibe_packets</emphasis> specifies whether to discard packets from different JGroups versions. Each message in the cluster is tagged with a JGroups version. When a message from a different version of JGroups is received, it will be discarded if set to true, otherwise a warning will be logged. The default is <literal>false</literal>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">mcast_send_buf_size, mcast_recv_buf_size, ucast_send_buf_size, ucast_recv_buf_size</emphasis> define receive and send buffer sizes. It is good to have a large receiver buffer size, so packets are less likely to get dropped due to buffer overflow."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<literal>tos</literal> specifies traffic class for sending unicast and multicast datagrams."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "On Windows 2000 machines, because of the media sense feature being broken with multicast (even after disabling media sense), you need to set the UDP protocol's <literal>loopback</literal> attribute to <literal>true</literal>."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "TCP configuration"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Alternatively, a JGroups-based cluster can also work over TCP connections. Compared with UDP, TCP generates more network traffic when the cluster size increases. TCP is fundamentally a unicast protocol. To send multicast messages, JGroups uses multiple TCP unicasts. To use TCP as a transport protocol, you should define a <literal>TCP</literal> element in the JGroups <literal>Config</literal> element. Here is an example of the <literal>TCP</literal> element."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Below are the attributes available in the <literal>TCP</literal> element."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">bind_addr</emphasis> specifies the binding address. It can also be set with the <literal>-Djgroups.bind_address</literal> command line option at server startup."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">start_port, end_port</emphasis> define the range of TCP ports the server should bind to. The server socket is bound to the first available port from <literal>start_port</literal>. If no available port is found (e.g., because of a firewall) before the <literal>end_port</literal>, the server throws an exception. If no <literal>end_port</literal> is provided or <literal>end_port < start_port</literal> then there is no upper limit on the port range. If <literal>start_port == end_port</literal>, then we force JGroups to use the given port (start fails if port is not available). The default is 7800. If set to 0, then the operating system will pick a port. Please, bear in mind that setting it to 0 will work only if we use MPING or TCPGOSSIP as discovery protocol because <literal>TCCPING</literal> requires listing the nodes and their corresponding ports."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">loopback</emphasis> specifies whether to loop outgoing message back up the stack. In <literal>unicast</literal> mode, the messages are sent to self. In <literal>mcast</literal> mode, a copy of the mcast message is sent. The default is false."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">recv_buf_size, send_buf_size</emphasis> define receive and send buffer sizes. It is good to have a large receiver buffer size, so packets are less likely to get dropped due to buffer overflow."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">conn_expire_time</emphasis> specifies the time (in milliseconds) after which a connection can be closed by the reaper if no traffic has been received."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">reaper_interval</emphasis> specifies interval (in milliseconds) to run the reaper. If both values are 0, no reaping will be done. If either value is > 0, reaping will be enabled. By default, reaper_interval is 0, which means no reaper."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">sock_conn_timeout</emphasis> specifies max time in millis for a socket creation. When doing the initial discovery, and a peer hangs, don't wait forever but go on after the timeout to ping other members. Reduces chances of *not* finding any members at all. The default is 2000."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">use_send_queues</emphasis> specifies whether to use separate send queues for each connection. This prevents blocking on write if the peer hangs. The default is true."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">external_addr</emphasis> specifies external IP address to broadcast to other group members (if different to local address). This is useful when you have use (Network Address Translation) NAT, e.g. a node on a private network, behind a firewall, but you can only route to it via an externally visible address, which is different from the local address it is bound to. Therefore, the node can be configured to broadcast its external address, while still able to bind to the local one. This avoids having to use the TUNNEL protocol, (and hence a requirement for a central gossip router) because nodes outside the firewall can still route to the node inside the firewall, but only on its external address. Without setting the external_addr, the node behind the firewall will broadcast its private address to the other nodes which will not be able to route to it."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">skip_suspected_members</emphasis> specifies whether unicast messages should not be sent to suspected members. The default is true."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">tcp_nodelay</emphasis> specifies TCP_NODELAY. TCP by default nagles messages, that is, conceptually, smaller messages are bundled into larger ones. If we want to invoke synchronous cluster method calls, then we need to disable nagling in addition to disabling message bundling (by setting <literal>enable_bundling</literal> to false). Nagling is disabled by setting <literal>tcp_nodelay</literal> to true. The default is false."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "TUNNEL configuration"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The TUNNEL protocol uses an external router to send messages. The external router is known as a <literal>GossipRouter</literal>. Each node has to register with the router. All messages are sent to the router and forwarded on to their destinations. The TUNNEL approach can be used to setup communication with nodes behind firewalls. A node can establish a TCP connection to the GossipRouter through the firewall (you can use port 80). The same connection is used by the router to send messages to nodes behind the firewall as most firewalls do not permit outside hosts to initiate a TCP connection to a host inside the firewall. The TUNNEL configuration is defined in the TUNNEL element in the JGroups Config element. Here is an example.."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The available attributes in the <literal>TUNNEL</literal> element are listed below."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">router_host</emphasis> specifies the host on which the GossipRouter is running."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">router_port</emphasis> specifies the port on which the GossipRouter is listening."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">loopback</emphasis> specifies whether to loop messages back up the stack. The default is <literal>true</literal>."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Discovery Protocols"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The cluster needs to maintain a list of current member nodes at all times so that the load balancer and client interceptor know how to route their requests. Discovery protocols are used to discover active nodes in the cluster and detect the oldest member of the cluster, which is the coordinator. All initial nodes are discovered when the cluster starts up. When a new node joins the cluster later, it is only discovered after the group membership protocol (GMS, see <xref linkend=\"jbosscache-jgroups-other-gms\" />) admits it into the group."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Since the discovery protocols sit on top of the transport protocol, you can choose to use different discovery protocols based on your transport protocol. These are also configured as sub-elements in the JGroups MBean <literal>Config</literal> element."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "PING"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "PING is a discovery protocol that works by either multicasting PING requests to an IP multicast address or connecting to a gossip router. As such, PING normally sits on top of the UDP or TUNNEL transport protocols. Each node responds with a packet {C, A}, where C=coordinator's address and A=own address. After timeout milliseconds or num_initial_members replies, the joiner determines the coordinator from the responses, and sends a JOIN request to it (handled by). If nobody responds, we assume we are the first member of a group."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Here is an example PING configuration for IP multicast."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Here is another example PING configuration for contacting a Gossip Router. <programlisting> <PING gossip_host=\"localhost\" gossip_port=\"1234\" timeout=\"3000\" num_initial_members=\"3\" down_thread=\"false\" up_thread=\"false\"/> </programlisting>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The available attributes in the <literal>PING</literal> element are listed below."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">timeout</emphasis> specifies the maximum number of milliseconds to wait for any responses. The default is 3000."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">num_initial_members</emphasis> specifies the maximum number of responses to wait for unless timeout has expired. The default is 2."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">gossip_host</emphasis> specifies the host on which the GossipRouter is running."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">gossip_port</emphasis> specifies the port on which the GossipRouter is listening on."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">gossip_refresh</emphasis> specifies the interval (in milliseconds) for the lease from the GossipRouter. The default is 20000."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">initial_hosts</emphasis> is a comma-seperated list of addresses (e.g., <literal>host1[12345],host2[23456]</literal>), which are pinged for discovery."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "If both <literal>gossip_host</literal> and <literal>gossip_port</literal> are defined, the cluster uses the GossipRouter for the initial discovery. If the <literal>initial_hosts</literal> is specified, the cluster pings that static list of addresses for discovery. Otherwise, the cluster uses IP multicasting for discovery."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The discovery phase returns when the <literal>timeout</literal> ms have elapsed or the <literal>num_initial_members</literal> responses have been received."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "TCPGOSSIP"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The TCPGOSSIP protocol only works with a GossipRouter. It works essentially the same way as the PING protocol configuration with valid <literal>gossip_host</literal> and <literal>gossip_port</literal> attributes. It works on top of both UDP and TCP transport protocols. Here is an example."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The available attributes in the <literal>TCPGOSSIP</literal> element are listed below."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">initial_hosts</emphasis> is a comma-seperated list of addresses (e.g., <literal>host1[12345],host2[23456]</literal>) for GossipRouters to register with."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "TCPPING"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The TCPPING protocol takes a set of known members and ping them for discovery. This is essentially a static configuration. It works on top of TCP. Here is an example of the <literal>TCPPING</literal> configuration element in the JGroups <literal>Config</literal> element."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The available attributes in the <literal>TCPPING</literal> element are listed below."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">initial_hosts</emphasis> is a comma-seperated list of addresses (e.g., <literal>host1[12345],host2[23456]</literal>) for pinging."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">port_range</emphasis> specifies the number of consecutive ports to be probed when getting the initial membership, starting with the port specified in the initial_hosts parameter. Given the current values of port_range and initial_hosts above, the TCPPING layer will try to connect to hosta:2300, hosta:2301, hosta:2302, hostb:3400, hostb:3401, hostb:3402, hostc:4500, hostc:4501, hostc:4502. The configuration options allows for multiple nodes on the same host to be pinged."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "MPING"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "MPING uses IP multicast to discover the initial membership. It can be used with all transports, but usually this is used in combination with TCP. TCP usually requires TCPPING, which has to list all group members explicitly, but MPING doesn't have this requirement. The typical use case for this is when we want TCP as transport, but multicasting for discovery so we don't have to define a static list of initial hosts in TCPPING or require external Gossip Router."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The available attributes in the <literal>MPING</literal> element are listed below."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">num_initial_members</emphasis> specifies the maximum number of responses to wait for unless timeout has expired. The default is 2.."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">bind_addr</emphasis> specifies the interface on which to send and receive multicast packets."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">bind_to_all_interfaces</emphasis> overrides the <literal>bind_addr</literal> and uses all interfaces in multihome nodes."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">mcast_addr, mcast_port, ip_ttl</emphasis> attributes are the same as related attributes in the UDP protocol configuration."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Failure Detection Protocols"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The failure detection protocols are used to detect failed nodes. Once a failed node is detected, a suspect verification phase can occur after which, if the node is still considered dead, the cluster updates its view so that the load balancer and client interceptors know to avoid the dead node. The failure detection protocols are configured as sub-elements in the JGroups MBean <literal>Config</literal> element."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "FD"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "FD is a failure detection protocol based on heartbeat messages. This protocol requires each node to periodically send are-you-alive messages to its neighbour. If the neighbour fails to respond, the calling node sends a SUSPECT message to the cluster. The current group coordinator can optionally double check whether the suspected node is indeed dead after which, if the node is still considered dead, updates the cluster's view. Here is an example FD configuration."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The available attributes in the <literal>FD</literal> element are listed below."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">timeout</emphasis> specifies the maximum number of milliseconds to wait for the responses to the are-you-alive messages. The default is 3000."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">max_tries</emphasis> specifies the number of missed are-you-alive messages from a node before the node is suspected. The default is 2."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">shun</emphasis> specifies whether a failed node will be shunned. Once shunned, the node will be expelled from the cluster even if it comes back later. The shunned node would have to re-join the cluster through the discovery process. JGroups allows to configure itself such that shunning leads to automatic rejoins and state transfer, which is the default behaivour within JBoss Application Server."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Regular traffic from a node counts as if it is a live. So, the are-you-alive messages are only sent when there is no regular traffic to the node for sometime."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "FD_SOCK"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "FD_SOCK is a failure detection protocol based on a ring of TCP sockets created between group members. Each member in a group connects to its neighbor (last member connects to first) thus forming a ring. Member B is suspected when its neighbor A detects abnormally closed TCP socket (presumably due to a node B crash). However, if a member B is about to leave gracefully, it lets its neighbor A know, so that it does not become suspected. The simplest FD_SOCK configuration does not take any attribute. You can just declare an empty <literal>FD_SOCK</literal> element in JGroups's <literal>Config</literal> element."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "There available attributes in the <literal>FD_SOCK</literal> element are listed below."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">bind_addr</emphasis> specifies the interface to which the server socket should bind to. If -Djgroups.bind_address system property is defined, XML value will be ignore. This behaivour can be reversed setting -Djgroups.ignore.bind_addr=true system property."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "VERIFY_SUSPECT"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "This protocol verifies whether a suspected member is really dead by pinging that member once again. This verification is performed by the coordinator of the cluster. The suspected member is dropped from the cluster group if confirmed to be dead. The aim of this protocol is to minimize false suspicions. Here's an example."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The available attributes in the FD_SOCK element are listed below."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "timeout specifies how long to wait for a response from the suspected member before considering it dead."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "FD versus FD_SOCK"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "FD and FD_SOCK, each taken individually, do not provide a solid failure detection layer. Let's look at the the differences between these failure detection protocols to understand how they complement each other:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis>FD</emphasis>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "An overloaded machine might be slow in sending are-you-alive responses."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "A member will be suspected when suspended in a debugger/profiler."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Low timeouts lead to higher probability of false suspicions and higher network traffic."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "High timeouts will not detect and remove crashed members for some time."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis>FD_SOCK</emphasis>:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Suspended in a debugger is no problem because the TCP connection is still open."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "High load no problem either for the same reason."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Members will only be suspected when TCP connection breaks"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "So hung members will not be detected."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Also, a crashed switch will not be detected until the connection runs into the TCP timeout (between 2-20 minutes, depending on TCP/IP stack implementation)."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The aim of a failure detection layer is to report real failures and therefore avoid false suspicions. There are two solutions:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "By default, JGroups configures the FD_SOCK socket with KEEP_ALIVE, which means that TCP sends a heartbeat on socket on which no traffic has been received in 2 hours. If a host crashed (or an intermediate switch or router crashed) without closing the TCP connection properly, we would detect this after 2 hours (plus a few minutes). This is of course better than never closing the connection (if KEEP_ALIVE is off), but may not be of much help. So, the first solution would be to lower the timeout value for KEEP_ALIVE. This can only be done for the entire kernel in most operating systems, so if this is lowered to 15 minutes, this will affect all TCP sockets."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The second solution is to combine FD_SOCK and FD; the timeout in FD can be set such that it is much lower than the TCP timeout, and this can be configured individually per process. FD_SOCK will already generate a suspect message if the socket was closed abnormally. However, in the case of a crashed switch or host, FD will make sure the socket is eventually closed and the suspect message generated. Example:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "This suspects a member when the socket to the neighbor has been closed abonormally (e.g. process crash, because the OS closes all sockets). However, f a host or switch crashes, then the sockets won't be closed, therefore, as a seond line of defense, FD will suspect the neighbor after 50 seconds. Note that with this example, if you have your system stopped in a breakpoint in the debugger, the node you're debugging will be suspected after ca 50 seconds."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "A combination of FD and FD_SOCK provides a solid failure detection layer and for this reason, such technique is used accross JGroups configurations included within JBoss Application Server."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Reliable Delivery Protocols"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Reliable delivery protocols within the JGroups stack ensure that data pockets are actually delivered in the right order (FIFO) to the destination node. The basis for reliable message delivery is positive and negative delivery acknowledgments (ACK and NAK). In the ACK mode, the sender resends the message until the acknowledgment is received from the receiver. In the NAK mode, the receiver requests retransmission when it discovers a gap."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "UNICAST"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The UNICAST protocol is used for unicast messages. It uses ACK. It is configured as a sub-element under the JGroups Config element. If the JGroups stack is configured with TCP transport protocol, UNICAST is not necessary because TCP itself guarantees FIFO delivery of unicast messages. Here is an example configuration for the <literal>UNICAST</literal> protocol."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "There is only one configurable attribute in the <literal>UNICAST</literal> element."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">timeout</emphasis> specifies the retransmission timeout (in milliseconds). For instance, if the timeout is \"100,200,400,800\", the sender resends the message if it hasn't received an ACK after 100 ms the first time, and the second time it waits for 200 ms before resending, and so on."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "NAKACK"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The NAKACK protocol is used for multicast messages. It uses NAK. Under this protocol, each message is tagged with a sequence number. The receiver keeps track of the sequence numbers and deliver the messages in order. When a gap in the sequence number is detected, the receiver asks the sender to retransmit the missing message. The NAKACK protocol is configured as the <literal>pbcast.NAKACK</literal> sub-element under the JGroups <literal>Config</literal> element. Here is an example configuration."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The configurable attributes in the <literal>pbcast.NAKACK</literal> element are as follows."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">retransmit_timeout</emphasis> specifies the retransmission timeout (in milliseconds). It is the same as the <literal>timeout</literal> attribute in the UNICAST protocol."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">use_mcast_xmit</emphasis> determines whether the sender should send the retransmission to the entire cluster rather than just the node requesting it. This is useful when the sender drops the pocket -- so we do not need to retransmit for each node."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">max_xmit_size</emphasis> specifies maximum size for a bundled retransmission, if multiple packets are reported missing."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">discard_delivered_msgs</emphasis> specifies whether to discard delivery messages on the receiver nodes. By default, we save all delivered messages. However, if we only ask the sender to resend their messages, we can enable this option and discard delivered messages."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">gc_lag specifies</emphasis> the number of messages garbage collection lags behind."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Other Configuration Options"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "In addition to the protocol stacks, you can also configure JGroups network services in the <literal>Config</literal> element."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Group Membership"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The group membership service in the JGroups stack maintains a list of active nodes. It handles the requests to join and leave the cluster. It also handles the SUSPECT messages sent by failure detection protocols. All nodes in the cluster, as well as the load balancer and client side interceptors, are notified if the group membership changes. The group membership service is configured in the <literal>pbcast.GMS</literal> sub-element under the JGroups <literal>Config</literal> element. Here is an example configuration."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The configurable attributes in the <literal>pbcast.GMS</literal> element are as follows."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">join_timeout</emphasis> specifies the maximum number of milliseconds to wait for a new node JOIN request to succeed. Retry afterwards."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">join_retry_timeout</emphasis> specifies the maximum number of milliseconds to wait after a failed JOIN to re-submit it."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">print_local_addr</emphasis> specifies whether to dump the node's own address to the output when started."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">shun</emphasis> specifies whether a node should shun itself if it receives a cluster view that it is not a member node."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">disable_initial_coord</emphasis> specifies whether to prevent this node as the cluster coordinator."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">view_bundling</emphasis> specifies whether multiple JOIN or LEAVE request arriving at the same time are bundled and handled together at the same time, only sending out 1 new view / bundle. This is is more efficient than handling each request separately."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Flow Control"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The flow control service tries to adapt the sending data rate and the receiving data among nodes. If a sender node is too fast, it might overwhelm the receiver node and result in dropped packets that have to be retransmitted. In JGroups, the flow control is implemented via a credit-based system. The sender and receiver nodes have the same number of credits (bytes) to start with. The sender subtracts credits by the number of bytes in messages it sends. The receiver accumulates credits for the bytes in the messages it receives. When the sender's credit drops to a threshold, the receivers sends some credit to the sender. If the sender's credit is used up, the sender blocks until it receives credits from the receiver. The flow control service is configured in the <literal>FC</literal> sub-element under the JGroups <literal>Config</literal> element. Here is an example configuration."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The configurable attributes in the <literal>FC</literal> element are as follows."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">max_credits</emphasis> specifies the maximum number of credits (in bytes). This value should be smaller than the JVM heap size."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">min_credits</emphasis> specifies the threshold credit on the sender, below which the receiver should send in more credits."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">min_threshold</emphasis> specifies percentage value of the threshold. It overrides the <literal>min_credits</literal> attribute."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Note"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Applications that use synchronous group RPC calls primarily do not require FC protocol in their JGroups protocol stack because synchronous communication, where the hread that makes the call blocks waiting for responses from all the members of the group, already slows overall rate of calls. Even though TCP provides flow control by itself, FC is still required in TCP based JGroups stacks because of group communication, where we essentially have to send group messages at the highest speed the slowest receiver can keep up with. TCP flow control only takes into account individual node communications and has not a notion of who's the slowest in the group, which is why FC is required."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Why is FC needed on top of TCP ? TCP has its own flow control !"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The reason is group communication, where we essentially have to send group messages at the highest speed the slowest receiver can keep up with. Let's say we have a cluster {A,B,C,D}. D is slow (maybe overloaded), the rest is fast. When A sends a group message, it establishes TCP connections A-A (conceptually), A-B, A-C and A-D (if they don't yet exist). So let's say A sends 100 million messages to the cluster. Because TCP's flow control only applies to A-B, A-C and A-D, but not to A-{B,C,D}, where {B,C,D} is the group, it is possible that A, B and C receive the 100M, but D only received 1M messages. (BTW: this is also the reason why we need NAKACK, although TCP does its own retransmission)."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Now JGroups has to buffer all messages in memory for the case when the original sender S dies and a node asks for retransmission of a message of S. Because all members buffer all messages they received, they need to purge stable messages (= messages seen by everyone) every now and then. This is done by the STABLE protocol, which can be configured to run the stability protocol round time based (e.g. every 50s) or size based (whenever 400K data has been received)."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "In the above case, the slow node D will prevent the group from purging messages above 1M, so every member will buffer 99M messages ! This in most cases leads to OOM exceptions. Note that - although the sliding window protocol in TCP will cause writes to block if the window is full - we assume in the above case that this is still much faster for A-B and A-C than for A-D."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "So, in summary, we need to send messages at a rate the slowest receiver (D) can handle."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "So do I always need FC?"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "This depends on how the application uses the JGroups channel. Referring to the example above, if there was something about the application that would naturally cause A to slow down its rate of sending because D wasn't keeping up, then FC would not be needed."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "A good example of such an application is one that makes synchronous group RPC calls (typically using a JGroups RpcDispatcher.) By synchronous, we mean the thread that makes the call blocks waiting for responses from all the members of the group. In that kind of application, the threads on A that are making calls would block waiting for responses from D, thus naturally slowing the overall rate of calls."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "A JBoss Cache cluster configured for REPL_SYNC is a good example of an application that makes synchronous group RPC calls. If a channel is only used for a cache configured for REPL_SYNC, we recommend you remove FC from its protocol stack."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "And, of course, if your cluster only consists of two nodes, including FC in a TCP-based protocol stack is unnecessary. There is no group beyond the single peer-to-peer relationship, and TCP's internal flow control will handle that just fine."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Another case where FC may not be needed is for a channel used by a JBoss Cache configured for buddy replication and a single buddy. Such a channel will in many respects act like a two node cluster, where messages are only exchanged with one other node, the buddy. (There may be other messages related to data gravitation that go to all members, but in a properly engineered buddy replication use case these should be infrequent. But if you remove FC be sure to load test your application.)"
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Fragmentation"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "This protocol fragments messages larger than certain size. Unfragments at the receiver's side. It works for both unicast and multicast messages. It is configured in the FRAG2 sub-element under the JGroups Config element. Here is an example configuration."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The configurable attributes in the FRAG2 element are as follows."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">frag_size</emphasis> specifies the max frag size in bytes. Messages larger than that are fragmented."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "TCP protocol already provides fragmentation but a fragmentation JGroups protocol is still needed if FC is used. The reason for this is that if you send a message larger than FC.max_bytes, FC protocol would block. So, frag_size within FRAG2 needs to be set to always be less than FC.max_bytes."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "State Transfer"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The state transfer service transfers the state from an existing node (i.e., the cluster coordinator) to a newly joining node. It is configured in the <literal>pbcast.STATE_TRANSFER</literal> sub-element under the JGroups <literal>Config</literal> element. It does not have any configurable attribute. Here is an example configuration."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Distributed Garbage Collection"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "In a JGroups cluster, all nodes have to store all messages received for potential retransmission in case of a failure. However, if we store all messages forever, we will run out of memory. So, the distributed garbage collection service in JGroups periodically purges messages that have seen by all nodes from the memory in each node. The distributed garbage collection service is configured in the <literal>pbcast.STABLE</literal> sub-element under the JGroups <literal>Config</literal> element. Here is an example configuration."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The configurable attributes in the <literal>pbcast.STABLE</literal> element are as follows."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">desired_avg_gossip</emphasis> specifies intervals (in milliseconds) of garbage collection runs. Value <literal>0</literal> disables this service."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">max_bytes</emphasis> specifies the maximum number of bytes received before the cluster triggers a garbage collection run. Value <literal>0</literal> disables this service."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">stability_delay</emphasis> specifies delay before we send STABILITY msg (give others a change to send first). If used together with max_bytes, this attribute should be set to a small number."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Set the <literal>max_bytes</literal> attribute when you have a high traffic cluster."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Merging"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "When a network error occurs, the cluster might be partitioned into several different partitions. JGroups has a MERGE service that allows the coordinators in partitions to communicate with each other and form a single cluster back again. The flow control service is configured in the <literal>MERGE2</literal> sub-element under the JGroups <literal>Config</literal> element. Here is an example configuration."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">max_interval</emphasis> specifies the maximum number of milliseconds to send out a MERGE message."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis role=\"bold\">min_interval</emphasis> specifies the minimum number of milliseconds to send out a MERGE message."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "JGroups chooses a random value between <literal>min_interval</literal> and <literal>max_interval</literal> to send out the MERGE message."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The cluster states are not merged in a merger. This has to be done by the application. If <literal>MERGE2</literal> is used in conjunction with TCPPING, the <literal>initial_hosts</literal> attribute must contain all the nodes that could potentially be merged back, in order for the merge process to work properly. Otherwise, the merge process would not merge all the nodes even though shunning is disabled. Alternatively use MPING, which is commonly used with TCP to provide multicast member discovery capabilities, instead of TCPPING to avoid having to specify all the nodes."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Binding JGroups Channels to a particular interface"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "In the Transport Protocols section above, we briefly touched on how the interface to which JGroups will bind sockets is configured. Let's get into this topic in more depth:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "First, it's important to understand that the value set in any bind_addr element in an XML configuration file will be ignored by JGroups if it finds that system property jgroups.bind_addr (or a deprecated earlier name for the same thing, <literal>bind.address</literal>) has been set. The system property trumps XML. If JBoss AS is started with the -b (a.k.a. --host) switch, the AS will set <literal>jgroups.bind_addr</literal> to the specified value."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Beginning with Enterprise Application Platform 4.2.0, for security reasons the Enterprise Application Platform will bind most services to localhost if -b is not set. The effect of this is that in most cases users are going to be setting -b and thus jgroups.bind_addr is going to be set and any XML setting will be ignored."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "So, what are <emphasis>best practices</emphasis> for managing how JGroups binds to interfaces?"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Binding JGroups to the same interface as other services. Simple, just use -b: <screen>./run.sh -b 192.168.1.100 -c all</screen>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Binding services (e.g., JBoss Web) to one interface, but use a different one for JGroups: <screen>./run.sh -b 10.0.0.100 -Djgroups.bind_addr=192.168.1.100 -c all</screen> Specifically setting the system property overrides the -b value. This is a common usage pattern; put client traffic on one network, with intra-cluster traffic on another."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Binding services (e.g., JBoss Web) to all interfaces. This can be done like this: <screen>./run.sh -b 0.0.0.0 -c all</screen> However, doing this will not cause JGroups to bind to all interfaces! Instead , JGroups will bind to the machine's default interface. See the Transport Protocols section for how to tell JGroups to receive or send on all interfaces, if that is what you really want."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Binding services (e.g., JBoss Web) to all interfaces, but specify the JGroups interface: <screen>./run.sh -b 0.0.0.0 -Djgroups.bind_addr=192.168.1.100 -c all</screen> Again, specifically setting the system property overrides the -b value."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Using different interfaces for different channels: <screen>./run.sh -b 10.0.0.100 -Djgroups.ignore.bind_addr=true -c all</screen>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "This setting tells JGroups to ignore the <literal>jgroups.bind_addr</literal> system property, and instead use whatever is specfied in XML. You would need to edit the various XML configuration files to set the <literal>bind_addr</literal> to the desired interfaces."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Isolating JGroups Channels"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Within JBoss Enterprise Application Platform, there are a number of services that independently create JGroups channels -- 3 different JBoss Cache services (used for HttpSession replication, EJB3 SFSB replication and EJB3 entity replication) along with the general purpose clustering service called HAPartition that underlies most other JBossHA services."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "It is critical that these channels only communicate with their intended peers; not with the channels used by other services and not with channels for the same service opened on machines not meant to be part of the group. Nodes improperly communicating with each other is one of the most common issues users have with JBoss AS clustering."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Whom a JGroups channel will communicate with is defined by its group name, multicast address, and multicast port, so isolating JGroups channels comes down to ensuring different channels use different values for the group name, multicast address and multicast port."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "To isolate JGroups channels for different services on the same set of AS instances from each other, you MUST change the group name and the multicast port. In other words, each channel must have its own set of values."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "For example, say we have a production cluster of 3 machines, each of which has an HAPartition deployed along with a JBoss Cache used for web session clustering. The HAPartition channels should not communicate with the JBoss Cache channels. They should use a different group name and multicast port. They can use the same multicast address, although they don't need to."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "To isolate JGroups channels for the same service from other instances of the service on the network, you MUST change ALL three values. Each channel must have its own group name, multicast address, and multicast port."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "For example, say we have a production cluster of 3 machines, each of which has an HAPartition deployed. On the same network there is also a QA cluster of 3 machines, which also has an HAPartition deployed. The HAPartition group name, multicast address, and multicast port for the production machines must be different from those used on the QA machines."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Changing the Group Name"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The group name for a JGroups channel is configured via the service that starts the channel. Unfortunately, different services use different attribute names for configuring this. For HAPartition and related services configured in the deploy/cluster-service.xml file, this is configured via a PartitionName attribute. For JBoss Cache services, the name of the attribute is ClusterName."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "For the HAPartition and all the standard JBoss Cache services, we make it easy for you to create unique groups names simply by using the -g (a.k.a. –partition) switch when starting JBoss: <screen>./run.sh -g QAPartition -b 192.168.1.100 -c all</screen> This switch sets the jboss.partition.name system property, which is used as a component in the configuration of the group name in all the standard clustering configuration files. For example, <screen><attribute name=\"ClusterName\">Tomcat-${jboss.partition.name:Cluster}</attribute></screen>"
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Changing the multicast address and port"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The -u (a.k.a. --udp) command line switch may be used to control the multicast address used by the JGroups channels opened by all standard AS services. <screen>/run.sh -u 230.1.2.3 -g QAPartition -b 192.168.1.100 -c all</screen> This switch sets the jboss.partition.udpGroup system property, which you can see referenced in all of the standard protocol stack configs in JBoss Enterprise Application Platform:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Unfortunately, setting the multicast ports is not so simple. As described above, by default there are four separate JGroups channels in the standard JBoss Enterprise Application Platform all configuration, and each should be given a unique port. There are no command line switches to set these, but the standard configuration files do use system properties to set them. So, they can be configured from the command line by using -D. For example,"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis>Why isn't it sufficient to change the group name?</emphasis>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "If channels with different group names share the same multicast address and port, the lower level JGroups protocols in each channel will see, process and eventually discard messages intended for the other group. This will at a minimum hurt performance and can lead to anomalous behavior."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis>Why do I need to change the multicast port if I change the address?</emphasis>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "It should be sufficient to just change the address, but there is a problem on several operating systems whereby packets addressed to a particular multicast port are delivered to all listeners on that port, regardless of the multicast address they are listening on. So the recommendation is to change both the address and the port."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "JGroups Troubleshooting"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis>Nodes do not form a cluster</emphasis>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Make sure your machine is set up correctly for IP multicast. There are 2 test programs that can be used to detect this: McastReceiverTest and McastSenderTest. Go to the <literal>$JBOSS_HOME/server/all/lib</literal> directory and start McastReceiverTest, for example: <screen>java -cp jgroups.jar org.jgroups.tests.McastReceiverTest -mcast_addr 224.10.10.10 -port 5555 </screen>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Then in another window start <literal>McastSenderTest</literal>: <screen>java -cp jgroups.jar org.jgroups.tests.McastSenderTest -mcast_addr 224.10.10.10 -port 5555</screen>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "If you want to bind to a specific network interface card (NIC), use <literal>-bind_addr 192.168.0.2</literal>, where 192.168.0.2 is the IP address of the NIC to which you want to bind. Use this parameter in both the sender and the receiver."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "You should be able to type in the <literal>McastSenderTest</literal> window and see the output in the <literal>McastReceiverTest</literal> window. If not, try to use -ttl 32 in the sender. If this still fails, consult a system administrator to help you setup IP multicast correctly, and ask the admin to make sure that multicast will work on the interface you have chosen or, if the machines have multiple interfaces, ask to be told the correct interface. Once you know multicast is working properly on each machine in your cluster, you can repeat the above test to test the network, putting the sender on one machine and the receiver on another."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Causes of missing heartbeats in FD"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Sometimes a member is suspected by FD because a heartbeat ack has not been received for some time T (defined by timeout and max_tries). This can have multiple reasons, e.g. in a cluster of A,B,C,D; C can be suspected if (note that A pings B, B pings C, C pings D and D pings A):"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "B or C are running at 100% CPU for more than T seconds. So even if C sends a heartbeat ack to B, B may not be able to process it because it is at 100%"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "B or C are garbage collecting, same as above."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "A combination of the 2 cases above"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The network loses packets. This usually happens when there is a lot of traffic on the network, and the switch starts dropping packets (usually broadcasts first, then IP multicasts, TCP packets last)."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "B or C are processing a callback. Let's say C received a remote method call over its channel and takes T+1 seconds to process it. During this time, C will not process any other messages, including heartbeats, and therefore B will not receive the heartbeat ack and will suspect C."
-msgstr ""
-
Deleted: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/EJB3.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/EJB3.po 2010-02-15 06:25:47 UTC (rev 100951)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/EJB3.po 2010-02-15 06:35:28 UTC (rev 100952)
@@ -1,324 +0,0 @@
-#
-# AUTHOR <EMAIL at ADDRESS>, YEAR.
-#
-msgid ""
-msgstr ""
-"Project-Id-Version: 0\n"
-"POT-Creation-Date: 2010-02-15T06:18:53\n"
-"PO-Revision-Date: 2010-02-15T06:18:53\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: None\n"
-"MIME-Version: 1.0\n"
-"Content-Type: application/x-publican; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
-
-#. Tag: title
-#, no-c-format
-msgid "Enterprise Applications with EJB3 Services"
-msgstr ""
-
-#. Tag: primary
-#, no-c-format
-msgid ">Enterprise Applications with EJB3 Services"
-msgstr ""
-
-#. Tag: secondary
-#, no-c-format
-msgid "Enterprise JavaBean 3.0"
-msgstr ""
-
-#. Tag: primary
-#, no-c-format
-msgid "EJB3"
-msgstr ""
-
-#. Tag: indexterm
-#, no-c-format
-msgid "EJB3 (Enterprise Java Bean 3.0) provides the core component model for Java EE 5 applications. An EJB3 bean is a managed component that is automatically wired to take advantage of all services the Java EE 5 server container provides, such as transaction, security, persistence, naming, dependency injection, etc. The managed component allows developers to focus on the business logic, and leave the cross-cutting concerns to the container as configurations. As an application developer, you need not create or destroy the components yourself. You only need to ask for an EJB3 bean from the Java EE container by its name, and then you can call its methods with all configured container services applied. You can get access to an EJB3 bean from either inside or outside of the Java EE container."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "JBoss Enterprise Application Platform 5 supports EJB3 out of the box. Note that JBoss Enterprise Application Platform 4.2 is a J2EE server, so it does not support the full EJB3 feature set."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The details of the EJB3 component programming model is beyond the scope of this guide. Most EJB3 interfaces and annotations are part of the Java EE 5 standard and hence they are the same for all Java EE 5 compliant application servers. Interested readers should refer to the EJB3 specification or numerous EJB3 books to learn more about EJB3 programming."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "In this chapter, we only cover EJB3 configuration issues that are specific to the JBoss Enterprise Application Platform. For instance, we discuss the JNDI naming conventions for EJB3 components inside the JBoss Enterprise Application Platform, the optional configurations for the Hibernate persistence engine for entity beans, as well as custom options in the JBoss EJB3 deployer."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Session Beans"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Session beans are widely used to provide transactional services for local and remote clients. To write a session bean, you need an interface and an implementation class."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "When you invoke a session bean method, the method execution is automatically managed by the transaction manager and the security manager in the server. You can specify the transactional or security properties for each method using annotations on the method. A session bean instance can be reused by many clients. Depending on whether the server maintains the bean's internal state between two clients, the session bean can be stateless or stateful. Depending on whether the bean has a remote business interface clients outside of the current JVM can call upon the EJB3 bean. All these are configurable via standard annotations on the beans. Note that the transactional or security properties are only active when the bean is called through a business interface."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "After you define a session bean, how does the client get a reference to it? As we discussed, the client does not create or destroy EJB3 components, it merely asks the server for a reference of an existing instance managed by the server. That is done via JNDI. In JBoss AS, the default local JNDI name for a session bean is dependent on the deployment packaging of the bean class."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "If the bean is deployed in a standalone JAR file in the <literal>JBOSS_DIST/default/deploy</literal> directory, the bean is accessible via local JNDI name <literal>MyBean/local</literal>, where <literal>MyBean</literal> is the implementation class name of the bean as we showed earlier. The \"local\" JNDI in JBoss AS means that the JNDI name is relative to <literal>java:comp/env/</literal>."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "If the JAR file containing the bean is packaged in an EAR file, the local JNDI name for the bean is <literal>myapp/MyBean/local</literal>, where <literal>myapp</literal> is the root name of the EAR archive file (e.g., <literal>myapp.ear</literal>, see later for the EAR packaging of EJB3 beans)."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Of course, you should change <literal>local</literal> to <literal>remote</literal> if the bean interface is annotated with <literal>@Remote</literal> and the bean is accessed from outside of the server it is deployed on. Below is the code snippet to get a reference of the MyBean bean in a web application (e.g., in a servlet or a JSF backing bean) packaged in <literal>myapp.ear</literal>, and then invoke a managed method."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "What the client gets from the JNDI is essentially a \"stub\" or \"proxy\" of the bean instance. When the client invokes a method, the proxy figures out how to route the request to the server and marshal together the response."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "If you do not like the default JNDI names, you can always specify your own JNDI binding for any bean via the <literal>@LocalBinding</literal> annotation on the bean implementation class. The JNDI binding is always \"local\" under the <literal>java:comp/env/</literal> space. For instance, the following bean class definition results in the bean instances available under JNDI name <literal>java:comp/env/MyService/MyOwnName</literal>."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Injecting EJB3 Beans into the Web Tier"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Java EE 5 allows you to inject EJB3 bean instances directly into the web application via annotations without explicit JNDI lookup. This behavior is not yet supported in JBoss Enterprise Application Platform 4.2. However, the JBoss Enterprise Platform provides an integration framework called JBoss Seam. JBoss Seam brings EJB3 / JSF integration to new heights far beyond what Java EE 5 provides. Please see more details in the JBoss Seam reference guide bundled with the platform."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Entity Beans (a.k.a. Java Persistence API)"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "EJB3 session beans allow you to implement data accessing business logic in transactional methods. To actually access the database, you will need EJB3 entity beans and the entity manager API. They are collectively called the Java Persistence API (JPA)."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "EJB3 Entity Beans are Plain Old Java Objects (POJOs) that map to relational database tables. For instance, the following entity bean class maps to a relational table named customer. The table has three columns: name, age, and signupdate. Each instance of the bean corresponds to a row of data in the table."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Besides simple data properties, the entity bean can also contain references to other entity beans with relational mapping annotations such as @OneToOne, @OneToMany, @ManyToMany etc. The relationships of those entity objects will be automatically set up in the database as foreign keys. For instance, the following example shows that each record in the Customer table has one corresponding record in the Account table, multiple corresponding records in the Order table, and each record in the Employee table has multiple corresponding records in the Customer table."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Using the EntityManager API, you can create, update, delete, and query entity objects. The EntityManager transparently updates the underlying database tables in the process. You can obtain an EntityManager object in your EJB3 session bean via the @PersistenceContext annotation."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The detailed use of the EntityManager API is beyond the scope of this book. Interested readers should refer to the JPA documentation or Hibernate EntityManager documentation."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "The persistence.xml file"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The EntityManager API is great, but how does the server know which database it is supposed to save / update / query the entity objects? How do we configure the underlying object-relational-mapping engine and cache for better performance and trouble shooting? The persistence.xml file gives you complete flexibility to configure the EntityManager."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The persistence.xml file is a standard configuration file in JPA. It has to be included in the META-INF directory inside the JAR file that contains the entity beans. The persistence.xml file must define a persistence-unit with a unique name in the current scoped classloader. The provider attribute specifies the underlying implementation of the JPA EntityManager. In JBoss Enterprise Application Platform, the default and only supported / recommended JPA provider is Hibernate. The jta-data-source points to the JNDI name of the database this persistence unit maps to. The java:/DefaultDS here points to the HSQL DB embedded in the JBoss Enterprise Application Platform. Please refer to <xref linkend=\"alternative_DBs\" /> on how to setup alternative databases for JBoss AS."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Inject EntityManager by persistence-unit name"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Since you might have multiple instances of persistence-unit defined in the same application, you typically need to explicitly tell the @PersistenceContext annotation which unit you want to inject. For instance, @PersistenceContext(name=\"myapp\") injects the EntityManager from the persistence-unit named \"myapp\"."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "However, if you deploy your EAR application in its own scoped classloader and have only one persistence-unit defined in the whole application, you can omit the \"name\" on @PersistenceContext. See later in this chapter for EAR packaging and deployment."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The properties element in the persistence.xml can contain any configuration properties for the underlying persistence provider. Since JBoss Enterprise Application Platform uses Hibernate as the EJB3 persistence provider, you can pass in any Hibernate options here. Please refer to the Hibernate and Hibernate EntityManager documentation for more details. Here we will just give an example to set the SQL dialect of the persistence engine to HSQL, and to create tables from the entity beans when the application starts and drop those tables when the application stops."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Use Alternative Databases"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "To use an alternative database other than the built-in HSQL DB to back your entity beans, you need to first define the data source for the database and register it in the JNDI. This is done via the *-ds.xml files in the deploy directory. Please see <xref linkend=\"Connectors_on_JBoss-Configuring_JDBC_DataSources\" /> for more details. Examples of *-ds.xml files for various databases are available in JBOSS_DIST/docs/examples/jca directory in the server."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Then, in the persistence.xml, you need to change the jta-data-source attribute to point to the new data source in JNDI (e.g., java:/MysqlDS if you are using the default mysql-ds.xml to setup a MySQL external database)."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "In most cases, Hibernate tries to automatically detect the database it connects to and then automatically selects an appropriate SQL dialect for the database. However, we have found that this detection does not always work, especially for less used database servers. We recommend you to set the hibernate.dialect property explicitly in persistence.xml. Here are the Hibernate dialect for database servers officially supported on the JBoss platform."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Oracle 9i and 10g: org.hibernate.dialect.Oracle9Dialect"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Microsoft SQL Server 2005: org.hibernate.dialect.SQLServerDialect"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "PostgresSQL 8.1: org.hibernate.dialect.PostgreSQLDialect"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "MySQL 5.0: org.hibernate.dialect.MySQL5Dialect"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "DB2 8.0: org.hibernate.dialect.DB2Dialect"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Sybase ASE 12.5: org.hibernate.dialect.SybaseDialect"
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Default Hibernate options"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Hibernate has many configuration properties. For the properties that you do not specify in the persistence.xml file, JBoss AS will provide a reasonable set of default values. The default Hibernate property values are specified in the <literal>JBOSS_DIST/server/default/deploy/ejb3.deployer/MEAT-INF/persistence.properties</literal> file. Below is the <literal>persistence.properties</literal> file bundled in JBoss AS 4.2. Notice the options that are commented out. They give you an idea of available properties in your <literal>persistence.xml</literal> file."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Message Driven Beans"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Messaging driven beans are specialized EJB3 beans that receive service requests via JMS messages instead of proxy method calls from the \"stub\". So, a crucial configuration parameter for the message driven bean is to specify which JMS message queue its listens to. When there is an incoming message in the queue, the server invokes the beans's <literal>onMessage()</literal> method, and passes in the message itself for processing. The bean class specifies the JMS queue it listens to in the @MessageDriven annotation. The queue is registered under the local JNDI java:comp/env/ name space."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "When a message driven bean is deployed, its incoming message queue is automatically created if it does not exist already. To send a message to the bean, you can use the standard JMS API."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Please refer to the JMS specification or books to learn how to program in the JMS API."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Package and Deploy EJB3 Services"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "EJB3 bean classes are packaged in regular JAR files. The standard configuration files, such as ejb-jar.xml for session beans, and persistence.xml for entity beans, are in the META-INF directory inside the JAR. You can deploy EJB3 beans as standalone services in JBoss AS or as part of an enterprise application (i.e., in an EAR archive). In this section, we discuss those two deployment options."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Deploy the EJB3 JAR"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "When you drop JAR files into the <literal>JBOSS_DIST/server/default/deploy/</literal> directory, it will be automatically picked up and processed by the server. All the EJB3 beans defined in the JAR file will then be available to other applications deployed inside or outside of the server via JNDI names like <literal>MyBean/local</literal>, where <literal>MyBean</literal> is the implementation class name for the session bean. The deployment is done via the JBoss EJB3 deployer in JBOSS_DIST/server/default/ejb3.deployer/. The META-INF/persistence.properties file we discussed earlier to configure the default behavior of EJB3 entity manager is located in the EJB3 deployer."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The EJB3 deployer automatically scans JARs on the classpath to look for EJB3 annotations. When it finds classes with EJB3 annotations, it would deploy them as EJB3 services. However, scanning all JARs on the classpath could be very time-consuming if you have large applications with many JARs deployed. In the JBOSS_DIST/server/default/ejb3.deployer/META-INF/jboss-service.xml file, you can tell the EJB3 deployer to ignore JARs you know do not contain EJB3 beans. The non-EJB3 JAR files shipped with the JBoss AS are already listed in the jboss.ejb3:service=JarsIgnoredForScanning MBean service:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "You can add any non-EJB3 JARs from your application to this list so that the server do not have to waste time scanning them. This could significantly improve the application startup time in some cases."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Deploy EAR with EJB3 JAR"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Most Java EE applications are deployed as EAR archives. An EAR archive is a JAR file that typically contains a WAR archive for the web pages, servlets, and other web-related components, one or several EJB3 JARs that provide services (e.g., data access and transaction) to the WAR components, and some other support library JARs required by the application. An EAR file also have deployment descriptors such as application.xml and jboss-app.xml. Below is the basic structure of a typical EAR application."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Notice that in JBoss AS, unlike in many other application servers, you do not need to declare EJB references in the web.xml file in order for the components in the WAR file to access EJB3 services. You can obtain the references directly via JNDI as we discussed earlier in the chapter."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "A typical application.xml file is as follows. It declares the WAR and EJB3 JAR archives in the EAR, and defines the web content root for the application. Of course, you can have multiple EJB3 modules in the same EAR application. The application.xml file could also optionally define a shared classpath for JAR files used in this application. The JAR file location defaults to lib in JBoss AS -- but it might be different in other application servers."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The jboss-app.xml file provides JBoss-specific deployment configuration for the EAR application. For instance, it can specify the deployment order of modules in the EAR, deploy JBoss-specific application modules in the EAR, such as SARs (Service ARchive for MBeans) and HARs (Hibernate ARchive for Hibernate objects), provide security domain and JMX MBeans that can be used with this application, etc. You can learn more about the possible attributes in jboss-app.xml in its DTD: http://www.jboss.org/j2ee/dtd/jboss-app_4_2.dtd."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "A common use case for jboss-app.xml is to configure whether this EAR file should be deployed in its own scoped classloader to avoid naming conflicts with other applications. If your EAR application is deployed in its own scoped classloader and it only has one persistence-unit defined in its EJB3 JARs, you will be able to use @PersistenceContext EntityManager to inject EntityManager to session beans without worrying about passing the persistence unit name to the @PersistenceContext annotation. The following jboss-app.xml specifies a scoped classloader myapp:archive=myapp.ear for the EAR application."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The EAR deployment is configured by the JBOSS_DIST/server/default/deploy/ear-deploy.xml file. This file contains three attributes as follows."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "If you set the Isolated parameter to true, all EAR deployment will have scoped classloaders by default. There will be no need to define the classloader in jboss-app.xml. The CallByValue attribute specifies whether we should treat all EJB calls as remote calls. Remote calls have a large additional performance penalty compared with local call-by-reference calls, because objects involved in remote calls have to be serialized and de-serialized. For most of our applications, the WAR and EJB3 JARs are deployed on the same server, hence this value should be default to false and the server uses local call-by-reference calls to invoke EJB methods in the same JVM. The EnablelibDirectoryByDefault attribute specifies whether the lib directory in the EAR archive should be the default location for shared library JARs."
-msgstr ""
-
Deleted: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Feedback.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Feedback.po 2010-02-15 06:25:47 UTC (rev 100951)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Feedback.po 2010-02-15 06:35:28 UTC (rev 100952)
@@ -1,59 +0,0 @@
-#
-# AUTHOR <EMAIL at ADDRESS>, YEAR.
-#
-msgid ""
-msgstr ""
-"Project-Id-Version: 0\n"
-"POT-Creation-Date: 2010-02-15T06:18:53\n"
-"PO-Revision-Date: 2010-02-15T06:18:53\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: None\n"
-"MIME-Version: 1.0\n"
-"Content-Type: application/x-publican; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
-
-#. Tag: title
-#, no-c-format
-msgid "Help Contribute"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "If you find a typographical error in the <citetitle>Administration and Configuration Guide</citetitle>, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in JIRA: <ulink url=\"http://jira.jboss.com\">http://jira.jboss.com</ulink> against the project <citetitle>JBoss Application Server</citetitle> and component <citetitle>Documentation</citetitle>."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, please include the section number and some of the surrounding text so we can find it easily."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Note"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Be sure to give us your name so you can receive full credit."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "This content is taken from svn.jboss.org/repos/jbossas/projects/docs/trunk and has yet to be branched."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "To access the content directly and make changes yourself:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The directory structure includes other languages the book will be translated in. For English please edit the files under <emphasis>en-US</emphasis>."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "To identify the filename you wish to edit, please check the chapter title which will match the file's name. The files are written in Docbook xml. After saving your changes please validate the files you've edited for errors before committing your changes."
-msgstr ""
-
Deleted: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/General_Configuration.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/General_Configuration.po 2010-02-15 06:25:47 UTC (rev 100951)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/General_Configuration.po 2010-02-15 06:35:28 UTC (rev 100952)
@@ -1,84 +0,0 @@
-#
-# AUTHOR <EMAIL at ADDRESS>, YEAR.
-#
-msgid ""
-msgstr ""
-"Project-Id-Version: 0\n"
-"POT-Creation-Date: 2010-02-15T06:18:53\n"
-"PO-Revision-Date: 2010-02-15T06:18:53\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: None\n"
-"MIME-Version: 1.0\n"
-"Content-Type: application/x-publican; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
-
-#. Tag: title
-#, no-c-format
-msgid "General Configuration"
-msgstr ""
-
-#. Tag: primary
-#, no-c-format
-msgid "Configuration"
-msgstr ""
-
-#. Tag: secondary
-#, no-c-format
-msgid "general"
-msgstr ""
-
-#. Tag: indexterm
-#, no-c-format
-msgid "This chapter covers general configuration issues for the JBoss Enterprise Application Platform."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Hosting multiple domains with your JBoss Enterprise Application Platform"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "This section discusses how you can use your application server to host multiple applications for multiple domains."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "In this section we use a scenario where a company has three domains with the DNS server pointing to the JBoss Enterprise Application Platform server:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "www.domainA11.net"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "www.domainB12.net"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "www.domainC13.net"
-msgstr ""
-
-#. Tag: orderedlist
-#, no-c-format
-msgid "The company has developed three applications to service the above domains which serve its 3 main services:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "applicationA.war"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "applicationB.war"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "applicationC.war"
-msgstr ""
-
Deleted: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/JGroups.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/JGroups.po 2010-02-15 06:25:47 UTC (rev 100951)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/JGroups.po 2010-02-15 06:35:28 UTC (rev 100952)
@@ -1,109 +0,0 @@
-#
-# AUTHOR <EMAIL at ADDRESS>, YEAR.
-#
-msgid ""
-msgstr ""
-"Project-Id-Version: 0\n"
-"POT-Creation-Date: 2010-02-15T06:18:53\n"
-"PO-Revision-Date: 2010-02-15T06:18:53\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: None\n"
-"MIME-Version: 1.0\n"
-"Content-Type: application/x-publican; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
-
-#. Tag: title
-#, no-c-format
-msgid "JGroups"
-msgstr ""
-
-#. Tag: secondary
-#, no-c-format
-msgid "multicast communication toolkit"
-msgstr ""
-
-#. Tag: indexterm
-#, no-c-format
-msgid "JBoss Enterprise Application Platform clustering is built on JGroups - a toolkit for reliable multicast communication between Enterprise Application Platform nodes on an existing computer network. It can be used to create groups of processes whose members can send messages to each other. JGroups enables developers to create reliable multipoint (multicast) applications where reliability is a deployment issue. JGroups also relieves the application developer from implementing this logic themselves. This saves significant development time and allows for the application to be deployed in different environments without having to change code. The following are the key features of JGroup."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Group creation and deletion. Group members can be spread across LANs or WANs"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Joining and leaving of groups"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Membership detection and notification about joined/left/crashed members"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Detection and removal of crashed members"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Sending and receiving of member-to-group messages (point-to-multipoint)"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Sending and receiving of member-to-member messages (point-to-point)"
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Flexible Protocol Stack"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The most powerful feature of JGroups is its flexible protocol stack, which allows developers to adapt it to exactly match their application requirements and network characteristics. The benefit of this is that you only pay for what you use. By mixing and matching protocols, various differing application requirements can be satisfied. JGroups comes with a number of protocols (but anyone can write their own), for example."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Transport protocols: UDP (IP Multicast), TCP, JMS"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Fragmentation of large messages"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Reliable unicast and multicast message transmission. Lost messages are retransmitted"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Failure detection: crashed members are excluded from the membership"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Ordering protocols: Atomic (all-or-none message delivery), Fifo, Causal, Total Order (sequencer or token based)"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Membership"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Encryption"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "More information on JGroups can be found on the <ulink url=\"http://www.jboss.org/jgroups/\">The JGroups homepage</ulink>"
-msgstr ""
-
Deleted: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Revision_History.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Revision_History.po 2010-02-15 06:25:47 UTC (rev 100951)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Revision_History.po 2010-02-15 06:35:28 UTC (rev 100952)
@@ -1,29 +0,0 @@
-#
-# AUTHOR <EMAIL at ADDRESS>, YEAR.
-#
-msgid ""
-msgstr ""
-"Project-Id-Version: 0\n"
-"POT-Creation-Date: 2010-02-15T06:18:53\n"
-"PO-Revision-Date: 2010-02-15T06:18:53\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: None\n"
-"MIME-Version: 1.0\n"
-"Content-Type: application/x-publican; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
-
-#. Tag: title
-#, no-c-format
-msgid "Revision History"
-msgstr ""
-
-#. Tag: firstname
-#, no-c-format
-msgid "Laura"
-msgstr ""
-
-#. Tag: member
-#, no-c-format
-msgid "Fixing to build."
-msgstr ""
-
Deleted: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Security.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Security.po 2010-02-15 06:25:47 UTC (rev 100951)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Security.po 2010-02-15 06:35:28 UTC (rev 100952)
@@ -1,124 +0,0 @@
-#
-# AUTHOR <EMAIL at ADDRESS>, YEAR.
-#
-msgid ""
-msgstr ""
-"Project-Id-Version: 0\n"
-"POT-Creation-Date: 2010-02-15T06:18:53\n"
-"PO-Revision-Date: 2010-02-15T06:18:53\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: None\n"
-"MIME-Version: 1.0\n"
-"Content-Type: application/x-publican; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
-
-#. Tag: title
-#, no-c-format
-msgid "Security"
-msgstr ""
-
-#. Tag: secondary
-#, no-c-format
-msgid "JBossAS"
-msgstr ""
-
-#. Tag: primary
-#, no-c-format
-msgid "JBoss Enterprise Application Platform"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The JBoss security framework default implementation is based on JAAS. It implements standard J2EE authentication and authorization but also supports extended security models with <ulink url=\"http://wiki.jboss.org/wiki/Edit.jsp?page=SecurityProxy\">SecurityProxy?</ulink> and <ulink url=\"http://wiki.jboss.org/wiki/Wiki.jsp?page=SecurityAssociation\">SecurityAssociation</ulink> implementations."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "JAAS based implementation enables pluggable authentication modules (PAMs) which is a way to integrate with existing authentication frameworks in your enterprise."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Changes affecting Security in JBoss Enterprise Application Platform 5"
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Web Layer"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Previously the server.xml of the tomcat service contained either the JaasSecurityMgrRealm? or JaccAuthorizationRealm? (for JACC) in the <filename>server.xml</filename> Starting JBoss5, we have consolidated the realms into one \"org.jboss.web.tomcat.security.JBossWebRealm?\". The Authorization Framework is used to plugin default, jacc or xacml authorization modes."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "General Configuration"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "We are making an effort to get away from the previous <ulink url=\"http://wiki.jboss.org/wiki/Wiki.jsp?page=JaasSecurityManagerService\">JaasSecurityManagerService</ulink> MBean service configuration in conf/jboss-service.xml. We are trying to introduce POJO beans such as the ones defined in deployers/security-deployer-beans.xml."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Security Context"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "We have the concept of <ulink url=\"http://wiki.jboss.org/wiki/Wiki.jsp?page=SecurityContext\">SecurityContext</ulink> to replace the legacy <ulink url=\"http://wiki.jboss.org/wiki/Wiki.jsp?page=SecurityAssociation\">SecurityAssociation</ulink>. Now it is possible to inject custom securitycontext objects by providing the FQN of it in the ejb2/web deployers. In the file: <filename>deployers/ejb-deployer-beans.xml</filename> <programlisting><bean name=\"EJB2xDeployer\" class=\"org.jboss.ejb.deployers.EjbDeployer\"> ... <!-- Specify an unauthenticated identity --> <property name=\"unauthenticatedIdentity\">anonymous</property> <!-- Specify a SecurityManagement Wrapper --> <property name=\"securityManagement\"> <inject bean=\"JNDIBasedSecurityManagement\"/> </property> <!-- Specify a SecurityContext FQN class name --> <property name=\"securityContextClassName\">org.jboss.security.plugins.JBossSecurityContext <!
;/property> <!-- Specify a SecurityDomain as fallback --> <property name=\"defaultSecurityDomain\">jboss-ejb-policy</property></programlisting> For the web deployer: In the file: <filename>deployers/jbossweb.deployer/META-INF/war-deployer-beans.xml</filename> <programlisting><!-- The WebMetaData to service mbean deployer --> <bean name=\"WarDeployer\" class=\"org.jboss.web.tomcat.service.deployers.TomcatDeployer\"> ... <!-- The JAAS security domain to use in the absense of an explicit security-domain specification in the war WEB-INF/jboss-web.xml --> <property name=\"defaultSecurityDomain\">java:/jaas/jboss-web-policy</property> <property name=\"securityManagerService\"> <inject bean=\"jboss.security:service=JaasSecurityManager\" /> </property> <!-- Specify a SecurityManagement Wrapper --> <property name=\"securityManagement\"> <inject bean=\"JNDIBasedSecurityManagement\"/> </property&!
gt; <!-- Specify a SecurityContext FQN class name --> &l!
t;proper
ty name=\"securityContextClassName\"> org.jboss.security.plugins.JBossSecurityContext</property></programlisting>"
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Default Security Domains for the EJB and WEB deployments."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "We have defined application policies \"jboss-ejb-policy\" and \"jboss-web-policy\" as the fall back security domains for the ejb and web layers. These are defined in deploy/security-policies-service.xml"
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Securing a Web Application in JBoss Enterprise Application Platform"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Securing web resources basically involves setting some stuff in the web deployment descriptor, and in jboss-web.xml. You also have to do a little prep work to the server itself to configure a security domain for JBoss SX. These instructions assume that you have JBoss AS installed, and you have a server instance created with at least Tomcat included. The \"default\" instance is a good choice here. The variable ${JBOSS_HOME} refers to the location you extracted/installed JBoss AS to, and ${server_configuration} corresponds to the name of the server instance you are configuring for security. The first part of these instructions refers to setting up JBoss SX for security, and the second part deals with setting up the web application for security using basic authentication. You can access the instructions in the following section."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Create a simple security domain for JBoss SX"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Setting up a security domain is simple with JBoss SX. The following instructions are a step by step methodology for creating a simple domain that uses two properties files to hold user ids, passwords, and roles for those users."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Open the <filename> ${JBOSS_HOME}/server/${server_configuration}/conf/login-config.xml</filename> file. This file sets up the configuration for the security domains available to applications running in the server. The file already has a few domains in there for some example/default resources, so you might want to look to those for inspiration. JBoss SX uses JAAS for the underlying security infrastructure, and JAAS uses a class called a \"login module\" to interact with a security store for authenticating credentials. This file basically hooks up a security domain (just a name really) to a JAAS login module. JBoss Enterprise Application Platform comes packed with a few different login modules which you can find more information about on the JBoss SX wiki page at JBossSX."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The easiest login module to start with is the <ulink url=\"http://wiki.jboss.org/wiki/Wiki.jsp?page=UsersRolesLoginModule\">UsersRolesLoginModule</ulink>. This login module allows you to specify user names, passwords and roles in a simple property file. Obviously, this module isn't one of the more secure modules, so you probably would want to use something like LDAP to store/lookup credentials in production."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Copy the \"jmx-console\" domain policy as a starting point. The \"jmx-console\" security domain policy contains the basics for configuring a UsersRolesLoginModule based security domain. Here is a copy of that section: <programlisting><application-policy name = \"jmx-console\"> <authentication> <login-module code=\"org.jboss.security.auth.spi.UsersRolesLoginModule\" flag = \"required\"> <module-option name=\"usersProperties\"> props/jmx-console-users.properties </module-option> <module-option name=\"rolesProperties\"> props/jmx-console-roles.properties </module-option> </login-module> </authentication> </application-policy></programlisting> Copy this section to the bottom of the file, and change the \"name\" attribute on the application-policy attribute to \"my-web\". Also, change the \"userProperties\" module-option text value to be \"props/my-web-users.properties\", and the \"roleProperties\" module-option !
text value to be \"props/my-web-roles.properties\". Save the login-config.xml file. The \"name\" attribute on the \"application-policy\" element specifies the name of the security domain. This name is important because it is what will be used to tie the security domain to the web application later. The \"login-module\" element specifies the login module that this domain will use. You can actually have multiple \"login-module\" elements to have multi-level authentication, but we'll stick to one for this simple case. The \"flag\" attribute on the login-module element specifies how to handle failed authentications from this module, and how it interacts with other modules. The \"required\" value is what you would want for a single login module, but you can refer to the DTD for the login-config.xml file for more info about the other options. Finally, the \"module-option\" elements specify some values to pass into the login module's \"initialize\" method. These values are passed !
in as a name-value map to that method. In the case of the <uli!
nk url=\
"http://wiki.jboss.org/wiki/Wiki.jsp?page=UsersRolesLoginModule\">UsersRolesLoginModule</ulink>, we need to tell the module what properties files to use for looking up user information (usersProperties), and what file to use for looking up role information (rolesProperties). These paths are relative to the ${JBOSS_HOME}/server/${server_configuration}/conf directory."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "In the ${JBOSS_HOME}/server/conf/props directory, copy the jmx-console-users.properties into a new file called my-web-users.properties, and copy the jmx-console-roles.properties into a new file called my-web-roles.properties. Opening the my-web-users.properties file, you will see a single entry like this: \"admin=admin\". When a user logs into this security domain, the login module will examine the properties data in this file for known users. The structure of the entries in this file is \"username=password\". Let's add a new entry to the file for your own user by pasting \"chris=secure\" on a new line below the \"admin=admin\" line in the file. Save this file. Next, open the <filename>my-web-roles.properties</filename> file, and you should see an line like the following: \"<emphasis>admin=JBossAdmin,HttpInvoker</emphasis>\". The entries in this file define what roles a user has associated with their account when they login. The form of these entries is \"username=Ro!
le1,Role2,...\" where the username is the user you wish to assign roles to, and the Roles entries are a comma separated list of roles to assign to that user. Add a new entry to this file by pasting \"chris=WebAppUser\" on a new line below the \"admin=....\" line. Save this file."
-msgstr ""
-
Deleted: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Virtual_Deployment_Framework.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Virtual_Deployment_Framework.po 2010-02-15 06:25:47 UTC (rev 100951)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/ja-JP/Virtual_Deployment_Framework.po 2010-02-15 06:35:28 UTC (rev 100952)
@@ -1,504 +0,0 @@
-#
-# AUTHOR <EMAIL at ADDRESS>, YEAR.
-#
-msgid ""
-msgstr ""
-"Project-Id-Version: 0\n"
-"POT-Creation-Date: 2010-02-15T06:18:54\n"
-"PO-Revision-Date: 2010-02-15T06:18:54\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: None\n"
-"MIME-Version: 1.0\n"
-"Content-Type: application/x-publican; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
-
-#. Tag: title
-#, no-c-format
-msgid "JBoss5 Virtual Deployment Framework"
-msgstr ""
-
-#. Tag: secondary
-#, no-c-format
-msgid "virtual deployment framework"
-msgstr ""
-
-#. Tag: primary
-#, no-c-format
-msgid "Virtual Deployment Framework"
-msgstr ""
-
-#. Tag: indexterm
-#, no-c-format
-msgid "As indicated in <xref linkend=\"JBoss_Enterprise_Application_Platform_5_Introduction\" /> the JBoss Enterprise Application Platform 5 is designed around the advanced concept of a Virtual Deployment Framework (VDF). This chapter discusses the JBoss5 Virtual Deployment Framework further. The following UML diagram illustrates an overview of the key JBoss5 Deployment Framework classes."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "The JBoss5 Deployment Framework Classes"
-msgstr ""
-
-#. Tag: figure
-#, no-c-format
-msgid "The key classes in the above diagram are:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis>MainDeployer</emphasis> : this interface defines the contract for the MainDeployer. The MainDeployer handles parsing of deployment archives into Deployment instances and deployment of those instances into the microcontainer. This update of the JMX based MainDeployer moves it to one based on the Microcontainer, JBoss5VirtualFileSystem, and Virtual Deployment Framework (VDF). Deployers are registered with the MainDeployer as an ordered list of deployers. MainDeployer contains two sets of deployers:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<emphasis>StructureDeployers</emphasis> used to analyze the structure of a DeploymentContext when <methodname>addDeploymentContext(DeploymentContext)</methodname> is invoked. For each StructureDeployer the <methodname>determineStructure(DeploymentContext)</methodname> method is invoked to analyze the deployment. A StructureDeployer returns true to indicate that the deployment was recognized and no further StructureDeployer should analyze the DeploymentContext."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Deployers used to translate a DeploymentUnit into runtime kernel beans when the MainDeployer.process is run. The Deployer methods are:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "isRelevant() : does the deployer want to process the unit."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "prepareDeploy() : take the new deployment to the ready stage"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "prepareUndeploy() : get ready to undeploy"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "handoff(new, old) : handover control from new to old"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "commitDeploy() : new deployment is now in control"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "commitUndeploy() : old deployment is out of here"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "getRelativeOrder() : specify the relative order of the deployer in a chain"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "DeploymentUnit : a representation of a runtime unit of work a Deployer operates on."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "DeploymentContext : a representation of structural aspects of deployable content."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "ManagedObject : a representation of the manageable properties for a deployment."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "VFS : the api for representing the read-only file system of the deployment."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "VirtualFile : the api for a file in the deployment."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "DomainClassLoader and ClassLoadingDomain : A generalization of the legacy JMX based unified class loading model. This is still in progress. The <classname>org.jboss.vfs.classloding.VFSClassLoader</classname> is the current simple implementation."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "MainDeployerImpl"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The <classname>org.jboss.deployers.plugins.deployment.MainDeployerImpl</classname> implementation of the <classname>org.jboss.deployers.spi.deployment.MainDeployer</classname> interfaces, includes the following standard method details:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>DeploymentContext getDeploymentContext(String name)</methodname>: obtain the <classname>DeploymentContext</classname> associated with the given name from all of the <classname>DeploymentContext</classname>s that have been added to the <classname>MainDeployer</classname>. This includes top level and all child contexts."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>Collection <DeploymentContext> getTopLevel()</methodname>: get a list of all of the top level <classname>DeploymentContext</classname>s added via the <methodname>addDeploymentContext(DeploymentContext)</methodname> method."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>Collection <DeploymentContext> getAll()</methodname>: get all of the <classname>DeploymentContext</classname>s, top-level and child associated with the <classname>MainDeployer</classname>."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>Collection <DeploymentContext> getErrors()</methodname>: get the <classname>DeploymentContext</classname>s that have failed to be structurally analyzed or deployed."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>Collection <DeploymentContext> getMissingDeployer()</methodname>: get the <classname>DeploymentContext</classname>s that are not deployed (<code>isDeployed() == false</code>) and are not root <filename>.jar</filename> files."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>void addDeploymentContext(DeploymentContext context) throws DeploymentException</methodname>: add a top-level deployment context. This runs a structural analysis of the <classname>DeploymentContext</classname> if its <classname>StructureDetermined</classname> state is not <property>PREDETERMINED</property>. If the structural analysis succeeds, the <classname>DeploymentContext</classname> is added for deployment during process."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>boolean removeDeploymentContext(String name) throws DeploymentException</methodname>: remove the top-level deployment associated with name."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>void process()</methodname>: runs through all<classname>DeploymentContext</classname>s that have been removed and undeploys each top-level <classname>DeploymentContext</classname>. The undeployment involves invoking the <methodname>performUndeploy(DeploymentUnit)</methodname> method on each <methodname>DeploymentContext.getDeploymentUnit()</methodname> method. Then for each <classname>DeploymentContext</classname>, <methodname>performUndeploy(DeploymentUnit)</methodname> on the component <methodname>DeploymentContext.getDeploymentUnit()</methodname> is performed. Next, the top-level <classname>DeploymentContext</classname>s that have been added are deployed by invoking <methodname>commitDeploy</methodname> on each deployer. The details of the deployment process are that each deployer is run on top-level context <classname>DeploymentUnit</classname> by invoking <methodname>Deployer.commitDeploy(DeploymentUnit)</methodname>, followed by the deployment of ea!
ch context of the top-level <classname>DeploymentContext</classname> components (<methodname>DeploymentContext.getComponents()</methodname>)."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>void shutdown()</methodname>: removes all top-level <classname>DeploymentContext</classname>s, and then invokes the undeployment process."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "In addition, the implementation adds the following methods."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>public synchronized void addDeployer(Deployer deployer)</methodname>: add a component deployer for non-structurual processing."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>public synchronized void removeDeployer(Deployer deployer)</methodname>: removes a component Deployer."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>public synchronized Set <Deployer> getDeployers()</methodname>: get the registered component deployers."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>public synchronized void setDeployers(Set<Deployer> deployers)</methodname>: set the component deployers."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>public synchronized void addStructureDeployer(StructureDeployer deployer)</methodname>: add a structural deployer."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>public synchronized void removeStructureDeployer(StructureDeployer deployer)</methodname>: remove a structural deployer."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>public synchronized Set<StructureDeployer> getStructureDeployers()</methodname>: obtain the registered structural deployers."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>public synchronized void setStructureDeployers(Set<StructureDeployer> deployers)</methodname> : set the structural deployers."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "JBoss5StructureDeployerClasses"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "org.jboss.deployers.plugins.structure.vfs.AbstractStructureDeployer"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "org.jboss.deployers.plugins.structure.vfs.file.FileStructure"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "org.jboss.deployers.plugins.structure.vfs.jar.JARStructure"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "org.jboss.deployers.plugins.structure.vfs.war.WARStructure"
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Deployer Helper and Base Classes"
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "JBoss5BaseDeployerClasses"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>org.jboss.deployers.plugins.deployer.AbstractDeployer</methodname>: forces <methodname>isRelevant</methodname> to return true and <methodname>getRelativeOrder</methodname> to return <property>Integer.MAX_VALUE</property>."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleDeployer</methodname>: collapses the <classname>Deployer</classname> contract to <methodname>deploy(DeploymentUnit)</methodname> and <methodname>undeploy(DeploymentUnit)</methodname> by forcing:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>prepareDeploy</methodname> to not undertake anything"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>commitDeploy</methodname> to call <methodname>deploy</methodname>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>prepareUndeploy</methodname> to call <methodname>undeploy</methodname>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>commitUndeploy</methodname> to not undertake anything"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>handoff</methodname> to not undertake anything"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>org.jboss.deployers.plugins.deployers.helpers.AbstractClassLoaderDeployer</methodname> implements <methodname>org.jboss.deployers.spi.classloader.ClassLoaderFactory</methodname> and <methodname>deploy(DeploymentUnit u)</methodname> as <methodname>u.createClassLoader(this)</methodname>."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>org.jboss.deployers.plugins.deployers.helpers.AbstractTopLevelClassLoaderDeployer</methodname> adds <methodname>createTopLevelClassLoader(DeploymentContext)</methodname> and <methodname>removeTopLevelClassLoader(DeploymentContext)</methodname> methods. It also implements <methodname>createClassLoader</methodname> to invoke <methodname>createTopLevelClassLoader</methodname> if <methodname>context.isTopLevel()</methodname> is <property>true</property>. Otherwise it will return the value of <methodname>context.getTopLevel().getClassLoader()</methodname>."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>org.jboss.deployers.plugins.deployers.helpers.AbstractRealDeployer<T></methodname> adds an attachment type T known as the <property>deploymentType</property> and a <classname>SimpleDeploymentVisitor<T></classname> visitor. The deployment implementation obtains a <property>deploymentType</property> metadata from the deployment unit and then delegates to the <methodname>visitor.deploy(DeploymentUnit, metadata)</methodname> method for each <property>deploymentType</property> metadata. Undeploy similarly delegates to <methodname>visitor.undeploy(DeploymentUnit, metadata)</methodname>."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>org.jboss.deployers.plugins.deployers.helpers.AbstractComponentDeployer<D, C></methodname>: In addition to a deployment type D, a component type C is introduced along with a <classname>SimpleDeploymentVisitor<C></classname> <property>compVisitor</property>. <methodname>Deployer.deploy(DeploymentUnit)</methodname> invokes <methodname>super.deploy(unit)</methodname> to process the deployment type metadata, and then obtains <methodname>unit.getAllMetaData(C)</methodname> and delegates to <methodname>compVisitor.deploy(unit, metadata)</methodname> to process the component metadata. Undeploy similarly invokes <methodname>super.undeploy(unit)</methodname> and the delegates to <methodname>compVisitor.undeploy(unit, metadata)</methodname>. The component visitor is expected to create <classname>DeploymentUnit</classname> components (<methodname>DeploymentUnit.addComponent(String)</methodname>) for the component metadata."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>org.jboss.deployers.plugins.deployers.helpers.AbstractTypedDeployer<T></methodname> adds an attachment type T known as the <property>deploymentType</property> and accessor and contains new features."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>org.jboss.deployers.plugins.deployers.helpers.AbstractParsingDeployer<T></methodname> adds a notion of obtaining an instance of the <property>deploymentType</property> by parsing a metadata file. The helper methods added include:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>protected T getMetaData(DeploymentUnit unit, String key)</methodname> returns <methodname>unit.getAttachment(key, getDeploymentType());</methodname>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>protected void createMetaData(DeploymentUnit unit, String name, String suffix)</methodname> calls <methodname>createMetaData(unit, name, suffix, getDeploymentType().getName());</methodname>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>protected void createMetaData(DeploymentUnit unit, String name, String suffix, String key)</methodname> calls <methodname>parse(unit, name)</methodname> if suffix is null and <methodname>parse(unit, name, suffix)</methodname> otherwise. The result is added as an attachment to <methodname>unit.getTransientManagedObjects()</methodname> under key with expected type T."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>protected T parse(DeploymentUnit unit, String name)</methodname> locates <methodname>VirtualFile unit.getMetaDataFile(name)</methodname>, and if it is found, calls <code>T result = parse(unit, file); init(unit, result, file);</code>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>protected T parse(DeploymentUnit unit, String name, String suffix)</methodname> locates <code>List<VirtualFile> files = unit.getMetaDataFiles(name, suffix)</code>, and if found, <code>calls T result = parse(unit, files.get(0)); init(unit, result, file);</code>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>protected abstract T parse(DeploymentUnit unit, VirtualFile file)</methodname> is an abstract method."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>protected void init(DeploymentUnit unit, T metaData, VirtualFile file)</methodname> is empty."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>org.jboss.deployers.plugins.deployers.helpers.JAXPDeployer<T></methodname> implements <methodname>parse(DeploymentUnit unit, VirtualFile file)</methodname> to obtain the <property>org.w3c.dom.Document</property> corresponding to a file using JAXP <classname>DocumentBuilder</classname> and a file using <classname>InputStream</classname>. This is parsed into <property>deploymentType T</property> by <methodname>calling parse(unit, file, document)</methodname>."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>protected abstract T parse(DeploymentUnit unit, VirtualFile file, Document document) throws Exception</methodname> is an abstract method."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>org.jboss.deployers.plugins.deployers.helpers.XSLDeployer<T></methodname> adds an <code>xslPath</code> that corresponds to a class loader resource for an XSL document. It also overrides the <methodname>parse(DeploymentUnit unit, VirtualFile file)</methodname> method to transform the JAXP document obtained from <methodname>JAXPDeployer.doParse</methodname>, and then parses this into <property>deploymentType T</property> by calling the abstract method, <methodname>parse(unit, file, document)</methodname>."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>org.jboss.deployers.plugins.deployers.helpers.ObjectModelFactoryDeployer<T></methodname> adds an abstract JBossXB <classname>ObjectModelFactory</classname> accessor that is used from within an overriden <methodname>parse(DeploymentUnit unit, VirtualFile file)</methodname> to unmarshall the XML document represented by file into an instance of <property>deploymentType T</property>."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>org.jboss.deployers.plugins.deployers.helpers.SchemaResolverDeployer<T></methodname> uses JBossXB <classname>UnmarshallerFactory</classname> with a <classname>SchemaBindingResolver</classname> from within an overriden <methodname>parse(DeploymentUnit unit, VirtualFile file)</methodname> to unmarshall the XML document represented by the file into an instance of <property>deploymentType T</property>. The XML document must have a valid schema with JBossXB annotations."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer<T></methodname> adds two abstract methods:"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>public abstract void deploy(DeploymentUnit unit, T deployment);</methodname>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<methodname>public abstract void undeploy(DeploymentUnit unit, T deployment);</methodname>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Overrides <methodname>deploy(DeploymentUnit unit)</methodname> to obtain the <classname>deploymentType</classname> instance using <methodname>unit.unit.getAttachment(getDeploymentType())</methodname>, and invokes <methodname>deploy(DeploymentUnit unit, T deployment)</methodname>."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Overrides <methodname>undeploy(DeploymentUnit unit)</methodname> to obtain the <classname>deploymentType</classname> instance using <methodname>unit.unit.getAttachment(getDeploymentType())</methodname>, and invokes <methodname>undeploy(DeploymentUnit unit, T deployment)</methodname>."
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Current Deployers"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<classname>org.jboss.deployers.plugins.deployers.kernel.BeanDeployer</classname>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<classname>org.jboss.deployers.plugins.deployers.kernel.KernelDeploymentDeployer</classname>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<classname>org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer</classname>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<classname>ServiceDeployments</classname>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<classname>org.jboss.system.deployers.SARDeployer</classname>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<classname>org.jboss.system.deployers.ServiceClassLoaderDeployer</classname>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<classname>org.jboss.system.deployers.ServiceDeploymentDeployer</classname>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<classname>org.jboss.system.deployers.ServiceDeployer</classname>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "JBoss5WebDeployments"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<classname>org.jboss.deployment.WebAppParsingDeployer</classname>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<classname>org.jboss.deployment.JBossWebAppParsingDeployer</classname>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<classname>org.jboss.web.tomcat.tc6.deployers.TomcatDeployer</classname>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<classname>org.jboss.resource.deployers.RARDeployer</classname>"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<classname>org.jboss.resource.deployers.RARParserDeployer</classname>"
-msgstr ""
-
-#. Tag: title
-#, no-c-format
-msgid "Virtual File System JBoss5VirtualFileSystem"
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "The virtual file system model of the deployment framework provides a consistent API for accessing logical files in logical file systems referenced by a URI/URL."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "Virtual File System (VFS): the main API for accessing read-only file system of the deployment. A VFS instance represents a virtual file system mount for a given root URI/URL."
-msgstr ""
-
-#. Tag: para
-#, no-c-format
-msgid "<classname>VirtualFile</classname>: the API for a file in the deployment."
-msgstr ""
-
More information about the jboss-cvs-commits
mailing list