diff --git a/jonas/.checkstyle b/.checkstyle similarity index 100% rename from jonas/.checkstyle rename to .checkstyle diff --git a/jonas/.checkstyle_eclipse_config b/.checkstyle_eclipse_config similarity index 100% rename from jonas/.checkstyle_eclipse_config rename to .checkstyle_eclipse_config diff --git a/jonas/.classpath b/.classpath similarity index 100% rename from jonas/.classpath rename to .classpath diff --git a/.cvsignore b/.cvsignore new file mode 100644 index 0000000000000000000000000000000000000000..7786cc6e79bf7690cc12643dcc978157b5495b8d --- /dev/null +++ b/.cvsignore @@ -0,0 +1,5 @@ +classes +output +output_eclipse +.project +temp diff --git a/.jdis b/.jdis new file mode 100644 index 0000000000000000000000000000000000000000..b353a72391c99da661d2e117dd293a1990a163c2 --- /dev/null +++ b/.jdis @@ -0,0 +1,6 @@ +Note regarding JOnAS J2EE certification: +This is an intermediate build made available for testing purposes. +The code is untested and presumed incompatible with the Java[tm] 2 Platform, +Enterprise Edition (J2EE [tm])" specification. You should not deploy or write +to this code, but instead use the tested and certified J2EE compatible version of +the code that is available at http://jonas.objectweb.org/download. diff --git a/jonas/.project b/.project similarity index 100% rename from jonas/.project rename to .project diff --git a/jonas/.settings/org.eclipse.jdt.core.prefs b/.settings/org.eclipse.jdt.core.prefs similarity index 100% rename from jonas/.settings/org.eclipse.jdt.core.prefs rename to .settings/org.eclipse.jdt.core.prefs diff --git a/jonas/.settings/org.eclipse.jdt.ui.prefs b/.settings/org.eclipse.jdt.ui.prefs similarity index 100% rename from jonas/.settings/org.eclipse.jdt.ui.prefs rename to .settings/org.eclipse.jdt.ui.prefs diff --git a/LicenceAgreement.txt b/LicenceAgreement.txt new file mode 100644 index 0000000000000000000000000000000000000000..678c6921d59838dd7d9240be016e05f877d261f1 --- /dev/null +++ b/LicenceAgreement.txt @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence + the version number 2.1.] + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +Licenses are intended to guarantee your freedom to share and change +free software--to make sure the software is free for all its users. + + This license, the Lesser General Public License, applies to some +specially designated software packages--typically libraries--of the +Free Software Foundation and other authors who decide to use it. You +can use it too, but we suggest you first think carefully about whether +this license or the ordinary General Public License is the better +strategy to use in any particular case, based on the explanations below. + + When we speak of free software, we are referring to freedom of use, +not price. Our General Public Licenses are designed to make sure that +you have the freedom to distribute copies of free software (and charge +for this service if you wish); that you receive source code or can get +it if you want it; that you can change the software and use pieces of +it in new free programs; and that you are informed that you can do +these things. + + To protect your rights, we need to make restrictions that forbid +distributors to deny you these rights or to ask you to surrender these +rights. These restrictions translate to certain responsibilities for +you if you distribute copies of the library or if you modify it. + + For example, if you distribute copies of the library, whether gratis +or for a fee, you must give the recipients all the rights that we gave +you. You must make sure that they, too, receive or can get the source +code. If you link other code with the library, you must provide +complete object files to the recipients, so that they can relink them +with the library after making changes to the library and recompiling +it. And you must show them these terms so they know their rights. + + We protect your rights with a two-step method: (1) we copyright the +library, and (2) we offer you this license, which gives you legal +permission to copy, distribute and/or modify the library. + + To protect each distributor, we want to make it very clear that +there is no warranty for the free library. Also, if the library is +modified by someone else and passed on, the recipients should know +that what they have is not the original version, so that the original +author's reputation will not be affected by problems that might be +introduced by others. + + Finally, software patents pose a constant threat to the existence of +any free program. We wish to make sure that a company cannot +effectively restrict the users of a free program by obtaining a +restrictive license from a patent holder. Therefore, we insist that +any patent license obtained for a version of the library must be +consistent with the full freedom of use specified in this license. + + Most GNU software, including some libraries, is covered by the +ordinary GNU General Public License. This license, the GNU Lesser +General Public License, applies to certain designated libraries, and +is quite different from the ordinary General Public License. We use +this license for certain libraries in order to permit linking those +libraries into non-free programs. + + When a program is linked with a library, whether statically or using +a shared library, the combination of the two is legally speaking a +combined work, a derivative of the original library. The ordinary +General Public License therefore permits such linking only if the +entire combination fits its criteria of freedom. The Lesser General +Public License permits more lax criteria for linking other code with +the library. + + We call this license the "Lesser" General Public License because it +does Less to protect the user's freedom than the ordinary General +Public License. It also provides other free software developers Less +of an advantage over competing non-free programs. These disadvantages +are the reason we use the ordinary General Public License for many +libraries. However, the Lesser license provides advantages in certain +special circumstances. + + For example, on rare occasions, there may be a special need to +encourage the widest possible use of a certain library, so that it becomes +a de-facto standard. To achieve this, non-free programs must be +allowed to use the library. A more frequent case is that a free +library does the same job as widely used non-free libraries. In this +case, there is little to gain by limiting the free library to free +software only, so we use the Lesser General Public License. + + In other cases, permission to use a particular library in non-free +programs enables a greater number of people to use a large body of +free software. For example, permission to use the GNU C Library in +non-free programs enables many more people to use the whole GNU +operating system, as well as its variant, the GNU/Linux operating +system. + + Although the Lesser General Public License is Less protective of the +users' freedom, it does ensure that the user of a program that is +linked with the Library has the freedom and the wherewithal to run +that program using a modified version of the Library. + + The precise terms and conditions for copying, distribution and +modification follow. Pay close attention to the difference between a +"work based on the library" and a "work that uses the library". The +former contains code derived from the library, whereas the latter must +be combined with the library in order to run. + + GNU LESSER GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License Agreement applies to any software library or other +program which contains a notice placed by the copyright holder or +other authorized party saying it may be distributed under the terms of +this Lesser General Public License (also called "this License"). +Each licensee is addressed as "you". + + A "library" means a collection of software functions and/or data +prepared so as to be conveniently linked with application programs +(which use some of those functions and data) to form executables. + + The "Library", below, refers to any such software library or work +which has been distributed under these terms. A "work based on the +Library" means either the Library or any derivative work under +copyright law: that is to say, a work containing the Library or a +portion of it, either verbatim or with modifications and/or translated +straightforwardly into another language. (Hereinafter, translation is +included without limitation in the term "modification".) + + "Source code" for a work means the preferred form of the work for +making modifications to it. For a library, complete source code means +all the source code for all modules it contains, plus any associated +interface definition files, plus the scripts used to control compilation +and installation of the library. + + Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running a program using the Library is not restricted, and output from +such a program is covered only if its contents constitute a work based +on the Library (independent of the use of the Library in a tool for +writing it). Whether that is true depends on what the Library does +and what the program that uses the Library does. + + 1. You may copy and distribute verbatim copies of the Library's +complete source code as you receive it, in any medium, provided that +you conspicuously and appropriately publish on each copy an +appropriate copyright notice and disclaimer of warranty; keep intact +all the notices that refer to this License and to the absence of any +warranty; and distribute a copy of this License along with the +Library. + + You may charge a fee for the physical act of transferring a copy, +and you may at your option offer warranty protection in exchange for a +fee. + + 2. You may modify your copy or copies of the Library or any portion +of it, thus forming a work based on the Library, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: + + a) The modified work must itself be a software library. + + b) You must cause the files modified to carry prominent notices + stating that you changed the files and the date of any change. + + c) You must cause the whole of the work to be licensed at no + charge to all third parties under the terms of this License. + + d) If a facility in the modified Library refers to a function or a + table of data to be supplied by an application program that uses + the facility, other than as an argument passed when the facility + is invoked, then you must make a good faith effort to ensure that, + in the event an application does not supply such function or + table, the facility still operates, and performs whatever part of + its purpose remains meaningful. + + (For example, a function in a library to compute square roots has + a purpose that is entirely well-defined independent of the + application. Therefore, Subsection 2d requires that any + application-supplied function or table used by this function must + be optional: if the application does not supply it, the square + root function must still compute square roots.) + +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Library, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Library, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote +it. + +Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Library. + +In addition, mere aggregation of another work not based on the Library +with the Library (or with a work based on the Library) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. + + 3. You may opt to apply the terms of the ordinary GNU General Public +License instead of this License to a given copy of the Library. To do +this, you must alter all the notices that refer to this License, so +that they refer to the ordinary GNU General Public License, version 2, +instead of to this License. (If a newer version than version 2 of the +ordinary GNU General Public License has appeared, then you can specify +that version instead if you wish.) Do not make any other change in +these notices. + + Once this change is made in a given copy, it is irreversible for +that copy, so the ordinary GNU General Public License applies to all +subsequent copies and derivative works made from that copy. + + This option is useful when you wish to copy part of the code of +the Library into a program that is not a library. + + 4. You may copy and distribute the Library (or a portion or +derivative of it, under Section 2) in object code or executable form +under the terms of Sections 1 and 2 above provided that you accompany +it with the complete corresponding machine-readable source code, which +must be distributed under the terms of Sections 1 and 2 above on a +medium customarily used for software interchange. + + If distribution of object code is made by offering access to copy +from a designated place, then offering equivalent access to copy the +source code from the same place satisfies the requirement to +distribute the source code, even though third parties are not +compelled to copy the source along with the object code. + + 5. A program that contains no derivative of any portion of the +Library, but is designed to work with the Library by being compiled or +linked with it, is called a "work that uses the Library". Such a +work, in isolation, is not a derivative work of the Library, and +therefore falls outside the scope of this License. + + However, linking a "work that uses the Library" with the Library +creates an executable that is a derivative of the Library (because it +contains portions of the Library), rather than a "work that uses the +library". The executable is therefore covered by this License. +Section 6 states terms for distribution of such executables. + + When a "work that uses the Library" uses material from a header file +that is part of the Library, the object code for the work may be a +derivative work of the Library even though the source code is not. +Whether this is true is especially significant if the work can be +linked without the Library, or if the work is itself a library. The +threshold for this to be true is not precisely defined by law. + + If such an object file uses only numerical parameters, data +structure layouts and accessors, and small macros and small inline +functions (ten lines or less in length), then the use of the object +file is unrestricted, regardless of whether it is legally a derivative +work. (Executables containing this object code plus portions of the +Library will still fall under Section 6.) + + Otherwise, if the work is a derivative of the Library, you may +distribute the object code for the work under the terms of Section 6. +Any executables containing that work also fall under Section 6, +whether or not they are linked directly with the Library itself. + + 6. As an exception to the Sections above, you may also combine or +link a "work that uses the Library" with the Library to produce a +work containing portions of the Library, and distribute that work +under terms of your choice, provided that the terms permit +modification of the work for the customer's own use and reverse +engineering for debugging such modifications. + + You must give prominent notice with each copy of the work that the +Library is used in it and that the Library and its use are covered by +this License. You must supply a copy of this License. If the work +during execution displays copyright notices, you must include the +copyright notice for the Library among them, as well as a reference +directing the user to the copy of this License. Also, you must do one +of these things: + + a) Accompany the work with the complete corresponding + machine-readable source code for the Library including whatever + changes were used in the work (which must be distributed under + Sections 1 and 2 above); and, if the work is an executable linked + with the Library, with the complete machine-readable "work that + uses the Library", as object code and/or source code, so that the + user can modify the Library and then relink to produce a modified + executable containing the modified Library. (It is understood + that the user who changes the contents of definitions files in the + Library will not necessarily be able to recompile the application + to use the modified definitions.) + + b) Use a suitable shared library mechanism for linking with the + Library. A suitable mechanism is one that (1) uses at run time a + copy of the library already present on the user's computer system, + rather than copying library functions into the executable, and (2) + will operate properly with a modified version of the library, if + the user installs one, as long as the modified version is + interface-compatible with the version that the work was made with. + + c) Accompany the work with a written offer, valid for at + least three years, to give the same user the materials + specified in Subsection 6a, above, for a charge no more + than the cost of performing this distribution. + + d) If distribution of the work is made by offering access to copy + from a designated place, offer equivalent access to copy the above + specified materials from the same place. + + e) Verify that the user has already received a copy of these + materials or that you have already sent this user a copy. + + For an executable, the required form of the "work that uses the +Library" must include any data and utility programs needed for +reproducing the executable from it. However, as a special exception, +the materials to be distributed need not include anything that is +normally distributed (in either source or binary form) with the major +components (compiler, kernel, and so on) of the operating system on +which the executable runs, unless that component itself accompanies +the executable. + + It may happen that this requirement contradicts the license +restrictions of other proprietary libraries that do not normally +accompany the operating system. Such a contradiction means you cannot +use both them and the Library together in an executable that you +distribute. + + 7. You may place library facilities that are a work based on the +Library side-by-side in a single library together with other library +facilities not covered by this License, and distribute such a combined +library, provided that the separate distribution of the work based on +the Library and of the other library facilities is otherwise +permitted, and provided that you do these two things: + + a) Accompany the combined library with a copy of the same work + based on the Library, uncombined with any other library + facilities. This must be distributed under the terms of the + Sections above. + + b) Give prominent notice with the combined library of the fact + that part of it is a work based on the Library, and explaining + where to find the accompanying uncombined form of the same work. + + 8. You may not copy, modify, sublicense, link with, or distribute +the Library except as expressly provided under this License. Any +attempt otherwise to copy, modify, sublicense, link with, or +distribute the Library is void, and will automatically terminate your +rights under this License. However, parties who have received copies, +or rights, from you under this License will not have their licenses +terminated so long as such parties remain in full compliance. + + 9. You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Library or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Library (or any work based on the +Library), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Library or works based on it. + + 10. Each time you redistribute the Library (or any work based on the +Library), the recipient automatically receives a license from the +original licensor to copy, distribute, link with or modify the Library +subject to these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties with +this License. + + 11. If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Library at all. For example, if a patent +license would not permit royalty-free redistribution of the Library by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Library. + +If any portion of this section is held invalid or unenforceable under any +particular circumstance, the balance of the section is intended to apply, +and the section as a whole is intended to apply in other circumstances. + +It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. + +This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. + + 12. If the distribution and/or use of the Library is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Library under this License may add +an explicit geographical distribution limitation excluding those countries, +so that distribution is permitted only in or among countries not thus +excluded. In such case, this License incorporates the limitation as if +written in the body of this License. + + 13. The Free Software Foundation may publish revised and/or new +versions of the Lesser General Public License from time to time. +Such new versions will be similar in spirit to the present version, +but may differ in detail to address new problems or concerns. + +Each version is given a distinguishing version number. If the Library +specifies a version number of this License which applies to it and +"any later version", you have the option of following the terms and +conditions either of that version or of any later version published by +the Free Software Foundation. If the Library does not specify a +license version number, you may choose any version ever published by +the Free Software Foundation. + + 14. If you wish to incorporate parts of the Library into other free +programs whose distribution conditions are incompatible with these, +write to the author to ask for permission. For software which is +copyrighted by the Free Software Foundation, write to the Free +Software Foundation; we sometimes make exceptions for this. Our +decision will be guided by the two goals of preserving the free status +of all derivatives of our free software and of promoting the sharing +and reuse of software generally. + + NO WARRANTY + + 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO +WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. +EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR +OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY +KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE +IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR +PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE +LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME +THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. + + 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN +WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY +AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU +FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR +CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE +LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING +RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A +FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF +SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH +DAMAGES. + + END OF TERMS AND CONDITIONS + + How to Apply These Terms to Your New Libraries + + If you develop a new library, and you want it to be of the greatest +possible use to the public, we recommend making it free software that +everyone can redistribute and change. You can do so by permitting +redistribution under these terms (or, alternatively, under the terms of the +ordinary General Public License). + + To apply these terms, attach the following notices to the library. It is +safest to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least the +"copyright" line and a pointer to where the full notice is found. + + + Copyright (C) + + This library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + This library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with this library; if not, write to the Free Software + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + +Also add information on how to contact you by electronic and paper mail. + +You should also get your employer (if you work as a programmer) or your +school, if any, to sign a "copyright disclaimer" for the library, if +necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in the + library `Frob' (a library for tweaking knobs) written by James Random Hacker. + + , 1 April 1990 + Ty Coon, President of Vice + +That's all there is to it! + + diff --git a/jonas/README b/README similarity index 100% rename from jonas/README rename to README diff --git a/README.J2EE b/README.J2EE new file mode 100644 index 0000000000000000000000000000000000000000..e46800d8d985fcddd2ad1aaf0ec2d98ef469522e --- /dev/null +++ b/README.J2EE @@ -0,0 +1,12 @@ +This version of JOnAS source code is made available in support of the open source +development process. Some numbered or tagged revisions of this source have been +tested and found to pass the Java[TM] 2 Platform, Enterprise Edition (J2EE[TM]) +Compatibility Test Suite, and you can find information on which revisions or tags +at http://jonas.objectweb.org/download. Please note that since only binaries can be +tested, source code cannot be described as a compatible implementation of the J2EE +Specification. The different build environment on your machine and any changes you +may make to this code could render your resulting build incompatible. Because of this, +writing or deploying applications to builds based on this code can lead to lack of +portability. You should instead consider deploying production applications on the +pre-built binaries of JOnAS that are available at http://jonas.objectweb.org/download +that have been tested and certified to meet the J2EE compatibility requirements. diff --git a/jonas/ReleaseNotes.txt b/ReleaseNotes.txt similarity index 100% rename from jonas/ReleaseNotes.txt rename to ReleaseNotes.txt diff --git a/jonas/assemblies/jonas-assemblies.iml b/assemblies/jonas-assemblies.iml similarity index 100% rename from jonas/assemblies/jonas-assemblies.iml rename to assemblies/jonas-assemblies.iml diff --git a/jonas/assemblies/jonas-configuration/jonas-configuration.iml b/assemblies/jonas-configuration/jonas-configuration.iml similarity index 100% rename from jonas/assemblies/jonas-configuration/jonas-configuration.iml rename to assemblies/jonas-configuration/jonas-configuration.iml diff --git a/jonas/assemblies/jonas-configuration/pom.xml b/assemblies/jonas-configuration/pom.xml similarity index 97% rename from jonas/assemblies/jonas-configuration/pom.xml rename to assemblies/jonas-configuration/pom.xml index 60361b9f53018895e8664dd1856b9b69914d7387..f02ae9f0d42ec00b6cb8572dfdba7433238bac0f 100644 --- a/jonas/assemblies/jonas-configuration/pom.xml +++ b/assemblies/jonas-configuration/pom.xml @@ -28,7 +28,7 @@ org.ow2.jonas jonas-assemblies - 5.0.4-SNAPSHOT + 5.0.4 ../pom.xml 4.0.0 diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/FirebirdSQL.properties b/assemblies/jonas-configuration/src/main/resources/conf/FirebirdSQL.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/FirebirdSQL.properties rename to assemblies/jonas-configuration/src/main/resources/conf/FirebirdSQL.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/HSQL1.properties b/assemblies/jonas-configuration/src/main/resources/conf/HSQL1.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/HSQL1.properties rename to assemblies/jonas-configuration/src/main/resources/conf/HSQL1.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/InstantDB1.properties b/assemblies/jonas-configuration/src/main/resources/conf/InstantDB1.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/InstantDB1.properties rename to assemblies/jonas-configuration/src/main/resources/conf/InstantDB1.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/InterBase1.properties b/assemblies/jonas-configuration/src/main/resources/conf/InterBase1.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/InterBase1.properties rename to assemblies/jonas-configuration/src/main/resources/conf/InterBase1.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/MailMimePartDS1.properties b/assemblies/jonas-configuration/src/main/resources/conf/MailMimePartDS1.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/MailMimePartDS1.properties rename to assemblies/jonas-configuration/src/main/resources/conf/MailMimePartDS1.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/MailSession1.properties b/assemblies/jonas-configuration/src/main/resources/conf/MailSession1.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/MailSession1.properties rename to assemblies/jonas-configuration/src/main/resources/conf/MailSession1.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/McKoi1.properties b/assemblies/jonas-configuration/src/main/resources/conf/McKoi1.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/McKoi1.properties rename to assemblies/jonas-configuration/src/main/resources/conf/McKoi1.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/MySQL.properties b/assemblies/jonas-configuration/src/main/resources/conf/MySQL.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/MySQL.properties rename to assemblies/jonas-configuration/src/main/resources/conf/MySQL.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/Oracle1.properties b/assemblies/jonas-configuration/src/main/resources/conf/Oracle1.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/Oracle1.properties rename to assemblies/jonas-configuration/src/main/resources/conf/Oracle1.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/PostgreSQL1.properties b/assemblies/jonas-configuration/src/main/resources/conf/PostgreSQL1.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/PostgreSQL1.properties rename to assemblies/jonas-configuration/src/main/resources/conf/PostgreSQL1.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/Sybase1.properties b/assemblies/jonas-configuration/src/main/resources/conf/Sybase1.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/Sybase1.properties rename to assemblies/jonas-configuration/src/main/resources/conf/Sybase1.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/a3debug.cfg b/assemblies/jonas-configuration/src/main/resources/conf/a3debug.cfg similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/a3debug.cfg rename to assemblies/jonas-configuration/src/main/resources/conf/a3debug.cfg diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/a3servers.xml b/assemblies/jonas-configuration/src/main/resources/conf/a3servers.xml similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/a3servers.xml rename to assemblies/jonas-configuration/src/main/resources/conf/a3servers.xml diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/carol.properties b/assemblies/jonas-configuration/src/main/resources/conf/carol.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/carol.properties rename to assemblies/jonas-configuration/src/main/resources/conf/carol.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/clusterd.xml b/assemblies/jonas-configuration/src/main/resources/conf/clusterd.xml similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/clusterd.xml rename to assemblies/jonas-configuration/src/main/resources/conf/clusterd.xml diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/cmi.properties b/assemblies/jonas-configuration/src/main/resources/conf/cmi.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/cmi.properties rename to assemblies/jonas-configuration/src/main/resources/conf/cmi.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/db2.properties b/assemblies/jonas-configuration/src/main/resources/conf/db2.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/db2.properties rename to assemblies/jonas-configuration/src/main/resources/conf/db2.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/domain.xml b/assemblies/jonas-configuration/src/main/resources/conf/domain.xml similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/domain.xml rename to assemblies/jonas-configuration/src/main/resources/conf/domain.xml diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/env.sh.include b/assemblies/jonas-configuration/src/main/resources/conf/env.sh.include similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/env.sh.include rename to assemblies/jonas-configuration/src/main/resources/conf/env.sh.include diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/env.start.sh.include b/assemblies/jonas-configuration/src/main/resources/conf/env.start.sh.include similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/env.start.sh.include rename to assemblies/jonas-configuration/src/main/resources/conf/env.start.sh.include diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/execute.properties b/assemblies/jonas-configuration/src/main/resources/conf/execute.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/execute.properties rename to assemblies/jonas-configuration/src/main/resources/conf/execute.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/file1.properties b/assemblies/jonas-configuration/src/main/resources/conf/file1.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/file1.properties rename to assemblies/jonas-configuration/src/main/resources/conf/file1.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/jaas.config b/assemblies/jonas-configuration/src/main/resources/conf/jaas.config similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/jaas.config rename to assemblies/jonas-configuration/src/main/resources/conf/jaas.config diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/jacorb.properties b/assemblies/jonas-configuration/src/main/resources/conf/jacorb.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/jacorb.properties rename to assemblies/jonas-configuration/src/main/resources/conf/jacorb.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/java.policy b/assemblies/jonas-configuration/src/main/resources/conf/java.policy similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/java.policy rename to assemblies/jonas-configuration/src/main/resources/conf/java.policy diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/jaxr.properties b/assemblies/jonas-configuration/src/main/resources/conf/jaxr.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/jaxr.properties rename to assemblies/jonas-configuration/src/main/resources/conf/jaxr.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/jgroups-cmi.xml b/assemblies/jonas-configuration/src/main/resources/conf/jgroups-cmi.xml similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/jgroups-cmi.xml rename to assemblies/jonas-configuration/src/main/resources/conf/jgroups-cmi.xml diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/jgroups-discovery.xml b/assemblies/jonas-configuration/src/main/resources/conf/jgroups-discovery.xml similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/jgroups-discovery.xml rename to assemblies/jonas-configuration/src/main/resources/conf/jgroups-discovery.xml diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/jgroups-ha.xml b/assemblies/jonas-configuration/src/main/resources/conf/jgroups-ha.xml similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/jgroups-ha.xml rename to assemblies/jonas-configuration/src/main/resources/conf/jgroups-ha.xml diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/jmx.access b/assemblies/jonas-configuration/src/main/resources/conf/jmx.access similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/jmx.access rename to assemblies/jonas-configuration/src/main/resources/conf/jmx.access diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/jmx.passwords b/assemblies/jonas-configuration/src/main/resources/conf/jmx.passwords similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/jmx.passwords rename to assemblies/jonas-configuration/src/main/resources/conf/jmx.passwords diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/jmx.rolebased.access b/assemblies/jonas-configuration/src/main/resources/conf/jmx.rolebased.access similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/jmx.rolebased.access rename to assemblies/jonas-configuration/src/main/resources/conf/jmx.rolebased.access diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/jonas-client.properties b/assemblies/jonas-configuration/src/main/resources/conf/jonas-client.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/jonas-client.properties rename to assemblies/jonas-configuration/src/main/resources/conf/jonas-client.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/jonas-realm.xml b/assemblies/jonas-configuration/src/main/resources/conf/jonas-realm.xml similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/jonas-realm.xml rename to assemblies/jonas-configuration/src/main/resources/conf/jonas-realm.xml diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/jonas.properties b/assemblies/jonas-configuration/src/main/resources/conf/jonas.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/jonas.properties rename to assemblies/jonas-configuration/src/main/resources/conf/jonas.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/jonas_areas.xml b/assemblies/jonas-configuration/src/main/resources/conf/jonas_areas.xml similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/jonas_areas.xml rename to assemblies/jonas-configuration/src/main/resources/conf/jonas_areas.xml diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/joramAdmin.xml b/assemblies/jonas-configuration/src/main/resources/conf/joramAdmin.xml similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/joramAdmin.xml rename to assemblies/jonas-configuration/src/main/resources/conf/joramAdmin.xml diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/jotm.properties b/assemblies/jonas-configuration/src/main/resources/conf/jotm.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/jotm.properties rename to assemblies/jonas-configuration/src/main/resources/conf/jotm.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/newjc/build-db.properties b/assemblies/jonas-configuration/src/main/resources/conf/newjc/build-db.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/newjc/build-db.properties rename to assemblies/jonas-configuration/src/main/resources/conf/newjc/build-db.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/newjc/build-jc.properties b/assemblies/jonas-configuration/src/main/resources/conf/newjc/build-jc.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/newjc/build-jc.properties rename to assemblies/jonas-configuration/src/main/resources/conf/newjc/build-jc.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/newjc/build-jc.xml b/assemblies/jonas-configuration/src/main/resources/conf/newjc/build-jc.xml similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/newjc/build-jc.xml rename to assemblies/jonas-configuration/src/main/resources/conf/newjc/build-jc.xml diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/newjc/build-master.properties b/assemblies/jonas-configuration/src/main/resources/conf/newjc/build-master.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/newjc/build-master.properties rename to assemblies/jonas-configuration/src/main/resources/conf/newjc/build-master.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/spy.properties b/assemblies/jonas-configuration/src/main/resources/conf/spy.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/spy.properties rename to assemblies/jonas-configuration/src/main/resources/conf/spy.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/trace.properties b/assemblies/jonas-configuration/src/main/resources/conf/trace.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/trace.properties rename to assemblies/jonas-configuration/src/main/resources/conf/trace.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/traceclient.properties b/assemblies/jonas-configuration/src/main/resources/conf/traceclient.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/traceclient.properties rename to assemblies/jonas-configuration/src/main/resources/conf/traceclient.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/uddi.properties b/assemblies/jonas-configuration/src/main/resources/conf/uddi.properties similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/uddi.properties rename to assemblies/jonas-configuration/src/main/resources/conf/uddi.properties diff --git a/jonas/assemblies/jonas-configuration/src/main/resources/conf/wrapper.conf b/assemblies/jonas-configuration/src/main/resources/conf/wrapper.conf similarity index 100% rename from jonas/assemblies/jonas-configuration/src/main/resources/conf/wrapper.conf rename to assemblies/jonas-configuration/src/main/resources/conf/wrapper.conf diff --git a/jonas/assemblies/jonas-examples/jonas-examples.iml b/assemblies/jonas-examples/jonas-examples.iml similarity index 100% rename from jonas/assemblies/jonas-examples/jonas-examples.iml rename to assemblies/jonas-examples/jonas-examples.iml diff --git a/jonas/assemblies/jonas-examples/pom.xml b/assemblies/jonas-examples/pom.xml similarity index 97% rename from jonas/assemblies/jonas-examples/pom.xml rename to assemblies/jonas-examples/pom.xml index 34073ed05b0039e4f2c9e3632fd1bd068ff27ae2..d51381112bee8d4e26f5a4da9bcb611db845e384 100644 --- a/jonas/assemblies/jonas-examples/pom.xml +++ b/assemblies/jonas-examples/pom.xml @@ -28,7 +28,7 @@ org.ow2.jonas jonas-assemblies - 5.0.4-SNAPSHOT + 5.0.4 ../pom.xml 4.0.0 diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/build.properties b/assemblies/jonas-examples/src/main/resources/examples/build.properties similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/build.properties rename to assemblies/jonas-examples/src/main/resources/examples/build.properties diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/build.xml b/assemblies/jonas-examples/src/main/resources/examples/build.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/build.xml rename to assemblies/jonas-examples/src/main/resources/examples/build.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/README b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/README similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/README rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/README diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/build.xml b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/build.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/build.xml rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/build.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/jaas/jaas.config b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/jaas/jaas.config similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/jaas/jaas.config rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/jaas/jaas.config diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/jetty.gif b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/jetty.gif similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/jetty.gif rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/jetty.gif diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/logoOW2.png b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/logoOW2.png similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/logoOW2.png rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/logoOW2.png diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/ow_jonas_logo.gif b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/ow_jonas_logo.gif similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/ow_jonas_logo.gif rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/ow_jonas_logo.gif diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/tomcat.gif b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/tomcat.gif similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/tomcat.gif rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/tomcat.gif diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/valid-xhtml11.png b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/valid-xhtml11.png similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/valid-xhtml11.png rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/valid-xhtml11.png diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/vcss.png b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/vcss.png similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/vcss.png rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/img/vcss.png diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/index.html b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/index.html similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/index.html rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/index.html diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/ow2_jonas.css b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/ow2_jonas.css similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/ow2_jonas.css rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/resources/web/ow2_jonas.css diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/application-client.xml b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/application-client.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/application-client.xml rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/application-client.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/application.xml b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/application.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/application.xml rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/application.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/jonas-client1.xml b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/jonas-client1.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/jonas-client1.xml rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/jonas-client1.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/jonas-client2.xml b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/jonas-client2.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/jonas-client2.xml rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/jonas-client2.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/jonas-secusb.xml b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/jonas-secusb.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/jonas-secusb.xml rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/jonas-secusb.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/jonas-web.xml b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/jonas-web.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/jonas-web.xml rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/jonas-web.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/ra.xml b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/ra.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/ra.xml rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/ra.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/secusb.xml b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/secusb.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/secusb.xml rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/secusb.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/web.xml b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/web.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/web.xml rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/etc/xml/web.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/Src.iml b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/Src.iml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/Src.iml rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/Src.iml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/Op.java b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/Op.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/Op.java rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/Op.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/OpBean.java b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/OpBean.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/OpBean.java rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/OpBean.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/OpHome.java b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/OpHome.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/OpHome.java rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/OpHome.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/OpLocal.java b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/OpLocal.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/OpLocal.java rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/OpLocal.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/OpLocalHome.java b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/OpLocalHome.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/OpLocalHome.java rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/beans/secusb/OpLocalHome.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/clients/Client.java b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/clients/Client.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/clients/Client.java rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/clients/Client.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/resourceadapters/ResourceAdapterImpl.java b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/resourceadapters/ResourceAdapterImpl.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/resourceadapters/ResourceAdapterImpl.java rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/resourceadapters/ResourceAdapterImpl.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/servlets/ServletOp.java b/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/servlets/ServletOp.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/servlets/ServletOp.java rename to assemblies/jonas-examples/src/main/resources/examples/j2ee1.4/src/java/org/ow2/jonas/earsample/servlets/ServletOp.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/README b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/README similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/README rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/README diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/build.xml b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/build.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/build.xml rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/build.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/application.xml b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/application.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/application.xml rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/application.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jaas-secured-application-client.xml b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jaas-secured-application-client.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jaas-secured-application-client.xml rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jaas-secured-application-client.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jaas-secured-jonas-client.xml b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jaas-secured-jonas-client.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jaas-secured-jonas-client.xml rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jaas-secured-jonas-client.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jaas.config b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jaas.config similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jaas.config rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jaas.config diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jms-application-client.xml b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jms-application-client.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jms-application-client.xml rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jms-application-client.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jms-jonas-client.xml b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jms-jonas-client.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jms-jonas-client.xml rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/jms-jonas-client.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/not-secured-application-client.xml b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/not-secured-application-client.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/not-secured-application-client.xml rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/not-secured-application-client.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/not-secured-jonas-client.xml b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/not-secured-jonas-client.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/not-secured-jonas-client.xml rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/not-secured-jonas-client.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/persistence.xml b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/persistence.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/persistence.xml rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/persistence.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web.xml b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web.xml rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web.xml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/architecture.png b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/architecture.png similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/architecture.png rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/architecture.png diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/jetty.gif b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/jetty.gif similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/jetty.gif rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/jetty.gif diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/logoOW2.png b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/logoOW2.png similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/logoOW2.png rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/logoOW2.png diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/ow_jonas_logo.gif b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/ow_jonas_logo.gif similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/ow_jonas_logo.gif rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/ow_jonas_logo.gif diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/tomcat.gif b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/tomcat.gif similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/tomcat.gif rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/tomcat.gif diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/valid-xhtml11.png b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/valid-xhtml11.png similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/valid-xhtml11.png rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/valid-xhtml11.png diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/vcss.png b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/vcss.png similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/vcss.png rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/img/vcss.png diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/index.html b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/index.html similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/index.html rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/index.html diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/ow2_jonas.css b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/ow2_jonas.css similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/ow2_jonas.css rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/etc/web/ow2_jonas.css diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/Src1.iml b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/Src1.iml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/Src1.iml rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/Src1.iml diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/client/JMSApplicationClient.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/client/JMSApplicationClient.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/client/JMSApplicationClient.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/client/JMSApplicationClient.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/client/NotSecuredApplicationClient.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/client/NotSecuredApplicationClient.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/client/NotSecuredApplicationClient.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/client/NotSecuredApplicationClient.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/client/SecuredApplicationClient.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/client/SecuredApplicationClient.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/client/SecuredApplicationClient.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/client/SecuredApplicationClient.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/client/package.html b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/client/package.html similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/client/package.html rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/client/package.html diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/entity/Author.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/entity/Author.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/entity/Author.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/entity/Author.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/entity/Book.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/entity/Book.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/entity/Book.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/entity/Book.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/entity/package.html b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/entity/package.html similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/entity/package.html rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/entity/package.html diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/init/Initializer.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/init/Initializer.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/init/Initializer.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/init/Initializer.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/init/InitializerBean.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/init/InitializerBean.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/init/InitializerBean.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/init/InitializerBean.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/init/package.html b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/init/package.html similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/init/package.html rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/init/package.html diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mail/Mailer.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mail/Mailer.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mail/Mailer.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mail/Mailer.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mail/MailerBean.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mail/MailerBean.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mail/MailerBean.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mail/MailerBean.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mail/package.html b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mail/package.html similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mail/package.html rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mail/package.html diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mdb/JMSMessageBean.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mdb/JMSMessageBean.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mdb/JMSMessageBean.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mdb/JMSMessageBean.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mdb/package.html b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mdb/package.html similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mdb/package.html rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/mdb/package.html diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/package.html b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/package.html similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/package.html rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/package.html diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/LocalReader.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/LocalReader.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/LocalReader.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/LocalReader.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/Reader.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/Reader.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/Reader.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/Reader.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/ReaderBean.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/ReaderBean.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/ReaderBean.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/ReaderBean.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/RemoteReader.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/RemoteReader.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/RemoteReader.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/RemoteReader.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/package.html b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/package.html similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/package.html rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/reader/package.html diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/web/AdminServlet.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/web/AdminServlet.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/web/AdminServlet.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/web/AdminServlet.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/web/ExampleServlet.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/web/ExampleServlet.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/web/ExampleServlet.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/web/ExampleServlet.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/web/package.html b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/web/package.html similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/web/package.html rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/web/package.html diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/LocalWriter.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/LocalWriter.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/LocalWriter.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/LocalWriter.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/RemoteWriter.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/RemoteWriter.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/RemoteWriter.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/RemoteWriter.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/Writer.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/Writer.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/Writer.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/Writer.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/WriterBean.java b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/WriterBean.java similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/WriterBean.java rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/WriterBean.java diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/package.html b/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/package.html similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/package.html rename to assemblies/jonas-examples/src/main/resources/examples/javaee-earsample/src/java/org/ow2/jonas/examples/ear/writer/package.html diff --git a/jonas/assemblies/jonas-examples/src/main/resources/examples/jonas-common.xml b/assemblies/jonas-examples/src/main/resources/examples/jonas-common.xml similarity index 100% rename from jonas/assemblies/jonas-examples/src/main/resources/examples/jonas-common.xml rename to assemblies/jonas-examples/src/main/resources/examples/jonas-common.xml diff --git a/jonas/assemblies/jonas-osgi/jonas-osgi.iml b/assemblies/jonas-osgi/jonas-osgi.iml similarity index 100% rename from jonas/assemblies/jonas-osgi/jonas-osgi.iml rename to assemblies/jonas-osgi/jonas-osgi.iml diff --git a/jonas/assemblies/jonas-osgi/pom.xml b/assemblies/jonas-osgi/pom.xml similarity index 99% rename from jonas/assemblies/jonas-osgi/pom.xml rename to assemblies/jonas-osgi/pom.xml index 961755079ad860e2fd694eeb8b058a86dc5ede5e..3fc7664258f4684da6d8b0fdd74090c21e53d773 100644 --- a/jonas/assemblies/jonas-osgi/pom.xml +++ b/assemblies/jonas-osgi/pom.xml @@ -28,7 +28,7 @@ org.ow2.jonas jonas-assemblies - 5.0.4-SNAPSHOT + 5.0.4 ../pom.xml 4.0.0 diff --git a/jonas/assemblies/jonas-osgi/src/main/assembly/assembly.xml b/assemblies/jonas-osgi/src/main/assembly/assembly.xml similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/assembly/assembly.xml rename to assemblies/jonas-osgi/src/main/assembly/assembly.xml diff --git a/jonas/assemblies/jonas-osgi/src/main/assembly/templates-component.xml b/assemblies/jonas-osgi/src/main/assembly/templates-component.xml similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/assembly/templates-component.xml rename to assemblies/jonas-osgi/src/main/assembly/templates-component.xml diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/ClientStubGen b/assemblies/jonas-osgi/src/main/resources/bin/ClientStubGen similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/ClientStubGen rename to assemblies/jonas-osgi/src/main/resources/bin/ClientStubGen diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/ClientStubGen.bat b/assemblies/jonas-osgi/src/main/resources/bin/ClientStubGen.bat similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/ClientStubGen.bat rename to assemblies/jonas-osgi/src/main/resources/bin/ClientStubGen.bat diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/GenIC b/assemblies/jonas-osgi/src/main/resources/bin/GenIC similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/GenIC rename to assemblies/jonas-osgi/src/main/resources/bin/GenIC diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/GenIC.bat b/assemblies/jonas-osgi/src/main/resources/bin/GenIC.bat similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/GenIC.bat rename to assemblies/jonas-osgi/src/main/resources/bin/GenIC.bat diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/JmsServer b/assemblies/jonas-osgi/src/main/resources/bin/JmsServer similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/JmsServer rename to assemblies/jonas-osgi/src/main/resources/bin/JmsServer diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/JmsServer.bat b/assemblies/jonas-osgi/src/main/resources/bin/JmsServer.bat similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/JmsServer.bat rename to assemblies/jonas-osgi/src/main/resources/bin/JmsServer.bat diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/RAConfig b/assemblies/jonas-osgi/src/main/resources/bin/RAConfig similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/RAConfig rename to assemblies/jonas-osgi/src/main/resources/bin/RAConfig diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/RAConfig.bat b/assemblies/jonas-osgi/src/main/resources/bin/RAConfig.bat similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/RAConfig.bat rename to assemblies/jonas-osgi/src/main/resources/bin/RAConfig.bat diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/WsGen b/assemblies/jonas-osgi/src/main/resources/bin/WsGen similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/WsGen rename to assemblies/jonas-osgi/src/main/resources/bin/WsGen diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/WsGen.bat b/assemblies/jonas-osgi/src/main/resources/bin/WsGen.bat similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/WsGen.bat rename to assemblies/jonas-osgi/src/main/resources/bin/WsGen.bat diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/jcl.bash b/assemblies/jonas-osgi/src/main/resources/bin/jcl.bash similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/jcl.bash rename to assemblies/jonas-osgi/src/main/resources/bin/jcl.bash diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/jcl.bat b/assemblies/jonas-osgi/src/main/resources/bin/jcl.bat similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/jcl.bat rename to assemblies/jonas-osgi/src/main/resources/bin/jcl.bat diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/jcl.ksh b/assemblies/jonas-osgi/src/main/resources/bin/jcl.ksh similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/jcl.ksh rename to assemblies/jonas-osgi/src/main/resources/bin/jcl.ksh diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/jcl.sh b/assemblies/jonas-osgi/src/main/resources/bin/jcl.sh similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/jcl.sh rename to assemblies/jonas-osgi/src/main/resources/bin/jcl.sh diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/jclient b/assemblies/jonas-osgi/src/main/resources/bin/jclient similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/jclient rename to assemblies/jonas-osgi/src/main/resources/bin/jclient diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/jclient.bat b/assemblies/jonas-osgi/src/main/resources/bin/jclient.bat similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/jclient.bat rename to assemblies/jonas-osgi/src/main/resources/bin/jclient.bat diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/jclusterd b/assemblies/jonas-osgi/src/main/resources/bin/jclusterd similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/jclusterd rename to assemblies/jonas-osgi/src/main/resources/bin/jclusterd diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/jclusterd.bat b/assemblies/jonas-osgi/src/main/resources/bin/jclusterd.bat similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/jclusterd.bat rename to assemblies/jonas-osgi/src/main/resources/bin/jclusterd.bat diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/jonas b/assemblies/jonas-osgi/src/main/resources/bin/jonas similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/jonas rename to assemblies/jonas-osgi/src/main/resources/bin/jonas diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/jonas.bat b/assemblies/jonas-osgi/src/main/resources/bin/jonas.bat similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/jonas.bat rename to assemblies/jonas-osgi/src/main/resources/bin/jonas.bat diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/joram_raconfig b/assemblies/jonas-osgi/src/main/resources/bin/joram_raconfig similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/joram_raconfig rename to assemblies/jonas-osgi/src/main/resources/bin/joram_raconfig diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/joram_raconfig.bat b/assemblies/jonas-osgi/src/main/resources/bin/joram_raconfig.bat similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/joram_raconfig.bat rename to assemblies/jonas-osgi/src/main/resources/bin/joram_raconfig.bat diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/newjb b/assemblies/jonas-osgi/src/main/resources/bin/newjb similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/newjb rename to assemblies/jonas-osgi/src/main/resources/bin/newjb diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/newjb.bat b/assemblies/jonas-osgi/src/main/resources/bin/newjb.bat similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/newjb.bat rename to assemblies/jonas-osgi/src/main/resources/bin/newjb.bat diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/newjc.bat b/assemblies/jonas-osgi/src/main/resources/bin/newjc.bat similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/newjc.bat rename to assemblies/jonas-osgi/src/main/resources/bin/newjc.bat diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/newjc.sh b/assemblies/jonas-osgi/src/main/resources/bin/newjc.sh similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/newjc.sh rename to assemblies/jonas-osgi/src/main/resources/bin/newjc.sh diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/probeJgroups b/assemblies/jonas-osgi/src/main/resources/bin/probeJgroups similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/probeJgroups rename to assemblies/jonas-osgi/src/main/resources/bin/probeJgroups diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/probeJgroups.bat b/assemblies/jonas-osgi/src/main/resources/bin/probeJgroups.bat similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/probeJgroups.bat rename to assemblies/jonas-osgi/src/main/resources/bin/probeJgroups.bat diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/registry b/assemblies/jonas-osgi/src/main/resources/bin/registry similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/registry rename to assemblies/jonas-osgi/src/main/resources/bin/registry diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/registry.bat b/assemblies/jonas-osgi/src/main/resources/bin/registry.bat similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/registry.bat rename to assemblies/jonas-osgi/src/main/resources/bin/registry.bat diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/setenv b/assemblies/jonas-osgi/src/main/resources/bin/setenv similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/setenv rename to assemblies/jonas-osgi/src/main/resources/bin/setenv diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/bin/setenv.bat b/assemblies/jonas-osgi/src/main/resources/bin/setenv.bat similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/bin/setenv.bat rename to assemblies/jonas-osgi/src/main/resources/bin/setenv.bat diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/build-jb.properties b/assemblies/jonas-osgi/src/main/resources/build-jb.properties similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/build-jb.properties rename to assemblies/jonas-osgi/src/main/resources/build-jb.properties diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/build-jb.xml b/assemblies/jonas-osgi/src/main/resources/build-jb.xml similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/build-jb.xml rename to assemblies/jonas-osgi/src/main/resources/build-jb.xml diff --git a/jonas/assemblies/jonas-osgi/src/main/resources/logs/README b/assemblies/jonas-osgi/src/main/resources/logs/README similarity index 100% rename from jonas/assemblies/jonas-osgi/src/main/resources/logs/README rename to assemblies/jonas-osgi/src/main/resources/logs/README diff --git a/jonas/assemblies/pom.xml b/assemblies/pom.xml similarity index 97% rename from jonas/assemblies/pom.xml rename to assemblies/pom.xml index ec7612a74c8dcf46ee72e72ad7a690c5b8eb64fe..0fd5e1191f42d3c8ea284cfd5480265f7a53cfae 100644 --- a/jonas/assemblies/pom.xml +++ b/assemblies/pom.xml @@ -28,7 +28,7 @@ org.ow2.jonas jonas - 5.0.4-SNAPSHOT + 5.0.4 ../pom.xml 4.0.0 diff --git a/jonas/clientbuild.xml b/clientbuild.xml similarity index 100% rename from jonas/clientbuild.xml rename to clientbuild.xml diff --git a/doc/README b/doc/README new file mode 100644 index 0000000000000000000000000000000000000000..cc76c9081eb26f2bdf8f4a216ba700b0b51f6ecc --- /dev/null +++ b/doc/README @@ -0,0 +1,4 @@ +$Id: $ +The war file come from http://forge.objectweb.org/projects/jonas-doc +This file will be unpacked into JONAS_ROOT/webapps/autoload directory +Version of this file can be found in versions.properties. \ No newline at end of file diff --git a/eclipse-settings/checkstyle-convention.xml b/eclipse-settings/checkstyle-convention.xml new file mode 100644 index 0000000000000000000000000000000000000000..24314732bfe69e373f0f2becd7d201a68423fbf9 --- /dev/null +++ b/eclipse-settings/checkstyle-convention.xml @@ -0,0 +1,188 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/eclipse-settings/eclipse-java-code-formatter.xml b/eclipse-settings/eclipse-java-code-formatter.xml new file mode 100644 index 0000000000000000000000000000000000000000..8d7be071a084b1c4d92b288b5833f938eed98a3f --- /dev/null +++ b/eclipse-settings/eclipse-java-code-formatter.xml @@ -0,0 +1,181 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/eclipse-settings/eclipse-java-codestyle-organize-import b/eclipse-settings/eclipse-java-codestyle-organize-import new file mode 100644 index 0000000000000000000000000000000000000000..1b52f7ec0913065f63e8ddb1795ed3cfd65894c2 --- /dev/null +++ b/eclipse-settings/eclipse-java-codestyle-organize-import @@ -0,0 +1,24 @@ +#Organize Import Order +#Mon Apr 19 08:43:05 CEST 2004 +19=org.objectweb.security +18=org.objectweb.medor +17=org.objectweb.jorm +16=org.objectweb.joram +15=org.objectweb.jonas +14=org.objectweb.jonas_ws +13=org.objectweb.jonas_web +12=org.objectweb.jonas_rar +11=org.objectweb.jonas_jms +10=org.objectweb.jonas_lib +9=org.objectweb.jonas_ejb +8=org.objectweb.jonas_ear +7=org.objectweb.jonas_client +6=org.objectweb.common +5=org.objectweb.carol +4=org.objectweb +3=org.apache +2=org +1=javax +21=com +0=java +20=org.objectweb.util diff --git a/eclipse-settings/jonas-style-convention.xml b/eclipse-settings/jonas-style-convention.xml new file mode 100644 index 0000000000000000000000000000000000000000..8d7be071a084b1c4d92b288b5833f938eed98a3f --- /dev/null +++ b/eclipse-settings/jonas-style-convention.xml @@ -0,0 +1,181 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/eclipse-settings/plugin-checkstyle-config.xml b/eclipse-settings/plugin-checkstyle-config.xml new file mode 100644 index 0000000000000000000000000000000000000000..c8e751d12ca16dc1f0d0df691051c68d111f8933 --- /dev/null +++ b/eclipse-settings/plugin-checkstyle-config.xml @@ -0,0 +1,253 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/jonas/jonas.iml b/jonas.iml similarity index 100% rename from jonas/jonas.iml rename to jonas.iml diff --git a/jonas/jonas.ipr b/jonas.ipr similarity index 100% rename from jonas/jonas.ipr rename to jonas.ipr diff --git a/jonas/modules/libraries/jonas-service-manager/pom.xml b/jonas/modules/libraries/jonas-service-manager/pom.xml deleted file mode 100644 index 3fd4fc07644d7443292654a2e5bb1eaaf09109e8..0000000000000000000000000000000000000000 --- a/jonas/modules/libraries/jonas-service-manager/pom.xml +++ /dev/null @@ -1,64 +0,0 @@ - - - - - org.ow2.jonas - jonas-libraries - 5.0.4-SNAPSHOT - ../pom.xml - - 4.0.0 - org.ow2.jonas - jonas-service-manager - bundle - JOnAS :: Libraries :: ServiceManager - - - org.ow2.jonas - jonas-commons - ${project.version} - - - org.ow2.jonas - jonas-services-api - ${project.version} - provided - - - org.ow2.bundles - ow2-util-log - - - org.ow2.jonas - jonas-management-javaee - ${project.version} - provided - - - \ No newline at end of file diff --git a/jonas/modules/libraries/management/reconfig/pom.xml b/jonas/modules/libraries/management/reconfig/pom.xml deleted file mode 100644 index 3e9d6f24b27ebd7ab668076608c795f21363ebf4..0000000000000000000000000000000000000000 --- a/jonas/modules/libraries/management/reconfig/pom.xml +++ /dev/null @@ -1,57 +0,0 @@ - - - - - org.ow2.jonas - jonas-management - 5.0.4-SNAPSHOT - ../pom.xml - - 4.0.0 - org.ow2.jonas - jonas-management-reconfig - bundle - JOnAS :: Libraries :: Management :: Reconfig - - - org.ow2.jonas - jonas-commons - ${project.version} - - - org.objectweb.monolog - monolog-api - ${monolog.version} - - - org.ow2.jonas - jonas-management-javaee - ${project.version} - provided - - - diff --git a/jonas/modules/libraries/security/interceptors/jrmp/pom.xml b/jonas/modules/libraries/security/interceptors/jrmp/pom.xml deleted file mode 100644 index 50139b1727af34c2f59195c37bf83cab0b3a123b..0000000000000000000000000000000000000000 --- a/jonas/modules/libraries/security/interceptors/jrmp/pom.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - org.ow2.jonas - jonas-security-interceptors - 5.0.4-SNAPSHOT - ../pom.xml - - 4.0.0 - org.ow2.jonas - jonas-sec-interceptors-jrmp - bundle - JOnAS :: Libraries :: Security :: Interceptors :: JRMP - - - - org.ow2.jonas - jonas-security-propagation - ${project.version} - - - org.ow2.jonas - jonas-commons - ${project.version} - - - org.ow2.carol - carol-interceptors - - - diff --git a/jonas_doc/.project b/jonas_doc/.project deleted file mode 100644 index 451f84138c0e6161dba861cf8d3c743f11b2ab6f..0000000000000000000000000000000000000000 --- a/jonas_doc/.project +++ /dev/null @@ -1,11 +0,0 @@ - - - jonas_doc - - - - - - - - diff --git a/jonas_doc/Jonas5_doc.iml b/jonas_doc/Jonas5_doc.iml deleted file mode 100644 index b439c615169dd0290825da9a7a235f0be382ecd3..0000000000000000000000000000000000000000 --- a/jonas_doc/Jonas5_doc.iml +++ /dev/null @@ -1,51 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/jonas_doc/build.properties b/jonas_doc/build.properties deleted file mode 100644 index 94f30b6f936e828cdbb8e3e742002c7c6f2c6cfa..0000000000000000000000000000000000000000 --- a/jonas_doc/build.properties +++ /dev/null @@ -1,14 +0,0 @@ -docbook.dtd.location=tools/docbook-5.0/dtc/docbook.dtd -docbook.public.id=-//OASIS//DTD DocBook XML V5.0//EN -fop.dir=tools/fop-0.94 -docbook.xsl.dir=tools/docbook-xsl-1.73.2 - -# Product version -product.version = 5.0.5-SNAPSHOT - -# EasyBeans Doc version to use -easybeans.version = 1.1.0-M1-JONAS - -# CMI Doc version to use -cmi.version = 2.0-RC8 - diff --git a/jonas_doc/build.xml b/jonas_doc/build.xml deleted file mode 100644 index 2679f97d7e5b503e04871936c7aad749979b9941..0000000000000000000000000000000000000000 --- a/jonas_doc/build.xml +++ /dev/null @@ -1,538 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ========================================================== - Generating @{file} - * formats: PDF & HTML & HTML Chunks - * language: @{lang} - ========================================================== - - - - - - - - - - - ========================================================== - Generating @{file} - * formats: PDF & HTML - * language: @{lang} - ========================================================== - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - xsltproc - file:@{file} - xsltproc - output:@{output} - xsltproc - style.file:@{style} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/jonas_doc/olddoc/Admin.html b/jonas_doc/olddoc/Admin.html deleted file mode 100644 index dcb898daaf1a5b6cc8ddd483a14b3d43c43fb625..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/Admin.html +++ /dev/null @@ -1,337 +0,0 @@ - - - - - - - Administration Guide - - - -

Administration Guide

- -

The target audience for this guide is the JOnAS server administrator.

- -

JOnAS provides the following two tools for performing some administration -tasks on a running JOnAS Server:

- -

These tools also allow administration of several JOnAS Servers. Each JOnAS -Server is identified by a name, which is the value of the -n -option used in the jonas start command (the default name is -jonas).

- - - -Begining with JOnAS 4, we also provide the -J2EE Management EJB component (MEJB), as specified by the -J2EE Management Specification which defines the J2EE Management Model. - -

jonas admin

- -

jonas admin is described in the JOnAS -Commands chapter.

- -

JonasAdmin

- -

This chapter provides information about installing, configuring, and using -the JonasAdmin administration console.

- -

JonasAdmin is the new administration tool for JOnAS and replaces the -deprecated Jadmin tool.

- -

JonasAdmin was developed using the Struts framework; it uses -standard technologies such as Java Servlets and JavaServer Pages. JonasAdmin -is more ergonomic than Jadmin and provides integrated administration -facilities for a Tomcat server running embedded in JOnAS.

- -

Installing JonasAdmin

- -

Designed as a web application, JonasAdmin is packed in a WAR and installed -under the JONAS_ROOT/webapps/autoload/ directory. This WAR can -be installed in JONAS_BASE/webapps/autoload if a JONAS_BASE -variable has been defined in the environment. When installed in the -autoload directory, JonasAdmin is deployed when starting the -JOnAS server, thus the administration console is automatically accessible.

- -

As with any web application, JonasAdmin requires a servlet server to be -installed. Additionally, the JOnAS server running JonasAdmin must have the -web container service present in the list of services defined in the -jonas.properties configuration file.

- -

When accessing JonasAdmin, the administrator must provide identification -and authentication.
-The jonas-realm.xml configuration file contains a memory realm -definition named memrlm_1, which is referenced in both -server.xml (for Tomcat) and jetty.xml (for Jetty) configuration files. The -default user name (jonas) and -password (jonas) corresponding to the admin -role can be modified here.
-

- -

Using JonasAdmin

- -

Once started, JonasAdmin can administer the JOnAS server in which it is -running, as well as other JOnAS servers with which it shares the same -registry. Typically, this is used to administer JOnAS servers running without -the WEB container service.
-Note that the administered JOnAS servers can be running on the same host or -on different hosts. Also, if Tomcat is used as the WEB container service -implementation, it can be administered using JonasAdmin.

- -

Running JonasAdmin

- -

Ensure that the web service is listed in the -jonas.services property in the jonas.properties -configuration file. If you are not using a jonas-tomcat or jonas-jetty -package, depending on the Servlet container being used, the -CATALINA_HOME or the JETTY_HOME environment -variable must have been previously set. Note that when running the Servlet -container on top of Unix, the DISPLAY environment variable must -be set in order to use the JOnAS server monitoring feature of JonasAdmin.

- -

Once JOnAS is launched, JonasAdmin must be loaded if it was not installed -in the autoload directory. The administration console is -accessible at the URL: -http://<hostname>:<portnumber>/jonasAdmin/ -using any web browser.

- -

<hostname> is the name of the host where the Servlet -container is running and <portnumber> is the http port number -(default is 9000).

- -

After logging in, the left-hand frame in the Welcome page displays the -management tree associated with the JOnAS server running JonasAdmin. -Starting with JOnAS 4.6, the management tree's root is Domain, which -corresponds to the new domain management facilities. -

-

In the image below, JonasAdmin is running on the master server named jonas -within a domain also named jonas. It is immediately apparent that this is a -master server, as we have a Deployment sub-tree under the Domain -root node. -

- -
-JonasAdmin -
- -

The management tree in this figure allows access to the following main -management facilities:

-
    -
  • Domain administration with domain level deployment facilities.
    • -
  • Current server administration
    • -
      -
    • Server monitoring
      • -
    • Logging management
      • -
    • Communication protocols management
      • -
    • Active services presentation and configuration
      • -
    • Dynamic deployment at the current server level
      • -
    • Resources management
      • -
    • Security management
      • -
    -
  • Joram platform administration
    • -
  • MBeans browsing
    • -
- -

Server management

- -

Displays general information about the administered JOnAS server, -including the JMX server and the WEB server, and provides the capability of -listing the content of the Registry.

- -
Server monitoring
- -

Presents memory usage, a count of the threads created by JOnAS, and other -monitoring information concerning managed services and resources.

- -
Logging management
- -

Allows the administrator to configure the JOnAS Logging system. -Additionally, if Tomcat is used as the WEB container service implementation, -it allows creation of new access log valves.

- -
Communication protocols management
- -

This management facility relates to the integration of Tomcat management -in JonasAdmin.
-It currently presents connectors defined in the Tomcat configuration and -allows for the creation of new HTTP, HTTPS, or AJP connectors.
-Note that the Protocols sub-tree is not presented if Jetty is -used as the WEB container service implementation.

- -
Active services presentation and configuration
- -

All the active services have a corresponding sub-tree in the -Services tree.

- -

Managing the various container services consists of presenting information -about the components deployed in these containers. New components can be -deployed using the dynamic deployment facilities presented in the next -section.

-

-Creation of a new context for WEB components to be deployed in the Tomcat server -is deprecated since JOnAS 4.6 (the New web application button is -removed). -

- -

Similarly, the services that allow management of the different types of -resources (DataSources, Resource Adapters, Jms and Mail resources) also -provide information about the resources being deployed. Additionally, -deployed resources (DataSources or MailFactories) can be reconfigured and -their new configuration made persistent by using a Save -button.

- -

The transaction service management allows reconfiguration (possibly -persistent) and presents monitoring information about transactions managed by -JOnAS.

- -
Dynamic deployment with JonasAdmin
- -

A very useful management operation is the capability of loading -stand-alone J2EE components (JAR, WAR, RAR packages) or J2EE applications -(EAR packages) in the administered server using the Deployment -sub-tree. -

-

-The administrator's task is facilitated by the display of the list of -deployable modules, the list of deployed modules, and the capability of -transferring modules from one list to another (which corresponds to -deploy/undeploy operations. -

-

-The deployable modules are files installed in directories specific to their type. For example, the -deployable JARs are un-deployed JARs installed in -JONAS_BASE/ejbjars/ or in a -JONAS_BASE/ejbjars/autoload/ directory. -

-

-The Deployment sub-tree also allows a J2EE package to be uploaded from -the local file system to the corresponding directory of the administered server -(install operation), and the opposite remove operation. -

- -
Resources management
-The Resources sub-tree provides the capability of loading or -creating new resources managed by the active services. For example, if the -JMS service is running, the JMS sub-tree in Resources presents -the existing JMS destinations (Topics and Queues), and allows the removal of -unused destinations and the creation of new JMS destinations.
-Adding or removing resources implies reconfiguration of the corresponding -service. If this new configuration is saved using the Save -button, the JOnAS configuration file is updated. As in the JMS service -example, the removed topics are deleted from the list assigned to the -jonas.service.jms.topics property and the newly created topics -are added to this list. - -
Security management
-The Security sub-tree presents existing security realms and -allows the creation of new realms of different types: memory, datasource, and -ldap realms. - -

Domain management

-

-First recall that domain management functions are accessible only when JonasAdmin -is deployed on a master server. The Domain tree contains only one -Server sub-tree, the currently administered server, which is initially -the server hosting JonasAdmin.

-

-Domain management principal function is to present the domain topology: list all the servers and clusters -belonging to the domain. It also allows modification of the domain topology by adding new servers and clusters -to the domain, removing servers and moving servers to/from clusters.

-

-In JOnAS 4.6 there is no cluster support, and the domain topology cannot be modified. The servers presented as belonging -to the domain are those that have been started with their discovery service enabled.

-

-In JOnAS 4.7, domain management page also presents servers that are not yet started but are specified as -belonging to the domain in the new configuration file named domain.xml. -Also, a server can be added to the domain when it has been started without having the discovery service enabled. -

-

-An essential domain management function is that the administrator can switch from the master to any of the -other servers in the domain. Currently, JonasAdmin allows only one category of global domain level management -operation, the deployment operation. Using any other management operation requires switching -to the server to be administered.

- -

Domain level deployment allows for deploying one or more J2EE packages (JARs, WARs, RARs or EARs), which -are installed in the corresponding master directory (ejbjars, webaps, rars or apps), into any running server in the domain. -A deployment operation target may be a server but also a cluster. In this case, the deployment -operation addresses all the running servers in the cluster, including servers in the embedded clusters, if any. -
-The deploy operation may have three semantics: -

    -
  • deploy only (create container) - which is useful when the package is already installed -on the target server.
    • -
  • distribute only - which means install the package in the target's corresponding directory
    • -
  • distribute and (re)deploy the package, with optionally replacing the current package -with the new one.
    • -
-Note that at domain level deployment the Upload and Remove operations -are only related to the master server itself. -

- -

Cluster and Domain management in JOnAS 4.8

- -

Note regarding persistent reconfiguration facilities

-It is important to note that JOnAS and Tomcat have different approaches to -reconfiguration persistency. In JOnAS, every Save operation is -related to a service or a resource reconfiguration. For example, the -administrator can reconfigure a service and a resource, but choose to save -only the new resource configuration.
-In Tomcat, the Save operation is global to all configuration -changes that have been performed. For example, if a new HTTP connector is -reconfigured and a new context created for a web application, both -configuration changes are saved when using the Save -button. - - -

Management EJB Component

-

-The MEJB component exposes the managed objects within the JOnAS -platform as JMX manageable resources. It is packed in an ejb-jar -file installed in the $JONAS_ROOT/ejbjars/autoload directory, -and therefor it is loaded at server start-up.

-

-The MEJB component is registered under the name -java:comp/env/ejb/MEJB.

-

-The current implementation allows access only to the manageable -resources within the current server (the server containing the -MEJB's container).

-

-The JOnAS distribution was enriched with a new example called -j2eemanagement, which shows how the MEJB can be used. -You can find details about this management application in -$JONAS_ROOT/j2eemanagement/README file.

- - - diff --git a/jonas_doc/olddoc/Cmi.html b/jonas_doc/olddoc/Cmi.html deleted file mode 100755 index 771460e755c2a0be41d013824a245b4986e5c289..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/Cmi.html +++ /dev/null @@ -1,499 +0,0 @@ - - - - - - - CMI Cluster Method Invocation - - - - -

CMI (Clustered Method Invocation)

- -

Introduction

- -

CMI is the protocol cluster for JOnAS ensuring:

-
    -
  • the jndi high availability through the registry replication and the - multi-target lookup
    • -
  • the load-balancing and fail-over at the EJB level (RMI flow) through - the CMI cluster stub -
      -
    • for the Home interface of the EJB's SSB, SFSB, EB
      • -
    • for the Remote interface of the EJB's SSB
      • -
    -
    • -
  • the SFSB high availability with the JOnAS HA service
    • -
- -

CMI architecture

- -

Getting started with the CMI Protocol

- -

CMI can be enabled in JOnAS by:

-
    -
  • setting the cmi protocol in the $JONAS_BASE/conf/carol.properties - file
    • -
  • compiling an application with the CMI protocol
    • -
- -

Clustered objects and CMI Registry

- -

CMI brings its own registry for implementing the jndi replication. Each -CMI registry instance over the cluster contains two areas:

-
    -
  • a local area for hosting the local objects that must not be - replicated
    • -
  • a distributed area hosting the global objects (cluster objects) that - must be replicated
    • -
- -

When an object is registered in the registry, the routing to the local or -global area is done according to:

-
    -
  • the type of the object: only the remote objects are replicated
    • -
  • the presence of the 'CMI class' having the same name as the object - class with the suffix '_CMI' and inherited from the - org.objectweb.carol.cmi.Distributor class
    • -
  • one of the two following methods returning true: -
      -
    • equivAtBind() if the replication has to take place at the bind() - time. For example, this could be the case for the EJB Remote Home - objects.
      • -
    • equivAtExport() if the replication has to take place at the - export() time. Typically, this could be the case for the SSB Remote - objects.
      • -
    -
    • -
- -

The entries of the distributed area are lists providing the ability, for -example, to gather several stubs for the the same jndi-name and thus to -return a stubs list.

- -

JNDI HA

- -

Registry Replication

- -

CMI relies on JGroups group-communication protocol for ensuring the global -registry replication. The parameters are gathered in the:

-
    -
  • $JONAS_BASE/conf/carol.properties for specifying the JGroups - configuration file name and the JGroups group name.
    • -
  • $JONAS_BASE/conf/jgroups-cmi.xml file for the settings of the jgroups - protocol stack. By default, the JGroups configuration uses the UDP - protocol and the multicast IP for broadcasting the registry updates. A - TCP-based stack can be used in a network environment that does not allow - the use of multicast IP or when a cluster is distributed over a WAN.
    • -
- -

CMI registry

- -

All the members of a cluster share the same JGroups configuration.

- -

If several cluster partitions are required over a single LAN, several -JGroups configurations must be configured with different values for the -following parameters:

-
    -
  • JGroups group name
    • -
  • JGroups multicast address
    • -
  • JGroups multicast port
    • -
- -

When a new node appears in the cluster, its registry content is -synchronized automatically.

- -

When a node disappears, JGroups notifies the other's member of the node -leaving and the registry entries related to this node are removed.

- -

Registry Fail-over

- -

On the client side, the high availability of the registry is provided by -the capability to set several JOnAS instances in the registry url. At the -lookup time, the client chooses (round-robin algorithm) one of the available -servers to get the home stub. If the server fails, the request is sent to -another server. The CMI url registry is specified in the -$JONAS_BASE/conf/carol.properties file using the following syntax:

-
carol.cmi.url=cmi://server1:port1[,server2:port2...]
- -

CMI Cluster Stub or Cluster-aware Stub

- -

Load-balancing and fail-over on the client side are provided through -cluster-aware stubs. These stubs are generated on the fly through ASM and -rely on:

-
    -
  • the RMI/JRMP protocol for communicating with the server side,
    • -
  • the CMI class associated with the EJB for the load-balancing and - fail-over logic.
    • -
- -

CMI cluster stub

- -

Cluster Map on the Client Side

- -

The CMI cluster stub handles a cluster map on the client side. The CMI -cluster stub is created:

-
    -
  • at lookup time for the SSB, SFSB, EB Home objects if the retrieved - object is replicated and located in the global registry
    • -
  • at create time for the SSB Remote objects if the retrieved object is - replicated and located in the global registry
    • -
- -

In these two cases, the call gets a stubs list from the global registry -and the CMI cluster stub updates the local cluster map. Afterwards, the local -cluster map can be updated dynamically during the invocation of the business methods calls (through the HA interceptors) when a new view is detected in -the cluster.

- -

If a communication error with a server occurs during a remote call -invocation, the server is removed from the cluster map.

- -

CMI Class

- -

CMI classes are generated by GenIC when compiling with the protocol CMI. -They are built from the velocity templates located in -$JONAS_ROOT/templates/genic directory. By default the templates used are:

-
    -
  • ClusterHomeDistributor.vm for the home interface of the SSB, SFSB, - EB
    • -
  • ClusterRemoteSLSBDistributor.vm for the remote interface of the SSB
    • -
- -

The templates inherit the org.objectweb.carol.cmi.Distributor class and -contain the following methods:

-
    -
  • choose(method, params): this method is called by the CMI cluster stub - at each remote method call to choose the next stub to use for invoking - the call. By default, this method implements the weighted round-robin - algorithm with a local preference, i.e., if there is a collocated server, - it will be selected in priority. The servers factors are set for each - JOnAS instance in the $JONAS_BASE/conf/carol.properties file.Below is - given the code of the choose() method implementing a simple RR algorithm : - 
    -    public StubData choose(Method method, Object[] parameters) throws NoServerException {
-
-        Set stubs = getCurrentState();
-        if (lastSet != stubs) {
-            lastSet = stubs;
-            rr.update(stubs);
-        }
-
-        return rr.get();
-    }
-
    -
    • -
  • onException(method, params, stub, exception): this method is called by - the CMI cluster stub when an exception occurs and returns a decision of - RETRY, RETURN, or THROW for indicating the behavior to the CMI smart - stub. By default, this method returns a RETRY decision if the exception - is related to a network error, and otherwise it returns a THROW - decision. Below is given the code of the mustFailover() method that - is used by default for analysing the exception and deciding if the fail-over - must occur : - 
    -     protected static boolean mustFailover(Exception ex) {
-        if (ex instanceof UnmarshalException) {
-            Throwable cause = ((UnmarshalException) ex).getCause();
-            if (( cause instanceof EOFException) ||
-                    (cause instanceof SocketException)) {
-                return true;
-            }
-        }
-
-        if ((ex instanceof ConnectException) ||
-                (ex instanceof ConnectIOException) ||
-                (ex instanceof NoSuchObjectException)) {
-              return true;
-        }
-       return false;
-     }
-
    - -
    • -
  • onReturn(method, params, stub, returnValue): this method is called by - the CMI cluster stub after having invoked the call and before returning - to the application. This call back enables implementation of a - post-processing on the return value. By default, this method does nothing. -

    -
    • -
- -

Customizing the Load-balancing and Fail-over Logic

- -

The user has the ability to customize the load-balancing and fail-over -logic for each EJB by specifying the velocity template to use in the JOnAS- -specific descriptor on deployment of the ejb-jar file. The XML elements -are:

-
<cluster-home-distributor>MyHomeDistributor.vm</cluster-home-distributor>
-
<cluster-remote-distributor>MyRemoteDistributor.vm</cluster-remote-distributor>
- -

If not set, the default velocity templates are used.

- -

If set with the value 'disabled', the CMI classes are not generated and -the EJB will not be distributed.

- -

If set with a file name, this file must be located in the -$JONAS_ROOT/templates/genic directory.

- -

The 'cluster-home-distributor' element is valid for the SSB, SFSB and -EB.

- -

The 'cluster-remote-distributor' element is valid for the SSB.

- -

High Availability with Horizontal Replication

- -

Stateful session beans (SFSBs) can be replicated since JOnAS 4.7 in order -to provide high availability in the case of failures in clustered environments. -A new service called High Availability (HA) has been included in JOnAS to -provide replication mechanishms. JOnAS HA also requires the cluster -method invocation (CMI) protocol.

- -

Compared to JOnAS 4.7, JOnAS 4.8 implements a new replication algorithm -based on a horizontal replication approach. The algorithm improves the -algorithm implemented for JOnAS 4.7 with the following enhancements:

- -
  • Replication of SFSBs with references to EBs: The algorithm can replicate -SFSBs that reference EB by means of both, local or remote interfaces.
    • -
  • Transaction awareness: The algorithm is transaction aware, meaning that -the state is not replicated if the transaction aborts.
    • -
  • Exactly-once semantics: Each transaction is committed exactly once at -the DB if the client does not fail. If the client fails, each transaction -is committed at most once at the DB
    • - -

    EJB replication Description

    - -

    Update-everywhere mode

    - -

    JOnAS implements an update-everywhere replication protocol according to -the database replication terminology (See the J. Gray et al.'s paper ''The -dangers of replication and a solution'' in proceedings of the ACM SIGMOD 96's -conference, Canada). In this protocol, a client can connect to any server. -When the client calls the create() method on the SFSB's Home interface, the -server the client connects to is selected following a round-robin scheme. All -the requests from the client to the SFSB will be processed by this server -until the client calls the remove() method on the remote interface. The rest -of the servers will act as backups for that client. Before sending the -response to the client, the SFSB's state is sent to the backups.

    - -

    If the server fails, another server among the backups will be selected to -serve the client requests, first restoring the current state of the SFSBs -from the state information stored in the HA local service. From this point -on, this server will receive the new client requests.

    - -

    The supported replication scenarios are shown in the following figure:

    - -
    -

    Replication scenarios in JOnAS 4.8

    -
    - -

    Transaction aware fail-over

    - -

    The horizontal approach aims to guarantee that the transactions are kept -consistent when a fail-over occurs. They are either aborted or restored -for ensuring the exactly-once semantics. During a fail-over, the new primary -uses a special table in the database for storing the transaction identifier -and enabling to find out if the transaction was committed or not. -

      -
    • If the transaction is aborted due to the primary failure, then the new primary will - not find the transaction identifier in the special table. The request will be replayed.
      • -
    • If the transaction is committed, then the new primary will find the transaction identifier, - which means that the transaction was committed. The request won't be replayed; the replicated - result is returned. -
      • -
    -Beyond the SFSB replication, the algorithm enables the building of applications -(stateful or stateless) with a high level of reliability and integrity. -

    - -

    Configuring JOnAS for EJB Replication

    - -

    The High Availability (HA) service is required in JOnAS in order to -replicate SFSBs. The HA service must be included in the list of available -services in JOnAS. This is done in the jonas.properties file placed in -$JONAS_BASE/conf.

    -
    ...
-jonas.services registry,jmx,jtm,db,dbm,security,resource,ejb,ws,web,ear,ha
-...
    - -

    The HA service must also be configured in the jonas.properties file:

    -
    ...
-jonas.service.ha.class org.objectweb.jonas.ha.HaServiceImpl
-jonas.service.ha.gcl jgroups
-...
-
    - -

    The HA service uses JGroups as a group communication layer (GCL). JGroups -behavior is specified by means of a stack of properties configured through an -XML file (See JGroups documentation for more -information: http://www.jgroups.org). The default configuration of the HA -service uses the $JONAS_BASE/conf/jgroups-ha.xml file and the sfsb-rep group name. The HA -service can be told to use a particular stack configuration or a particular group name by modifying the following -lines in jonas.properties:

    -
    ...
-jonas.service.ha.jgroups.conf jgroups-ha.xml
-jonas.service.ha.jgroups.groupname jonas-rep
-...
    -Finally, the CMI protocol must be specified in the carol.properties file in -$JONAS_BASE/conf: -
    ...
-carol.protocols=cmi...
-...
    - -

    Transaction Table Configuration

    -

    The new horizontal replication algorithm uses a database table -to keep track of current running transactions. This table is accessed from the new -elected node during fail-over to detect whether or not the current transaction committed at -the former local node, ensuring exactly-once semantics. -The table contains only one column: the transaction identifier (txid).

    -

    In JOnAS 4.8 this table must be created manually with the following SQL command:

    -
    create TABLE ha_transactions (txid varchar(60));
    -

    This table should be located preferably in the database used by the replicated -application, but it is not mandatory. If the table is not created in the database -used by the replicated application, it is necessary to configure a new datasource -for the database that contains this transaction table. This datasource must be -configured to use the serializable transaction isolation level.

    - -

    The database that holds the transaction table is accessed by the replication service with -the JNDI name configured in jonas.properties.

    -
    ...
-jonas.service.ha.datasource tx_table_ds
-...
    - -

    Configuring Garbage Collection

    -Due to the fact that the replication algorithm stores information associated with -clients' transactions and that the server is not notified when a client dies, -the HA service might have been storing unnecessary replication information over -time. In order to automatically clean this unnecessary replication information, -the HA service includes a garbage collection mechanism. It is possible -to configure the number of seconds the system waits to execute this mechanism -by changing the following property in the jonas.properties file: -
    ...
-jonas.service.ha.timeout 600
-...
    - -

    Configuring an Application for Replication

    - -

    jonas-ejb-jar.xml

    - -

    In order to configure an application for replication, the <cluster-replicated/> element must be added to the bean definition of every -bean requiring high availability in the jonas-ejb-jar.xml deployment -descriptor file. This element can have two possible -values: true or false (default value). In addition, if the programmer wants -to change the behavior of the CMI stubs (e.g., the server selection policy), -it is possible to specify different distributor implementations by means of -<cluster-home-distributor/> and <cluster-remote-distributor/> -elements. In this case, the value corresponds to the .vm file that implements -the distributor in its home and remote parts respectively. If the -<cluster-replicated/> element is present without the -<cluster-*-distributor/> elements, the default values are used -(ClusterHomeSFSBRepDistributor.vm and ClusterRemoteSFSBRepDistributor.vm).

    - -

    The following is an example description for a replicated SFSB in -jonas-ejb-jar.xml file:

    -
    ...
-<jonas-session>
-   <ejb-name>DummySFSB</ejb-name>
-   <jndi-name>DummySFSB</jndi-name>
-   ...
-   <cluster-replicated>true</cluster-replicated>
-   <cluster-home-distributor>Dummy_HomeDistributor.vm</cluster-home-distributor>
-   <cluster-remote-distributor>Dummy_RemoteDistributor.vm</cluster-remote-distributor>
-</jonas-session>
-...
    - -

    The <cluster-replicated/> element can also be set in the SSB or EB for -

      -
    • enabling the transaction checking mechanism ensuring the exactly-once semantic at - fail-over
      • -
    • supporting the EB references replication
      • -
    -

    - -

    Note: When set in the SSB, the mechanism inhibits the load-balancing at the remote -interface. After the home create() method call, all the requests are sent to the same -instance.

    - -

    Entity Beans lock policy

    - -

    The lock policy for the Entity Beans in a replicated application must be configured -as database in the jonas-ejb-jar.xml deployment descriptor file.

    -

    The following is an example description for a replicated EB in the jonas-ejb-jar.xml:

    -
    ...
-<jonas-entity>
-    <ejb-name>MyEntitySLR</ejb-name>
-    <jndi-name>MyEntityHome</jndi-name>
-    <cluster-replicated>true</cluster-replicated>
-    <shared>true</shared>
-    <jdbc-mapping>
-        <jndi-name>example_ds</jndi-name>
-    </jdbc-mapping>
-    <lock-policy>database</lock-policy>
-</jonas-entity>
-...
    - -

    Datasource used by the application

    - -

    The datasources used by replicated applications must be configured to use the -serializable transaction isolation level.

    -

    The following is an example for a datasource configuration file for the Postgres DBMS:

    -
    ...
-datasource.name         example_ds
-datasource.url          jdbc:postgresql://xxx.xxx.xxx.xxx:xxxx/database
-datasource.classname    org.postgresql.Driver
-datasource.username     jonas
-datasource.password
-datasource.mapper       rdb.postgres
-datasource.isolationlevel       serializable
-...
    - -

    Finally, when compiling the application that includes the replicated -beans, the CMI protocol must be specified in order to generate the classes -that include the replication logic.

    - -

    Status and Management Information in Admin. Console for the HA Service's Replication Algorithm

    - -The JOnAS administration console offers several items of information about the HA -service's replication algorithm and allows the configuring of several parameters -related to its behaviour. The related information and parameters include: - -
      -
    • The name of the service.
      • -
    • The binded name for the MBean. The name can be changed.
      • -
    • The number of replicated messages sent by the algorithm to the cluster's - replicas.
      • -
    • The average size of the replicated messages sent.
      • -
    • The total size of the replicated messages sent.
      • -
    • The current JGroups configuration file name used.
      • -
    • The current timeout established to clean in memory information related - to SFSBs required by the algorithm. When this timeout expires, the - information is garbage-collected. This avoids increasing the memory used - by the algorithm. The administrator can set a different - timeout if required.
      • -
    • The datasource name required by the algorithm to keep track of current - running transactions (See Transaction Table Configuration section above). - The default datasource is setted through the "jonas.service.ha.datasource" - parameter in the "jonas.properties" configuration file, but the administrator - can configure different datasources and can set here, the name of the one - that will be used by the algorithm, once JOnAS has started. -

      NOTE: It is recomended to not change the Datasource once the HA service - is running.

      • -
    - - - - diff --git a/jonas_doc/olddoc/Deployer.html b/jonas_doc/olddoc/Deployer.html deleted file mode 100644 index 7d6b8a5c144f35a44820ad84b57dc0b95303d1c0..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/Deployer.html +++ /dev/null @@ -1,237 +0,0 @@ - - - - - - Deployment and Installation Guide - - - - -

    Deployment and Installation Guide

    - -

    Target audience

    - -

    The target audience for this guide is the application deployer.

    - -

    The content of this guide is the following:

    -
      -
    1. Deployment and installation - process principles
      2. -
    2. Example of deploying and installing - an EJB using an ejb-jar file
      3. -
    3. Deploying and installing a Web - application
      4. -
    4. Deploying and installing a J2EE - application
      5. -
    - -

    Deployment and installation -process principles

    - -

    - -

    The deployment and installation of Enterprise Beans

    - -

    This guide assumes that the Enterprise Bean provider followed the -Enterprise Beans Programmer's Guide and packaged the beans's classes together -with the deployment descriptors in a ejb-jar file. To deploy un-packed -Enterprise Beans, refer to Configuring EJB -Container service.
    -

    - -

    To deploy the Enterprise Beans in JOnAS, the deployer must add the -interposition classes interfacing the EJB components with the services -provided by the JOnAS application server.
    -The GenIC tool supplied in the JOnAS -distribution provides the capability of generating interposition classes and -updating the ejb-jar file.
    -The application deployer may also need to customize the deployment -descriptors in order to adapt it to a specific operational environment. This -must be done before using GenIC.

    - -

    The deployer may choose to deploy the Enterprise Beans as stand-alone -application components, in which case the ejb-jar must be installed in the -$JONAS_ROOT/ejbjars directory. The deployer may also choose to -include them in war or ear packaging, which is presented in the following -sections.

    - -

    The deployment and installation of Web and J2EE applications

    -Once the packaging of the application components has been completed as -described in the WAR Packaging or EAR Packaging guides, the obtained archive file must be -installed in the: -
      -
    • $JONAS_ROOT/webapps directory, for war files
      • -
    • $JONAS_ROOT/apps directory, for ear files
      • -
    - -

    Example of deploying and installing -an EJB using an ejb-jar file

    - -

    For this example, it is assumed that a user wants to customize the -deployment of the AccountImpl bean in the JOnAS example -examples/src/eb by
    -changing the name of the database table used for the persistence of the -AccountImpl.

    - -

    The current directory is $JONAS_ROOT/examples/src/eb. The -user will do the following:

    -
      -
    • Edit jonas-ejb-jar.xml and modify the value of the - <jdbc-table-name> element included in the - <jdbc-mapping> element corresponding to - AccountImpl entity.
      • -
    • Compile all the .java files present in this - directory:
      -   javac -d ../../classes Account.java - AccountImplBean.java AccountExplBean.java AccountHome.java - ClientAccount.java
      • -
    • Perform deployment -
        -
      • Build an ejbjar file named ejb-jar.jar with all the - corresponding classes and the two deployment descriptors:
        - 
        -mkdir -p ../../classes/META-INF
-cp  ejb-jar.xml  ../../classes/META-INF/ejb-jar.xml
-cp jonas-ejb-jar.xml  ../../classes/META-INF/jonas-ejb-jar.xml
-cd ../../classes
-jar cvf eb/ejb-jar.jar META-INF/ejb-jar.xml META-INF/jonas-ejb-jar.xml 
-  eb/Account.class  eb/AccountExplBean.class  eb/AccountHome.class   eb/AccountImplBean.class
-
        -
        • -
      • From the source directory, run the GenIC generation tool - that will generate the final ejb-jar.jar file with the - interposition classes: - 
        GenIC -d ../../classes  ejb-jar.jar
        • -
      -
      • -
    • Install the ejb-jar in the $JONAS_ROOT/ejbjars - directory: - 
      cp ../../classes/eb/ejb-jar.jar $JONAS_ROOT/ejbjars/ejb-jar.jar
      • -
    -The JOnAS application Server can now be launched using the command:
    -  jonas start - -

    The steps just described for building the new ejb-jar.jar -file explain the deployment process. It is generally implemented by an ANT -build script.

    - -

    If Apache ANT is installed on your machine, type ant -install in the $JONAS_ROOT/examples/src directory to build -and install all ejb-jar.jar files for the examples.
    -To write a build.xml file for ANT, use the ejbjar -task, which is one of the optional EJB tasks defined -in ANT. The ejbjar task contains a nested element called -jonas, which implements the deployment process described above -(interposition classes generation and EJB-JAR file update).
    -Generally, the latest version of the EJB task containing an updated -implementation of the jonas nested element is provided with -JOnAS, in $JONAS_ROOT/lib/common/ow_jonas_ant.jar. Click here -for the documentation corresponding -to this new version of the jonas nested element.
    -As an example, this code snippet is taken from the -$JONAS_ROOT/examples/src/alarm/build.xml:
    -

    - <!-- ejbjar task  -->
- <taskdef name="ejbjar"
-    classname="org.objectweb.jonas.ant.EjbJar"
-    classpath="${jonas.root}/lib/common/ow_jonas_ant.jar" />
-
-  <!-- Deploying ejbjars via ejbjar task  -->
-  <target name="jonasejbjar"
-	  description="Build and deploy the ejb-jar file"
-	  depends="compile" >
-    <ejbjar basejarname="alarm"
-	    srcdir="${classes.dir}"
-	    descriptordir="${src.dir}/beans/org/objectweb/alarm/beans"
-            dependency="full">
-      <include name="**/alarm.xml"/>
-      <support dir="${classes.dir}">
-	<include name="**/ViewProxy.class"/>
-      </support>
-      <jonas destdir="${dist.ejbjars.dir}"
-             jonasroot="${jonas.root}"
-             protocols="${protocols.names}" />
-    </ejbjar>
-  </target>
-
    -

    - -

    Deploying and installing a Web -application

    - -

    Before deploying a web application in the JOnAS application server, first -package its components in a war file as explained in the WAR packaging guide.
    -For Apache ANT, refer to the target war in the -$JONAS_ROOT/examples/earsample/build.xml file.

    - -

    Next, install the war file into the -$JONAS_ROOT/webapps directory.
    -Note: Be aware that the war file must not be installed in the -$CATALINA_HOME/webapps directory.

    - -

    Then, check the configuration: before running the web application; -check that the web service is present in the -jonas.services property. The ejb service may also be -needed if the Web application uses enterprise beans.
    -The name of the war file can be added in the -jonas.service.web.descriptors section.

    - -

    Finally, run the application Server:
    -  jonas start

    - -

    The web components are deployed in a web container created during the -startup. If the war file was not added in the -jonas.service.web.descriptors list, the web components can be -dynamically deployed using the jonas admin command or -JonasAdmin tool.

    - -

    Deploying and installing a J2EE -application

    - -

    Before deploying a J2EE application in the JOnAS application server, first -package its components in an ear file as explained in the EAR packaging -guide.
    -For Apache ANT, refer to the target ear in the -$JONAS_ROOT/examples/earsample/build.xml file.

    - -

    Next, install the ear file into the $JONAS_ROOT/apps -directory.

    - -

    Then, check the configuration: before running the application, -check that the ejb, web and ear services are -present in the jonas.services property.
    -The name of the ear file can be added in the -jonas.service.ear.descriptors section.

    - -

    Finally, run the application Server:
    -  jonas start

    - -

    The application components are deployed in EJB and web containers created -during the startup. If the ear file was not added in the -jonas.service.ear.descriptors list, the application components -can be dynamically deployed using the jonas admin command or -JonasAdmin tool.

    - - diff --git a/jonas_doc/olddoc/Domain.html b/jonas_doc/olddoc/Domain.html deleted file mode 100644 index 8f94f208cc31a2c90f7f0fbc640457055ea2841a..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/Domain.html +++ /dev/null @@ -1,365 +0,0 @@ - - - - - - - Domain Management in JOnAS - - - - -

    Domain and Cluster Management in JOnAS

    - -

    The content of this guide is the following:

    -
      -
    1. Target Audience and Rationale
      2. -
    2. Domain and Cluster Management Functions
      3. -
    3. Mechanisms used by Domain Management
      4. -
    4. J2EEDomain MBean
      5. -
    5. MBeans for domain/cluster monitoring
      6. -
    6. How to start Servers in a Domain
      7. -
    7. How to define domain configuration using domain.xml file
      8. -
    - -

    Target Audience and Rationale

    -

    This guide is intended for JOnAS administrators responsible for the configuration - and administration of JOnAS servers running within a management domain. -

    - -

    Domain and Cluster Management Functions

    -

    A JOnAS management domain is composed of a set of JOnAS servers that are running under the same - management authority. All the servers in the domain must have a distinct server name and - a common domain name. -

    -

    The servers in a domain can be administered by a management application running on a server - playing the role of administrator or master. The managed servers play the role of slaves. - Note that it is possible to have several masters in a domain. Also note that default configuration - corresponds to a slave server running without the discovery service (the role of this service is - described below and its configuration here). -

    -

    - Typically, when deploying the JonasAdmin application on a slave, the administrator can manage only - the server on which the application is running. When deploying JonasAdmin on a master server, - the administrator can manage all the known servers in the domain: -

      -
    • the administrator can see the state of the servers belonging to the domain;
      • -
    • can apply management operations to - one or more servers in the domain;
      • -
    • switch management from the master to any other running server - in the domain, then switch back to the master.
      • -
    • Starting with JOnAS 4.8, administration is enriched with domain and cluster monitoring features, - and remote control.
      • -
    -

    -

    - Cluster management facilities was introduced in JOnAS 4.7. - A cluster is a group of servers having common properties within a domain. A cluster may be the target of a - domain level management operation - currently applications and J2EE modules deployment only. -

    -

    - The domain topology (servers and clusters composing the domain) can be defined using a new domain.xml - configuration file. Also, servers and clusters may be dynamically added and removed to the domain via JonasAdmin. -

    -

    - Starting with JOnAS 4.8, domain and cluster management is enhanced with monitoring functions available in - JonasAdmin. As in the previous version, clusters may be created by an administrator in a static (via domain.xml) - or dynamic (via JonasAdmin) way. These clusters are now called logical cluster. A new class of clusters - is supported in the current version, the physical clusters that are detected automatically by the management - infrastructure. Several types of physical clusters are supported: Mod JK clusters, Tomcat clusters, CMI clusters, etc. - All the members of a type of physical cluster share specific properties which depend on the cluster type, e.g., all - the members of a CMI cluster have the same JGroups configuration. Note that a given JOnAS instance may belong to - several physical and logical clusters. -

    -

    - An important domain level administration operation introduced in JOnAS 4.8, is the possiblity to start/stop - the managed servers via a so called cluster daemon. - Cluster daemons can be defined and associated - to servers using the domain.xml configuration file. A cluster daemon has to be collocalized (located on the same - machine) with the servers it controls. -

    - -

    Mechanisms used by Domain Management

    -

    Basically, domain management in JOnAS relies on JSR 160 specification. When a JOnAS server is started, - it creates at least one JSR 160 connector server as explained in - JSR 160 support in JOnAS. -

    -

    - A connector server makes it possible for a JMX remote API client to access and manage the MBeans exposed - through the MBean server running in a remote JVM. In order to establish a connection, the remote client - needs to know the address of the connector server. JSR 160 does not provide any specific API that would - make it possible for a client to find the address of a connector server. The standard suggests using - existing discovery and lookup infrastructures, for instance, JNDI API with an LDAP back end. -

    -

    - A new service added to JOnAS, the Discovery Service, allows JOnAS servers running over - a LAN within the same management domain to communicate to each other the connector-server addresses they create - at start-up. All the servers in the domain having the discovery service in the services list, will - publish their connector-server address at start-up. The goal is to allow master servers to - discover which servers are running in their domain, and to establish connections allowing them to remotely - manage the slave servers by a management application deployed on a master server. -

    -

    - Starting with JOnAS 4.7, a server can be added to a domain via a management operation, thus allowing servers which - cannot use the multicast-based discovery service to join a management domain. -

    -

    - The current discovery service implementation is based on MBeans (called discovery MBeans) which use: -

      -
    • IP Multicast protocol to communicate their connector-server addresses and state transitions to each other.
      • -
    • JMX notifications to update domain management information within a master server.
      • -
    -

    -

    J2EEDomain MBean

    - Domain management information can be retrieved from J2EEDomain MBean. -

    - The J2EEDomain MBean has the following JMX ObjectName: - 

    -  domainName:j2eeType=J2EEDomain,name=domainName
-
    - Where domainName is the name of the domain. -

    -

    - A J2EEDomain MBean contains several management attributes and operations related to servers management - in a domain: -

      -
    • If the J2EEDomain is registered in a master server's MBean server, the servers - attribute keeps the list of the servers known in the domain. Otherwise, it contains only one element corresponding to itself. - The elements in the servers list are Strings representing J2EEServer ObjectNames - associated to the running servers. By iterating over the servers - list, a management application can determine the name of the servers in the domain. -
      • -
    • The getConnectorServerURLs operation returns the connector server addresses for a server in the list. - In order to administer a given server in the domain, any management application has to create an - MBeanServerConnection object using one of the connector-server addresses corresponding to that server - (see the j2eemanagement sample). -
      • -
    -

    -

    -

    -

    - Starting with JOnAS 4.7, the J2EEDomain MBean was enriched in order to support adding/removing a server to/from the domain, - creating a cluster in the domain, listing the clusters in a domain. -

    -

    - The following is a list of some of the new management attributes and operations exposed by a J2EEDomain MBean: -

      -
    • addServer(String serverName, String[] connectorServerURLs)
      • -
    • getServerState(serverName)
      • -
    • createCluster(String clusterName)
      • -
    • clusters attribute gives the String representation of the J2EEDomain ObjectNames - associated to the clusters created in this domain - (or in this cluster if the current J2EEDomain MBean is associated to a cluster).
      • -
    -

    -

    - In JOnAS 4.7, clusters are implemented as "sub-domains", they have associated J2EEDomain - type MBeans. For example, if a cluster named clust is created in the domain named - domainName, it has an associated MBean with the following JMX ObjectName: - 

    -  domainName:j2eeType=J2EEDomain,name=domainName,clusterName=clust,parentClusterName=domainName
-
    - -

    - -

    MBeans for domain/cluster monitoring

    -

    - An important re-engineering of domain management mechanisms was conducted in JOnAS 4.8 to support - cluster and domain monitoring. Clusters aren't implemented as sub-domains anymore; there is only - one J2EEDomain MBean registered in the master's MBean server. Another important point - is that the servers' state is no longer accessible in the J2EEDomain MBean (getServerState(serverName) - operation doesn't exist anymore). On the other hand, new MBeans were created: -

    -
      -
    • ServerProxy MBeans. For every server known in the domain, a ServerProxy MBean is created with the - following JMX ObjectName: - 
      -  domainName:type=ServerProxy,name=serverName
-
      - It contains a State attribute which gives the server state as known by the master, and - a set of monitoring information like memory usage, threads, transactions, etc. which are periodically - updated. The servers may be in one of the following states: -
        -
      • INIT - corresponds to a server that was added to the domain. This is a temporary state.
        • -
      • UNREACHABLE - corresponds to a server that was added to the domain but the master - is unable to access the managed server (the MBeanServerConnection could - not be established, or it doesn't work anymore)
        • -
      • RUNNING - corresponds to a server that is running and controlled by the master
        • -
      • STOPPED - corresponds to a server which was stopped with the jonas stop - command (if the server has enabled its discovery service), or if the server was stopped - using the remote control mechanisms (via the cluster daemon).
        • -
      • FAILED - corresponds to a particular case of UNREACHABLE state. The master decides to pass - a server in the FAILED state if it is UNREACHABLE for a while, and if it has some information - allowing to infer that the server is failed: First, the managed server had its discovery service - enabled (otherwise, the server stop can't be detected, so can't distinguish STOPPED from FAILED). - Moreover, the master can use information provided by the cluster daemon, if the - server has an associated, running, cluster daemon.
        • -
      -
      • -
    • Cluster MBeans. For every cluster created in the domain, a LogicalCluster - MBean is created with the following JMX ObjectName: - 
      -  domainName:type=LogicalCluster,name=clusterName
-
      -

      - The master may have registered other types of cluster MBeans which correspond to physical clusters. - They are automatically created by the management system if managed servers are identified as - being members of supported physical cluster types. -

      - A cluster MBean contains a State attribute and a member's list. - A cluster may be in one of the following states, - which depends on the state of its members. -
        -
      • INIT - corresponds to a cluster that was created in the domain. This is a temporary state.
        • -
      • UP - all the members are in RUNNING state
        • -
      • DOWN - all the members are STOPPED
        • -
      • FAILED - all the members are FAILED
        • -
      • PARTIALLY_FAILED - at least one member is FAILED
        • -
      • PARTIALLY_UP - at least one member is RUNNING, there is no failed member
        • -
      • PARTIALLY_DOWN- at least one member is STOPPED, there is no FAILED member, there is no RUNNING member
        • -
      -
      • -
    • ClusterMember MBeans. A member MBean's role is to make the link between a cluster MBean and - the ServerProxy MBean - corresponding to the server which belongs to that cluster. Any member MBean has a ServerProxy attribute - equal to the corresponding ServerProxy MBean OBJECT_NAME. If a server belongs to several clusters, there is a - member MBean for each cluster, and all these members have the same value for the ServerProxy attribute. - There are several types of member MBeans. They correspond to the several cluster types. The - LogicalClusterMember - MBeans are used to represent LogicalCluster members. -
      • -
    - -

    Physical clusters

    -Logical clusters are created by the administrator to facilitate management administration on a group of -servers. Physical clusters are created automatically if servers running in the domain have particular -properties which depend on the cluster type. -
      -
    • Mod_jk load balancing clusters. The members of such a cluster are workers defined in -the mod_jk configuration file workers.properties. The workers correspond to JOnAS server instances -having the web service based on Tomcat and a specific configuration (server.xml having a Connector -XML element for AJP1.3 protocol defined, as well as the Engine element having the jvmRoute attribute -set to the worker name). -

      The ObjectNames corresponding to Mod_jk clusters and Mod_jk cluster members are: - 

      -  domainName:type=JkCluster,name=clusterName
-
      - 
      -  domainName:type=JkClusterMember,name=workerName,JkCluster=clusterName
-
      - The workerName and clusterName are defined in the workers.properties configuration file. -

      -
      • -
    • Tomcat session replication clusters. The members are JOnAS-Tomcat cluster servers having -a Cluster element defined in server.xml file. The management infrastructure detects -Tomcat cluster members by looking for Tomcat Cluster MBeans in the managed server's MBean server. -

      The ObjectNames corresponding to Tomcat session replication clusters and Tomcat cluster members are: - 

      -  domainName:type=TomcatCluster,name=clusterName
-
      - 
      -  domainName:type=TomcatClusterMember,name=serverName,TomcatCluster=clusterName
-
      - The clusterName can be defined in the server.xml configuration file. -

      -
      • -
    • CMI clusters. The members are JOnAS cluster servers sharing the same CMI configuration -for the JNDI replication and the EJB clustering. -

      The ObjectNames corresponding to the CMI clusters and cluster members are: - 

      -  domainName:type=CmiCluster,name=clusterName
-
      - 
      -  domainName:type=CmiClusterMember,name=serverName,CmiCluster=clusterName
-
      - The clusterName can be defined in the carol.properties configuration file and - represents a JavaGroups group name. -

      -
      • -
    • HA clusters. The members are JOnAS cluster servers sharing the same HA service configuration -for the EJB replication. -

      The ObjectNames corresponding to the HA clusters and cluster members are: - 

      -  domainName:type=HaCluster,name=clusterName
-
      - 
      -  domainName:type=HaClusterMember,name=serverName,HaCluster=clusterName
-
      - The clusterName can be defined in the jonas.properties configuration file and - represents a JavaGroups group name. -

      -
      • -
    - -

    How to start manageable servers in a Domain

    -

    The servers must adhere to these rules:

    -
      -
    • The servers must be started on hosts connected by a LAN.
      • -
    • The servers must be configured with the discovery service activated (see - Configuring Discovery Service). -
      • -
    • There must be at least one master server in the domain. - The role of a server, slave - or master, is determined by the discovery service configuration. -
      • -
    • The servers must have different names, but the same domain name.
      • -
    -

    Also note the following:

    -
      -
    • Servers may be started in any order.
      • -
    • Servers may join or leave the domain at any time. Domain management information is updated on the master server(s).
      • -
    • A slave server may become master by invoking the startDiscoveryMaster management operation exposed by - the discovery service. This operation can be invoked using the JonasAdmin management console deployed on a master.
      • -
    -

    Example

    -

    Consider a scenario in which there are three JOnAS servers named jonas, j1 and j2. - Assume that they have discovery service configured with at least one of the servers playing the role of master. -

    -
      -
    • Start the server named jonas in domain jonas (by default, the domain name is given by the server's name) - 
      -  jonas start
-
      • -
    • Start the server named j1 in domain jonas - 
      -  jonas start -n j1 -Ddomain.name=jonas
-
      • -
    • Start the server named j2 in domain jonas - 
      -  jonas start -n j2 -Ddomain.name=jonas
-
      • -
    - -

    How to define domain configuration using domain.xml file

    -

    A default domain configuration is provided in $JONAS_ROOT/conf/domain.xml. -This configuration corresponds to a domain named jonas managed by a master -server also named jonas. The location tag defines a JMX remote -connector server URL for this server. -

    - - - diff --git a/jonas_doc/olddoc/JOnASWP.html b/jonas_doc/olddoc/JOnASWP.html deleted file mode 100644 index d89455ae281d603c9aa8d46d16c631333d4eb6fb..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/JOnASWP.html +++ /dev/null @@ -1,868 +0,0 @@ - - - - - The JOnAS Platform - - - - - -

    Java Open Application Server (JOnAS): a -J2EETM Platform

    - -

    Last modified at 2006-11-30, JOnAS 4.8

    -Logo JOnAS - -

    This document provides an overview of the JOnAS platform. The content of -this document is the following:

    - - -

    Introduction

    - -

    J2EE

    - -

    The SunTM J2EE -specification, together with its related specifications ( EJBTM, JMSTM,...), defines -an architecture and interfaces for developing and deploying distributed -Internet JavaTM server applications based on a multi-tier -architecture. This specification intends to facilitate and standardize the -development, deployment, and assembling of application components; such -components will be deployable on J2EE platforms. The resulting applications -are typically web-based, transactional, database-oriented, multi-user, -secured, scalable, and portable. More precisely, this specification describes -two kinds of information:

    -
      -
    • The first is the runtime environment, called a J2EE server, which - provides the execution environment and the required system services, such - as the transaction service, the persistence service, the Java Message - Service (JMS), and the security service.
      • -
    • The second is programmer and user information explaining how an - application component should be developed, deployed, and used.
      • -
    - -

    Not only will an application component be independent of the platform and -operating system (since it is written in Java), it will also be independent -of the J2EE platform.

    - -

    A typical J2EE application is composed of 1) presentation components, also -called "web components" (Servlets and JSPsTM), which define -the application Web interface, and 2) enterprise components, the "Enterprise -JavaBeans" (EJB), which define the application business logic and application -data. The J2EE server provides containers for hosting web and enterprise -components. The container provides the component life-cycle management and -interfaces the components with the services provided by the J2EE server. -There are two types of containers; the web container handles Servlet and JSP -components, while the EJB container handles the Enterprise JavaBeans -components. A J2EE server can also provide an environment for deploying Java -clients (accessing EJBs); it is called client container.

    -J2EE Architecture - -

    ObjectWeb

    - -

    JOnAS is an open source application server, developed within the ObjectWeb -consortium. ObjectWeb is an open -source initiative which can be compared to Apache or Linux, but in the area -of middleware. The aim of ObjectWeb is to develop and -promote open source middleware software.

    - -

    ObjectWeb is an International Consortium hosted by INRIA, officially -founded in February 2002 by Bull, France Telecom, and INRIA. All software is -available with the LGPL license.

    - -

    The technical objective of this consortium is to develop a distributed -component-based, middleware technology, in line with CORBA, Java, and W3C -standards. The intent is to apply the component model, as already used at the -application level in J2EE and in the CORBA Component Model, at the middleware -level itself. The functional coverage of ObjectWeb projects addresses naming, -trading, communication (events, messages), availability and safety -(transactions, persistence, replication, fault tolerance), load balancing, -and security. Some related topics are also addressed, such as robustness, -optimization, code quality, as well as benchmarks, tests, evaluations, -demonstrators, and development tools. More recently, the middleware -eco-system around JOnAS within ObjectWeb addresses Service Oriented -Architecture (SOA).

    - -

    ObjectWeb already has a significant number of members: corporations, -universities, individual members (individual membership is free). ObjectWeb -members contribute to ObjectWeb orientations and participate in all ObjectWeb -working groups, meetings, workshops, and conferences. The community of -developers and users working with ObjectWeb components and platforms is -constantly growing.

    - -

    JOnAS Features

    - -

    JOnAS is a pure Java, open source, application server. Its high modularity -allows to it to be used as

    -
      -
    • a J2EE server, for deploying and running EAR applications (i.e. - applications composed of both web and ejb components),
      • -
    • an EJB container, for deploying and running EJB components (e.g. for - applications without web interfaces or when using JSP/Servlet engines - that are not integrated as a JOnAS container),
      • -
    • a Web container, for deploying and running JSPs and Servlets (e.g. for - applications without EJB components).
      • -
    - -

    System Requirements

    - -

    JOnAS is available for JDK 1.4 and JDK 5. It has been used on many -operating systems (Linux, AIX, Windows, Solaris, HP-UX, etc.), and with -different Databases (Oracle, PostgreSQL, MySQL, SQL server, Access, DB2, -Versant, Informix, Interbase, etc.).

    - -

    Java Standard Conformance

    - -

    JOnAS supports the deployment of applications conforming to J2EE 1.4 -specification. Its current integration of Tomcat or Jetty as a Web container -ensures conformity to Servlet 2.4 and JSP 2.0 specifications. The JOnAS -server relies on or implements the following Java APIs: EJBTM 2.1, -JTATM 1.0.1, JDBC 3.0, J2EE CATM 1.5, JMXTM -1.2, JNDITM 1.2.1, JMSTM 1.1, JavaMailTM -1.3, ServletTM 2.4, JSPTM 2.0, JAASTM 1.0, -JACCTM 1.0, Web Services 1.1, JAX-RPCTM 1.1, -SAAJTM 1.2, JAXRTM 1.0, J2EE Management 1.0, -JAFTM 1.0, JAXPTM 1.2 specifications. JOnAS is -architectured in terms of services.

    - -

    Key Features

    - -

    JOnAS provides the following important advanced features:

    -
      -
    • Management: JOnAS server management uses JMX and - provides a JSP/Struts-based management console. It provides high level - functionalities for monitoring and managing clusters of JOnAS - servers.
      • -
    • Services: JOnAS's service-based architecture provides - for high modularity and configurability of the server. It allows the - developer to apply a component-model approach at the middleware level, - and makes the integration of new modules easy (e.g. for open source - contributors). It also provides a way to start only the services needed - by a particular application, thus saving valuable system resources. JOnAS - services are manageable through JMX.
      • -
    • Scalability: JOnAS integrates several optimization - mechanisms for increasing server scalability. This includes a pool of - stateless session beans, a pool of message-driven beans, a pool of - threads, a cache of entity beans, activation/passivation of entity beans, - a pool of connections (for JDBC, JMS, J2EE CA), storage access - optimizations (shared flag, isModified).
      • -
    • Clustering: JOnAS clustering solutions, both at the - WEB and EJB levels, provide load balancing, high availability, and - failover support.
      • -
    • Distribution: JOnAS works with several distributed - processing environments, due to the integration of the CAROL (Common - Architecture for RMI ObjectWeb Layer) ObjectWeb project, which allows - simultaneous support of several communication protocols: -
        -
      • RMI using the Sun proprietary protocol JRMP
        • -
      • RMI on IIOP
        • -
      • CMI, the "Cluster aware" distribution protocol of JOnAS
        • -
      • IRMI, an open source RMI protocol implementation
        • -
      -

      JOnAS benefits from transparent local RMI call optimization.

      -
      • -
    • Support of "Web Services:" Due to the integration of - AXIS, JOnAS allows J2EE components to access "Web services" (i.e., to be - "Web Services" clients), and allows J2EE components to be deployed as - "Web Services" endpoints. Standard Web Services clients and endpoints - deployment, as specified in J2EE 1.4, is supported.
      • -
    • Support of JDO: By integrating the ObjectWeb - implementation of JDO, SPEEDO, and its associated J2EE - CA Resource Adapter, JOnAS provides the capability of using JDO within - J2EE components.
      • -
    • Early support of EJB3: Even before the EJB3 - specification (part of Java EE 5, the new J2EE specification) is - finalized, JOnAS already provides an EJB3 container. This one is - available as a J2EE CA Resource Adapter, which may be deployed on JOnAS - 4. It is developed as a standalone ObjectWeb project, named EasyBeans. This container makes - EJB development far more easy.
      • -
    - -

    Three critical J2EE aspects were implemented early on in the JOnAS -server:

    -
      -
    • J2EECA: Enterprise Information Systems (EIS) can be - easily accessed from JOnAS applications. By supporting the Java Connector - Architecture, JOnAS allows deployment of any J2EE CA-compliant Resource - Adapter (connector), which makes the corresponding EIS available from the - J2EE application components. For example, Bull GCOS mainframes can be - accessed from JOnAS using their associated HooX - connectors. Moreover, with J2EE 1.4, resource adapters are now the - "standard" way to plug JDBC drivers and JMS implementation, to J2EE - platforms. A JDBC Resource Adapter is available with JOnAS, which - provides JDBC PreparedStatement pooling and can be used in place of the - JOnAS DBM service. A JORAM JMS Resource Adapter is also available. The - JOnAS EJB3 early container is also available as a Resource Adapter.
      • -
    • JMS: JMS implementations can be easily plugged into - JOnAS. They run as a JOnAS service or through a resource adapter in the - same JVM (Java Virtual Machine) or in a separate JVM. JOnAS provides - administration facilities that hide the JMS proprietary administration - APIs. Currently, two JMS implementations can be used: the JORAM open source JMS - implementation from Objectweb, and Websphere MQ. JORAM management is - particularly strongly integrated within the JOnAS management console. - Clustering configurations involving load balacing and high availability - at the JMS level are also available thanks to JORAM HA features.
      • -
    • JTA: The JOnAS platform supports distributed - transactions that involve multiple components and transactional - resources. The JTA transactions support is provided through JOTM, a Transaction Monitor that has - been developed on an implementation of the CORBA Transaction Service - (OTS). Originally this transaction monitor was JOnAS internal; it has - been extracted to be available as a standalone project, JOTM.
      • -
    - -

    JOnAS Packages

    - -

    JOnAS is available for download with three different packagings:

    -
      -
    • A simple packaging contains the JOnAS application server only, without - the associated Web Container implementation. To use it for J2EE Web - applications, Tomcat or Jetty must be installed (with an adequate - version) and it must be configured to work with JOnAS.
      • -
    • A JOnAS-Tomcat package contains both JOnAS and Tomcat, pre-configured, - and with compiled examples. This is a ready-to-run J2EE application - server.
      • -
    • A JOnAS-Jetty package contains both JOnAS and Jetty, pre-configured, - and with compiled examples. This is a ready-to-run J2EE application - server.
      • -
    - -

    These packages also contain AXIS, thus providing pre-configured "Web -Services" support.

    - -

    JOnAS Architecture

    - -

    JOnAS is designed with services in mind. A service typically provides -system resources to containers. Most of the components of the JOnAS -application server are pre-defined JOnAS services. However, it is possible -and easy for an advanced JOnAS user to define a service and to integrate it -into JOnAS. Because J2EE applications do not necessarily need all services, -it is possible to define, at JOnAS server configuration time, the set of -services that are to be launched at server start.

    - -

    The JOnAS architecture is illustrated in the following figure, showing WEB -and EJB containers relying on JOnAS services (this figure only misses the HA -service). Two thin clients are also shown in this figure, one of which is the -JOnAS administration console (called JonasAdmin).

    -J2EE Architecture - -

    Communication and Naming Service

    - -

    This service (also called "Registry") is used for launching the RMI -registry, the CosNaming, and/or the CMI registry, depending on the JOnAS -configuration (CAROL configuration, which specifies which communication -protocols are to be used). There are different registry launching modes: in -the same JVM or not, automatically if not already running. CAROL enables -multi-protocol runtime support and deployment, which avoids having to -redeploy components when changing the communication protocol.

    - -

    This service provides the JNDI API to application components and to other -services in order to bind and lookup remote objects (e.g. EJB Homes) and -resource references (JDBC DataSource, Mail and JMS connection factories, -etc.).

    - -

    EJB Container Service

    - -

    This service is in charge of loading the EJB 2.1 components and their -containers. EJB containers consist of a set of Java classes that implement -the EJB specification and a set of interposition classes that interface the -EJB components with the services provided by the JOnAS application server. -Interposition classes are specific to each EJB component and are generated by -the deployment tool called GenIC; this tool is automatically called at -deployment time, if necessary.

    - -

    Enterprise JavaBeans (EJB) are software components that implement the -business logic of an application (while the Servlets and JSPs implement the -presentation). There are three types of Enterprise JavaBeans:

    -
      -
    • Session beans are objects associated with only one - client, short-lived (one method call or a client session), that represent - the current state of the client session. They can be transaction-aware, - stateful, or stateless.
      • -
    • Entity beans are objects that represent data in a - database. They can be shared by several clients and are identified by - means of a primary key. The EJB container is responsible for managing the - persistence of such objects. The persistence management of such an object - is entirely transparent to the client that will use it, and may or may - not be transparent to the bean provider who develops it. This depends on - if it is one of the following: -
        -
      • An enterprise bean with Container-Managed - Persistence. In this case, the bean provider does not - develop any data access code; persistence management is delegated to - the container. The mapping between the bean and the persistent - storage is provided in the deployment descriptor, in an application - server-specific way.
        • -
      • An enterprise bean with Bean-Managed Persistence. - In this case, the bean provider writes the database access operations - in the methods of the enterprise bean that are specified for data - creation, load, store, retrieval, and remove operations.
        • -
      -
      • -
    • Message-driven Beans are objects that can be - considered as message listeners. They execute on receipt of a JMS (Java Message Service) - message; they are transaction-aware and stateless. They implement some - type of asynchronous EJB method invocation. -

      -
      • -
    - -

    JOnAS configuration provides a means for specifying a set of ejb-jar files -to be loaded at server start. Ejb-jar files can also be deployed at server -runtime using the JOnAS administration tools.

    - -

    For implementing Container-Managed Persistence of EJB 2.0 and EJB 2.1 -(CMP2), JOnAS relies on the ObjectWeb JORM (Java Object Repository Mapping) -and MEDOR (Middleware Enabling -Distributed Object Requests) frameworks. JORM supports complex mappings of -EJBs to database tables.

    - -

    The JOnAS EJB 2.1 container provides many optimization mechanisms to -improve data access and scalability: pool of instances, caches, lock -policies...

    - -

    JOnAS also implements the Timer Service features as specified in EJB -2.1.

    - -

    WEB Container Service

    - -

    This service is in charge of running a Servlet/JSP Engine in the JVM of -the JOnAS server and of loading web applications ("war" files) within this -engine. Currently, this service can be configured to use Tomcat or Jetty. Servlet/JSP engines are -integrated within JOnAS as "web containers," i.e. such containers provide the -web components with access to the system resources (of the application -server) and to EJB components, in a J2EE-compliant way.

    - -

    JOnAS configuration provides a means for specifying that this service be -launched during JOnAS initialization. Additionally, JOnAS configuration -provides a means for specifying a set of war files to be loaded. War files -may also be deployed at server runtime using the JOnAS administration tools. -User management for Tomcat/Jetty and JOnAS has been unified. The -class-loading delegation policy (priority to the Webapp classloader or to the -parent classloader) can be configured. Tomcat management has been strongly -integrated within the JOnAS management console.

    - -

    Servlet and JSPTM are technologies -for developing dynamic web pages. The Servlet approach allows the development -of Java classes (HTTP Servlets) that can be invoked through HTTP requests and -that generate HTML pages. Typically, Servlets access the information system -using Java APIs (as JDBC or the APIs of EJB components) in order to build the -content of the HTML page they will generate in response to the HTTP request. -The JSP technology is a complement of the Servlet technology. A JSP is an -HTML page containing Java code within particular XML-like tags; this Java -code is in charge of generating the dynamic content of the HTML page.

    - -

    Servlets and JSPs are considered as J2EE application components, -responsible for the application presentation logic. Such application -components can access resources provided by the J2EE server (such as JDBC -datasources, JMS connection factories, EJBs, mail factories). For J2EE -components, the actual assignment of these resources is performed at -component deployment time and is specified in the deployment descriptor of -each component, since the component code uses logical resource names.

    - -

    Ear Service

    - -

    This service is used for deploying complete J2EE applications, i.e. -applications packaged in EAR files, which themselves contain ejb-jar files -and/or war files. This service handles the EAR files and delegates the -deployment of the war files to the WEB Container service and the ejb-jar -files to the EJB Container service. It handles creating the appropriate class -loaders, in order for the J2EE application to execute properly.

    - -

    For deploying J2EE applications, JOnAS must be configured to launch the -EAR service and to specify the set of EAR files to be loaded. EAR files can -also be deployed at server runtime using the JOnAS administration tools.

    - -

    Transaction Service

    - -

    This service encapsulate a Java Transaction Monitor called JOTM (a project from ObjectWeb). It is a -mandatory service which handles distributed transactions. It provides -transaction management for EJB components as defined in their deployment -descriptors. It handles two-phase commit protocol against any number of -Resource Managers (XA Resources). For J2EE, a transactional resource may be a -JDBC connection, a JMS session, or a J2EE CA Resource Adapter connection. The -transactional context is implicitly propagated with the distributed requests. -The Transaction Monitor can be distributed across one or more JOnAS servers; -thus a transaction may involve several components located on different JOnAS -servers. This service implements the JTA 1.0.1 specification, thus allowing -transactions from application components or from application clients to be -explicitly started and terminated. Starting transactions from application -components is only allowed from Web components, session beans, or -message-driven beans (only these two types of beans, which is called -"Bean-managed transaction demarcation").

    - -

    One of the main advantages of the EJB support for transactions is its -declarative aspect, which means that transaction control is no longer -hard-coded in the server application, but is configured at deployment time. -This is known as "Container-managed transaction demarcation." With -"Container-managed transaction demarcation," the transactional -behaviour of an enterprise bean is defined at configuration time and is part -of the deployment descriptor of the bean. The EJB container is responsible -for providing the transaction demarcation for the enterprise beans according -to the value of transactional attributes associated with EJB methods, which -can be one of the following:

    -
      -
    • NotSupported: If the method is called - within a transaction, this transaction is suspended during the time of - the method execution.
      • -
    • Required: If the method is called within - a transaction, the method is executed in the scope of this transaction, - else, a new transaction is started for the execution of the method and - committed before the method result is sent to the caller.
      • -
    • RequiresNew: The method will always be - executed within the scope of a new transaction. The new transaction is - started for the execution of the method, and committed before the method - result is sent to the caller. If the method is called within a - transaction, this transaction is suspended before the new one is started, - and resumed when the new transaction has completed.
      • -
    • Mandatory: The method should always be - called within the scope of a transaction, else the container will throw - the TransactionRequired exception.
      • -
    • Supports: The method is invoked within - the caller transaction scope. If the caller does not have an associated - transaction, the method is invoked without a -

      transaction scope.

      -
      • -
    • Never: With this attribute the client is - required to call the method without a transaction context, else the - Container throws the java.rmi.RemoteException exception.
      • -
    - -

    Database Service

    - -

    This service is responsible for handling Datasource objects. A Datasource -is a standard JDBC administrative object for handling connections to a -database. The Database service creates and loads such datasources on the -JOnAS server. Datasources to be created and deployed can be specified at -JOnAS configuration time, or they can be created and deployed at server -runtime using the JOnAS administration tools. The Database service is also -responsible for connection pooling; it manages a pool of database connections -to be used by the application components, thus avoiding many physical -connection creations, which are time-consuming operations. The database -service can now be replaced by the JDBC Resource Adapter, to be deployed by -the J2EE CA Resource Service, which additionally provides JDBC -PreparedStatement pooling.

    - -

    Security Service

    - -

    This service implements the authorization mechanisms for accessing J2EE -components, as specified in the J2EE specification.

    -
      -
    • EJB security is based on the concept of roles. The - methods can be accessed by a given set of roles. In order to access the - methods, the user must be in at least one role of this set.
      - The mapping between roles and methods (permissions) is done in the - deployment descriptor using the security-role and - method-permission elements. Programmatic security management is - also possible using two methods of the EJBContext interface in order to - enforce or complement security check in the bean code: - getCallerPrincipal() and isCallerInRole (String - roleName). The role names used in the EJB code (in the - isCallerInRole method) are, in fact, references to actual security roles, - which makes the EJB code independent of the security configuration - described in the deployment descriptor. The programmer makes these role - references available to the bean deployer or application assembler by way - of the security-role-ref elements included in the - session or entity elements of the deployment - descriptor.
      • -
    • WEB security uses the same mechanisms, however permissions are defined - for URL patterns instead of EJB methods. Thus, the security configuration - is described in the Web deployment descriptor. Programmatically, the - caller role is accessible within a web component via the - isUserInRole (String roleName) method.
      • -
    - -

    In JOnAS, the mapping between roles and user identification is done in the -user identification repository. This user identification repository can be -stored either in files, in a JNDI repository (such as LDAP), or in a -relational database. This is achieved through a JOnAS implementation of the -Realm for each Web container and through the JAAS login modules for Java -clients. These Realms use authentication resources provided by JOnAS, which -rely either on files, LDAP or JDBC. These realms are in charge of propagating -the security context to the EJB container during EJB calls. JAAS login -modules are provided for user authentication of Web Container and Java -clients. Certificate-based authentication is also available, with -CRLLoginModule login module for certificate revocation.

    - -

    JOnAS also implements the Java Authorization Contract for Containers (JACC -1.0) specification, allowing authorizations to be managed as java security -permissions, and providing the ability to plug any security policy -provider.

    - -

    Messaging Service

    - -

    Asynchronous EJB method invocation is possible on Message-driven Beans -components. A Message-driven Bean is an EJB component that can be considered -as a JMS (Java Message -Service) MessageListener, i.e. which processes JMS messages -asynchronously. It is associated with a JMS destination and its -onMessage method is activated on the reception of messages sent by a -client application to this destination. It is also possible for any EJB -component to use the JMS API within the scope of transactions managed by the -application server.

    - -

    For supporting Message-driven Beans and JMS operations coded within -application components, the JOnAS application server relies on a JMS -implementation. JOnAS makes use of a third-party JMS implementation; -currently the JORAM open source -software is integrated and delivered with JOnAS, and other JMS provider -implementations can easily be integrated. JORAM provides several noteworthy -features: in particular, reliability (with a persistent mode), distribution -(transparently to the JMS client, it can run as several servers, thus -allowing load balancing), and the choice of TCP or SOAP as communication -protocol for transmitting messages.

    - -

    The JMS service is in charge of launching (or establishing connection to) -the integrated JMS server, which may or may not run in the same JVM as JOnAS. -It also provides connection pooling and thread pooling (for Message-driven -Beans). Through this service, JOnAS provides facilities to create -JMS-administered objects such as the connection factories and the -destinations, either at server launching time or at runtime using the JOnAS -administration tools.

    - -

    Note that the same function of JMS implementation integration may now be -achieved through a Resource Adapter, to be deployed by the J2EE CA Resource -Service. Such a Resource Adapter (J2EE CA 1.5) is provided for JORAM.

    - -

    J2EE CA Resource Service

    - -

    The J2EE Connector Architecture (J2EE CA) allows the connection of -different Enterprise Information Systems (EIS) to a J2EE application server. -It is based on the Resource Adapter (RA), an architecture component -comparable to a software driver, which connects the EIS, the application -server, and the enterprise application (J2EE components). The RA is generally -provided by an EIS vendor and provides a Java interface (the Common Client -Interface or CCI) to the J2EE components for accessing the EIS (this can also -be a specific Java interface). The RA also provides standard interfaces for -plugging into the application server, allowing them to collaborate to keep -all system-level mechanisms (transactions, security, and connection -management) transparent from the application components.

    -JCA Architecture - -

    The application performs "business logic" operations on the EIS data using -the RA client API (CCI), while transactions, connections (including pooling), -and security on the EIS are managed by the application server through the RA -(system contract).

    - -

    The JOnAS Resource service is in charge of deploying J2EE CA-compliant -Resource Adapters (connectors), packaged as RAR files, on the JOnAS server. -RAR files can also be included in EAR files, in which case the connector will -be loaded by the application classloader. Once Resource Adapters are -deployed, a connection factory instance is available in the JNDI namespace to -be looked up by application components.

    - -

    A J2EE CA 1.0 Resource Adapter for JDBC is available with JOnAS. It can -replace the current JOnAS database service for plugging JDBC drivers and -managing connection pools. It also provides JDBC PreparedStatement -pooling.

    - -

    A J2EE CA 1.5 Resource Adapter for JMS is available with JOnAS. It can -replace the current JOnAS Messaging service for plugging JORAM.

    - -

    Management Service

    - -

    The Management service is needed to administrate a JOnAS server from the -JOnAS administration console. Each server running this service is visible -from the administration console. This service is based on JMX. Standard -MBeans are defined within the JOnAS application server; they expose the -management methods of the instrumented JOnAS server objects such as services, -containers, the server itself. These MBeans implements the management model -as specified in the J2EE Management Specification. The Management service -runs a JMX server (if not available within the JDK, as is the case with JDK -5). The MBeans of the JOnAS server are registered within this JMX server. The -JOnAS administration console is a Struts-based Web application (servlet/JSP) -that accesses the JMX server to present the managed features within the -administration console. Thus, through a simple Web browser, it is possible to -manage one or several JOnAS application servers. The administration console -provides a means for configuring all JOnAS services (and making the -configuration persistent), for deploying any type of application (EJB-JAR, -WAR, EAR) and any type of resource (DataSources, JMS and Mail connection -factories, J2EE CA connectors), all without the need to stop or restart the -server. The administration console displays information for monitoring the -servers and applications, such as used memory, used threads, number of EJB -instances, the state of pools, which component currently uses which -resources, etc.. When Tomcat is used as Web Container, the Tomcat Management -is integrated within the JOnAS console. The concept of domain allows a set of -servers to be managed from a single management console, clusters have been -introduced within the console, allowing, for example, an application to be -deployed on a predefined subset of JOnAS instances. The cluster management -allows remote control and monitoring of cluster nodes; EJB and HTTP clusters -resulting from HA and load balancing configurations are automatically -detected and displayed in the console. A Management EJB (MEJB) is also -delivered, providing access to the management features, as specified in the -J2EE Management Specification. This MEJB is also accessible through Web -Services. JASMINe, a new ObjectWeb -project dedicated to cluster deployment and monitoring has been created.

    - -

    Mail Service

    - -

    A J2EE application component can send e-mail messages using JavaMailTM. The -Mail service of the JOnAS application server provides the necessary resources -to such application components. The Mail service creates mail factories and -registers these resources in the JNDI namespace in the same way that the -database service or the JMS service creates Datasources or -ConnectionFactories and registers these objects in the JNDI namespace. There -are two types of mail factories: javax.mail.Session and -javax.mail.internet.MimePartDataSource.

    - -

    WebServices Service

    - -

    This service is implemented on top of AXIS and is used for the deployment -of Web Services.

    - -

    HA Service

    - -

    This service is used for implementing Stateful Session Beans replication, -when configuring high availibility at the EJB/RMI level within a clustered -environment.

    - -

    JOnAS Development and Deployment -Environment

    - -

    JOnAS Configuration and Deployment -Facilities

    - -

    Once JOnAS has been installed in a directory referenced by the JONAS_ROOT -environment variable, it is possible to configure servers and to deploy -applications into several execution environments. This is achieved using the -JONAS_BASE environment variable. JONAS_ROOT and JONAS_BASE can be compared to -the CATALINA_HOME and CATALINA_BASE variables of Tomcat. While JONAS_ROOT is -dedicated to JOnAS installation, JONAS_BASE is used to specify a particular -JOnAS instance configuration. JONAS_BASE designates a directory containing a -specific JOnAS configuration, and it identifies subdirectories containing the -EJB-JAR, WAR, EAR, and RAR files that can be loaded in this application -environment. There is an ANT target in the JOnAS build.xml file for creating -a new JONAS_BASE directory structure. Thus, from one JOnAS installation, it -is possible to switch from one application environment to another by just -changing the value of the JONAS_BASE variable. There are two ways to -configure a JOnAS application server and load applications: either using the -administration console or by editing the configuration files. There are also -"autoload" directories for each type of application and resource (EJB-JAR, -WAR, EAR, RAR) that allow the JOnAS server to automatically load the -applications located in these directories when starting.

    - -

    A tool named "newjc" is provided to deploy and configure a set of JOnAS -servers within a cluster.

    - -

    JOnAS provides several facilities for deployment:

    -
      -
    • For writing the deployment descriptors, plugins for Integrated - Development Environments (IDE) provide some generation and editing - features (Eclipse and JBuilder plugins are available). The NewBean JOnAS - built-in tool generates template deployment descriptors. The Xdoclet tool - also generates deployment descriptors for JOnAS. A JSR88-compliant (J2EE - 1.4) deployment tool named "Dolphin" is available in beta version within - the Ishmael - ObjectWeb project.
      • -
    • Some basic tools for the deployment itself are the JOnAS GenIC command - line tool and the corresponding ANT ejbjar task. The IDE plugins - integrate the use of these tools for deployment operations.
      • -
    - -

    Fractal Deployment Framework (FDF) is a tool for deploying and configuring -the JOnAS software on a distributed environment.

    - -

    JOnAS Development Environments

    - -

    There are many plugins and tools that facilitate the development of J2EE -applications to be deployed on JOnAS. IDE plugins for Eclipse (JOPE, Lomboz, and, of course, WTP) and JBuilder (Kelly) provide the -means to develop, deploy, and debug J2EE components on JOnAS. The Xdoclet code-generation engine can -generate EJB interfaces and deployment descriptors (standard and JOnAS -specific ones), taking as input the EJB implementation class containing -specific JavaDoc tags. The JOnAS NewBean tool generates templates of -interfaces, implementation class, and deployment descriptors for any kind of -EJB. Many development tools may work with JOnAS; refer to the JOnAS tools page for -more details.

    - -

    In addition, JOnAS is delivered with complete J2EE examples, providing a -build.xml ANT file with all the necessary targets for compiling, deploying, -and installing J2EE applications.

    - -

    Clustering and Performance

    - -

    Clustering for an application server generally makes use of three -features: Load Balancing (LB), High Availability (HA) and Failover. Such -mechanisms can be provided at the Web container level by dispatching requests -to several Servlet/JSP engine instances, at the EJB container level by -dispatching EJB requests to several EJB container instances, and at the -database level by using several databases. A replicated JNDI naming is also -necessary.

    - -

    JOnAS provides Load Balancing, HA, and Failover at the WEB container level -using the Apache Tomcat mod_jk plugin and an HTTP in memory -session-replication mechanism based on JGroups. The plugin dispatches HTTP -requests from the Apache web server to Tomcat instances running as JOnAS web -containers. Server fluctuations are automatically taken into account. This -plugin supports round-robin and weighted round-robin load-balancing -algorithms, with a sticky session option.

    - -

    Load balancing and HA are provided at the EJB container level in JOnAS. -Operations invoked on EJB Home interfaces (EJB creation and retrieval) and -invocations of business methods on stateless session beans are dispatched on -the nodes of the cluster. The mechanism is based on a "clustered-aware" -replicated JNDI registry using a Clustered remote Method Invocation protocol -(CMI). The stubs contain the knowledge of the cluster and implement the -load-balancing policy, which may be round-robin and weighted round-robin; -these stubs are dynamically updated according to cluster topology changes -(dynamic cluster). This load-balancing policy may be easily customized. -Failover at the EJB level is provided by implementing a stateful session bean -state replication mechanism that ensures the transaction and global -consistency.

    - -

    Load balancing and HA may also be provided at the JMS level, thanks to the -JORAM HA capabilities.

    - -

    The JOnAS clustering architecture is illustrated in the following -figure.

    -Clustered Architecture - -

    Apache is used as the front-end HTTP server; Tomcat is used as the JOnAS -web container. The JOnAS servers share the same database. The mod_jk plug-in -provides Load Balancing / High Availability at the Servlet/JSP level. -Failover is provided through the in-memory, session-replication mechanism. -Load Balancing / High Availability is provided at the EJB level through the -CMI protocol associated with the replicated, clustered-aware JNDI registry. -Tomcat may or may not run in the same JVM as the EJB container. JOnAS -provides some documentation for configuring such an architecture.

    - -

    The use of the C-JDBC ObjectWeb -project offers load balancing and high availability at the database level. -The use of C-JDBC is transparent to the application (in our case to JOnAS), -since it is viewed as a standard JDBC driver. However, this "driver" -implements the cluster mechanisms (reads are load-balanced and writes are -broadcasted). The database is distributed and replicated among several nodes, -and C-JDBC load balances the queries between these nodes. An evaluation of -C-JDBC using the TPC-W benchmark on a 6-node cluster has shown performance -scaling linearly up to six nodes.

    - -

    In addition to clustering solutions, JOnAS provides many mechanisms, -intrinsic to the JOnAS server, for being highly scalable and efficient. This -includes the following:

    -
      -
    • A pool of stateless session bean instances
      • -
    • A pool of entity bean instances, configurable for each entity bean - within its deployment descriptor
      • -
    • Activation/passivation of entity beans, passivation can be controlled - through the management console
      • -
    • Many locking policies for entity beans are available in the EJB 2.1 - container, in order to adapt the locking policy to the application needs, - at the entity bean granularity level
      • -
    • Pools of connections, for JDBC, JMS, J2EE CA connectors
      • -
    • A pool of threads for message-driven beans
      • -
    • Session bean timeout can be specified at deployment
      • -
    • A "shared" flag in the specific deployment descriptor of an entity bean - indicates whether the persistent representation of this entity bean is - shared by several servers/applications, or whether it is dedicated to the - JOnAS server where it is loaded. In the latter case, the optimization - performed by JOnAS consists of not reloading the corresponding data - between transactions
      • -
    • The usual EJB 1.1 "isModified" (or "Dirty") mechanism is available for - avoiding storage of unmodified data
      • -
    • An optimization called "Data Prefetching" provides JDBC resultsets - re-use by the EJB container (this optimization reduces the number of SQL - statements executed by the EJB container).
      • -
    - -

    Perspectives

    - -

    As an open source implementation of an application server, JOnAS is -constantly evolving to satisfy user requirements and to follow the related -standards. The main JOnAS evolutions currently planned are the following:

    -
      -
    • The JOnAS services architecture will be re-engineered in order to - provide more flexible, dynamic and adaptable configuration and management - features. It will be achieved by using the OSGi technology and will be - the first step of the JOnAS 5 development
      • -
    • Support of the Java EE 5 specification will be provided
      • -
    • JOnAS Management will continuously be improved
      • -
    • The clustering mechanisms will be improved
      • -
    • Advanced cluster configuration management and monitoring (including - self management features) will be developed in the JASMINe project
      • -
    - -

    Sun, Java, and all -Java-based trademarks are trademarks or registered trademarks of Sun -Microsystems, Inc. in the U.S. and other countries.

    - - diff --git a/jonas_doc/olddoc/JOnASWebServices.html b/jonas_doc/olddoc/JOnASWebServices.html deleted file mode 100644 index 7f8707b2e86071133e89c6190444beafedb49047..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/JOnASWebServices.html +++ /dev/null @@ -1,814 +0,0 @@ - - - - - Web Services with JOnAS - - - - - -

    Web Services with JOnAS

    -Starting with JOnAS 3.3, Web Services can be used within EJBs and/or -servlets/JSPs. This integration conforms to the JSR 921(Web Service for J2EE -v1.1) specification.
    -
    - - -

    1. Web Services

    - -

    A. Some Definitions

    -WSDL: -WSDL (Web Service Description Language -v1.1) is an XML-based format for specifying the interface to a web -service. The WSDL details the service's available methods and parameter -types, as well as the actual SOAP endpoint for the service. In essence, WSDL -is the "user's manual" for the web service.
    -SOAP: -SOAP (Simple Object Access Protocol -v1.2) is an XML-based protocol for sending requests and responses to and -from web services. It consists of three parts: an envelope defining message -contents and processing, encoding rules for application-defined data types, -and a convention for representing remote procedure calls and responses.
    -JAX-RPC: -JAX-RPC (Java Api for XML -RPC v1.1)  is the Java API for XML-based RPC. RPC (Remote Procedure -Call) allows a client to execute procedures on other systems. The RPC -mechanism is often used in a distributed client/server model in which the -server defines a service as a collection of procedures that may be called by -remote clients. In the context of Web services, RPCs are represented by the -XML- based protocol SOAP when transmitted across systems.
    -In addition to defining envelope structure and encoding rules, the SOAP -specification defines a convention for representing remote procedure calls -and responses. An XML-based RPC server application can define, describe and -export a web service as an RPC-based service. WSDL (Web Service Description -Language) specifies an XML format for describing a service as a set of -endpoints operating on messages. With the JAX-RPC API, developers can -implement clients and services described by WSDL.
    -
    - - -

    B. Overview of a Web Service

    - -

    Strictly speaking, a Web Service is a well-defined, modular, encapsulated -function used for loosely coupled integration between applications' or -systems' components. It is based on standard technologies, such as XML, SOAP, -and UDDI.

    - -

    Web Services are generally exposed and discovered through a standard -registry service. With these standards, Web Services consumers (whether they -be users or other applications) can access a broad range of information -- -personal financial data, news, weather, and enterprise documents -- through -applications that reside on servers throughout the network.

    - -

    Web Services use a WSDL Definition (refer to www.w3.org/TR/WSDL) as a contract -between client and server (also called endpoint). WSDL defines the types to -serialize through the network (described with XMLSchema), the messages to -send and receive (composition, parameters), the portTypes (abstract view of a -Port), the bindings (concrete description of PortType: SOAP, GET, POST, ...), -the services (set of Ports), and the Port (the port is associated with a -unique endpoint URL that defines the location of the Web Service).

    - -

    A Web Service for J2EE is a component with some methods exposed and -accessible by HTTP (through servlet(s)). Web Services can be implemented as -Stateless Session Beans or as JAXRPC classes (a simple Java class, no -inheritance needed).

    - -
    -WS endpoint
    -Figure 1. Web Services endpoints deployed within JOnAS (an external client -code can access the endpoint via AxisServlet)
    -WS client
    -Figure 2. Web Services client deployed within JOnAS (can access external Web -Services)
    - -

    The servlet is used to respond to a client request and dispatch the call -to the designated instance of servant (the SSB or JAXRPC class exposed as Web -Service). It handles the deserialization of incoming SOAP messages to -transform SOAP XML into a Java Object, perform the call, and serialize the -call result (or the thrown exception) into SOAP XML before sending the -response message to the client.

    -
    - - -

    2. Exposing a J2EE Component as -a Web Service

    -There are two types of J2EE components that can be exposed as Web Services -endpoints: StateLess Session Beans and JAX-RPC classes. Web Services' -Endpoints must not contain state information.
    -
    -A new standard Deployment Descriptor has been created to describe Web -Services endpoints. This Descriptor is named "webservices.xml" and can be -used in a webapp (in WEB-INF/) or in an EjbJar (in META-INF/). This -Descriptor has its JOnAS-specific Deployment Descriptor -(jonas-webservices.xml is optional).
    -
    -Refer to the webServices sample for example files. - -

    A. JAX-RPC Endpoint

    -A JAX-RPC endpoint is a simple class running in the servlet container (Tomcat -or Jetty). SOAP requests are dispatched to an instance of this class and the -response is serialized and sent back to the client.
    -A JAX-RPC endpoint must be in a WebApp (the WAR file must contain a -"WEB-INF/webservices.xml").
    -
    - - -

    B. Stateless Session Bean -Endpoint

    -An SSB is an EJB that will be exposed (all or some of its methods) as a Web -Service endpoint.
    -In the ejb-jar.xml standard descriptor, a session bean, exposed as a web -service, must now use the new service-endpoint tag. Here the developer -defines the fully-qualified interface name of the web service. Notice that no -other interfaces (home, remote, localhome, local) are needed with a session -bean exposed as web service.
    -
    -Typically, an SSB must be in an EjbJar, and a "META-INF/webservices.xml" is -located in the EjbJar file.
    -
    - - -

    C. Usage
    -

    - -

    In this Descriptor, the developer describes the components that will be -exposed as Web Services' endpoints; these are called the port-component(s). A -set of port-components defines a webservice-description, and a -webservice-description uses a WSDL Definition file for a complete description -of the Web Services' endpoints.

    - -

    Each port-component is linked to the J2EE component that will respond to -the request (service-impl-bean with a servlet-link or ejb-link child element) -and to a WSDL port (wsdl-port defining the port's QName). A list of JAX-RPC -Handlers is provided for each port-component. The optional -service-endpoint-interface defines the methods of the J2EE components that -will be exposed (no inheritance needed).

    - -

    A JAX-RPC Handler is a class used to read and/or modify the SOAP Message -before transmission and/or after reception (refer to the JAX-RPC v1.1 spec. -chap#12 "SOAP Message Handlers").The Session Handler is a simple example that -will read/write SOAP session information in the SOAP Headers. Handlers are -identified with a unique name (within the application unit), are initialized -with the init-param(s), and work on processing a list of SOAP Headers defined -with soap-headers child elements. The Handler is run as the SOAP actor(s) -defined in the list of soap-roles.

    - -

    A webservice-description defines a set of port-components, a WSDL -Definition (describing the Web Service) and a mapping file (WSDL-2-Java -bindings). The wsdl-file element and the jaxrpc-mapping-file element must -specify a path to a file contained in the module unit (i.e., the war/jar -file). Note that a URL cannot be set here. The specification also requires -that the WSDLs be placed in a wsdl subdirectory (i.e., WEB-INF/wsdl or -META-INF/wsdl); there is no such requirement for the jaxrpc-mapping-file. All -the ports defined in the WSDL must be linked to a port-component. This is -essential because the WSDL is a contract between the endpoint and a client -(if the client uses a port not implemented/linked with a component, the -client call will systematically fail).
    -

    - -

    As for all other Deployment Descriptors, a standard -XML Schema is used to constrain the XML.
    -

    - -

    D. Simple Example (expose a JAX-RPC Endpoint) of webservices.xml

    - - - - - - - - -
    <?xml version="1.0"?>
    -
    - <webservices xmlns="http://java.sun.com/xml/ns/j2ee"
    -              - xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    -              - xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
    -                                  - http://www.ibm.com/webservices/xsd/j2ee_web_services_1_1.xsd"
    -              - version="1.1">
    -   <display-name>Simple Web Service Endpoint - DeploymentDesc</display-name>
    -
    -   <webservice-description>
    -     <!-- name must be unique in an Application unit - -->
    -     <!-- - Should not contain spaces !!! -->
    -     <webservice-description-name>
    -       SimpleWebServiceEndpoint
    -     </webservice-description-name>
    -
    -     <!-- Link to the WSDL file describing the - endpoint -->
    -     - <wsdl-file>WEB-INF/wsdl/warendpoint.wsdl</wsdl-file>
    -
    -     <!-- Link to the mapping file describing - binding between WSDL and Java -->
    -     - <jaxrpc-mapping-file>WEB-INF/warEndpointMapping.xml</jaxrpc-mapping-file>
    -
    -     <!-- The list of endpoints -->
    -     <port-component>
    -
    -           <!-- Unique name of - the port-component -->
    -           <!-- Should not contain spaces !!! - -->
    -       - <port-component-name>WebappPortComp1</port-component-name>
    -
    -       <!-- The QName of the WSDL Port the - J2EE port-component is linked to -->
    -       <!-- Must Refers to a port in - associated WSDL document -->
    -       <wsdl-port - xmlns:ns="    http://wsendpoint.servlets.ws.objectweb.org">
    -           - ns:wsendpoint1
    -       </wsdl-port>
    -
    -           <!-- The endpoint - interface defining methods exposed -->
    -       <!--    for the - endpoint                             - -->
    -       - <service-endpoint-interface>
    -         org.objectweb.ws.servlets.wsendpoint.WSEndpointSei
    -       </service-endpoint-interface>
    -
    -           <!-- Link to the J2EE - component (servlet/EJB)    -->
    -       <!-- implementing methods of the - SEI          -    -->
    -       - <service-impl-bean>
    -         <!-- name of the - servlet defining the JAX-RPC endpoint    -->
    -             <!-- can - be ejb-link if SSB is used (only in EjbJar!)    - -->
    -         - <servlet-link>WSEndpoint</servlet-link>
    -       </service-impl-bean>
    -
    -           <!-- The list of - optional JAX-RPC Handlers -->
    -       <handler>
    -         - <handler-name>MyHandler</handler-name>
    -         - <handler-class>org.objectweb.ws.handlers.SimpleHandler</handler-class>
    -
    -             <!-- A - list of init-param for Handler configuration -->
    -         - <init-param>
    -            - <param-name>param1</param-name>
    -            - <param-value>value1</param-value>
    -         </init-param>
    -         <init-param>
    -            - <param-name>param2</param-name>
    -            - <param-value>value2</param-value>
    -         </init-param>
    -       </handler>
    -     </port-component>
    -   </webservice-description>
    - </webservices>
    - -

    E. The optional jonas-webservices.xml

    - -The jonas-webservices.xml file is an optional deployment descriptor. This descriptor -is used by WsGen to set some specifics for the generated webapp that is in charge of -the SOAP request dispatching. Its role is to allow for the specifications of the -webapp's name, context root, security settings and endpoint URL customization.
    -
    -Some parameters are only used if the web service is implemented by a Session Bean: -
      -
    • jonas:jonas-webservices/jonas:war: specify the filename of the webapp -frontend generated for this EjbJar
      • -
    • jonas:jonas-webservices/jonas:context-root: specify the context root of the webapp -frontend generated for this EjbJar
      • -
    - -
    -War Name: Specifies the name of the generated -WAR. Setting the <war> element is optional; if it is not specified, then the -default naming convention is used to retrieve the WAR name from the ejbjar's name.
    -
    -   Default Naming: -<ejbjar-name>.jar will have an -<ejbjar-name>.war WebApp.
    -
    - -Context Root: Specifies the context root of the -generated WAR. Setting the <context-root> element is optional; if it is not specified, -then the default naming convention is used and the context root will be the same as the WAR's name. -
    -
    -   Default Naming: -<webapp-name>.war will have a -<webapp-name> context root.
    -
    - -Endpoint URL Customization: Specifies the endpoint URL -of a given jonas-port-component. Setting the <endpoint-url> element is optional; if it is not specified, -then the default naming convention is used and the URL will look like /<context-root>/<port-component-name>/<wsdl:port-name>.
    -
    - -Security: The security settings specify which -security settings, if any, the generated webapp should use. Setting up security within this -file is very similar to how security would be set up in a regular web.xml.
    -
    - -
    NOTE: -When using the <endpoint-security-constraint>, -<endpoint-login-config>, or -<endpoint-security-role> elements, the j2ee namespace -must be included in the jonas-webservices element (that is, -xmlsn:j2ee="http://java.sun.com/xml/j2ee"), and the namespace -for all elements within these tags (that is, the 'j2ee' -in the example below) must be specified.
    -
    - -   Security Constraint: -the <endpoint-security-constraint> specifies the <security-constraint> -in the web.xml -of the generated webapp.
    -
    -   Login Config: the -<endpoint-login-config> specifies -the <login-config> in the web.xml of the generated webapp.
    -
    -   Security Role: the -<endpoint-security-role> specifies -the <security-role> in the web.xml -of the generated webapp.
    -
    -   Realm: the -<endpoint-realm> specifies the security -realm for the generated webapp.
    -
    -   Realm Name: the -<endpoint-realm-name> specifies the -name of the security realm for the generated webapp. - -
    -
    -Example:
    - - - - - - - - -
    - - 
    -<?xml version="1.0"?>
-<jonas-webservices xmlns="http://www.objectweb.org/jonas/ns"
-                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-                   xmlns:j2ee:"http://java.sun.com/xml/ns/j2ee"
-                   xsi:schemaLocation="http://www.objectweb.org/jonas/ns http://www.objectweb.org/jonas/ns/jonas_j2ee_web_services_4_5.xsd">
-
-  <!-- the name of the webapp in the EAR              -->
-  <!-- (it is the same as the one in application.xml) -->
-  <war>dispatchingWebApp.war</war>
-
-  <!-- the context root the webapp should use -->
-  <context-root>endpoint</context-root>
-
-  <jonas-port-component>
-    <port-component-name>ssbEndpoint</port-component-name>
-    <!-- We can specify with endpoint-uri the URL we want to have for the given port.      -->
-    <!-- Will be something like : http://<host>:<port>/<context-root>/services1/webservice -->
-    <endpoint-uri>/services1/webservice</endpoint-uri>
-  </jonas-port-component>
-
-  <!-- everthing in this element will appear in the security-constraint -->
-  <!-- element in the web.xml of the generated webapp                   -->
-  <endpoint-security-constraint>
-    <j2ee:web-resouce-collection>
-      <j2ee:web-resource-name>Stateless Session Bean Endpoint</j2ee:web-resource-name>
-      <j2ee:url-pattern>/*</j2ee:url-pattern>
-    </j2ee:web-resource-collection>
-    <j2ee:auth-constraint>
-      <j2ee:role-name>admin</j2ee:role-name>
-    </j2ee:auth-constraint>
-  </endpoint-security-constraint>
-
-  <!-- everything in this element will appear in the login-config -->
-  <!-- element in the web.xml of the generated webapp             -->
-  <endpoint-login-config>
-    <j2ee:auth-method>BASIC</j2ee:auth-method>
-    <j2ee:realm-name>Endpoint Authentication Area</j2ee:realm-name>
-  </endpoint-login-config>
-
-  <!-- everything in this element will appear in the security-role -->
-  <!-- element in the web.xml of the generated webapp              -->
-  <endpoint-security-role>
-    <j2ee:role-name>admin</j2ee:role-name>
-  </endpoint-security-role>
-
-  <!-- the realm the generated webapp should use -->
-  <endpoint-realm>memrlm_1</endpoint-realm>
-
-  <!-- the name of the realm the generated webapp should use -->
-  <endpoint-realm-name>Endpoint Authentication Area</endpoint-realm-name>
-
-</jonas-webservices>
-
    - -

    F. Changes to jonas-web.xml

    -JOnAS allows the developer to fully configure an application by setting the -hostname, the context-root, and the port used to access the Web Services. -This is done in the jonas-web.xml of the dispatching WebApp.
    -host: configure the hostname to use -in URL (must be an available web container host).
    -port: configure the port number to -use in URL (must be an available HTTP/HTTPS connector port number).
    -
    -When these values are not set, JOnAS will attempt to determine the default -values for host and port.
    -Limitations:
    -- The host can only be determined when only one host is set for the web -container.
    -- The port can only be determined when only one connector is used by the web -container.
    - - -

    3. The client of a Web -Service

    -An EJB or a servlet that wants to use a Web Service (as client) must declare -a dependency on the Web Service with a service-ref element (same principle as for -all *-ref elements).
    - - -

    A. The service-ref element

    -The service-ref element declares reference to a Web Service used by a J2EE -component in the web, EJB and Client application Deployment Descriptor.
    -The component uses a logical name called a service-ref-name to lookup the -service instance. Thus, any component that performs a lookup on a Web Service -must declare a dependency (the service-ref element) in the standard -deployment descriptor (web.xml, ejb-jar.xml or application-client.xml).
    -
    -Example of service-ref:
    - - - - - - - - -
      <service-ref>
    -     <!--     (Optional) A Web services - description that can be used
    -          in administration - tool.     -->
    -     <description>Sample WebService - Client</description>
    -
    -     <!--     (Optional) The WebService - reference name -->
    -     <display-name>WebService Client - 1</display-name>
    -
    -     <!--     (Optional) An icon for this - WebService. -->
    -     <icon> <!-- ... --> </icon>
    -
    -     <!--     The logical name for the reference - that is used in the client source
    -          code. It is recommended, but not - required that the name begin with
    -          'services/'     -->
    -     - <service-ref-name>services/myService</service-ref-name>
    -
    -     <!--     Defines the class name of the - JAX-RPC Service interface that
    -         the client depends on. In most - cases, the value will be:
    -         javax.xml.rpc.Service but a - generated specific Service Interface
    -         class may be specified (requires - WSDL knowledge and thus
    -         the wsdl-file element). -     -->
    -     - <service-interface>javax.xml.rpc.Service</service-interface>
    -
    -     <!--     (Optional) Contains the location - (relative to the root of
    -          the module) of the web service WSDL - description.
    -          - needs to be in the wsdl - directory.
    -          - required if generated interface - and sei are declared. -->
    -     - <wsdl-file>WEB-INF/wsdl/stockQuote.wsdl</wsdl-file>
    -    
    -     <!--     (Optional) A file specifying the - correlation of the WSDL definition
    -          to the interfaces (Service Endpoint - Interface, Service Interface).
    -          - required if generated - interface and sei (Service Endpoint
    -          Interface) are - declared.    -->
    -     - <jaxrpc-mapping-file>WEB-INF/myMapping.xml</jaxrpc-mapping-file>
    -
    -     <!--     (Optional) Declares the specific - WSDL service element that is being
    -          referred to. It is not specified if - no wsdl-file is declared or if
    -          WSDL contains only 1 service - element. A service-qname is composed
    -          of a namespaceURI and a localpart. - It must be defined if more than 1
    -          service is declared in - the WSDL.     -->
    -       <service-qname - xmlns:ns="    http://beans.ws.objectweb.org">
    -          ns:MyWSDLService
    -     </service-qname>
    -
    -     <!--     Declares a client dependency on - the container for resolving a Service
    -          Endpoint Interface to a WSDL port. - It optionally associates the
    -          Service Endpoint Interface with a - particular port-component.     -->
    -     <port-component-ref>
    -
    -       - <service-endpoint-interface>
    -      org.objectweb.ws.beans.ssbendpoint.MyService
    -          - </service-endpoint-interface>
    -
    -       <!-- Defines a link to a port component - declared in another unit
    -            of the - application -->
    -       - <!-- link is only used when an application module wants to access - a  -->
    -       - <!-- web service colocated in the same application - unit             - -->
    -       - <port-component-link>ejb_module.jar#PortComponentName    </port-component-link>
    -     </port-component-ref>
    -
    -     <!--A list of Handlers to use for this - service-ref  -->
    -     <handler>
    -        <!--     Must be unique - within the module. -->
    -        - <handler-name>MyHandler</handler-name>
    -
    -        - <handler-class>org.objectweb.ws.handlers.myHandler</handler-class>
    -
    -        <!-- A list of init-params (couple - name/value) for Handler
    -             - initialization -->
    -        <init-param>
    -          - <param-name>param_1</param-name>
    -         -  <param-value>value_1</param-value>
    -        </init-param>
    -
    -        <!-- A list of QNames specifying the - SOAP Headers the handler
    -             will work on. Namespace and - locapart values must be found
    -             inside the WSDL. -->
    -        <soap-header - xmlns:ns="    http://ws.objectweb.org">
    -             - ns:MyWSDLHeader
    -        </soap-header>
    -
    -        <!-- A list of     SOAP actor - definitions that the Handler will play
    -             as a role. A soap-role is a - namespace URI.     -->
    -        - <soap-role>http://actor.soap.objectweb.org</soap-role>
    -
    -        <!-- A list - of     port-name elements that defines the WSDL - port-name that
    -             a handler should be - associated with. If no port-name is specified,
    -             the handler is assumed to - be associated with all ports of the
    -             service-ref.     - -->
    -        - <port-name>myWSDLPort</port-name>
    -     </handler>
    -   </service-ref>
    -
    - - -

    B. The jonas-service-ref element

    -A jonas-service-ref must be specified for each service-ref declared in the -standard Deployment Descriptor. The jonas-service-ref adds JOnAS-specific -(and Web Service engine-specific) information to service-ref elements.
    -
    -Example of jonas-service-ref:
    - - - - - - - - -
        - <jonas-service-ref>
    -
    -           <!-- Define the service-ref - contained in the component
    -            deployment descriptor - (web.xml, ejb-jar.xml, application-client.xml).
    -            used as a key to associate a - service-ref to its correspondent
    -            jonas-service-ref-->
    -           - <service-ref-name>services/myService</service-ref-name>
    -
    -           <!-- Define the physical - name of the resource. -->
    -           - <jndi-name>webservice_1</jndi-name>
    -      
    -       <!-- A list of init-param used for specific - configuration of
    -            the service -->
    -       <jonas-init-param>
    -         - <param-name>param</param-name>
    -         - <param-value>name</param-value>
    -       </jonas-init-param>
    -     </jonas-service-ref>
    -
    - - -

    4. WsGen

    - -

    WsGen is a new JOnAS tool that works in the same way as GenIC. It takes -archive files (EJB-JAR, WAR, JAR client, EAR) and generates all the necessay -components related to web services:

    -
      -
    • Creates vendor-specific web-services deployment files for the server - side and, when needed, the client side (Axis will use its own wsdd - format).
      • -
    • Creates a WebApp for each EJB-JAR exposing web services.
      • -
    • Generates and compiles client side artifacts (Services and Port - Bindings implementations classes).
      • -
    - -

    For example, to provide an EJB-exposing method as a web service, a -developer creates a webservices.xml file packaged in EjbJar's -META-INF directory. WsGen automatically creates a configured webapp (using an -Axis servlet) and wraps it (ejbjar + webapp) in an EAR file.

    - -

    With a JaxRpc class, WsGen adds a servlet (an Axis servlet) inside the -existing web deployment descriptor and generates an Axis-specific -configuration file.

    - -

    When using service-ref (from ejbjars, web applications, or clients), WsGen -automatically generates a Stub from WSDL (if a generated service interface -name is provided).

    - -

    Usage

    - -

    WsGen is used typically from an ant build file. Simply add this taskdef -under the ejbjar taskdef:

    -
    <taskdef name="wsgen" classname="org.objectweb.jonas.ant.WsGenTask"
-   classpath="${jonas.root}/lib/common/ow_jonas_ant.jar" />
-<wsgen srcdir="${temp.dir}"
-   destdir="${dist.dir}"
-   verbose="false"
-   debug="false">
-      <include name="webapps/wswarsample.war"/>
-</wsgen>
    - -

    See the $JONAS_ROOT/examples/webservices samples for complete -build scripts.

    - -

    Note that the ejbjar/webapp/client archive must include WSDL, -jax-rpc-mappings used in service-ref, or webservices.xml. When these -files are used from a service-ref, they are added into the generic ejb-jar -with the ejbjar ant task of JOnAS; you must ensure that they have been placed -inside the srcdir given to the ejbjar task (otherwise, the ejbjar task cannot -find them and will produce an error).

    - -

    This task is a directory-based -task and, as such, forms an implicit Fileset. This -defines which files, relative to the srcdir, will be processed. The -wsgen task supports all the attributes of Fileset to refine the set of files -to be included in the implicit fileset.

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    AttributeDescriptionRequired
    srcdirDirectory where file archive (EjbJar, War, Client, Ear) is - locatedYes
    destdirDirectory where generated files will be placedNo
    verboseVerbose mode (Defaults to false)No
    debugDebug mode (Defaults to false)No
    javacoptsList of options given to the java compilerNo
    jonasrootDirectory where JOnAS is installedNo
    jonasbaseDirectory where JOnAS configuration is storedNo
    - -

    Wsgen is also usable from the command line with WsGen script (available on -*nix and Windows).

    - -
    -
    - - diff --git a/jonas_doc/olddoc/MBeans.html b/jonas_doc/olddoc/MBeans.html deleted file mode 100644 index d68701dffc06bb6b7d7eb98fb7ba338281e046c4..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/MBeans.html +++ /dev/null @@ -1,152 +0,0 @@ - - - - - - - Working with Management Beans - - - - -

    Working with Management Beans

    - -

    The content of this guide is the following:

    -
      -
    1. Target Audience and Rationale
      2. -
    2. About JOnAS MBeans and their use in - JonaSAdmin
      3. -
    3. Using JOnAS MBeans in a Management - Application
      4. -
    4. Registering User MBeans
      5. -
    - -

    Target Audience and Rationale

    - -

    This chapter is intended for advanced JOnAS users who are interested in -understanding management facilities that JOnAS provides, and possibly -extending these facilities for their application needs.

    - -

    JOnAS management facilities are based on Management Beans (MBeans) -compliant to JMX -Specification. Moreover, JOnAS implements JSR 77 specification, which -defines the management model for J2EE platforms.

    - -

    About JOnAS MBeans and their use in -JonaSAdmin

    - -

    MBeans provide access to management functions such as configuration, -deployment/undeployment, monitoring of resources and application modules.

    - -

    MBeans are created not only by the different JOnAS services, but also by the -components integrated in JOnAS (Web server Tomcat or Jetty, JORAM MOM, etc.). -They are registered in the current MBean Server, which is started by each -JOnAS server instance. Remote access to the MBean Server is facilitated by -JMX remote connectors compliant to the JSR 160 specification. See more -information about connectors here.

    - -

    JonasAdmin application implements the management functions listed above -using the different MBeans registered in the MBeanServer of the JOnAS -instance currently being managed. This is usually the server on which -JonasAdmin is deployed, but it may be another server running in the same -management domain.

    - -

    JonasAdmin also presents, in a structured way, all the registered MBeans, -their attributes and operations. In the future, JonasAdmin will probably be -extended to allow setting attributes and invoking operations.

    - -

    Using JOnAS MBeans in a Management -Application

    - -

    In order to invoke a management operation on a MBean, the caller must -access to the MBean server.

    - -

    Local MBean Server

    - -

    When the caller is located in the same JVM as the MBean Server, it can use -javax.management.MBeanServerFactory class to obtain a reference -to the MBean Server:

    -
                    List mbeanServers = MBeanServerFactory.findMBeanServer(null);
-                if (mbeanServers != null && mbeanServers.size() > 0) {
-                        return (MBeanServer) mbeanServers.get(0);
-                }
-
    - -

    - -

    Using Remote Connectors

    - -

    When the caller is remote, it can use a JMX remote connector to establish -a connection with the MBean Server and obtain a -javax.management.MBeanServerConnection object.

    - -

    Suppose that the connector server has the following address: -service:jmx:jrmp://host/jndi/jrmp://host:1099/jrmpconnector_jonas, -which is the default for a JOnAS server called jonas.

    -
                    JMXServiceURL connURL = new JMXServiceURL("service:jmx:jrmp://host/jndi/jrmp://host:1099/jrmpconnector_jonas");
-                JMXConnector connector = JMXConnectorFactory.newJMXConnector(connURL, null);
-                connector.connect(null);
-                MBeanServerConnection conn = connector.getMBeanServerConnection();
-                return conn;
-
    - -

    - -

    Using a Management EJB

    - -

    A remote caller can also use the MEJB provided by the JOnAS distribution. -A Management EJB implementation, compliant to the JSR 77, is packed in the -mejb.ear installed in the -JONAS_ROOT/ejbjars/autoload directory. Thus, the MEJB is -automatically deployed at JOnAS start-up. Its Home is registered -in JNDI under the name ejb/mgmt/MEJB. JOnAS distribution also -contains an example using the MEJB in a J2EE application, the -j2eemanagement sample.

    - -

    - -

    Using the Management Web Service Endpoint

    - -

    -A remote caller can use the Management Web Service endpoint packaged -as a part of the mejb.ear installed in the -JONAS_ROOT/ejbjars/autoload directory. Thus, the management -endpoint is automatically deployed at JOnAS start-up. Check - http://<hostname>:<port>/mejb/ManagementEndpoint/ManagementEndpoint?wsdl - for the WSDL file on a running JOnAS instance. The endpoint allows light-weight -clients to query JOnAS MBeans from virtually any platform by leveraging the -platform-independant nature of Web Services. -

    - -

    Registering User MBeans

    - -

    Application MBeans can be created and registered in the MBean server by -calling registerMBean method on the MBeanServer -object or createMBean method on the -MBeanServerConnection object. Also, MBeans can be loaded using -the m-let service, a dynamic loading mechanism provided by the JMX -implementation. This mechanism allows loading MBeans from a remote URL. The -information on the MBeans to load is provided in a m-let text file. Refer to -JMX implementation documentation for details concerning this file. In addition, -the howto document -JOnAS and JMX, registering and manipulating MBeans -illustrates the use of this m-let mechanism. In order -to make an m-let text file accessible to JOnAS applications, it can be installed -in the JONAS_ROOT/conf directory.

    - - diff --git a/jonas_doc/olddoc/PG_Client.html b/jonas_doc/olddoc/PG_Client.html deleted file mode 100644 index 3630b6597ef4bcab27213b7477d154ab238ca743..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/PG_Client.html +++ /dev/null @@ -1,372 +0,0 @@ - - - - - - - J2EE Client Application Programmer's Guide - - - -

    J2EE Client Application Programmer's Guide

    - -

    Target Audience and Content

    - -

    The target audience for this guide is the Client component provider, i.e. -the person in charge of developing the Client components on the client side. -It describes how the Client component provider should build the deployment -descriptors of its Client components and how the client components should be -packaged.

    - -

    The content of this guide is the following:

    -
      -
    1. Target Audience and Content
      2. -
    2. Launching J2EE Client Applications - -
      3. -
    3. Defining the Client Deployment - Descriptor - -
      4. -
    4. Client Packaging - -
      5. -
    - -

    - -

    Launching J2EE Client Applications

    - -

    Launching clients

    - -

    The J2EE client application can be

    -
      -
    • a standalone client in a .jar file,
      • -
    • a client bundle in an .ear file. An ear can contain many java - clients.
      • -
    • a class name which must be found in the CLASSPATH.
      • -
    - -

    All the files required to launch the client container are in the -JONAS_ROOT/lib/client.jar file. This jar includes a manifest -file with the name of the class to launch. To launch the client container, -simply type:

    - -

    java -jar $JONAS_ROOT/lib/client.jar -?. This will launch the -client container and display usage information about this client -container.

    - -

    To launch the client container on a remote computer, copy the client.jar -and invoke the client container by typing java -jar -path_to_your/client.jar.

    - -

    The client that must be launched by the client container is given as an -argument of the client container.
    -example : java -jar client.jar myApplication.ear
    -or java -jar client.jar myClient.jar.

    - -

    Configuring client container

    - -

    JNDI access

    - -

    Defining the JNDI access and the protocol to use is an important part of -configuration.
    -The JOnAS server, as well as the ClientContainer, uses the values specified -in the carol.properties file.
    -This file can be used at different levels.
    -The carol.properties is searched with the following priority -(high to low):

    -
      -
    • the carol.properties specified by the - -carolFile argument to the client container
      • -
    • the carol.properties packaged into the client application - (the jar client)
      • -
    • if not located previously, it will use the - carol.properties contained in the - JONAS_ROOT/lib/client.jar.
      • -
    - -

    A convenient way is to update the carol.properties of a -client.jar with a customized carol.properties -file. That is, use the jar -uf client.jar carol.properties -command.

    - -

    Trace configuration

    - -

    The client container client.jar includes a -traceclient.properties file. This is the same file as the one in -JONAS_ROOT/conf directory.
    -A different configuration file can be used for the traces by specifying the -parameter -traceFile when invoking the client container.
    -The file in the client.jar can be replaced with the jar --uf client.jar traceclient.properties command.

    - -

    Classpath configuration

    - -

    Some jars/classes can be added to the client container. For example if a class requires some extra libraries/classes, -the option -cp path/to/classes can be used.

    -

    The classloader of the client container will use the libraries/classes provided by the -cp flag. -

    - -

    Specifying the client to use (EAR case)

    - -

    An ear can contain many java clients, which are described in the -application.xml file inside the -<module><java> elements.
    -To invoke the client container with an ear, such as java -jar -client.jar my.ear, specify the java client to use if there are many -clients. Otherwise, it will take the first client.
    -To specify the jar client to use from an ear, use the argument --jarClient and supply the name of the client to use.
    -The earsample example in the JOnAS examples has two java clients -in its ear.

    - -

    Specifying the directory for unpacking the ear (EAR case)

    - -

    By default, the client container will use the system property -java.io.tmpdir.
    -To use another temporary directory, specify the path by giving the argument --tmpDirto the client -container.

    - -

    Disable Automated WsGen

    - -

    By default, the client container will apply WsGen (generation of web services artifacts) on all given archives.
    -To disable that feature (because WsGen has already been applied on the application, or because -the client contains no web services), add the -nowsgen option to the client container.

    - -

    Examples

    - -

    The earsample and jaasclient examples of the -JOnAS examples are packaged for use by the client container.
    -The first example demonstrates the client inside an ear. The second example -demonstrates the use of a standalone client.

    - -

    - -

    Defining the Client Deployment -Descriptor

    - -

    Principles

    - -

    The Client component programmer is responsible for providing the -deployment descriptor associated with the developed client components.

    - -

    The client component provider's responsibilities and the Application -Assembler's responsibilities are to provide an XML deployment descriptor that -conforms to the deployment descriptor's XML DTD as defined in the Java -TM Application Client Specification Version 1.4.(Refer to -$JONAS_ROOT/xml/application-client_1_4.xsd or  -http://java.sun.com/xml/ns/j2ee/application-client_1_4.xsd).

    - -

    To customize the Client components, information not defined in the -standard XML deployment descriptor may be needed. Such information might -include, for example, the mapping of the name of referenced resources to its -JNDI name. This information can be specified during the deployment phase -within another XML deployment descriptor that is specific to JOnAS. The -JOnAS-specific deployment descriptor's XML schema is located in -$JONAS_ROOT/xml/jonas-client_X_Y.xsd. The file name of the -JOnAS-specific XML deployment descriptor must be -'jonas-client.xml'.

    - -

    JOnAS interprets the <!DOCTYPE> tag at the parsing of the deployment -descriptor XML files.
    -The parser first tries to get the specified DTD via the classpath, then it -uses the specified URL (or path).

    - -

    The parser gets the specified schema via the classpath (schemas are packaged -in the $JONAS_ROOT/lib/common/ow_jonas.jar file).

    - -

    The standard deployment descriptor (application-client.xml) should contain -structural information that includes the following:

    -
      -
    • A Client description
      • -
    • Environment entries
      • -
    • EJB references
      • -
    • Resource references
      • -
    • Resource env references
      • -
    • The callback handler to use
      • -
    - -

    The JOnAS-specific deployment descriptor (jonas-client.xml) may contain -information that includes the following::

    -
      -
    • The JNDI name of the external resources referenced by a Client - component
      • -
    • The JNDI name of the external resources environment referenced by a - Client component
      • -
    • The JNDI name of the beans referenced by a Client component
      • -
    • The security aspects including the jaas file, the jaas entry, and a - login/password to use for a specific callback handler
      • -
    - -

    Examples of Client Deployment -Descriptors

    -
      -
    • Example of a standard Client Deployment Descriptor - (application-client.xml): - 
      <?xml version="1.0" encoding="UTF-8"?>
-
-<application-client xmlns="http://java.sun.com/xml/ns/j2ee"
-                    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-                    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
-                    http://java.sun.com/xml/ns/j2ee/application-client_1_4.xsd"
-                    version="1.4">
-
-  <display-name>Client of the earsample</display-name>
-  <description>client of the earsample</description>
-
-  <env-entry>
-    <env-entry-name>envEntryString</env-entry-name>
-    <env-entry-type>java.lang.String</env-entry-type>
-    <env-entry-value>Test of envEntry of application-client.xml file</env-entry-value>
-  </env-entry>
-
-
-  <ejb-ref>
-    <ejb-ref-name>ejb/Op</ejb-ref-name>
-    <ejb-ref-type>Session</ejb-ref-type>
-    <home>org.objectweb.earsample.beans.secusb.OpHome</home>
-    <remote>org.objectweb.earsample.beans.secusb.Op</remote>
-    <ejb-link>secusb.jar#EarOp</ejb-link>
-  </ejb-ref>
-
-  <resource-ref>
-    <res-ref-name>url/jonas</res-ref-name>
-    <res-type>java.net.URL</res-type>
-    <res-auth>Container</res-auth>
-  </resource-ref>
-
-  <callback-handler>org.objectweb.jonas.security.auth.callback.LoginCallbackHandler
-  </callback-handler>
-
-</application-client>
      -
      • -
    • Example of a specific Client Deployment Descriptor (jonas-client.xml): - 
      <?xml version="1.0" encoding="UTF-8"?>
-<jonas-client xmlns="http://www.objectweb.org/jonas/ns"
-              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-              xsi:schemaLocation="http://www.objectweb.org/jonas/ns
-              http://www.objectweb.org/jonas/ns/jonas-client_4_0.xsd">
-
-  <jonas-resource>
-    <res-ref-name>url/jonas</res-ref-name>
-    <jndi-name>http://jonas.objectweb.org</jndi-name>
-  </jonas-resource>
-
-  <jonas-security>
-    <jaasfile>jaas.config</jaasfile>
-    <jaasentry>earsample</jaasentry>
-    <username>jonas</username>
-    <password>jonas</password>
-  </jonas-security>
-
-</jonas-client>
-
      -
      • -
    - -

    Tips

    - -

    Although some characters, such as ">", are legal, it is good practice -to replace them with XML entity references.

    - -

    The following is a list of the predefined entity references for XML:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    &lt;<less than
    &gt;>greater than
    &amp;&ampersand
    &apos;'apostrophe
    &quot;"quotation mark
    - -

    - -

    Client Packaging

    - -

    Principles

    - -

    Client components are packaged for deployment in a standard Java -programming language Archive file called a jar file (Java ARchive). -The document root contains a subdirectory called META-INF, which -contains the following files and directories:

    -
      -
    • application-client.xml: The standard xml deployment descriptor - in the format defined in the J2EE 1.4 Specification. Refer to - $JONAS_ROOT/xml/application-client_1_4.xsd.
      • -
    • jonas-client.xml: The optional JOnAS specific xml deployment - descriptor in the format defined in - $JONAS_ROOT/xml/jonas-client_X_Y.xsd.
      • -
    - -

    The manifest of this client jar must contain the name of the class to -launch (containing the main method). This is defined by the value of the -Main-Class attribute of the manifest file.
    -For a standalone client (not bundled in an Ear), all the Ejb classes (except -the skeleton) on which lookups will be performed must be included.

    - -

    Example

    - -

    Two examples of building a java client are provided.
    -

    -
      -
    • The first is the build.xml of the - earsample example with a java client inside the ear.
      - Refer to the client1jar and client2jar targets.
      • -
    • The second is the build.xml of the - jaasclient example with a java standalone client which - performs a lookup on an EJB.
      - Refer to the clientjars target.
      • -
    - - diff --git a/jonas_doc/olddoc/PG_Connector.html b/jonas_doc/olddoc/PG_Connector.html deleted file mode 100644 index 1fed0171181df09210c13de6e887f058e543c030..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/PG_Connector.html +++ /dev/null @@ -1,352 +0,0 @@ - - - - - - - J2EE Connector Programmer's Guide - - - -

    J2EE Connector Programmer's Guide

    - -

    The content of this guide is the following:

    -
      -
    1. Target Audience and Content
      2. -
    2. Principles
      3. -
    3. Defining the JOnAS Connector - Deployment Descriptor
      4. -
    4. Resource Adapter (RAR) - Packaging
      5. -
    5. Use and Deployment of a Resource - Adapter
      6. -
    6. JDBC Resource Adapters
      7. -
    7. Appendix: Connector Architecture - Principles
      8. -
    - -

    Target Audience and Content

    - -

    This chapter is provided for advanced JOnAS users concerned with EAI -(Enterprise Application Integration) and using the J2EE Connector -Architecture principles (refer to the Appendix for an introduction to the connectors). -The target audience for this guide is the Resource Adapter deployer and -programmer. It describes the JOnAS specific deployment file -(jonas-ra.xml) and the sample code to access deployed RARs.

    - -

    Principles

    - -

    Resource Adapters are packaged for deployment in a standard Java -programming language Archive file called a rar file (Resource -ARchive), which is described in the J2EE Connector Architecture -specification.

    - -

    The standard method for creating the jonas-ra.xml file is to use -the RAConfig tool. For a complete description refer to RAConfig.

    - -

    Defining the JOnAS Connector -Deployment Descriptor

    - -

    The jonas-ra.xml contains JOnAS specific information describing -deployment information, logging, pooling, jdbc connections, and RAR config -property values.

    -
      -
    • Deployment Tags: -
        -
      • jndiname: (Required) Name the RAR will be registered as. This value - will be used in the resource-ref section of an EJB.
        • -
      • rarlink: Jndiname of a base RAR file. Useful for deploying - multiple connection factories without having to deploy the complete - RAR file again. When this is used, the only entry in RAR is a - META-INF/jonas-ra.xml.
        • -
      • native-lib: Directory where additional files in the RAR should be - deployed.
        • -
      -
      • -
    • Logging Tags: -
        -
      • log-enabled: Determines if logging should be enabled for the - RAR.
        • -
      • log-topic: Log topic to use for the PrintWriter logger, which - allows a separate handler for each deployed RAR.
        • -
      -
      • -
    • Pooling Tags: -
        -
      • pool-init: Initial size of the managed connection pool.
        • -
      • pool-min: Minimum size of the managed connection pool.
        • -
      • pool-max: Maximum size of the managed connection pool. Value of -1 - is unlimited.
        • -
      • pool-max-age: Maximum number of milliseconds to keep the managed - connection in the pool. Value of 0 is an unlimited amount of - time.
        • -
      • pstmt-max: Maximum number of PreparedStatements per managed - connection in the pool. Only needed with the JDBC RA of JOnAS or - another database vendor's RAR. Value of 0 is unlimited and -1 - disables the cache.
        • -
      -
      • -
    • JDBC Connection Tags: Only valid with a Connection - implementation of java.sql.Connection. -
        -
      • jdbc-check-level: Level of checking that will be done for the jdbc - connection. Values are 0 for no checking, 1 to validate that the - connection is not closed before returning it, and greater than 1 to - send the jdbc-test-statement.
        • -
      • jdbc-test-statement: Test SQL statement sent on the connection if - the jdbc-check-level is set accordingly.
        • -
      -
      • -
    • Config Property Value Tags: -
        -
      • Each entry must correspond to the config-property specified in the - ra.xml of the RAR file. The default values specified in the ra.xml will - be loaded first and any values set in the jonas-ra.xml will - override the specified defaults.
        • -
      -
      • -
    - -

    Deployment Descriptor Examples

    - -

    The following portion of a jonas-ra.xml file shows the linking to -a base RAR file named BaseRar. All properties from the base RAR will be -inherited and any values given in this jonas-ra.xml will override -the other values.

    -
      <jonas-resource>
-    <jndiname>rar1</jndiname>
-    <rarlink>BaseRar</rarlink>
-    <native-lib>nativelib</native-lib>
-    <log-enabled>false</log-enabled>
-    <log-topic>com.xxx.rar1</log-topic>
-    <jonas-config-property>
-      <jonas-config-property-name>ip</jonas-config-property-name>
-      <jonas-config-property-value>www.xxx.com</jonas-config-property-value>
-    </jonas-config-property>
-    .
-    .
-  </jonas-resource>
    - -

    The following portion of a jonas-ra.xml file shows the -configuration of a jdbc rar file.

    -
      <jonas-resource>
-    <jndiname>jdbc1</jndiname>
-    <rarlink></rarlink>
-    <native-lib>nativelib</native-lib>
-    <log-enabled>false</log-enabled>
-    <log-topic>com.xxx.jdbc1</log-topic>
-    <pool-params>
-      <pool-init>0</pool-init>
-      <pool-min>0</pool-min>
-      <pool-max>100</pool-max>
-      <pool-max-age>0</pool-max-age>
-      <pstmt-max>20</pstmt-max>
-    </pool-params>
-    <jdbc-conn-params>
-      <jdbc_check-level>2</jdbc_check-level>
-      <jdbc-test-statement>select 1</jdbc-test-statement>
-    </jdbc-conn-params>
-    <jonas-config-property>
-      <jonas-config-property-name>url</jonas-config-property-name>
-      <jonas-config-property-value>jdbc:oracle:thin:@test:1521:DB1</jonas-config-property-value>
-    </jonas-config-property>
-    .
-    .
-  </jonas-resource>
    - -

    Resource Adapter (RAR) Packaging

    - -

    Resource Adapters are packaged for deployment in a standard Java -programming language Archive file called an RAR file (Resource -Adapter ARchive). This file can contain the following:

    -
    -
    Resource Adapters' deployment descriptor
    -
    The RAR file must contain the deployment descriptors, which are made - up of: -
      -
    • The standard xml deployment descriptor, in the format defined in - the J2EE 1.4 specification. Refer to - $JONAS_ROOT/xml/connector_1_5.xsd or  - http://java.sun.com/xml/ns/j2ee/connector_1_5.xsd. - This deployment descriptor must be stored with the name META-INF/ra.xml in - the RAR file.
      • -
    • The JOnAS-specific XML deployment descriptor in the format - defined in $JONAS_ROOT/xml/jonas-ra_X_Y.xsd. This JOnAS - deployment descriptor must be stored with the name - META-INF/jonas-ra.xml in the RAR file.
      • -
    -
    -
    -
    -
    Resource adapter components (jar)
    -
    One or more jars which contain the java interfaces, implementation, - and utility classes required by the resource adapter.
    -
    Platform-specific native libraries
    -
    One or more native libraries used by the resource adapter
    -
    Misc
    -
    One or more html, image files, or locale files used by the resource - adapter.
    -
    - -

    Before deploying an RAR file, the JOnAS-specific XML must be configured -and added. Refer to the RAConfig -section for information.

    - -

    Use and Deployment of a Resource -Adapter

    - -

    Accessing Resource Adapter involves the following steps:

    -
      -
    • The bean provider must specify the connection factory requirements by - declaring a resource manager connection factory reference in its - EJB deployment descriptor. For example: - 
            <resource-ref>
-        <res-ref-name>eis/MyEIS</res-ref-name>
-        <res-type>javax.resource.cci.ConnectionFactory</res-type>
-        <res-auth>Container</res-auth>
-      </resource-ref>
-
      - The mapping to the actual JNDI name of the connection factory - (here adapt_1) is done in the JOnAS-specific deployment - descriptor with the following element: - 
            <jonas-resource>
-        <res-ref-name>eis/MyEIS</res-ref-name>
-        <jndi-name>adapt_1</jndi-name>
-      </jonas-resource>
      -

      This means that the bean programmer will have access to a - connection factory instance using the JNDI interface via the - java:comp/env/eis/MyEIS name:

      - 
           // obtain the initial JNDI naming context
-     Context inictx = new InitialContext();
-
-     // perform JNDI lookup to obtain the connection factory
-     javax.resource.cci.ConnectionFactory cxf =
-             (javax.resource.cci.ConnectionFactory)
-                  inictx .lookup("java:comp/env/eis/MyEIS");
      - The bean programmer can then get a connection by calling the method - getConnection on the connection factory. - 
            javax.resource.cci.Connection cx = cxf.getConnection();
-
      - The returned connection instance represents an application-level handle - to a physical connection for accessing the underlying EIS.
      - After finishing with the connection, it must be closed using the - close method on the Connection interface: - 
               cx.close();
-
      -
      • -
    • -
        -
      • The resource adapter must be deployed before being used by the - application. Deploying the resource adapter requires the following: -
          -

        • Build a JOnAS-specific resource adapter configuration - file that will be included in the resource adapter.
          - This jonas-ra XML file is used to configure the resource adapter in - the operational environment and reflects the values of all - properties declared in the deployment descriptor for the resource - adapter, plus additional JOnAS-specific configuration properties. - JOnAS provides a deployment tool RAConfig that is - capable of building this XML file from an RA deployment descriptor - inside an RAR file. Example:

          - 
                     RAConfig -path . -j adap_1 ra
-
          - These properties may be specific for each resource adapter and its - underlying EIS. They are used to configure the resource adapter via - its managedConnectionFactory class. It is mandatory - that this class provide getter and setter method for each of its - supported properties (as it is required in the Connector - Architecture specification). -

          After configuring the jonas-ra.xml file created above, it can be - added to the resource adapter by executing the following:

          - 
                     RAConfig -u jonas-ra.xml ra
-
          - This will add the xml file to the ra.rar file, which is now ready - for deployment.
          • -
        -
        • -
      • The JOnAS resource service must be configured and started at - JOnAS launching time:
        - In the jonas.properties file: -
          -
        • Verify that the name resource is included in the - jonas.services property.
          • -
        • Use one of the following methods to deploy an RAR file: -
            -
          • The names of the resource adapter files (the '.rar' - suffix is optional) must be added in the list of Resource - Adapters to be used in the - jonas.service.resource.resources property. If the - '.rar' suffix is not used on the property, it will be used when - trying to allocate the specified Resource Adapter. - 
                     jonas.service.resource.resources  MyEIS.rar, MyEIS1
-
            -
            • -
          • Place the RAR file in the connectors autoload directory of - $JONAS_BASE, default value is $JONAS_BASE/rars/autoload. Note - that it may be different if - jonas.service.resource.autoload in - jonas.properties is configured differently.
            • -
          • Add the RAR via the "jonas admin -a xxx.rar" - command.
            • -
          • Add the RAR via the JonasAdmin console.
            • -
          -
          • -
        -
        • -
      -
      • -
    - -

    JDBC Resource Adapters

    - -

    These generic JDBC resource adapters are supplied by JOnAS and are a -replacement for the DBM service. Refer to Configuring JDBC Resource -Adapters for a complete description and usage guide.

    - -

    Appendix: Connector Architecture -Principles

    - -

    The Java Connector Architecture allows the connection of different -Enterprise Information Systems (EIS) to an application server such as JOnAS. -It defines a way for enterprise applications (based on EJB, servlet, JSP or -J2EE clients) to communicate with existing EIS. This requires the use of a -third party software component called "Resource Adapter" for each type of -EIS, which should be previously deployed on the application server. The -Resource Adapter is an architecture component comparable to a software -driver, which connects the EIS, the application server, and the enterprise -application (J2EE components in the case of JOnAS as application server). The -RA provides an interface (the Common Client Interface or CCI) to the -enterprise application (J2EE components) for accessing the EIS. The RA also -provides standard interfaces for plugging into the application server, so -that they can collaborate to keep all system-level mechanisms (transactions, -security, and connection management) transparent from the application -components.

    - - -

    The resource adapter plugs into JOnAS and provides connectivity between -the EIS, JOnAS, and the application. The application performs "business -logic" operations on the EIS data using the RA client API (CCI), while -transactions, connections (including pooling), and security on the EIS is -managed by JOnAS through the RA (system contract).

    - - diff --git a/jonas_doc/olddoc/PG_Deployment.html b/jonas_doc/olddoc/PG_Deployment.html deleted file mode 100644 index 5653807ccdc1e6ac0b9ccbeaaa29390c2e2734c1..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/PG_Deployment.html +++ /dev/null @@ -1,329 +0,0 @@ - - - - - - - Defining the Deployment Descriptor - - - -

    EJB Programmer's Guide: Defining the -Deployment Descriptor

    - -

    Target Audience and Content

    - -

    The target audience for this guide is the Enterprise Bean provider, i.e. -the person in charge of developing the software components on the server -side. It describes how the bean provider should build the deployment -descriptors of its components.

    - -

    The content of this guide is the following:

    -
      -
    1. Target Audience and Content
      2. -
    2. Principles
      3. -
    3. Example of Session Descriptors
      4. -
    4. Example of Container-managed - Persistence Entity Descriptors (CMP1.1)
      5. -
    5. Tips
      6. -
    - -

    Principles

    - -

    The bean programmer is responsible for providing the deployment descriptor -associated with the developed Enterprise Beans. The Bean Provider's -responsibilities and the Application Assembler's responsibilities is to -provide an XML deployment descriptor that conforms to the deployment -descriptor's XML schema as defined in the EBJ specification version 2.1. (Refer -to $JONAS_ROOT/xml/ejb-jar_2_1.xsd or  -http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd).

    - - -

    To deploy Enterprise JavaBeans on the EJB server, information not defined -in the standard XML deployment descriptor may be needed. For example, this -information may include the mapping of the bean to the underlying database -for an entity bean with container-managed persistence. This information is -specified during the deployment step in another XML deployment descriptor -that is specific to JOnAS. The JOnAS-specific deployment descriptor's XML schema -is located in $JONAS_ROOT/xml/jonas-ejb-jar_X_Y.xsd. The file -name of the JOnAS-specific XML deployment descriptor must be the file name of -the standard XML deployment descriptor prefixed by 'jonas-'.

    - -

    The parser gets the specified schema via the classpath (schemas are packaged -in the $JONAS_ROOT/lib/common/ow_jonas.jar file).

    - -

    The standard deployment descriptor should contain structural information -for each enterprise bean that includes the following:

    -
      -
    • the Enterprise bean's name,
      • -
    • the Enterprise bean's class,
      • -
    • the Enterprise bean's home interface,
      • -
    • the Enterprise bean's remote interface,
      • -
    • the Enterprise bean's type,
      • -
    • a re-entrancy indication for the entity bean,
      • -
    • the session bean's state management type,
      • -
    • the session bean's transaction demarcation type,
      • -
    • the entity bean's persistence management,
      • -
    • the entity bean's primary key class,
      • -
    • container-managed fields,
      • -
    • environment entries,
      • -
    • the bean's EJB references,
      • -
    • resource manager connection factory references,
      • -
    • transaction attributes.
      • -
    - -

    The JOnAS-specific deployment descriptor contains information for each -enterprise bean including:

    -
      -
    • the JNDI name of the Home object that implement the Home interface of - the enterprise bean,
      • -
    • the JNDI name of the DataSource object corresponding to the resource - manager connection factory referenced in the enterprise bean's class,
      • -
    • the JNDI name of each EJB references,
      • -
    • the JNDI name of JMS administered objects,
      • -
    • information for the mapping of the bean to the underlying database, if - it is an entity with container-managed persistence.
      • -
    - -

    - -

    Example of Session Descriptors

    -
    <?xml version="1.0" encoding="ISO-8859-1"?>
-<ejb-jar xmlns="http://java.sun.com/xml/ns/j2ee"
-         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
-         http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd"
-         version="2.1">
-  <description>Here is the description of the test's beans</description>
-  <enterprise-beans>
-    <session>
-      <description>... Bean example one ...</description>
-      <display-name>Bean example one</display-name>
-      <ejb-name>ExampleOne</ejb-name>
-      <home>tests.Ex1Home</home>
-      <remote>tests.Ex1</remote>
-      <ejb-class>tests.Ex1Bean</ejb-class>
-      <session-type>Stateful</session-type>
-      <transaction-type>Container</transaction-type>
-      <env-entry>
-        <env-entry-name>name1</env-entry-name>
-        <env-entry-type>java.lang.String</env-entry-type>
-        <env-entry-value>value1</env-entry-value>
-      </env-entry>
-      <ejb-ref>
-        <ejb-ref-name>ejb/ses1</ejb-ref-name>
-        <ejb-ref-type>session</ejb-ref-type>
-        <home>tests.SS1Home</home>
-        <remote>tests.SS1</remote>
-      </ejb-ref>
-      <resource-ref>
-        <res-ref-name>jdbc/mydb</res-ref-name>
-        <res-type>javax.sql.DataSource</res-type>
-        <res-auth>Application</res-auth>
-      </resource-ref>
-    </session>
-  </enterprise-beans>
-  <assembly-descriptor>
-    <container-transaction>
-      <method>
-        <ejb-name>ExampleOne</ejb-name>
-        <method-name>*</method-name>
-      </method>
-      <trans-attribute>Required</trans-attribute>
-    </container-transaction>
-    <container-transaction>
-      <method>
-        <ejb-name>ExampleOne</ejb-name>
-        <method-inter>Home</ejb-name>
-        <method-name>*</method-name>
-      </method>
-      <trans-attribute>Supports</trans-attribute>
-    </container-transaction>
-    <container-transaction>
-      <method>
-        <ejb-name>ExampleOne</ejb-name>
-        <method-name>methodOne</method-name>
-      </method>
-      <trans-attribute>NotSupported</trans-attribute>
-    </container-transaction>
-    <container-transaction>
-      <method>
-        <ejb-name>ExampleOne</ejb-name>
-        <method-name>methodTwo</method-name>
-        <method-params><method-param>int</method-param></method-params>
-      </method>
-      <trans-attribute>Mandatory</trans-attribute>
-    </container-transaction>
-    <container-transaction>
-      <method>
-        <ejb-name>ExampleOne</ejb-name>
-        <method-name>methodTwo</method-name>
-        <method-params><method-param>java.lang.String</method-param></method-params>
-      </method>
-      <trans-attribute>NotSupported</trans-attribute>
-    </container-transaction>
-  </assembly-descriptor>
-</ejb-jar>
-
-
-<?xml version="1.0" encoding="ISO-8859-1"?>
-<jonas-ejb-jar xmlns="http://www.objectweb.org/jonas/ns"
-               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-               xsi:schemaLocation="http://www.objectweb.org/jonas/ns
-               http://www.objectweb.org/jonas/ns/jonas-ejb-jar_4_0.xsd" >
-  <jonas-session>
-    <ejb-name>ExampleOne</ejb-name>
-    <jndi-name>ExampleOneHome</jndi-name>
-    <jonas-ejb-ref>
-      <ejb-ref-name>ejb/ses1</ejb-ref-name>
-      <jndi-name>SS1Home_one</jndi-name>
-    </jonas-ejb-ref>
-    <jonas-resource>
-      <res-ref-name>jdbc/mydb</res-ref-name>
-      <jndi-name>jdbc_1</jndi-name>
-    </jonas-resource>
-  </jonas-session>
-</jonas-ejb-jar>
-
    - -

    Example of Container-managed -Persistence Entity Descriptors (CMP 1.1)

    -
    <?xml version="1.0" encoding="ISO-8859-1"?>
-<ejb-jar xmlns="http://java.sun.com/xml/ns/j2ee"
-         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
-         http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd"
-         version="2.1">
-         
-  <description>Here is the description of the test's beans</description>
-  <enterprise-beans>
-    <entity>
-      <description>... Bean example one ...</description>
-      <display-name>Bean example two</display-name>
-      <ejb-name>ExampleTwo</ejb-name>
-      <home>tests.Ex2Home</home>
-      <remote>tests.Ex2</remote>
-      <local-home>tests.Ex2LocalHome</local-home>
-      <local>tests.Ex2Local</local>
-      <ejb-class>tests.Ex2Bean</ejb-class>
-      <persistence-type>Container</persistence-type>
-      <prim-key-class>tests.Ex2PK</prim-key-class>
-      <reentrant>False</reentrant>
-      <cmp-version>1.x</cmp-version>
-      <cmp-field>
-        <field-name>field1</field-name>
-      </cmp-field>
-      <cmp-field>
-        <field-name>field2</field-name>
-      </cmp-field>
-      <cmp-field>
-        <field-name>field3</field-name>
-      </cmp-field>
-      <primkey-field>field3</primkey-field>
-      <env-entry>
-        <env-entry-name>name1</env-entry-name>
-        <env-entry-type>java.lang.String</env-entry-type>
-        <env-entry-value>value1</env-entry-value>
-      </env-entry>
-    </entity>
-  </enterprise-beans>
-  <assembly-descriptor>
-    <container-transaction>
-      <method>
-        <ejb-name>ExampleTwo</ejb-name>
-        <method-name>*</method-name>
-      </method>
-      <trans-attribute>Supports</trans-attribute>
-    </container-transaction>
-  </assembly-descriptor>
-</ejb-jar>
-
-
-<?xml version="1.0" encoding="ISO-8859-1"?>
-<jonas-ejb-jar xmlns="http://www.objectweb.org/jonas/ns"
-               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-               xsi:schemaLocation="http://www.objectweb.org/jonas/ns
-               http://www.objectweb.org/jonas/ns/jonas-ejb-jar_4_0.xsd" >
-  <jonas-entity>
-    <ejb-name>ExampleTwo</ejb-name>
-    <jndi-name>ExampleTwoHome</jndi-name>
-    <jndi-local-name>ExampleTwoLocalHome</jndi-local-name>
-    <jdbc-mapping>
-      <jndi-name>jdbc_1</jndi-name>
-      <jdbc-table-name>YourTable</jdbc-table-name>
-      <cmp-field-jdbc-mapping>
-        <field-name>field1</field-name>
-        <jdbc-field-name>dbf1</jdbc-field-name>
-      </cmp-field-jdbc-mapping>
-      <cmp-field-jdbc-mapping>
-        <field-name>field2</field-name>
-        <jdbc-field-name>dbf2</jdbc-field-name>
-      </cmp-field-jdbc-mapping>
-      <cmp-field-jdbc-mapping>
-        <field-name>field3</field-name>
-        <jdbc-field-name>dbf3</jdbc-field-name>
-      </cmp-field-jdbc-mapping>
-      <finder-method-jdbc-mapping>
-        <jonas-method>
-          <method-name>findByField1</method-name>
-        </jonas-method>
-        <jdbc-where-clause>where dbf1 = ?</jdbc-where-clause>
-      </finder-method-jdbc-mapping>
-    </jdbc-mapping>
-  </jonas-entity>
-</jonas-ejb-jar>
-
    - -

    Tips

    - -

    Although some characters, such as ">", are legal, it is good practice -to replace them with XML entity references.

    - -

    The following is a list of the predefined entity references for XML:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    &lt;<less than
    &gt;>greater than
    &amp;&ampersand
    &apos;'apostrophe
    &quot;"quotation mark
    - - diff --git a/jonas_doc/olddoc/PG_EarDeployment.html b/jonas_doc/olddoc/PG_EarDeployment.html deleted file mode 100644 index 3e8821dbdc5bc08e3de614faa3953723badc55f4..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/PG_EarDeployment.html +++ /dev/null @@ -1,236 +0,0 @@ - - - - - - - J2EE Application Assembler's Guide - - - -

    J2EE Application Assembler's Guide

    - -

    Target Audience and Content

    - -

    The target audience for this guide is the Application Provider and -Assembler, i.e. the person in charge of combining one or more components -(ejb-jars and/or wars) to create a J2EE application. It describes how the -J2EE components should be packaged to create a J2EE application.

    - -

    The content of this guide is the following:

    -
      -
    1. Target Audience and Content
      2. -
    2. Defining the Ear Deployment - Descriptor - -
      3. -
    3. EAR Packaging
      4. -
    - -

    Defining the Ear Deployment -Descriptor

    - -

    Principles

    - -

    The application programmer is responsible for providing the deployment -descriptor associated with the developed application (Enterprise ARchive). -The Application Assembler's responsibilities is to provide a XML deployment -descriptor that conforms to the deployment descriptor's XML schema as defined in -the J2EE specification version 1.4. (Refer to -$JONAS_ROOT/xml/application_1_4.xsd or  -http://java.sun.com/xml/ns/j2ee/application_1_4.xsd).

    - -

    To deploy J2EE applications on the application server, all information is -contained in one XML deployment descriptor. The file name for the application -XML deployment descriptor is application.xml and it must be -located in the top level META-INF directory.

    - -

    The parser gets the specified schema via the classpath (schemas are packaged -in the $JONAS_ROOT/lib/common/ow_jonas.jar file).

    - -

    Some J2EE application examples are provided in the JOnAS distribution:

    -
      -
    • $JONAS_ROOT/examples/alarm for The Alarm demo
      • -
    • $JONAS_ROOT/examples/cmp2 for The Cmp2 example
      • -
    • $JONAS_ROOT/examples/earsample for The EarSample example
      • -
    • $JONAS_ROOT/examples/petstore1.3 for The Blueprints Petstore application
      • -
    - -

    The standard deployment descriptor should contain structural information -that includes the following:

    -
      -
    • EJB components,
      • -
    • Web components,
      • -
    • Client components,
      • -
    • Alternate Deployment Descriptor for theses components,
      • -
    • Security role.
      • -
    - -

    There is no JOnAS-specific deployment descriptor for the Enterprise -ARchive.

    - -

    - -

    Simple example of Application -Deployment Descriptor

    -
    <?xml version="1.0" encoding="UTF-8"?>
-
-<application xmlns="http://java.sun.com/xml/ns/j2ee"
-             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-             xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
-             http://java.sun.com/xml/ns/j2ee/application_1_4.xsd"
-             version="1.4">
-
-  <display-name>Simple example of application</display-name>
-  <description>Simple example</description>
-
-  <module>
-    <ejb>ejb1.jar</ejb>
-  </module>
-  <module>
-    <ejb>ejb2.jar</ejb>
-  </module>
-
-  <module>
-    <web>
-      <web-uri>web.war</web-uri>
-      <context-root>web</context-root>
-    </web>
-  </module>
-</application>
-
    - -

    Advanced example of Application -Deployment Descriptors with alternate DD and security

    -
    <?xml version="1.0" encoding="UTF-8"?>
-
-<application xmlns="http://java.sun.com/xml/ns/j2ee"
-             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-             xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
-             http://java.sun.com/xml/ns/j2ee/application_1_4.xsd"
-             version="1.4">
-
-  <display-name>Ear Security</display-name>
-  <description>Application with alt-dd and security</description>
-  <module>
-    <web>
-      <web-uri>admin.war</web-uri>
-      <context-root>admin</context-root>
-    </web>
-  </module>
-  <module>
-    <ejb>ejb.jar</ejb>
-    <alt-dd>altdd.xml</alt-dd>
-  </module>
-  <security-role>
-    <role-name>admin</role-name>
-  </security-role>
-</application>
-
    - -

    Tips

    - -

    Although some characters, such as ">", are legal, it is good practice -to replace them with XML entity references.

    - -

    The following is a list of the predefined entity references for XML:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    &lt;<less than
    &gt;>greater than
    &amp;&ampersand
    &apos;'apostrophe
    &quot;"quotation mark
    - -

    - -

    EAR Packaging

    - -

    J2EE applications are packaged for deployment in a standard Java -programming language Archive file called an ear file (Enterprise -ARchive). This file can contain the following:

    -
    -
    The web components (war)
    -
    One or more wars which contain the web components of the J2EE - application. Due to the class loader hierarchy, when the wars are - packaged in a J2EE application, it is not necessary to package classes - of EJBs accessed by the web components in the WEB-INF/lib - directory.
    - Details about this class loader hierarchy are described in JOnAS class loader - hierarchy.
    -
    The EJB components (ejb-jar)
    -
    One or more ejb-jars, which contain the beans of the J2EE - application.
    -
    The RAR components (resource adapters)
    -
    One or more rars, which contain the resource adapters of the J2EE - application.
    -
    The libraries (jar)
    -
    One or more jars which contain the libraries (tag libraries and any - utility libraries) used for the J2EE application.
    -
    The J2EE deployment descriptor
    -
    The standard xml deployment descriptor in the format defined in the - J2EE 1.4 specification. See - $JONAS_ROOT/xml/application_1_4.xsd. This deployment - descriptor must be stored with the name - META-INF/application.xml in the ear file.
    -
    - -

    Example

    - -

    Before building an ear file for a J2EE application, the ejb-jars and the -wars that will be packaged in the J2EE application must be built and the XML -deployment descriptor (application.xml) must be written.

    - -

    Then, the ear file (<j2ee-application>.ear) can be -built using the jar command:

    -
        cd <your_j2ee_application_directory>
-    jar cvf <j2ee-application>.ear *
-
    - - diff --git a/jonas_doc/olddoc/PG_Entity.html b/jonas_doc/olddoc/PG_Entity.html deleted file mode 100644 index ea1cc2154a635de68b9d0dcfc33561531a351d6d..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/PG_Entity.html +++ /dev/null @@ -1,2999 +0,0 @@ - - - - - - Developing Entity Beans - - - - -

    EJB Programmer's Guide: Developing Entity -Beans

    - -

    Target Audience and Content

    -The target audience for this guide is the Enterprise Bean provider, i.e. the -person in charge of developing the software components on the server side, -and more specifically the Entity Beans. - -

    The content of this guide is the following:

    -
      -
    1. Target Audience and content
      2. -
    2. Introduction
      3. -
    3. The Home Interface
      4. -
    4. The Component Interface
      5. -
    5. The Primary Key Class
      6. -
    6. The Enterprise Bean Class
      7. -
    7. Writing Database Access Operations - (bean-managed persistence)
      8. -
    8. Configuring Database Access for - Container-managed Persistence
      9. -
    9. Tuning Container for Entity Bean - Optimizations
      10. -
    10. Using CMP2.0 Persistence - -
      11. -
    - -

    Introduction

    -An Entity Bean is comprised of the following elements, which are developed by -the Enterprise Bean Provider: -
      -
    • The Component Interface is the client view of the bean. It - contains all the "business methods" of the bean.
      • -
    • The Home Interface contains all the methods for the bean life - cycle (creation, suppression) and for instance retrieval (finding one or - several bean objects) used by the client application. It can also contain - methods called "home methods," supplied by the bean provider, for - business logic which is not specific to a bean instance.
      • -
    • The Primary Key class (for entity beans only) contains a subset - of the bean's fields that identifies a particular instance of an entity - bean. This class is optional since the bean programmer can alternatively - choose a standard class (for example, java.lang.String)
      • -
    • The bean implementation class implements the business methods - and all the methods (described in the EJB specification) allowing the - bean to be managed in the container.
      • -
    • The deployment descriptor, containing the bean properties that - can be edited at assembly or deployment time.
      • -
    -Note that, according to the EJB 2.0 specification, the couple "Component -Interface and Home Interface" can be either local or remote. Local -Interfaces (Home and Component) are to be used by a client running in the -same JVM as the EJB component. Create and finder methods of a local (or -remote) home interface return local (or remote) component interfaces. An EJB -component may have both remote and local interfaces, even if normally only -one type of interface is provided. If an entity bean is the target of a -container-managed relationship (refer to EJB 2.0 persistence), then it must -have local interfaces. - -

    The description of these elements is provided in the following -sections.

    - -

    Note that in this documentation, the term "Bean" always means "Enterprise -Bean."

    - -

    An entity bean represents persistent data. It is an object view of an -entity stored in a relational database. The persistence of an entity bean can -be handled in two ways:

    -
      -
    • Container-Managed Persistence: the persistence is implicitly - managed by the container, no code for data access is supplied by the bean - provider. The bean's state will be stored in a relational database - according to a mapping description delivered within the deployment - descriptor (CMP 1.1) or according to an implicit mapping (CMP 2.0).
      • -
    • Bean-Managed Persistence: the bean provider writes the database - access operations (JDBC code) in the methods of the enterprise bean that - are specified for data creation, load, store, retrieval, and remove - operations (ejbCreate, ejbLoad, ejbStore, ejbFind..., ejbRemove).
      • -
    -Currently, the platform handles persistence in relational storage systems -through the JDBC interface. For both container-managed and bean-managed -persistence, JDBC connections are obtained from an object provided at the EJB -server level, the DataSource. The DataSource interface is defined in -the JDBC 2.0 standard -extensions. A DataSource object identifies a database and a means to access -it via JDBC (a JDBC driver). An EJB server may propose access to several -databases and thus provides the corresponding DataSource objects. DataSources -are described in more detail in the section "Configuring JDBC DataSources." - -

    The Home Interface

    -In addition to "home business methods," the Home interface is used by any -client application to create, remove, and retrieve instances of the entity -bean. The bean provider only needs to provide the desired interface; the -container will automatically provide the implementation. The interface must -extend the javax.ejb.EJBHome interface if it is remote, or the -javax.ejb.EJBLocalHome interface if it is local. The methods of a -remote home interface must follow the rules for java RMI. The signatures of -the "create" and "find..." methods should match the signatures of the -"ejbCreate" and "ejbFind..." methods that will be provided later in the -enterprise bean implementation class (same number and types of arguments, but -different return types). - -

    create methods:

    -
      -
    • The return type is the enterprise bean's component interface.
      • -
    • The exceptions defined in the throws clause must include the exceptions - defined for the ejbCreate and ejbPostCreate methods, and must include - javax.ejb.CreateException and java.rmi.RemoteException - (the latter, only for a remote interface).
      • -
    -remove methods: -
      -
    • The interfaces for these methods must not be defined, they are - inherited from EJBHome or EJBLocalHome.
      • -
    • The method is void remove taking as argument the primary key - object or the handle (for a remote interface).
      • -
    • The exceptions defined in the throws clause should be - javax.ejb.RemoveException and java.rmi.RemoteException - for a remote interface.
      • -
    • The exceptions defined in the throws clause should be - javax.ejb.RemoveException and java.ejb.EJBException for - a local interface.
      • -
    -finder methods: - -

    Finder methods are used to search for an EJB object or a collection of EJB -objects. The arguments of the method are used by the entity bean -implementation to locate the requested entity objects. For bean-managed -persistence, the bean provider is responsible for developing the -corresponding ejbFinder methods in the bean implementation. For -container-managed persistence, the bean provider does not write these -methods; they are generated at deployment time by the platform tools; the -description of the method is provided in the deployment descriptor, as -defined in the section "Configuring database -access for container-managed persistence." In the Home interface, the -finder methods must adhere to the following rules:

    -
      -
    • They must be named "find<method>" (e.g. - findLargeAccounts).
      • -
    • The return type must be the enterprise bean's component interface, or a - collection thereof.
      • -
    • The exceptions defined in the throws clause must include the exceptions - defined for the matching ejbFind method, and must include - javax.ejb.FinderException and java.rmi.RemoteException - (the latter, only for a remote interface).
      • -
    -At least one of these methods is mandatory: findByPrimaryKey, which -takes as argument a primary key value and returns the corresponding EJB -object. - -

    home methods:

    -
      -
    • Home methods are methods that the bean provider supplies for business - logic that is not specific to an entity bean instance.
      • -
    • The throws clause of every home method on the remote home interface - includes the java.rmi.RemoteException.
      • -
    • Home methods implementation is provided by the bean developer in the - bean implementation class as public static methods named - ejbHome<METHOD_NAME>(...), where <METHOD_NAME> is - the name of the method in the home interface.
      • -
    - -

    Example

    -The Account bean example, provided with the platform examples, is used to -illustrate these concepts. The state of an entity bean instance is stored in -a relational database, where the following table should exist, if CMP 1.1 is -used: - -

    create table ACCOUNT (ACCNO integer primary key, CUSTOMER varchar(30), -BALANCE number(15,4));

    - -

    public interface AccountHome extends EJBHome {

    - -

        public Account create(int accno, String -customer, double balance)
    -        throws RemoteException, -CreateException;

    - -

        public Account findByPrimaryKey(Integer -pk)
    -        throws RemoteException, -FinderException;

    - -

        public Account findByNumber(int accno) -
    -        throws RemoteException, -FinderException;

    - -

        public Enumeration findLargeAccounts(double -val)
    -        throws RemoteException, -FinderException;
    -}

    - -

    The Component Interface

    -Business methods: - -

    The Component Interface is the client's view of an instance of the entity -bean. It is what is returned to the client by the Home interface after -creating or finding an entity bean instance. This interface contains the -business methods of the enterprise bean. The interface must extend the -javax.ejb.EJBObject interface if it is remote, or the -javax.ejb.EJBLocalObject if it is local. The methods of a remote -component interface must follow the rules for java RMI. For each method -defined in this component interface, there must be a matching method of the -bean implementation class (same arguments number and types, same return type, -same exceptions except for RemoteException).

    - -

    Example

    -public interface Account extends EJBObject {
    -    public double getBalance() throws -RemoteException;
    -    public void setBalance(double d) throws -RemoteException;
    -    public String getCustomer() throws -RemoteException;
    -    public void setCustomer(String c) throws -RemoteException;
    -    public int getNumber() throws -RemoteException;
    -} - -

    The Primary Key Class

    -The Primary Key class is necessary for entity beans only. It encapsulates the -fields representing the primary key of an entity bean in a single object. If -the primary key in the database table is composed of a single column with a -basic data type, the simplest way to define the primary key in the bean is to -use a standard java class (for example, java.lang.Integer or -java.lang.String). This must have the same type as a field in the -bean class. It is not possible to define it as a primitive field (for -example, int, float or boolean). Then, it is only necessary to specify the -type of the primary key in the deployment descriptor: -
          <prim-key-class>java.lang.Integer</prim-key-class>
    -And, for container-managed persistence, the field which represents the -primary key: -
          <primkey-field>accno</primkey-field>
    -The alternative way is to define its own Primary Key class, described as -follows: - -

    The class must be serializable and must provide suitable implementation of -the hashcode() and equals(Object) methods.

    - -

    For container-managed persistence, the following rules must be -followed:

    -
      -
    • The fields of the primary key class must be declared as public.
      • -
    • The primary key class must have a public default constructor.
      • -
    • The names of the fields in the primary key class must be a subset of - the names of the container-managed fields of the enterprise bean.
      • -
    - -

    Example

    -public class AccountBeanPK implements java.io.Serializable { - -
    - public int accno; - -

    public AccountBeanPK(int accno) { this.accno = accno; }

    - -

    public AccountBeanPK() { }

    -
    - -
    - public int hashcode() { return accno; }
    - -
    - public boolean equals(Object other) { - -
    - ...
    - }
    -} - -

    Special case: Automatic generation of primary keys field

    - -

    There are two ways to manage the automatic primary key with JOnAS. The -first method is closer to what is described in the EJB specification, i.e. an -automatic PK is a hidden field, the type of which is not known even by the -application. The second method is to declare a usual PK CMP field of type -java.lang.Integer as automatic. The two cases are described below.

    - -

    1) Standard automatic primary keys (from JOnAS 4.0.0)

    - -

    In this case, an automatic PK is a hidden field, the type of which is not -known even by the application. All that is necessary is to stipulate in the -standard deployment descriptor that this EJB has an automatic PK, by -specifying java.lang.Object as primkey-class. The primary key will be -completely hidden to the application (no CMP field, no getter/setter method). -This is valid for both CMP 2.x and CMP1 entity beans. The container will -create an internal CMP field and generate its value when the entity bean is -created.

    - -

    Example:

    - -

    Standard deployment descriptor:

    -
      <entity>
-    ...
-    <ejb-name>AddressEJB</ejb-name>
-    <local-home>com.titan.address.AddressHomeLocal</local-home>
-    <local>com.titan.address.AddressLocal</local>
-    <ejb-class>com.titan.address.AddressBean</ejb-class>
-    <persistence-type>Container</persistence-type>
-    <prim-key-class>java.lang.Object</prim-key-class>
-    <reentrant>False</reentrant>
-    <cmp-version>2.x</cmp-version>
-    <abstract-schema-name>Cmp2_Address</abstract-schema-name>
-    <cmp-field><field-name>street</field-name></cmp-field>
-    <cmp-field><field-name>city</field-name></cmp-field>
-    <cmp-field><field-name>state</field-name></cmp-field>
-    <cmp-field><field-name>zip</field-name></cmp-field>
    - -

    - -

    Address Bean Class extract:

    -
       // Primary key is not explicitly initialized during ejbCreate method
-   // No cmp field corresponds to the primary key
-   public Integer ejbCreateAddress(String street, String city,
-        String state, String zip ) throws javax.ejb.CreateException {
-     setStreet(street);
-     setCity(city);
-     setState(state);
-     setZip(zip);
-     return null;
-   }
    - -

    If nothing else is specified, and the JOnAS default CMP 2 database mapping -is used, the JOnAS container will generate a database column with name -JPK_ to handle this PK. However, it is possible to specify in -the JOnAS-specific Deployment Descriptor the name of the column that will be -used to store the PK value in the table, using the specific -<automatic-pk-field-name> element, as follows (this is necessary for -CMP2 legacy and for CMP1):

    - -

    JOnAS-specific deployment descriptor:

    -
      <jonas-ejb-jar xmlns="http://www.objectweb.org/jonas/ns"
-    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-    xsi:schemaLocation="http://www.objectweb.org/jonas/ns http://www.objectweb.org/jonas/ns/jonas-ejb-jar_4_0.xsd" >
-  <jonas-entity>
-     <ejb-name>AddressEJB</ejb-name>
-     <jdbc-mapping>
-        <jndi-name>jdbc_1</jndi-name>
-        <automatic-pk-field-name>FieldPkAuto</automatic-pk-field-name>
-     </jdbc-mapping>
-  </jonas-entity>
    - -

    2) CMP field as automatic primary key (was already in JOnAS -3.3.x)

    - -

    The idea is to declare a usual PK CMP field of type java.lang.Integer as -automatic, then it no longer appears in create methods and its value is -automatically generated by the container at EJB instance creation time. But -it is still a cmp field, with getter/setter methods, accessible from the -application. Example:

    - -

    In the standard DD, there is a usual primary key definition,

    -
      <entity>
-     ...
-     <prim-key-class>java.lang.Integer</prim-key-class>
-     <cmp-field><field-name>id</field-name></cmp-field>
-     <primkey-field>id</primkey-field>
    - -

    and in the JOnAS-specific Deployment Descriptor, it should be specified -that this PK is automatic,

    -
      <jonas-entity>
-     ...
-     <jdbc-mapping>
-
-     <automatic-pk>true</automatic-pk>
    -

    -Note: The automatic primary key is given a unique ID -by an algorithm that is based on the system time; -therefore, IDs may be not sequential. -

    -

    -Important restriction: This algorithm will not work if used inside -a cluster with the same entity bean that is being managed in several jonas servers. -

    -

    The Enterprise Bean Class

    -The EJB implementation class implements the bean's business methods of the -component interface and the methods dedicated to the EJB environment, the -interface of which is explicitly defined in the EJB specification. The class -must implement the javax.ejb.EntityBean interface, must be defined -as public, cannot be abstract for CMP 1.1, and must be abstract for -CMP 2.0 (in this case, the abstract methods are the get and set accessor -methods of the bean cmp and cmr fields). Following is a list of the EJB -environment dedicated methods that the EJB provider must develop. - -

    The first set of methods are those corresponding to the create and find -methods of the Home interface:

    -
      -
    • public PrimaryKeyClass ejbCreate(...); -

      This method is invoked by the container when a client invokes the - corresponding create operation on the enterprise Bean's home interface. - The method should initialize instance's variables from the input - arguments. The returned object should be the primary key of the created - instance. For bean-managed persistence, the bean provider should develop - here the JDBC code to create the corresponding data in the database. For - container-managed persistence, the container will perform the database - insert after the ejbCreate method completes and the return value - should be null.

      -
      • -
    • public void ejbPostCreate(...); -

      There is a matching ejbPostCreate method (same input parameters) for - each ejbCreate method. The container invokes this method after the - execution of the matching ejbCreate(...) method. During the ejbPostCreate - method, the object identity is available.

      -
      • -
    • public <PrimaryKeyClass or Collection> - ejbFind<method> (...); // bean-managed persistence - only -

      The container invokes this method on a bean instance that is not - associated with any particular object identity (some kind of class method - ...) when the client invokes the corresponding method on the Home - interface. The implementation uses the arguments to locate the requested - object(s) in the database and returns a primary key (or a collection - thereof). Currently, collections will be represented as - java.util.Enumeration objects or - java.util.Collection. The mandatory FindByPrimaryKey - method takes as argument a primary key type value and returns a primary - key object (it verifies that the corresponding entity exists in the - database). For container-managed persistence, the bean provider - does not have to write these finder methods; they are generated at - deployment time by the EJB platform tools. The information needed by the - EJB platform for automatically generating these finder methods should be - provided by the bean programmer. The EJB 1.1 specification does not - specify the format of this finder method description; for JOnAS, - the CMP 1.1 finder methods description should be provided in the - JOnAS-specific deployment descriptor of the Entity Bean (as an SQL - query). Refer to the section "Configuring - database access for container-managed persistence." The EJB 2.0 - specification defines a standard way to describe these finder methods, - i.e. in the standard deployment descriptor, as an EJB-QL query. Also - refer to the section "Configuring - database access for container-managed persistence." Then, the methods - of the javax.ejb.EntityBean interface must be implemented:

      -
        -
      • public void setEntityContext(EntityContext ic); -

        Used by the container to pass a reference to the EntityContext to - the bean instance. The container invokes this method on an instance - after the instance has been created. Generally, this method is used - to store this reference in an instance variable.

        -
        • -
      • public void unSetEntityContext(); -

        Unset the associated entity context. The container calls this - method before removing the instance. This is the last method the - container invokes on the instance.

        -
        • -
      • public void ejbActivate(); -

        The container invokes this method when the instance is taken out - of the pool of available instances to become associated with a - specific EJB object. This method transitions the instance to the - ready state.

        -
        • -
      • public void ejbPassivate(); -

        The container invokes this method on an instance before the - instance becomes dissociated with a specific EJB object. After this - method completes, the container will place the instance into the pool - of available instances.

        -
        • -
      • public void ejbRemove(); -

        This method is invoked by the container when a client invokes a - remove operation on the enterprise bean. For entity beans with - bean-managed persistence, this method should contain the JDBC - code to remove the corresponding data in the database. For - container-managed persistence, this method is called - before the container removes the entity representation in the - database.

        -
        • -
      • public void ejbLoad(); -

        The container invokes this method to instruct the instance to - synchronize its state by loading it from the underlying database. For - bean-managed persistence, the EJB provider should code at this - location the JDBC statements for reading the data in the database. - For container-managed persistence, loading the data from the - database will be done automatically by the container just - before ejbLoad is called, and the ejbLoad method should only - contain some "after loading calculation statements."

        -
        • -
      • public void ejbStore(); -

        The container invokes this method to instruct the instance to - synchronize its state by storing it to the underlying database. For - bean-managed persistence, the EJB provider should code at this - location the JDBC statements for writing the data in the database. - For entity beans with container-managed persistence, this - method should only contain some "pre-store statements," since the - container will extract the container-managed fields and write them to - the database just after the ejbStore method call.

        -

        -
        • -
      -
      • -
    - -

    Example

    - -

    The following examples are for container-managed persistence with EJB 1.1 -and EJB 2.0. For bean-managed persistence, refer to the examples delivered -with your specific platform.

    - -

    CMP 1.1

    -
    package eb;
-
-import java.rmi.RemoteException;
-import javax.ejb.EntityBean;
-import javax.ejb.EntityContext;
-import javax.ejb.ObjectNotFoundException;
-import javax.ejb.RemoveException;
-import javax.ejb.EJBException;
-
-public class AccountImplBean implements EntityBean {
-
-    // Keep the reference on the EntityContext
-    protected EntityContext entityContext;
-
-    // Object state
-    public Integer accno;
-    public String customer;
-    public double balance;
-
-    public Integer ejbCreate(int val_accno, String val_customer, double val_balance) {
-
-        // Init object state
-        accno = new Integer(val_accno);
-        customer = val_customer;
-        balance = val_balance;
-        return null;
-    }
-
-    public void ejbPostCreate(int val_accno, String val_customer, double val_balance) { 
-        // Nothing to be done for this simple example.
-    }
-
-    public void ejbActivate() {
-        // Nothing to be done for this simple example.
-    }
-
-    public void ejbLoad() {
-        // Nothing to be done for this simple example, in implicit persistence.
-    }
-
-    public void ejbPassivate() {
-        // Nothing to be done for this simple example.
-    }
-
-
-    public void ejbRemove() {
-        // Nothing to be done for this simple example, in implicit persistence.
-    }
-
-    public void ejbStore() {
-        // Nothing to be done for this simple example, in implicit persistence.
-    }
-
-    public void setEntityContext(EntityContext ctx) {
-        // Keep the entity context in object
-        entityContext = ctx;
-    }
-
-    public void unsetEntityContext() {
-        entityContext = null;
-    }
-
-    public double getBalance() {
-        return balance;
-    }
-
-    public void setBalance(double d) {
-        balance = balance + d;
-    }
-
-    public String  getCustomer() {
-        return customer;
-    }
-
-    public void setCustomer(String c) {
-        customer = c;
-    }
-
-    public int getNumber()  {
-        return accno.intValue();
-    }
-}
    -CMP 2.0 -
    import java.rmi.RemoteException;
-import javax.ejb.EntityBean;
-import javax.ejb.EntityContext;
-import javax.ejb.ObjectNotFoundException;
-import javax.ejb.RemoveException;
-import javax.ejb.CreateException;
-import javax.ejb.EJBException;
-
-public abstract class AccountImpl2Bean implements EntityBean {
-
-    // Keep the reference on the EntityContext
-    protected EntityContext entityContext;
-
-
-    /*========================= Abstract set and get accessors for cmp fields ==============*/
-
-    public abstract String getCustomer();
-    public abstract void setCustomer(String customer);
-
-    public abstract double getBalance();
-    public abstract void setBalance(double balance);
-
-    public abstract int getAccno();
-    public abstract void setAccno(int accno);
-
-    /*========================= ejbCreate methods ============================*/
-
-
-    public Integer ejbCreate(int val_accno, String val_customer, double val_balance) 
-        throws CreateException {
-
-        // Init object state
-        setAccno(val_accno);
-        setCustomer(val_customer);
-        setBalance(val_balance);
-        return null;
-    }
-    
-    public void ejbPostCreate(int val_accno, String val_customer, double val_balance) { 
-        // Nothing to be done for this simple example.
-    }
-
-
-    /*====================== javax.ejb.EntityBean implementation =================*/
-
-    public void ejbActivate() {
-        // Nothing to be done for this simple example.
-    }
-
-    public void ejbLoad() {
-        // Nothing to be done for this simple example, in implicit persistence.
-    }
-
-    public void ejbPassivate() {
-        // Nothing to be done for this simple example.
-    }
-
-    public void ejbRemove() throws RemoveException {
-        // Nothing to be done for this simple example, in implicit persistence.
-    }
-
-    public void ejbStore() {
-        // Nothing to be done for this simple example, in implicit persistence.
-    }
-  
-    public void setEntityContext(EntityContext ctx) { 
-
-        // Keep the entity context in object
-        entityContext = ctx;
-    }
-
-    public void unsetEntityContext()  {
-        entityContext = null;
-    }
-
-    /**
-     * Business method to get the Account number
-     */
-    public int getNumber()  {
-        return getAccno();
-    }
-
-}
    - -

    Writing Database Access Operations -(bean-managed persistence)

    -For bean-managed persistence, data access operations are developed by -the bean provider using the JDBC interface. However, getting database -connections must be obtained through the javax.sql.DataSource -interface on a datasource object provided by the EJB platform. This is -mandatory since the EJB platform is responsible for managing the connection -pool and for transaction management. Thus, to get a JDBC connection, in each -method performing database operations, the bean provider must: -
      -
    • call the getConnection(...) method of the DataSource object, to - obtain a connection to perform the JDBC operations in the current - transactional context (if there are JDBC operations),
      • -
    • call the close() method on this connection after the database - access operations, so that the connection can be returned to the - connection pool (and be dissociated from the potential current - transaction).
      • -
    -A method that performs database access must always contain the getConnection -and close statements, as follows: -
    public void doSomethingInDB (...) {
-    conn = dataSource.getConnection();
-    ... // Database access operations
-    conn.close();
-}
    -A DataSource object associates a JDBC driver with a database (as an ODBC -datasource). It is created and registered in JNDI by the EJB server at launch -time (refer also to the section "JDBC DataSources configuration"). - -

    A DataSource object is a resource manager connection factory for -java.sql.Connection objects, which implements connections to a -database management system. The enterprise bean code refers to resource -factories using logical names called "Resource manager connection factory -references." The resource manager connection factory references are special -entries in the enterprise bean environment. The bean provider must use -resource manager connection factory references to obtain the datasource -object as follow:

    -
      -
    • Declare the resource reference in the standard deployment descriptor - using a resource-ref element.
      • -
    • Lookup the datasource in the enterprise bean environment using the JNDI - interface (refer to the section "Enterprise Bean's - Environment").
      • -
    -The deployer binds the resource manager connection factory references to the -actual resource factories that are configured in the server. This binding is -done in the JOnAS-specific deployment descriptor using the jonas-resource -element. - -

    Example

    -The declaration of the resource reference in the standard deployment -descriptor looks like the following: -
    <resource-ref>
-<res-ref-name>jdbc/AccountExplDs</res-ref-name>
-<res-type>javax.sql.DataSource</res-type>
-<res-auth>Container</res-auth>
-</resource-ref>
    -The <res-auth> element indicates which of the two resource manager -authentication approaches is used: -
      -
    • Container: the deployer sets up the sign-on information.
      • -
    • Bean: the bean programmer should use the getConnection method - with user and password parameters.
      • -
    -The JOnAS-specific deployment descriptor must map the environment JNDI name -of the resource to the actual JNDI name of the resource object managed by the -EJB server. This is done in the <jonas-resource> element. -
      <jonas-entity>
-    <ejb-name>AccountExpl</ejb-name>
-    <jndi-name>AccountExplHome</jndi-name>
-    <jonas-resource>
-      <res-ref-name>jdbc/AccountExplDs</res-ref-name>
-      <jndi-name>jdbc_1</jndi-name>
-    </jonas-resource>
-  </jonas-entity>
    -The ejbStore method of the same Account example with bean-managed persistence -is shown in the following example. It performs JDBC operations to update the -database record representing the state of the entity bean instance. The JDBC -connection is obtained from the datasource associated with the bean. This -datasource has been instantiated by the EJB server and is available for the -bean through its resource reference name, which is defined in the standard -deployment descriptor. - -

    In the bean, a reference to a datasource object of the EJB server is -initialized:

    - -

    it = new InitialContext();

    - -

    ds = -(DataSource)it.lookup("java:comp/env/jdbc/AccountExplDs");

    - -

    Then, this datasource object is used in the implementation of the methods -performing JDBC operations, such as ejbStore, as illustrated in the -following:

    -
    public void ejbStore
-    Connection conn = null;
-    PreparedStatement stmt = null;
-    try { // get a connection
-        conn = ds.getConnection();
-        // store Object state in DB
-        stmt = conn.prepareStatement("update account set customer=?,balance=? where accno=?");
-        stmt.setString(1, customer);
-        stmt.setDouble(2, balance);
-        Integer pk = (Integer)entityContext.getPrimaryKey();
-        stmt.setInt(3, pk.accno);
-        stmt.executeUpdate();
-     } catch (SQLException e) {
-        throw new javax.ejb.EJBException("Failed to store bean to database", e);
-     } finally {
-        try {
-            if (stmt != null) stmt.close();    // close statement
-            if (conn != null) conn.close();    // release connection
-        } catch (Exception ignore) {}
-     }
-}
    -Note that the close statement instruction may be important if the server is -intensively accessed by many clients performing entity bean access. If the -statement is not closed in the finally block, since stmt is in the -scope of the method, it will be deleted at the end of the method (and the -close will be implicitly done). However, it may be some time before the Java -garbage collector deletes the statement object. Therefore, if the number of -clients performing entity bean access is important, the DBMS may raise a "too -many opened cursors" exception (a JDBC statement corresponds to a DBMS -cursor). Since connection pooling is performed by the platform, closing the -connection will not result in a physical connection close, therefore opened -cursors will not be closed. Thus, it is preferable to explicitly close the -statement in the method. - -

    It is a good programming practice to put the JDBC connection and JDBC -statement close operations in a finally bloc of the try statement.

    - -

    Configuring Database Access for -Container-managed Persistence

    -The standard way to indicate to an EJB platform that an entity bean has -container-managed persistence is to fill the -<persistence-type> tag of the deployment descriptor with the -value "container," and to fill the <cmp-field> tag of the -deployment descriptor with the list of container-managed fields (the fields -that the container will have in charge to make persistent). The CMP version -(1.x or 2.x) should also be specified in the <cmp-version> tag. In the -textual format of the deployment descriptor, this is represented by the -following lines: -
        <persistence-type>container</persistence-type>
-    <cmp-version>1.x</cmp-version>
-    <cmp-field>
-      <field-name>fieldOne</field-name>
-    </cmp-field>
-    <cmp-field>
-      <field-name>fieldTwo</field-name>
-    </cmp-field>
    -With container-managed persistence the programmer need not develop the -code for accessing the data in the relational database; this code is included -in the container itself (generated by the platform tools). However, for the -EJB platform to know how to access the database and which data to read and -write in the database, two types of information must be provided with the -bean: -
      -
    • First, the container must know which database to access and how to - access it. To do this, the only required information is the name of - the DataSource that will be used to get the JDBC connection. For - container-managed persistence, only one DataSource per bean should be - used.
      • -
    • Then, it is necessary to know the mapping of the bean fields to the - underlying database (which table, which column). For CMP 1.1 or CMP - 2.0, this mapping is specified by the deployer in the JOnAS-specific - deployment descriptor. Note that for CMP 2.0, this mapping may be - entirely generated by JOnAS.
      • -
    -The EJB specification does not specify how this information should be -provided to the EJB platform by the bean deployer. Therefore, what is -described in the remainder of this section is specific to JOnAS. - -

    For CMP 1.1, the bean deployer is responsible for defining the mapping of -the bean fields to the database table columns. The name of the DataSource can -be set at deployment time, since it depends on the EJB platform -configuration. This database configuration information is defined in the -JOnAS-specific deployment descriptor via the jdbc-mapping element. -The following example defines the mapping for a CMP 1.1 entity bean:

    -
        <jdbc-mapping>
-      <jndi-name>jdbc_1</jndi-name>
-      <jdbc-table-name>accountsample</jdbc-table-name>
-      <cmp-field-jdbc-mapping>
-      <field-name>mAccno</field-name>
-      <jdbc-field-name>accno</jdbc-field-name>
-      </cmp-field-jdbc-mapping>
-      <cmp-field-jdbc-mapping>
-      <field-name>mCustomer</field-name>
-      <jdbc-field-name>customer</jdbc-field-name>
-      </cmp-field-jdbc-mapping>
-      <cmp-field-jdbc-mapping>
-      <field-name>mBalance</field-name>
-      <jdbc-field-name>balance</jdbc-field-name>
-    </jdbc-mapping>
    -jdbc_1 is the JNDI name of the DataSource object identifying the -database. accountsample is the name of the table used to store the -bean instances in the database. mAccno, mCustomer, and -mBalance are the names of the container-managed fields of the bean -to be stored in the accno, customer, and balance -columns of the accountsample table. This example applies to -container-managed persistence. For bean-managed persistence, -the database mapping does not exist. - -

    For a CMP 2.0 entity bean, only the jndi-name element of the -jdbc-mapping is mandatory, since the mapping may be generated -automatically (for an explicit mapping definition, refer to the "JOnAS Database Mapping" section of the Using CMP2.0 persistence chapter):

    -
    -    <jdbc-mapping>
-      <jndi-name>jdbc_1</jndi-name>
-    </jdbc-mapping>
-    <cleanup>create</cleanup>
-
    -For a CMP 2.0 entity bean, the JOnAS-specific deployment descriptor contains -an additional element, cleanup, at the same level as the -jdbc-mapping element, which can have one of the following values: -
    -
    removedata
    -
    at bean loading time, the content of the tables storing the bean data - is deleted
    -
    removeall
    -
    at bean loading time, the tables storing the bean data are dropped - (if they exist) and created
    -
    none
    -
    do nothing
    -
    create
    -
    default value (if the element is not specified), at bean loading - time, the tables for storing the bean data are created if they do not - exist
    -
    -For CMP 1.1, the jdbc-mapping element can also contain information -defining the behaviour of the implementation of a find<method> -method (i.e. the ejbFind<method> method, that will be generated -by the platform tools). This information is represented by the -finder-method-jdbc-mapping element. - -

    For each finder method, this element provides a way to define an SQL WHERE -clause that will be used in the generated finder method implementation to -query the relational table storing the bean entities. Note that the table -column names should be used, not the bean field names. Example:

    -
          <finder-method-jdbc-mapping>
-        <jonas-method>
-          <method-name>findLargeAccounts</method-name>
-        </jonas-method>
-        <jdbc-where-clause>where balance &gt; ?</jdbc-where-clause>
-      </finder-method-jdbc-mapping>
    -The previous finder method description will cause the platform tools to -generate an implementation of ejbFindLargeAccount(double arg) that returns -the primary keys of the entity bean objects corresponding to the tuples -returned by the "select ... from Account where balance > ?", where '?' -will be replaced by the value of the first argument of the findLargeAccount -method. If several '?' characters appear in the provided WHERE clause, this -means that the finder method has several arguments and the '?' characters -will correspond to these arguments, adhering to the order of the method -signature. - -

    In the WHERE clause, the parameters can be followed by a number, which -specifies the method parameter number that will be used by the query in this -position.
    -Example: The WHERE clause of the following finder method can be:

    -
          Enumeration findByTextAndDateCondition(String text, java.sql.Date date)
-
-      WHERE (description like ?1 OR summary like ?1) AND (?2 &gt; date)
    -Note that a <finder-method-jdbc-mapping> element for the -findByPrimaryKey method is not necessary, since the meaning of this -method is known. - -

    Additionally, note that for CMP 2.0, the information defining the -behaviour of the implementation of a find<method> method is -located in the standard deployment descriptor, as an EJB-QL query -(i.e. this is not JOnAS-specific information). The same finder method example -in CMP 2.0:

    -
          <query>
-        <query-method>
-          <method-name>findLargeAccounts</method-name>
-          <method-params>
-              <method-param>double</method-param>
-          </method-params>
-        </query-method>
-        <ejb-ql>SELECT OBJECT(o) FROM accountsample o WHERE o.balance &gt; ?1</ejb-ql>
-      </query>
    -The datatypes supported for container-managed fields in CMP 1.1 are the -following:
    -  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Java TypeJDBC TypeJDBC driver Access methods
    booleanBITgetBoolean(), setBoolean()
    byteTINYINTgetByte(), setByte()
    short SMALLINTgetShort(), setShort()
    int INTEGERgetInt(), setInt()
    long BIGINTgetLong(), setLong()
    float FLOATgetFloat(), setFloat()
    double DOUBLEgetDouble(), setDouble
    byte[] VARBINARY or LONGVARBINARY (1)getBytes(), setBytes()
    java.lang.StringVARCHAR or LONGVARCHAR (1)getString(), setString()
    java.lang.BooleanBITgetBoolean(), setObject()
    java.lang.IntegerINTEGERgetInt(), setObject()
    java.lang.ShortSMALLINTgetShort(), setObject()
    java.lang.LongBIGINTgetLong(), setObject()
    java.lang.FloatREALgetFloat(), setObject()
    java.lang.DoubleDOUBLEgetDouble(), setObject()
    java.math.BigDecimalNUMERICgetBigDecimal(), setObject()
    java.math.BigIntegerNUMERICgetBigDecimal(), setObject()
    java.sql.DateDATEgetDate(), setDate()
    java.sql.TimeTIMEgetTime(), setTime()
    java.sql.Timestamp TIMESTAMPgetTimestamp(), setTimestamp()
    any serializable classVARBINARY or LONGVARBINARY (1)getBytes(), setBytes()
    - -

    (1) The mapping for String will normally be VARCHAR, but will turn into -LONGVARCHAR if the given value exceeds the driver's limit on VARCHAR values. -The case is similar for byte[] and VARBINARY and LONGVARBINARY values.

    - -

    For CMP 2.0, the supported datatypes depend on the JORM mapper used.

    - - -

    Tuning Container for Entity Bean -Optimizations

    -JOnAS must make a compromise between scalability and performance. For that reason, several tags in the JOnAS-specific deployment -descriptor have been introduced. For most applications, there is no need to change the default -values for all these tags. See -$JONAS_ROOT/xml/jonas-ejb-jar_4_7.xsd for a complete description -of the JOnAS-specific deployment descriptor. - -

    Note that if several of these elements are used, they should appear in the -following order within the <jonas-entity> element:

    -
      -
    1. is-modified-method-name
      2. -
    2. passivation-timeout
      3. -
    3. read-timeout
      4. -
    4. max-wait-time
      5. -
    5. inactivity-timeout
      6. -
    6. deadlock-timeout
      7. -
    7. shared
      8. -
    8. prefetch
      9. -
    9. hard-limit
      10. -
    10. max-cache-size
      11. -
    11. min-pool-size
      12. -
    12. cleanup
      13. -
    13. lock-policy
      14. -
    - -

    lock-policy

    -The JOnAS ejb container is able to manage seven different lock-policies: -
    -
    container-serialized (default)
    -
    The container ensures the - transaction serialization. This policy is suitable for entity beans - having non transacted methods that can modify the bean state. - It works only if the bean is accessed from 1 jonas server (shared = - false).
    -
    container-serialized-transacted
    -
    The container ensures the - transaction serialization. This policy is suitable for most entity beans.
    -
    container-read-committed
    -
    This policy is similar to - container-serialized-transacted, except that accesses outside transaction do not - interfere with transactional accesses. This can help to avoid deadlocks in - certain cases, when accessing a bean concurrently with and without a - transactional context. The only drawback of this policy is that it - consumes more memory (2 instances instead of 1).
    -
    container-read-uncommitted (deprecated)
    -
    All methods share the same - instance (like container-serialized), but there is no synchronization. - For example, this policy is of interest for read-only entity beans, or if - the bean instances are very rarely modified. It will fail if two or more - threads try to modify the same instance concurrently. - This policy is deprecated because it can be replaced by container-read-write.
    -
    database
    -
    Allow the database to handle the transaction isolation. - With this policy, it is possible to choose the transaction isolation in a - database. This may be of interest for applications that heavily use - transactional read-only operations, or when the flag shared is needed. It - does not work with all databases and is not memory efficient.
    -
    read-only
    -
    The bean state is never written to the database. - If the bean is shared, the bean state is read from the database regularly. - Use the read-timeout tag to specify the timeout value.
    -
    container-read-write
    -
    All methods share the same - instance (like container-serialized). A synchronization is done only when - the instance is modified. No lock is taken while the instance is read only. - This policy does not work if the bean is shared, nor does it work for CMP 1.x beans.
    -
    - -

    Important: If CMP1 beans are deployed, only the following policies should be used: -

      -
    • container-serialized
      • -
    • container-serialized-transacted
      • -
    • read-only
      • -
    • container-read-committed
      • -
    • database, but only with shared=true.
      • -
    -

    - -

    shared

    -This flag will be defined as true if the bean persistent state can -be accessed outside the JOnAS Server. When this flag is false, the -JOnAS Server can do some optimization, such as not re-reading the bean state -before starting a new transaction. -The default value depends on the lock-policy: -
      -
    • false for container-serialized, container-read-uncommitted or container-read-write. For these 3 policies, shared=false is mandatory.
      • -
    • true in the other cases.
      • -
    -Lock policy database works only if shared=true. - - -

    prefetch

    -This is a CMP2-specific option. The default is false. This can be set to true -if it is desirable to have a cache managed after finder methods execution, in -order to optimize further accesses inside the same transaction. - -

    Important note:

    -
      -
    • The prefetch will not be used for methods that have no transactional - context.
      • -
    • It is impossible to set the prefetch option if the lock policy is - container-read-uncommitted.
      • -
    - -

    max-cache-size / hard-limit / max-wait-time

    -This optional integer value represents the maximum number of instances in memory. -The purpose of this value is to keep JOnAS scalable. The default value is "no -limit". To save memory, this value should be set very low if it is known that -instances will not be reused. -Depending on whether hard-limit value is true or false, this max-cache-size value will -be overtaken or not: In the case of hard-limit = true, the container will never allocate more -instances than the max-cache-size value. When the limit is reached, the thread will be -set to waiting until instances are released. It is possible to specify the maximum time to -wait for an instance with the tag max-wait-time. The default is 0, which means "no wait". - -

    min-pool-size

    -This optional integer value represents the number of instances that will be -created in the pool when the bean is loaded. This will improve bean instance -create time, at least for the first instances. The default value is 0. -When passivation occurs, for example if there are too many instances in memory, -instances are released and placed in the pool only if min-pool-size is not -reached. The intent is to try to keep at least min-pool-size instances in the pool of -available instances. - -

    is-modified-method-name

    -To improve performance of CMP 1.1 entity beans, JOnAS implements the -isModified extension. Before performing an update, the container calls a -method of the bean whose name is identified in the -is-modified-method-name element of the JOnAS-specific deployment -descriptor. This method is responsible for determining if the state of the -bean has been changed. By doing this, the container determines if it must -store data in the database or not. - -

    Note that this is useless with CMP2 entity beans, since this will be done -automatically by the container.

    - -

    Example

    - -

    The bean implementation manages a boolean isDirty and implements -a method that returns the value of this boolean: isModified

    -
    -    private transient boolean isDirty;
-    public boolean isModified() {
-        return isDirty;
-    }
-
    - -

    The JOnAS-specific deployment descriptor directs the bean to implement an -isModified method:

    -
    -    <jonas-entity>
-      <ejb-name>Item</ejb-name>
-      <is-modified-method-name>isModified</is-modified-method-name>
-      .....
-    </jonas-entity>
-
    - -

    Methods that modify the value of the bean must set the flag -isDirty to true.
    -Methods that restore the value of the bean from the database must reset the -flag isDirty to false. Therefore, the flag must be set to -false in the ejbLoad() and ejbStore() methods.

    - -

    passivation-timeout

    -This flag is used only when lock-policy = container-serialized. -When instances are accessed outside of any transaction, their state is kept in memory -to improve performance. However, a passivation will occur in three situations: -
      -
    1. When the bean is unloaded from the server, at least when the server - is stopped.
      2. -
    2. When a transaction is started on this instance.
      3. -
    3. After a configurable timeout: passivation-timeout. If the bean is always accessed with no - transaction, it may be prudent to periodically store the bean state on - disk.
      4. -
    -This passivation timeout can be configured in the JOnAS-specific deployment -descriptor, with the non-mandatory tag <passivation-timeout>. Example: -
        <jonas-entity>
-      <ejb-name>Item</ejb-name>
-      <passivation-timeout>5</passivation-timeout>
-      .....
-    </jonas-entity>
-
    -This entity bean will be passivated every five second, if not accessed within -transactions. - - -

    read-timeout

    -This flag is used only when lock-policy = read-only. -In case shared=true has been set, it is important to synchronize the bean -state by reading it periodically from the storage. -This is configurable with the read-timeout flag. -Value is in seconds. - -

    inactivity-timeout

    -Bean passivation sends the state of the bean to persistent storage and removes from -memory only the bean instance objects that are holding this state. All container objects handling -bean access (remote object, interceptors, ...) are kept in memory so that future access -will work, requiring only a reload -operation (getting the state). It may be advantageous to conserve more memory and completely remove the -bean instance from memory; this can be achieved through the <inactivity-timeout> -element. This element is used to save memory when a bean has not been used for a long period of time. -If the bean has not been used after the specified time (in seconds), all its -container objects are removed -from the server. If a client has kept a reference on a remote object and tries to use it, then the client will receive an -exception. - -

    Using CMP2.0 persistence

    - -

    This section highlights the main differences between CMP as defined in EJB -2.0 specification (called CMP2.0) and CMP as defined in EJB 1.1 specification -(called CMP1.1). Major new features in the standard development and -deployment of CMP2.0 entity beans are listed (comparing them to CMP1.1), -along with JOnAS-specific information. Mapping CMP2.0 entity beans to the -database is described in detail. Note that the database mapping can be -created entirely by JOnAS, in which case the JOnAS-specific deployment -descriptor for an entity bean should contain only the datasource and the -element indicating how the database should be initialized.

    - -

    Standard CMP2.0 Aspects

    - -

    This section briefly describes the new features available in CMP2.0 as -compared to CMP 1.1, and how these features change the development of entity -beans.

    - -

    Entity Bean Implementation Class

    - -

    The EJB implementation class 1) implements the bean's business methods of -the component interface, 2) implements the methods dedicated to the EJB -environment (the interface of which is explicitly defined in the EJB -specification), and 3) defines the abstract methods representing both the -persistent fields (cmp-fields) and the relationship fields (cmr-fields). The -class must implement the javax.ejb.EntityBean interface, be defined -as public, and be abstract (which is not the case for CMP1.1, where it must -not be abstract). The abstract methods are the get and set accessor methods -of the bean cmp and cmr fields. Refer to the examples and details in the -section "Developing Entity Beans" of -the JOnAS documentation.

    - -

    Standard Deployment Descriptor

    - -

    The standard way to indicate to an EJB platform that an entity bean has -container-managed persistence is to fill the -<persistence-type> tag of the deployment descriptor with the -value "container," and to fill the <cmp-field> tags of the -deployment descriptor with the list of container-managed fields (the fields -that the container will have in charge to make persistent) and the -<cmr-field> tags identifying the relationships. The CMP -version (1.x or 2.x) should also be specified in the <cmp-version> tag. -This is represented by the following lines in the deployment descriptor:

    -
        <persistence-type>container</persistence-type>
-    <cmp-version>1.x</cmp-version>
-    <cmp-field>
-      <field-name>fieldOne</field-name>
-    </cmp-field>
-    <cmp-field>
-      <field-name>fieldTwo</field-name>
-    </cmp-field>
-
    - -

    Note that for running CMP1.1-defined entity beans on an EJB2.0 platform, -such as JOnAS 3.x, you must introduce this -<cmp-version> element in your deployment descriptors, since the -default cmp-version value (if not specified) is 2.x.

    - -

    Note that for CMP 2.0, the information defining the behaviour of the -implementation of a find<method> method is located in -the standard deployment descriptor as an EJB-QL query (this -is not JOnAS-specific information). -For CMP 1.1, this information is located in the JOnAS-specific deployment -descriptor as an SQL WHERE clause specified in a -<finder-method-jdbc-mapping> element.

    - -

    Finder method example in CMP 2.0: for a findLargeAccounts(double -val) method defined on the Account entity bean of the JOnAS eb -example.

    -
          <query>
-        <query-method>
-          <method-name>findLargeAccounts</method-name>
-          <method-params>
-              <method-param>double</method-param>
-          </method-params>
-        </query-method>
-        <ejb-ql>SELECT OBJECT(o) FROM accountsample o WHERE o.balance &gt; ?1</ejb-ql>
-      </query>
-
    - -

    JOnAS EJBQL extension

    - -

    LIMIT clause

    - -

    The LIMIT feature has been added to the standard EJBQL -query language. This feature enables you to retrieve just a portion -of the results generated by the rest of a query.

    - -

    The syntax of the LIMIT clause is:

    -
    -    limit_clause ::= LIMIT limit_expression (, limit_expression )?
-    limit_expression ::= integer_literal | input_parameter
-
    -

    The first limit_expression corresponds to the start_at range and the second one to the size range.

    - -

    The limit_clause is the last clause of the query:

    -
    -    ejbql ::= select_clause from_clause [where_clause] [orderby_clause] [limit_clause]
-
    -

    Example:

    -
    -    SELECT OBJECT(c) FROM jt2_Customer AS c ORDER BY c.id LIMIT ?1, 20
-
    -

    Note that this feature is currently not implemented on all the database types supported by JORM/MEDOR.

    - -

    JOnAS Database mappers

    - -

    For implementing the EJB 2.0 persistence (CMP2.0), JOnAS relies on the JORM framework. JORM -itself relies on JOnAS DataSources (specified in DataSource properties files) -for connecting to the actual database. JORM must adapt its object-relational -mapping to the underlying database, for which it makes use of adapters called -"mappers." Thus, for each type of database (and more precisely for each JDBC -driver), the corresponding mapper must be specified in the DataSource. This -is the purpose of the datasource.mapper property of the -DataSource properties file. Note that all JOnAS-provided DataSource -properties files (in JOnAS_ROOT/conf) already contain this property with the -correct mapper.

    - - - - - - - - - - - - - - -
    property namedescriptionpossible values
    datasource.mapperJORM database mapper
      -
    • rdb: generic mapper (JDBC standard driver ...)
      • -
    • rdb.cloudscape: Cloudscape
      • -
    • rdb.db2: DB2
      • -
    • rdb.firebird: Firebird
      • -
    • rdb.hsql: HSQL
      • -
    • rdb.mckoi: McKoi Db
      • -
    • rdb.mysql: MySQL
      • -
    • rdb.oracle8: Oracle 8 and lesser versions
      • -
    • rdb.oracle: Oracle 9
      • -
    • rdb.postgres: PostgreSQL (>= 7.2)
      • -
    • rdb.sapdb: Sap DB
      • -
    • rdb.sqlserver: MS Sql Server
      • -
    • rdb.sybase: Sybase
      • -
    -
    - -

    Contact the JOnAS team to obtain a mapper for other databases.

    - -

    The container code generated at deployment is now independent of the JORM mappers. -Until JOnAS 4.1.4, the container code generated at deployment (GenIC or ejbjar ant task) -was dependent on this mapper. It was possible to deploy (generate container code) -a bean for several mappers in order to change the database (i.e. the -DataSource file) without redeploying the bean. These mappers were -specified as the mappernames argument of the GenIC command -or as the mappernames attribute of the JOnAS ANT ejbjar -task. The value was a comma-separated list of mapper names for which the -container classes were generated. These mappernames options are now -deprecated.

    - - -

    JOnAS Database Mapping (Specific Deployment -Descriptor)

    - -

    The mapping to the database of entity beans and their relationships may be -specified in the JOnAS-specific deployment descriptor, in -jonas-entity elements, and in jonas-ejb-relation elements. -Since JOnAS is able to generate the database mapping, all the elements of the -JOnAS-specific deployment descriptor defined in this section (which are -sub-elements of jonas-entity or jonas-ejb-relation) are -optional, except those for specifying the datasource and the initialization -mode (i.e. the jndi-name of jdbc-mapping and -cleanup). The default values of these mapping elements, provided in -this section, define the JOnAS-generated database mapping.

    - -

    Specifying and Initializing the Database

    - -

    For specifying the database within which a CMP 2.0 entity bean is stored, -the jndi-name element of the jdbc-mapping is necessary. -This is the JNDI name of the DataSource representing the database storing the -entity bean.

    -
        <jdbc-mapping>
-      <jndi-name>jdbc_1</jndi-name>
-    </jdbc-mapping>
-
    - -

    For a CMP 2.0 entity bean, the JOnAS-specific deployment descriptor -contains an additional element, cleanup, to be specified before the -jdbc-mapping element, which can have one of the following values:

    -
    -
    removedata
    -
    at bean loading time, the content of the tables storing the bean data - is deleted
    -
    removeall
    -
    at bean loading time, the tables storing the bean data are dropped - (if they exist) and created
    -
    none
    -
    do nothing
    -
    create
    -
    default value (if the element is not specified), at bean loading - time, the tables for storing the bean data are created if they do not - exist.
    -
    - -

    It may be useful for testing purposes to delete the database data each -time a bean is loaded. For this purpose, the part of the JOnAS-specific -deployment descriptor related to the entity bean may look like the -following:

    -
        <cleanup>removedata</cleanup>
-    <jdbc-mapping>
-      <jndi-name>jdbc_1</jndi-name>
-    </jdbc-mapping>
-
    - -

    CMP fields Mapping

    - -

    Mapping CMP fields in CMP2.0 is similar to that of CMP 1.1, but in CMP2.0 -it is also possible to specify the SQL type of a column. Usually this SQL -type is used if JOnAS creates the table (create value of the -cleanup element), and if the JORM default chosen SQL type is not -appropriate.

    - -
    Standard Deployment Descriptor
    -
        .....
-    <entity>
-      <ejb-name>A</ejb-name>
-      .....
-      <cmp-field>
-        <field-name>idA</field-name>
-      </cmp-field>
-      <cmp-field>
-        <field-name>f</field-name>
-      </cmp-field>
-    .....
-    </entity>
-    .....
-
    - -
    Database Mapping
    - - - - - - - - - - - - - - - - -
    t_A
    c_idAc_f
    ......
    - -
    JOnAS Deployment Descriptor
    -
        .....
-    <jonas-entity>
-      <ejb-name>A</ejb-name>
-      .....
-      <jdbc-mapping>
-        <jndi-name>jdbc_1</jndi-name>
-        <jdbc-table-name>t_A</jdbc-table-name>
-        <cmp-field-jdbc-mapping>
-          <field-name>idA</field-name>
-          <jdbc-field-name>c_idA</jdbc-field-name>
-        </cmp-field-jdbc-mapping>
-        <cmp-field-jdbc-mapping>
-          <field-name>f</field-name>
-          <jdbc-field-name>c_f</jdbc-field-name>
-          <sql-type>varchar(40)</sql-type>
-        </cmp-field-jdbc-mapping>
-      </jdbc-mapping>
-      .....
-    </jonas-entity>
-    .....
-
    - -

    Defaults values:

    - - - - - - - - - - - - - - - - - - - - - - - - -
    jndi-nameMandatory
    jdbc-table-nameOptional.
    - Default value is the upper-case CMP2 abstract-schema-name, - or the CMP1 ejb-name, suffixed by - _.
    cmp-field-jdbc-mappingOptional.
    jdbc-field-nameOptional.
    - Default value is the field-name suffixed by _.
    - idA_ and f_ in the example.
    sql-typeOptional.
    - Default value defined by JORM.
    -  - -

    CMR fields Mapping to primary-key-fields -(simple pk)

    - -
    1-1 unidirectional relationships
    - -
    Standard Deployment Descriptor
    -
        .....
-    <entity>
-      <ejb-name>A</ejb-name>
-      .....
-      <cmp-field>
-        <field-name>idA</field-name>
-      </cmp-field>
-      <primkey-field>idA</primkey-field>
-      .....
-    </entity>
-    .....
-    <entity>
-      <ejb-name>B</ejb-name>
-      .....
-      <cmp-field>
-        <field-name>idB</field-name>
-      </cmp-field>
-      <primkey-field>idB</primkey-field>
-      .....
-    </entity>
-    .....
-    <relationships>
-      <ejb-relation>
-        <ejb-relation-name>a-b</ejb-relation-name>
-        <ejb-relationship-role>
-          <!-- A => B -->
-                <ejb-relationship-role-name>a2b</ejb-relationship-role-name>
-          <multiplicity>One</multiplicity>
-          <relationship-role-source>
-            <ejb-name>A</ejb-name>
-          </relationship-role-source>
-          <cmr-field>
-            <cmr-field-name>b</cmr-field-name>
-          </cmr-field>
-        </ejb-relationship-role>
-        <ejb-relationship-role>
-          <!-- B => A -->
-          <ejb-relationship-role-name>b2a</ejb-relationship-role-name>
-          <multiplicity>One</multiplicity>
-          <relationship-role-source>
-            <ejb-name>B</ejb-name>
-          </relationship-role-source>
-        </ejb-relationship-role>
-      </ejb-relation>
-    </relationships>
-    .....
-
    - -
    Database Mapping
    - - - - - - - - -
    - - - - - - - - - - - - - - - -
    t_A
    c_idAcfk_idB
    ......
    -     		- - - - - - - - - - - - -
    t_B
    c_idB
    ...
    -
    - -

    There is a foreign key in the table of the bean that owns the CMR -field.

    - -
    JOnAS Deployment Descriptor
    -
        .....
-    <jonas-entity>
-      <ejb-name>A</ejb-name>
-      .....
-      <jdbc-mapping>
-        <jndi-name>jdbc_1</jndi-name>
-        <jdbc-table-name>t_A/jdbc-table-name>
-        <cmp-field-jdbc-mapping>
-          <field-name>idA</field-name>
-          <jdbc-field-name>c_idA</jdbc-field-name>
-        </cmp-field-jdbc-mapping>
-      </jdbc-mapping>
-      .....
-    </jonas-entity>
-    .....
-    <jonas-entity>
-      <ejb-name>B</ejb-name>
-      .....
-      <jdbc-mapping>
-        <jndi-name>jdbc_1</jndi-name>
-        <jdbc-table-name>t_B/jdbc-table-name>
-        <cmp-field-jdbc-mapping>
-          <field-name>idB</field-name>
-          <jdbc-field-name>c_idB</jdbc-field-name>
-        </cmp-field-jdbc-mapping>
-      </jdbc-mapping>
-      .....
-    </jonas-entity>
-    .....
-    <jonas-ejb-relation>
-      <ejb-relation-name>a-b</ejb-relation-name>
-      <jonas-ejb-relationship-role>
-        <ejb-relationship-role-name>a2b</ejb-relationship-role-name>
-        <foreign-key-jdbc-mapping>
-          <foreign-key-jdbc-name>cfk_idb</foreign-key-jdbc-name>
-        </foreign-key-jdbc-mapping>
-      </jonas-ejb-relationship-role>
-    </jonas-ejb-relation>
-    .....
-
    - -

    foreign-key-jdbc-name is the column name of the foreign key in the -table of the source bean of the relationship-role.
    -In this example, where the destination bean has a primary-key-field, it is -possible to deduce that this foreign-key-jdbc-name column is to be associated -with the column of this primary-key-field in the table of the destination -bean.

    - -

    Default values:

    - - - - - - - - - - - - -
    jonas-ejb-relationOptional
    foreign-key-jdbc-nameOptional.
    - Default value is the abstract-schema-name of the destination bean, - suffixed by _, and by its primary-key-field.
    - B_idb in the example.
    -  - -
    1-1 bidirectional relationships
    - -

    Compared to 1-1 unidirectional relationships, there is a CMR field in both -of the beans, thus making two types of mapping possible.

    - -
    Standard Deployment Descriptor
    -
        .....
-    <relationships>
-      <ejb-relation>
-        <ejb-relation-name>a-b</ejb-relation-name>
-        <ejb-relationship-role>
-          <!-- A => B -->
-                <ejb-relationship-role-name>a2b</ejb-relationship-role-name>
-          <multiplicity>One</multiplicity>
-          <relationship-role-source>
-            <ejb-name>A</ejb-name>
-          </relationship-role-source>
-          <cmr-field>
-            <cmr-field-name>b</cmr-field-name>
-          </cmr-field>
-        </ejb-relationship-role>
-        <ejb-relationship-role>
-          <!-- B => A -->
-          <ejb-relationship-role-name>b2a</ejb-relationship-role-name>
-          <multiplicity>One</multiplicity>
-          <relationship-role-source>
-            <ejb-name>B</ejb-name>
-          </relationship-role-source>
-          <cmr-field>
-            <cmr-field-name>a</cmr-field-name>
-          </cmr-field>
-        </ejb-relationship-role>
-      </ejb-relation>
-    </relationships>
-    .....
-
    - -
    Database Mapping
    - -

    Two mappings are possible. One of the tables may hold a foreign key.

    - -

    Case 1:

    - - - - - - - - -
    - - - - - - - - - - - - - - - -
    t_A
    c_idAcfk_idB
    ......
    -     		- - - - - - - - - - - - -
    t_B
    c_idB
    ...
    -
    - -

    Case 2:

    - - - - - - - - -
    - - - - - - - - - - - - -
    t_A
    c_idA
    ...
    -     		- - - - - - - - - - - - - - - -
    t_B
    c_idBcfk_idA
    ......
    -
    - -
    JOnAS Deployment Descriptor
    - -

    Case 1:

    -
        .....
-    <jonas-ejb-relation>
-      <ejb-relation-name>a-b</ejb-relation-name>
-      <jonas-ejb-relationship-role>
-        <ejb-relationship-role-name>a2b</ejb-relationship-role-name>
-        <foreign-key-jdbc-mapping>
-          <foreign-key-jdbc-name>cfk_idb</foreign-key-jdbc-name>
-        </foreign-key-jdbc-mapping>
-      </jonas-ejb-relationship-role>
-    </jonas-ejb-relation>
-    .....
-
    - -

    Case 2:

    -
        .....
-    <jonas-ejb-relation>
-      <ejb-relation-name>a-b</ejb-relation-name>
-      <jonas-ejb-relationship-role>
-        <ejb-relationship-role-name>b2a</ejb-relationship-role-name>
-        <foreign-key-jdbc-mapping>
-          <foreign-key-jdbc-name>cfk_ida</foreign-key-jdbc-name>
-        </foreign-key-jdbc-mapping>
-      </jonas-ejb-relationship-role>
-    </jonas-ejb-relation>
-    .....
-
    - -

    For the default mapping, the foreign key is in the table of the source -bean of the first ejb-relationship-role of the ejb-relation. In the example, -the default mapping corresponds to case 1, since the ejb-relationship-role -a2b is the first defined in the ejb-relation a-b. Then, the -default values are similar to those of the 1-1 unidirectional -relationship.

    -  - -
    1-N unidirectional relationships
    - -
    Standard Deployment Descriptor
    -
        .....
-    <relationships>
-      <ejb-relation>
-        <ejb-relation-name>a-b</ejb-relation-name>
-        <ejb-relationship-role>
-          <!-- A => B -->
-                <ejb-relationship-role-name>a2b</ejb-relationship-role-name>
-          <multiplicity>One</multiplicity>
-          <relationship-role-source>
-            <ejb-name>A</ejb-name>
-          </relationship-role-source>
-          <cmr-field>
-            <cmr-field-name>b</cmr-field-name>
-            <cmr-field-type>java.util.Collection</cmr-field-type>
-          </cmr-field>
-        </ejb-relationship-role>
-        <ejb-relationship-role>
-          <!-- B => A -->
-          <ejb-relationship-role-name>b2a</ejb-relationship-role-name>
-          <multiplicity>Many</multiplicity>
-          <relationship-role-source>
-            <ejb-name>B</ejb-name>
-          </relationship-role-source>
-        </ejb-relationship-role>
-      </ejb-relation>
-    </relationships>
-    .....
-
    - -
    Database Mapping
    - - - - - - - - -
    - - - - - - - - - - - - -
    t_A
    c_idA
    ...
    -     		- - - - - - - - - - - - - - - -
    t_B
    c_idBcfk_idA
    ......
    -
    - -

    In this case, the foreign key must be in the table of the bean which is on -the "many" side of the relationship (i.e. in the table of the source bean of -the relationship role with multiplicity many), t_B.

    - -
    JOnAS Deployment Descriptor
    -
        .....
-    <jonas-ejb-relation>
-      <ejb-relation-name>a-b</ejb-relation-name>
-      <jonas-ejb-relationship-role>
-        <ejb-relationship-role-name>b2a</ejb-relationship-role-name>
-        <foreign-key-jdbc-mapping>
-          <foreign-key-jdbc-name>cfk_ida</foreign-key-jdbc-name>
-        </foreign-key-jdbc-mapping>
-      </jonas-ejb-relationship-role>
-    </jonas-ejb-relation>
-    .....
-
    - -

    Default values:

    - - - - - - - - - - - - -
    jonas-ejb-relationOptional
    foreign-key-jdbc-nameOptional.
    - Default value is the abstract-schema-name of the destination bean of - the "one" side of the relationship (i.e. the source bean of the - relationship role with multiplicity one), suffixed by _, and - by its primary-key-field.
    - A_ida in the example.
    -  - -
    1-N bidirectional relationships
    - -

    Similar to 1-N unidirectional relationships, but with a CMR field in each -bean.

    - -
    Standard Deployment Descriptor
    -
        .....
-    <relationships>
-      <ejb-relation>
-        <ejb-relation-name>a-b</ejb-relation-name>
-        <ejb-relationship-role>
-          <!-- A => B -->
-                <ejb-relationship-role-name>a2b</ejb-relationship-role-name>
-          <multiplicity>One</multiplicity>
-          <relationship-role-source>
-            <ejb-name>A</ejb-name>
-          </relationship-role-source>
-          <cmr-field>
-            <cmr-field-name>b</cmr-field-name>
-            <cmr-field-type>java.util.Collection</cmr-field-type>
-          </cmr-field>
-        </ejb-relationship-role>
-        <ejb-relationship-role>
-          <!-- B => A -->
-          <ejb-relationship-role-name>b2a</ejb-relationship-role-name>
-          <multiplicity>Many</multiplicity>
-          <relationship-role-source>
-            <ejb-name>B</ejb-name>
-          </relationship-role-source>
-          <cmr-field>
-            <cmr-field-name>a</cmr-field-name>
-          </cmr-field>
-        </ejb-relationship-role>
-      </ejb-relation>
-    </relationships>
-    .....
-
    - -
    Database mapping
    - - - - - - - - -
    - - - - - - - - - - - - -
    t_A
    c_idA
    ...
    -     		- - - - - - - - - - - - - - - -
    t_B
    c_idBcfk_idA
    ......
    -
    - -

    In this case, the foreign key must be in the table of the bean which is on -the "many" side of the relationship (i.e. in the table of the source bean of -the relationship role with multiplicity many), t_B.

    - -
    JOnAS Deployment Descriptor
    -
        .....
-    <jonas-ejb-relation>
-      <ejb-relation-name>a-b</ejb-relation-name>
-      <jonas-ejb-relationship-role>
-        <ejb-relationship-role-name>b2a</ejb-relationship-role-name>
-        <foreign-key-jdbc-mapping>
-          <foreign-key-jdbc-name>cfk_ida</foreign-key-jdbc-name>
-        </foreign-key-jdbc-mapping>
-      </jonas-ejb-relationship-role>
-    </jonas-ejb-relation>
-    .....
-
    - -

    Default values:

    - - - - - - - - - - - - -
    jonas-ejb-relationOptional
    foreign-key-jdbc-nameOptional.
    - Default value is the abstract-schema-name of the destination bean of - the "one" side of the relationship (i.e. the source bean of the - relationship role with multiplicity one), suffixed by _, and - by its primary-key-field.
    - A_ida in the example.
    -  - -
    N-1 unidirectional relationships
    - -

    Similar to 1-N unidirectional relationships, but the CMR field is defined -on the "many" side of the relationship, i.e. on the (source bean of the) -relationship role with multiplicity "many."

    - -
    Standard Deployment Descriptor
    -
        .....
-    <relationships>
-      <ejb-relation>
-        <ejb-relation-name>a-b</ejb-relation-name>
-        <ejb-relationship-role>
-          <!-- A => B -->
-                <ejb-relationship-role-name>a2b</ejb-relationship-role-name>
-          <multiplicity>Many</multiplicity>
-          <relationship-role-source>
-            <ejb-name>A</ejb-name>
-          </relationship-role-source>
-          <cmr-field>
-            <cmr-field-name>b</cmr-field-name>
-          </cmr-field>
-        </ejb-relationship-role>
-        <ejb-relationship-role>
-          <!-- B => A -->
-          <ejb-relationship-role-name>b2a</ejb-relationship-role-name>
-          <multiplicity>One</multiplicity>
-          <relationship-role-source>
-            <ejb-name>B</ejb-name>
-          </relationship-role-source>
-        </ejb-relationship-role>
-      </ejb-relation>
-    </relationships>
-    .....
-
    - -
    Database mapping
    - - - - - - - - -
    - - - - - - - - - - - - - - - -
    t_A
    c_idAcfk_idB
    ......
    -     		- - - - - - - - - - - - -
    t_B
    c_idB
    ...
    -
    - -

    In this case, the foreign key must be in the table of the bean which is on -the "many" side of the relationship (i.e. in table of the source bean of the -relationship role with multiplicity many), t_A.

    - -
    JOnAS Deployment Descriptor
    -
        .....
-    <jonas-ejb-relation>
-      <ejb-relation-name>a-b</ejb-relation-name>
-      <jonas-ejb-relationship-role>
-        <ejb-relationship-role-name>a2b</ejb-relationship-role-name>
-        <foreign-key-jdbc-mapping>
-          <foreign-key-jdbc-name>cfk_idb</foreign-key-jdbc-name>
-        </foreign-key-jdbc-mapping>
-      </jonas-ejb-relationship-role>
-    </jonas-ejb-relation>
-    .....
-
    - -

    Default values:

    - - - - - - - - - - - - -
    jonas-ejb-relationOptional
    foreign-key-jdbc-nameOptional.
    - Default value is the abstract-schema-name of the destination bean of - the "one" side of the relationship (i.e. the source bean of the - relationship role with multiplicity one), suffixed by _, and - by its primary-key-field.
    - B_idb in the example.
    -  - -
    N-M unidirectional relationships
    - -
    Standard Deployment Descriptor
    -
        .....
-    <relationships>
-      <ejb-relation>
-        <ejb-relation-name>a-b</ejb-relation-name>
-        <ejb-relationship-role>
-          <!-- A => B -->
-                <ejb-relationship-role-name>a2b</ejb-relationship-role-name>
-          <multiplicity>Many</multiplicity>
-          <relationship-role-source>
-            <ejb-name>A</ejb-name>
-          </relationship-role-source>
-          <cmr-field>
-            <cmr-field-name>b</cmr-field-name>
-            <cmr-field-type>java.util.Collection</cmr-field-type>
-          </cmr-field>
-        </ejb-relationship-role>
-        <ejb-relationship-role>
-          <!-- B => A -->
-          <ejb-relationship-role-name>b2a</ejb-relationship-role-name>
-          <multiplicity>Many</multiplicity>
-          <relationship-role-source>
-            <ejb-name>B</ejb-name>
-          </relationship-role-source>
-        </ejb-relationship-role>
-      </ejb-relation>
-    </relationships>
-    .....
-
    - -
    Database mapping
    - - - - - - - - - -
    - - - - - - - - - - - - -
    t_A
    c_idA
    ...
    -     		- - - - - - - - - - - - -
    t_B
    c_idB
    ...
    -     		- - - - - - - - - - - - - - - -
    tJoin_AB
    cfk_idAcfk_idB
    ......
    -
    - -

    In this case, there is a join table composed of the foreign keys of each -entity bean table.

    - -
    JOnAS Deployment Descriptor
    -
        .....
-    <jonas-ejb-relation>
-      <ejb-relation-name>a-b</ejb-relation-name>
-      <jdbc-table-name>tJoin_AB</jdbc-table-name>
-      <jonas-ejb-relationship-role>
-        <ejb-relationship-role-name>a2b</ejb-relationship-role-name>
-        <foreign-key-jdbc-mapping>
-          <foreign-key-jdbc-name>cfk_idb</foreign-key-jdbc-name>
-        </foreign-key-jdbc-mapping>
-      </jonas-ejb-relationship-role>
-      <jonas-ejb-relationship-role>
-        <ejb-relationship-role-name>b2a</ejb-relationship-role-name>
-        <foreign-key-jdbc-mapping>
-          <foreign-key-jdbc-name>cfk_ida</foreign-key-jdbc-name>
-        </foreign-key-jdbc-mapping>
-      </jonas-ejb-relationship-role>
-    </jonas-ejb-relation>
-    .....
-
    - -

    Default values

    - - - - - - - - - - - - - - - - -
    jonas-ejb-relationOptional
    jdbc-table-nameOptional.
    - Default value is built from the abstract-schema-names of the beans, - separated by _.
    - A_B in the example.
    foreign-key-jdbc-nameOptional.
    - Default value is the abstract-schema-name of the destination bean, - suffixed by _, and by its primary-key-field.
    - B_idb and A_ida in the example.
    -  - -
    N-M bidirectional relationships
    - -

    Similar to N-M unidirectional relationships, but a CMR field is defined -for each bean.

    - -
    Standard deployment Descriptor
    -
        .....
-    <relationships>
-      <ejb-relation>
-        <ejb-relation-name>a-b</ejb-relation-name>
-        <ejb-relationship-role>
-          <!-- A => B -->
-                <ejb-relationship-role-name>a2b</ejb-relationship-role-name>
-          <multiplicity>Many</multiplicity>
-          <relationship-role-source>
-            <ejb-name>A</ejb-name>
-          </relationship-role-source>
-          <cmr-field>
-            <cmr-field-name>b</cmr-field-name>
-            <cmr-field-type>java.util.Collection</cmr-field-type>
-          </cmr-field>
-        </ejb-relationship-role>
-        <ejb-relationship-role>
-          <!-- B => A -->
-          <ejb-relationship-role-name>b2a</ejb-relationship-role-name>
-          <multiplicity>Many</multiplicity>
-          <relationship-role-source>
-            <ejb-name>B</ejb-name>
-          </relationship-role-source>
-          <cmr-field>
-            <cmr-field-name>a</cmr-field-name>
-            <cmr-field-type>java.util.Collection</cmr-field-type>
-          </cmr-field>
-        </ejb-relationship-role>
-      </ejb-relation>
-    </relationships>
-    .....
-
    - -
    Database mapping
    - - - - - - - - - -
    - - - - - - - - - - - - -
    t_A
    c_idA
    ...
    -     		- - - - - - - - - - - - -
    t_B
    c_idB
    ...
    -     		- - - - - - - - - - - - - - - -
    tJoin_AB
    cfk_idAcfk_idB
    ......
    -
    - -

    In this case, there is a join table composed of the foreign keys of each -entity bean table.

    - -
    JOnAS Deployment Descriptor
    -
        .....
-    <jonas-ejb-relation>
-      <ejb-relation-name>a-b</ejb-relation-name>
-      <jdbc-table-name>tJoin_AB</jdbc-table-name>
-      <jonas-ejb-relationship-role>
-        <ejb-relationship-role-name>a2b</ejb-relationship-role-name>
-        <foreign-key-jdbc-mapping>
-          <foreign-key-jdbc-name>cfk_idb</foreign-key-jdbc-name>
-        </foreign-key-jdbc-mapping>
-      </jonas-ejb-relationship-role>
-      <jonas-ejb-relationship-role>
-        <ejb-relationship-role-name>b2a</ejb-relationship-role-name>
-        <foreign-key-jdbc-mapping>
-          <foreign-key-jdbc-name>cfk_ida</foreign-key-jdbc-name>
-        </foreign-key-jdbc-mapping>
-      </jonas-ejb-relationship-role>
-    </jonas-ejb-relation>
-    .....
-
    - -

    Default values:

    - - - - - - - - - - - - - - - - -
    jonas-ejb-relationOptional
    jdbc-table-nameOptional.
    - Default value is built from the abstract-schema-names of the beans, - separated by _.
    - A_B in the example.
    foreign-key-jdbc-nameOptional.
    - Default value is the abstract-schema-name of the destination bean, - suffixed by _, and by its primary-key-field.
    - B_idb and A_ida in the example.
    -  - -

    CMR fields Mapping to composite -primary-keys

    - -

    In the case of composite primary keys, the database mapping should provide -the capability to specify which column of a foreign key corresponds to which -column of the primary key. This is the only difference between relationships -based on simple primary keys. For this reason, not all types of relationship -are illustrated below.

    - -
    1-1 bidirectional relationships
    - -
    Standard Deployment Descriptor
    -
        .....
-    <entity>
-      <ejb-name>A</ejb-name>
-      .....
-      <prim-key-class>p.PkA</prim-key-class>
-      .....
-      <cmp-field>
-        <field-name>id1A</field-name>
-      </cmp-field>
-      <cmp-field>
-        <field-name>id2A</field-name>
-      </cmp-field>
-      .....
-    </entity>
-    .....
-    <entity>
-      <ejb-name>B</ejb-name>
-      .....
-      <prim-key-class>p.PkB</prim-key-class>
-      .....
-      <cmp-field>
-        <field-name>id1B</field-name>
-      </cmp-field>
-      <cmp-field>
-        <field-name>id2B</field-name>
-      </cmp-field>
-      .....
-    </entity>
-    .....
-    <relationships>
-      <ejb-relation>
-        <ejb-relation-name>a-b</ejb-relation-name>
-        <ejb-relationship-role>
-          <!-- A => B -->
-                <ejb-relationship-role-name>a2b</ejb-relationship-role-name>
-          <multiplicity>One</multiplicity>
-          <relationship-role-source>
-            <ejb-name>A</ejb-name>
-          </relationship-role-source>
-          <cmr-field>
-            <cmr-field-name>b</cmr-field-name>
-          </cmr-field>
-        </ejb-relationship-role>
-        <ejb-relationship-role>
-          <!-- B => A -->
-          <ejb-relationship-role-name>b2a</ejb-relationship-role-name>
-          <multiplicity>One</multiplicity>
-          <relationship-role-source>
-            <ejb-name>B</ejb-name>
-          </relationship-role-source>
-          <cmr-field>
-            <cmr-field-name>a</cmr-field-name>
-          </cmr-field>
-        </ejb-relationship-role>
-      </ejb-relation>
-    </relationships>
-    .....
-
    - -
    Database mapping
    - -

    Two mappings are possible, one or another of the tables may hold the -foreign key.

    - -

    Case 1:

    - - - - - - - - -
    - - - - - - - - - - - - - - - - - - - - - -
    t_A
    c_id1Ac_id2Acfk_id1Bcfk_id2B
    ............
    -     		- - - - - - - - - - - - - - - -
    t_B
    c_id1Bc_id2B
    ......
    -
    - -

    Case 2:

    - - - - - - - - -
    - - - - - - - - - - - - - - - -
    t_A
    c_id1Ac_id2A
    ......
    -     		- - - - - - - - - - - - - - - - - - - - - -
    t_B
    c_id1Bc_id2Bcfk_id1Acfk_id2A
    ............
    -
    - -
    JOnAS Deployment Descriptor
    - -

    Case 1:

    -
        .....
-    <jonas-ejb-relation>
-      <ejb-relation-name>a-b</ejb-relation-name>
-      <jonas-ejb-relationship-role>
-        <ejb-relationship-role-name>a2b</ejb-relationship-role-name>
-        <foreign-key-jdbc-mapping>
-          <foreign-key-jdbc-name>cfk_id1b</foreign-key-jdbc-name>
-          <key-jdbc-name>c_id1b</key-jdbc-name>
-        </foreign-key-jdbc-mapping>
-        <foreign-key-jdbc-mapping>
-          <foreign-key-jdbc-name>cfk_id2b</foreign-key-jdbc-name>
-          <key-jdbc-name>c_id2b</key-jdbc-name>
-        </foreign-key-jdbc-mapping>
-      </jonas-ejb-relationship-role>
-    </jonas-ejb-relation>
-    .....
-
    - -

    Case 2:

    -
        .....
-    <jonas-ejb-relation>
-      <ejb-relation-name>a-b</ejb-relation-name>
-      <jonas-ejb-relationship-role>
-        <ejb-relationship-role-name>b2a</ejb-relationship-role-name>
-        <foreign-key-jdbc-mapping>
-          <foreign-key-jdbc-name>cfk_id1a</foreign-key-jdbc-name>
-          <key-jdbc-name>c_id1a</key-jdbc-name>
-        </foreign-key-jdbc-mapping>
-        <foreign-key-jdbc-mapping>
-          <foreign-key-jdbc-name>cfk_id2a</foreign-key-jdbc-name>
-          <key-jdbc-name>c_id2a</key-jdbc-name>
-        </foreign-key-jdbc-mapping>
-      </jonas-ejb-relationship-role>
-    </jonas-ejb-relation>
-    .....
-
    - -

    For the default mapping (values), the foreign key is in the table of the -source bean of the first ejb-relationship-role of the ejb-relation. In the -example, the default mapping corresponds to case 1, since the -ejb-relationship-role a2b is the first defined in the ejb-relation a-b.

    -  - -
    N-M unidirectional relationships
    - -
    Standard Deployment Descriptor
    -
        .....
-    <entity>
-      <ejb-name>A</ejb-name>
-      .....
-      <cmp-field>
-        <field-name>id1A</field-name>
-      </cmp-field>
-      <cmp-field>
-        <field-name>id2A</field-name>
-      </cmp-field>
-      .....
-    </entity>
-    .....
-    <entity>
-      <ejb-name>B</ejb-name>
-      .....
-      <cmp-field>
-        <field-name>id1B</field-name>
-      </cmp-field>
-      <cmp-field>
-        <field-name>id2B</field-name>
-      </cmp-field>
-      .....
-    </entity>
-    .....
-    <relationships>
-      <ejb-relation>
-        <ejb-relation-name>a-b</ejb-relation-name>
-        <ejb-relationship-role>
-          <!-- A => B -->
-                <ejb-relationship-role-name>a2b</ejb-relationship-role-name>
-          <multiplicity>Many</multiplicity>
-          <relationship-role-source>
-            <ejb-name>A</ejb-name>
-          </relationship-role-source>
-          <cmr-field>
-            <cmr-field-name>b</cmr-field-name>
-            <cmr-field-type>java.util.Collection</cmr-field-type>
-          </cmr-field>
-        </ejb-relationship-role>
-        <ejb-relationship-role>
-          <!-- B => A -->
-          <ejb-relationship-role-name>b2a</ejb-relationship-role-name>
-          <multiplicity>Many</multiplicity>
-          <relationship-role-source>
-            <ejb-name>B</ejb-name>
-          </relationship-role-source>
-        </ejb-relationship-role>
-      </ejb-relation>
-    </relationships>
-    .....
-
    - -
    Database mapping
    - - - - - - - - - -
    - - - - - - - - - - - - - - - -
    t_A
    c_id1Ac_id2A
    ......
    -     		- - - - - - - - - - - - - - - -
    t_B
    c_id1Bc_id2B
    ......
    -     		- - - - - - - - - - - - - - - - - - - - - -
    tJoin_AB
    cfk_id1Acfk_id2Acfk_id1Bcfk_id2B
    ............
    -
    - -

    In this case, there is a join table composed of the foreign keys of each -entity bean table.

    - -
    JOnAS Deployment Descriptor
    -
        .....
-    <jonas-ejb-relation>
-      <ejb-relation-name>a-b</ejb-relation-name>
-      <jdbc-table-name>tJoin_AB</jdbc-table-name>
-      <jonas-ejb-relationship-role>
-        <ejb-relationship-role-name>a2b</ejb-relationship-role-name>
-        <foreign-key-jdbc-mapping>
-          <foreign-key-jdbc-name>cfk_id1b</foreign-key-jdbc-name>
-          <key-jdbc-name>c_id1b</key-jdbc-name>
-        </foreign-key-jdbc-mapping>
-        <foreign-key-jdbc-mapping>
-          <foreign-key-jdbc-name>cfk_id2b</foreign-key-jdbc-name>
-          <key-jdbc-name>c_id2b</key-jdbc-name>
-        </foreign-key-jdbc-mapping>
-      </jonas-ejb-relationship-role>
-      <jonas-ejb-relationship-role>
-        <ejb-relationship-role-name>b2a</ejb-relationship-role-name>
-        <foreign-key-jdbc-mapping>
-          <foreign-key-jdbc-name>cfk_id1a</foreign-key-jdbc-name>
-          <key-jdbc-name>c_id1a</key-jdbc-name>
-        </foreign-key-jdbc-mapping>
-        <foreign-key-jdbc-mapping>
-          <foreign-key-jdbc-name>cfk_id2a</foreign-key-jdbc-name>
-          <key-jdbc-name>c_id2a</key-jdbc-name>
-        </foreign-key-jdbc-mapping>
-      </jonas-ejb-relationship-role>
-    </jonas-ejb-relation>
-    .....
-
    - - diff --git a/jonas_doc/olddoc/PG_Environment.html b/jonas_doc/olddoc/PG_Environment.html deleted file mode 100644 index 82090226bd56355a3a262490c3a3fdbe06bfb4ae..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/PG_Environment.html +++ /dev/null @@ -1,300 +0,0 @@ - - - - - - - Enterprise Bean Environment - - - -

    EJB Programmer's Guide: Enterprise Bean -Environment

    - -

    Target Audience and Content

    - -

    The target audience for this guide is the Enterprise Bean provider, i.e. -the person in charge of developing the software components on the server -side. It describes how an enterprise component can refer to values, -resources, or other components in a way that is configurable at deployment -time.

    - -

    The content of this guide is the following:

    -
      -
    1. Target Audience and Content
      2. -
    2. Introduction
      3. -
    3. Environment Entries
      4. -
    4. Resource References
      5. -
    5. Resource Environment - References
      6. -
    6. EJB References
      7. -
    7. Deprecated EJBContext.getEnvironment() - method
      8. -
    - -

    Introduction

    - -

    The enterprise bean environment is a mechanism that allows customization -of the enterprise bean's business logic during assembly or deployment. The -environment is a way for a bean to refer to a value, to a resource, or to -another component so that the code will be independent of the actual referred -object. The actual value of such environment references (or variables) is set -at deployment time, according to what is contained in the deployment -descriptor. The enterprise bean's environment allows the enterprise bean to -be customized without the need to access or change the enterprise bean's -source code.

    - -

    The enterprise bean environment is provided by the container (i.e. the -JOnAS server) to the bean through the JNDI interface as a JNDI context. The -bean code accesses the environment using JNDI with names starting with -"java:comp/env/".

    - -

    Environment Entries

    - -

    The bean provider declares all the bean environment entries in the -deployment descriptor via the env-entry element. The deployer can -set or modify the values of the environment entries.

    - -

    A bean accesses its environment entries with a code similar to the -following:

    -
        InitialContext ictx = new InitialContext();
-    Context myenv = ictx.lookup("java:comp/env");
-    Integer min = (Integer) myenv.lookup("minvalue");
-    Integer max = (Integer) myenv.lookup("maxvalue");
-
    - -

    In the standard deployment descriptor, the declaration of these variables -are as follows:

    -
        <env-entry>
-      <env-entry-name>minvalue</env-entry-name>
-      <env-entry-type>java.lang.Integer</env-entry-type>
-      <env-entry-value>12</env-entry-value>
-    </env-entry>
-    <env-entry>
-      <env-entry-name>maxvalue</env-entry-name>
-      <env-entry-type>java.lang.Integer</env-entry-type>
-      <env-entry-value>120</env-entry-value>
-    </env-entry>
-
    - -

    Resource References

    - -

    The resource references are another examples of environment entries. For -such entries, using subcontexts is recommended:

    -
      -
    • java:comp/env/jdbc for references to DataSources objects.
      • -
    • java:comp/env/jms for references to JMS connection - factories.
      • -
    - -

    In the standard deployment descriptor, the declaration of a resource -reference to a JDBC connection factory is:

    -
        <resource-ref>
-      <res-ref-name>jdbc/AccountExplDs</res-ref-name>
-      <res-type>javax.sql.DataSource</res-type>
-      <res-auth>Container</res-auth>
-    </resource-ref>
-
    - -

    And the bean accesses the datasource as in the following:

    -
        InitialContext ictx = new InitialContext();
-    DataSource ds = ictx.lookup("java:comp/env/jdbc/AccountExplDs");
-
    - -

    Binding of the resource references to the actual resource manager -connection factories that are configured in the EJB server is done in the -JOnAS-specific deployment descriptor using the jonas-resource -element.

    -
        <jonas-resource>
-      <res-ref-name>jdbc/AccountExplDs</res-ref-name>
-      <jndi-name>jdbc_1</jndi-name>
-    </jonas-resource>
-
    - -

    Resource Environment References

    - -

    The resource environment references are another example of environment -entries. They allow the Bean Provider to refer to administered objects that -are associated with resources (for example, JMS Destinations), by using -logical names. Resource environment references are defined in the -standard deployment descriptor.

    -
        <resource-env-ref>
-      <resource-env-ref-name>jms/stockQueue</resource-env-ref-name>
-      <resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
-    </resource-env-ref>
-
    -Binding of the resource environment references to administered objects in the -target operational environment is done in the JOnAS-specific deployment -descriptor using the jonas-resource-env element. -
        <jonas-resource-env>
-      <resource-env-ref-name>jms/stockQueue</resource-env-ref-name>
-      <jndi-name>myQueue<jndi-name>
-    </jonas-resource-env>
-
    - -

    EJB References

    - -

    The EJB reference is another special entry in the enterprise bean's -environment. EJB references allow the Bean Provider to refer to the homes of -other enterprise beans using logical names. For such entries, using -the subcontext java:comp/env/ejb is recommended.

    - -

    The declaration of an EJB reference used for accessing the bean through -its remote home and component interfaces in the standard deployment -descriptor is shown in the following example:

    -
        <ejb-ref>
-      <ejb-ref-name>ejb/ses1</ejb-ref-name>
-      <ejb-ref-type>session</ejb-ref-type>
-      <home>tests.SS1Home</home>
-      <remote>tests.SS1</remote>
-    </ejb-ref>
-
    - -

    The declaration of an EJB reference used for accessing the bean through -its local home and component interfaces in the standard deployment -descriptor is shown in the following example:

    -
        <ejb-local-ref>
-      <ejb-ref-name>ejb/locses1</ejb-ref-name>
-      <ejb-ref-type>session</ejb-ref-type>
-      <local-home>tests.LocalSS1Home</local-home>
-      <local>tests.LocalSS1</local>
-      <ejb-link>LocalBean</ejb-link>
-    </ejb-local-ref>
-
    - -

    -Local interfaces are available in the same JVM as the bean providing this interface. -The use of these interfaces also implies that the classloader of the component performing a lookup - (bean or servlet component) is a child of the EJB classloader providing the local interface.
    - Local interfaces, then, are not available to outside WARs or outside EJB-JARs - even if they run in the same JVM. This is due to the fact that classes of - the local interfaces are not visible on the client side. - Putting them under the WEB-INF/lib folder of a WAR would not change - anything as the two classes would be loaded by different classloaders, - which will throw a "ClassCastException". -

    - To summarize, local interfaces are available only for -
      -
    • beans in a same ejb jar file.
      • -
    • from servlets to beans or ejbs to ejbs but in the same ear file.
      • -
    - - -

    If the referred bean is defined in the same ejb-jar or EAR file, the -optional ejb-link element of the ejb-ref element can -be used to specify the actual referred bean. The value of the ejb-link -element is the name of the target enterprise bean, i.e. the name defined in -the ejb-name element of the target enterprise bean. If the target enterprise -bean is in the same EAR file, but in a different ejb-jar file, the name of -the ejb-link element may be the name of the target bean, prefixed by the -name of the containing ejb-jar file followed by '#' (e.g. -"My_EJBs.jar#bean1"); prefixing by the name of the ejb-jar file is necessary -only if some ejb-name conflicts occur, otherwise the name of the target bean -is enough. In the following example, the ejb-link element has been -added to the ejb-ref (in the referring bean SSA) and a part of the -description of the target bean (SS1) is shown:

    -
        <session>
-      <ejb-name>SSA</ejb-name>
-      ...
-      <ejb-ref>
-        <ejb-ref-name>ejb/ses1</ejb-ref-name>
-        <ejb-ref-type>session</ejb-ref-type>
-        <home>tests.SS1Home</home>
-        <remote>tests.SS1</remote>
-        <ejb-link>SS1</ejb-link>
-      </ejb-ref>
-    ...
-    </session>
-    ...
-    <session>
-      <ejb-name>SS1</ejb-name>
-      <home>tests.SS1Home</home>
-      <local-home>tests.LocalSS1Home</local-home>
-      <remote>tests.SS1</remote>
-      <local>tests.LocalSS1</local>
-      <ejb-class>tests.SS1Bean</ejb-class>
-      ...
-    </session>
-     ...
-
    - -

    If the bean SS1 was not in the same ejb-jar file as SSA, but in another -file named product_ejbs.jar, the ejb-link element could have been:

    -
            <ejb-link>product_ejbs.jar#SS1</ejb-link>
-
    - -

    If the referring component and the referred bean are in separate files and -not in the same EAR, the current JOnAS implementation does not allow use of -the ejb-link element. In this case, to resolve the reference, the -jonas-ejb-ref element in the JOnAS-specific deployment descriptor -would be used to bind the environment JNDI name of the EJB reference to the -actual JNDI name of the associated enterprise bean home. In the following -example, it is assumed that the JNDI name of the SS1 bean home is -SS1Home_one.

    -
        <jonas-session>
-      <ejb-name>SSA</ejb-name>
-      <jndi-name>SSAHome</jndi-name>
-      <jonas-ejb-ref>
-        <ejb-ref-name>ejb/ses1</ejb-ref-name>
-        <jndi-name>SS1Home_one</jndi-name>
-      </jonas-ejb-ref>
-    </jonas-session>
-    ...
-    <jonas-session>
-      <ejb-name>SS1</ejb-name>
-      <jndi-name>SS1Home_one</jndi-name>
-      <jndi-local-name>SS1LocalHome_one</jndi-local-name>
-    </jonas-session>
-    ...
-
    - -

    The bean locates the home interface of the other enterprise bean using the -EJB reference with the following code:

    -
        InitialContext ictx = new InitialContext();
-    Context myenv = ictx.lookup("java:comp/env");
-    SS1Home home = (SS1Home)javax.rmi.PortableRemoteObject.narrow(myEnv.lookup("ejb/ses1"),
-                    SS1Home.class);
-
    - -

    Deprecated -EJBContext.getEnvironment() method

    - -

    JOnAS provides support for EJB 1.0-style definition of environment -properties. EJB1.0 environment must be declared in the -ejb10-properties sub-context. For example:

    -
        <env-entry>
-      <env-entry-name>ejb10-properties/foo</env-entry-name>
-      <env-entry-type>java.lang.String</env-entry-type>
-      <env-entry-value>foo value</env-entry-value>
-    </env-entry>
-
    - -

    The bean can retrieve its environment with the following code:

    -
        SessionContext ctx;
-    Properties prop;
-    public void setSessionContext(SessionContext sc) {
-        ctx = sc;
-        prop = ctx.getEnvironment();
-    }
-    public mymethod() {
-        String foo = prop.getProperty("foo");
-        ...
-    }
-
    - - diff --git a/jonas_doc/olddoc/PG_J2eeApps.html b/jonas_doc/olddoc/PG_J2eeApps.html deleted file mode 100644 index 71ee36f09e94f07c6e0bd01051396f00fc20e5df..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/PG_J2eeApps.html +++ /dev/null @@ -1,317 +0,0 @@ - - - - - - - J2EE Application Programmer's Guide - - - -

    J2EE Application Programmer's Guide

    - -

    Target Audience and Content

    - -

    The target audience for this guide is the application component provider, -i.e., the person in charge of developing the software components on the server -side (the business tier).

    - -

    The content of this guide is the following:

    -
      -
    1. Target Audience and Content
      2. -
    2. Principles - -
      3. -
    3. JOnAS class loader hierarchy - -
      4. -
    - -

    Principles

    - -

    JOnAS supports two types of J2EE application components: Enterprise -Beans and Web components. In addition to providing guides for -construction of application components, guides are supplied for application -assembly, deployment, and administration.

    - -

    Enterprise Bean Creation

    - -

    The individual in charge of developing Enterprise Beans should consult the -Enterprise Beans Programmer's Guide for instructions on how to perform the -following tasks:

    -
      -
    1. Write the source code for the beans.
      2. -
    2. Specify the deployment descriptor.
      3. -
    3. Bundle the compiled classes and the deployment descriptor into an EJB - JAR file.
      4. -
    - -

    This JOnAS documentation provides guides for developing the three types of -enterprise bean:

    - - -

    Deployment descriptor specification is presented in the Defining the Deployment -Descriptor chapter.

    - -

    More specific issues related to transaction behaviour, the Enterprise Bean -environment, or security service, are presented in the corresponding -chapters: Transactional behaviour, Enterprise Bean -Environment, Security Management.

    - -

    Principles and tools for providing EJB JAR files are presented in the -chapters EJB -Packaging and Deployment -and Installation Guide.

    - -

    Web Components Creation

    - -

    Web designers in charge of JSP pages and software developers providing -servlets can consult the Web Application Programmer's Guide.

    - -

    The Developing Web -Components guide explains how to construct Web components, as well as how -to access Enterprise Beans from within the Web Components.

    -Deployment descriptor specification is presented in the Defining the Web -Deployment Descriptor chapter. - -

    Web components can be used as Web application components or as -J2EE application components. In both cases, a WAR file will be -created, but the content of this file is different in the two situations. In -the first case, the WAR contains the Web components and the Enterprise Beans. -In the second case, the WAR does not contain the Enterprise Beans. The EJB -JAR file containing the Enterprise Beans is packed together with the WAR file -containing the Web components, into an EAR file.
    -Principles and tools for providing WAR files are presented in WAR Packaging and -the Deployment and -Installation Guide.

    - -

    J2EE Application Assembler

    - -

    The application assembler in charge of assembling the application -components already bundled in EJB JAR files and WAR files into a J2EE EAR -file, can obtain useful information from the J2EE Application -Assembler's Guide chapter.

    - -

    Application Deployer and -Administrator

    - -

    JOnAS provides tools for the deployment and administration of Enterprise -Beans (EJB JARs), Web applications (WARs), and J2EE applications (EARs).

    - -

    The Deployment and -Installation Guide covers issues related to the deployment of application -components.

    - -

    The Administration Guide -presents information about how to manage the JOnAS server and the JOnAS -services that allow deployment of the different types of application -components: EJB Container service, Web Container service, and EAR service.

    - -

    JOnAS class loader hierarchy

    - -

    This section describes a new and important key feature of the J2EE -integration: the class loader hierarchy in JOnAS.

    - -

    Understanding class loader -hierarchy

    - -

    An application is deployed by its own class loader. This means, for -example, that if a WAR and an EJB JAR are deployed separately, the classes -contained in the two archives are loaded with two separate classloaders with -no hierarchy between them. Thus, the EJBs from within the JAR will not be -visible to the Web components in the WAR.
    -This is not acceptable in cases where the Web components of an application -need to reference and use some of the EJBs (this concerns local references in -the same JVM).

    - -

    For this reason, prior to EAR files, when a Web application had to be -deployed using EJBs, the EJB JAR had to be located in the -WEB-INF/lib directory of the Web application.

    - -

    Currently, with the J2EE integration and the use of the EAR packaging, -class visibility problems no longer exist and the EJB JAR is no longer -required in the WEB-INF/lib directory.

    - -

    The following sections describe the JOnAS class loader hierarchy and -explain the mechanism used to locate the referenced classes.

    - -

    Commons class loader

    - -

    The commons class loader is a JOnAS-specific class loader that will load -all classes required to start the JOnAS server. This class loader has the -system class loader as parent class loader. The commons class loader adds all -the common libraries required to start the JOnAS server (J2EE apps, commons -logging, objectweb components, etc.); it also loads the classes located in -XTRA_CLASSPATH.

    -

    The JARs loaded by the commons class loader are located -under the JONAS_ROOT/lib/commons and JONAS_BASE/lib/commons directories. You can -extend this class loader by adding your own JARs inside these -directories. If you are using a Jetty packaging, -JONAS_ROOT/lib/jetty will be loaded too. -

    -

    Note that the lib/ext extension mechanism is now - deprecated. You should place additional JARs directly in the - classloader directory (commons, apps, - tools) under JONAS_ROOT and/or JONAS_BASE.
    - You should now use the JONAS_BASE/lib/commons if you want to - extend the commons ClassLoader, JONAS_BASE/lib/apps - for apps ClassLoader and JONAS_BASE/lib/tools - for tools ClassLoader.
    - Notice that the JONAS_BASE extension directories are always - loaded after JONAS_ROOT directories, so if the same class is in JONAS_ROOT/lib/commons - and in JONAS_BASE/lib/commons, the one located in JONAS_ROOT/lib/commons will be used. - -

    - -

    To have a library available for each component running inside JOnAS, add -the required JAR files in the JONAS_ROOT/lib/commons directory or in -the JONAS_BASE/lib/commons. All jars in subordinate directories will -also be loaded.
    -If a specific jar is needed only for a web application (i.e., need to use a -version of a jar file which is different than a version loaded by JOnAS), -change the compliance of the web application classloader to the java 2 -delegation model. Refer to the following: WEB class loader.
    -It is also possible to use the extension mechanism, which is described in the -section dependencies of the J2EE specification (section 8.1.1.28).

    - -

    Application class loader

    - -

    The application class loader is a JOnAS-specific class loader that will -load all application classes required by the user applications. This implies -that this loader will load all single RAR files. Thus, all applications -have the visibility of the resource adapters classes. This class loader has the -commons class loader as parent class loader.

    -

    The JARs loaded by the application class loader are - located under the JONAS_ROOT/lib/apps directory, - under JONAS_ROOT/lib/catalina/common/lib directory - (CATALINA_HOME/common/lib if you are not using the - Tomcat package) and under JONAS_BASE/lib/apps directory. - You can extend this class loader by adding your own - JARs inside these directories.
    -

    - -

    Tools class loader

    - -

    The tools class loader is a JOnAS-specific class loader that will load all -classes for which applications do not require visibility. (User applications -will not have the ability to load the classes packaged in the tools class -loader). For example, it includes the jakarta velocity and digester -components. This class loader has the commons class loader as parent class -loader.

    -

    The JARs loaded by the tools class loader are located under the - JONAS_ROOT/lib/tools directory and under the - JONAS_BASE/lib/tools directory. You can extend this class loader - by adding your own JARs inside these directories. -

    - -

    Tomcat class loader

    - -

    The tomcat class loader is a class loader that will load all classes of -the tomcat server (CATALINA_HOME/server/lib directory). The -classes of the common directory of tomcat -(CATALINA_HOME/common/lib directory) are loaded by the -application classloader and not by this tomcat classloader. Applications have -the visibility of the classes and not the server classes. To have -the visibility of the server classes, the context must have -the privileged attribute set to true. This class loader -has the application class loader as parent class loader.

    -

    The JARs loaded by the tomcat class loader are located - under the JONAS_ROOT/lib/catalina/server/lib directory (if - using Tomcat packaging, unless these libs are located under - CATALINA_HOME/server/lib). You can extend this class - loader by adding your own JARs inside this directory. -

    - -

    JOnAS class loaders

    - -

    The JOnAS class loader hierarchy that allows the deployment of EAR -applications without placing the EJB JAR in the WEB-INF/lib -directory consists of the following:

    - -

    EAR class loader

    - -

    The EAR class loader is responsible for loading the EAR application. There -is only one EAR class loader per EAR application. This class loader is the -child of the application class loader, thus making JOnAS classes visible to -it.

    - -

    EJB class loader

    - -

    The EJB class loader is responsible for loading all the EJB JARs of the -EAR application, thus all the EJBs of the same EAR application are loaded -with the same EJB classloader. This class loader is the child of the EAR -class loader.

    - -

    WEB class loader

    - -

    The WEB class loader is responsible for loading the Web components. There -is one WEB class loader per WAR file, and this class loader is the child of -the EJB class loader. Using this class loader hierarchy (the EJB class loader -is the parent of the WEB class loader) eliminates the problem of visibility -between classes when a WEB component tries to reference EJBs; the classes -loaded with the EJB class loader are definitely visible to the classes loaded -by its child class loader (WEB class loader).

    - -

    The compliance of the class loader of the web application to the java 2 -delegation model can be changed by using the jonas-web.xml file. This is -described in the section "Defining the Web Deployment -Descriptor."

    - -

    If the java2-delegation-model element is set to false, the class loader of -the web application looks for the class in its own repository before asking -its parent class loader.

    - -

    Conclusion

    - -

    The resulting JOnAS class loader hierarchy is as follows:

    - -
    -
    - - diff --git a/jonas_doc/olddoc/PG_JmsGuide.html b/jonas_doc/olddoc/PG_JmsGuide.html deleted file mode 100644 index 18ae7d416c778b7f39d4b5df15885552d5e6213a..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/PG_JmsGuide.html +++ /dev/null @@ -1,883 +0,0 @@ - - - - - - JMS User's Guide - - - - -

    JMS User's Guide

    -
      -
    1. JMS installation and configuration - aspects
      2. -
    2. Writing JMS operations within an - application component
      3. -
    3. Some programming rules and restrictions - when using JMS within EJB
      4. -
    4. JMS administration
      5. -
    5. Running an EJB performing JMS - operations
      6. -
    6. A JMS EJB example
      7. -
    - -

    As required by the J2EE v1.4 specification, application components -(servlets, JSP pages and enterprise beans) can use JMS for Java messaging. -Furthermore, applications can use Message-driven Beans for asynchronous EJB -method invocation, as specified by the EJB 2.1 specification.

    - -

    Starting with the JOnAS 3.1 version, JOnAS supports the Java Message -Service Specification 1.1. Previously in JMS 1.0.2, client programming for -Point-to-point and Pub/Sub domains was achieved using similar, but separate, -class hierarchies. Now, JMS 1.1 offers a domain-independent approach to -programming the client application. Thus, the programming model is simpler -and it is now possible to engage queues and topics in the same -transaction.

    - -

    Enterprise Bean providers can use JMS Connection Factory resources via -resource references, and JMS Destination resources (JMS Queues and JMS -Topics) via resource environment references. Thus, they are able to -provide JMS code, inside an EJB method or web component method, for sending -or synchronously receiving messages to/from a JMS Queue or Topic.

    - -

    The EJB container and the Web container can allow for JMS operations -within a global transaction, which may include other resources such as -databases.

    - -

    JOnAS integrates a third party JMS implementation (JORAM) which is the default JMS -service, and for which a J2EE1.4-compliant Resource Adapter archive file is -also provided. Other JMS providers, such as SwiftMQ and WebSphere MQ, -may easily be integrated.

    - -

    Starting with release 4.1, a JMS provider can be integrated within JOnAS -by deploying a corresponding resource adapter. This is the -preferred method as the JMS service will eventually become deprecated in -later JOnAS releases. Also, this method allows deployment of 2.1 MDBs (not -possible with the JMS service).

    - -

    For performing JMS operations, JMS-administered objects will be used by -the application components, such as connection factories and destinations. -Refer to the JMS Administration section for -an explanation of how to create those objects.

    - -

    JMS installation and configuration -aspects

    -To use JMS with JOnAS, no additional installation or configuration operations -are required. JOnAS contains: -
      -
    • the Java[TM] Message Service API 1.1, currently integrated with the - JOnAS distribution,
      • -
    • a JMS implementation. Currently, the OpenSource JORAM (http://joram.objectweb.org), is - integrated with the JOnAS distribution, thus no installation is - necessary.
      • -
    - -

    Additionally, the SwiftMQ product -and IBM's WebSphere MQ -have been used with JOnAS.

    - -

    Writing JMS operations within an -application component

    -To send (or synchronously receive) JMS messages, the component requires -access to JMS-administered objects, i.e. Connection Factories for creating -connections to JMS resources and Destination objects (Queue or Topic), which -are the JMS entities used as destinations within JMS sending operations. Both -are made available through JNDI by the JMS provider administration facility. - -

    Refer to the JOnAS example jms as a supplement to this -present reading. This example jms is described here.

    - -

    Accessing the Connection Factory

    -The EJB specification introduces the concept of Resource Manager -Connection Factory References. This concept also appears in the J2EE v1.4 -specification. It is used to create connections to a resource manager. To -date, three types of Resource Manager Connection Factories are -considered: -
      -
    • DataSource objects (javax.sql.DataSource) represent connection - factories for JDBC connection objects.
      • -
    • JMS Connection factories (javax.jms.ConnectionFactory, - javax.jms.QueueConnectionFactory and - javax.jms.TopicConnectionFactory) are connection factories - for JMS connection objects.
      • -
    • Java Mail Connection factories (javax.mail.Session or - javax.mail.internet.MimePartDataSource) are connection - factories for Java Mail connection objects.
      • -
    -The connection factories of interest here are the second type, which should -be used to get JMS Connection Factories. - -

    Note that starting with JMS 1.1, it is recommended that only the -javax.jms.ConnectionFactory be used (rather than -javax.jms.QueueConnectionFactory or -javax.jms.TopicConnectionFactory ). However, the new -implementation is fully backwards compatible and existing applications will -work as is.

    - -

    The standard deployment descriptor should contain the following -resource-ref element:

    -
          <resource-ref>
-      <res-ref-name>jms/conFact</res-ref-name>
-      <res-type>javax.jms.ConnectionFactory</res-type>
-      <res-auth>Container</res-auth>
-      </resource-ref>
    -This means that the programmer will have access to a -ConnectionFactory object using the JNDI name -java:comp/env/jms/conFact. The source code for obtaining the factory -object is the following: -
          ConnectionFactory qcf = (ConnectionFactory)
-                 ctx.lookup("java:comp/env/jms/conFact");
    -The mapping to the actual JNDI name of the connection factory (as assigned by -the JMS provider administration tool), CF in the example, is defined -in the JOnAS-specific deployment descriptor with the following element: -
          <jonas-resource>
-      <res-ref-name>jms/conFact</res-ref-name>
-      <jndi-name>CF</jndi-name>
-      </jonas-resource>
    - -

    Accessing the Destination Object

    -Accessing a JMS destination within the code of an application component -requires using a Resource Environment Reference, which is represented -in the standard deployment descriptor as follows: -
          <resource-env-ref>
-      <resource-env-ref-name>jms/stockQueue</resource-env-ref-name>
-      <resource-env-ref-type>javax.jms.Queue<resource-env-ref-type>
-      </resource-env-ref>
    -The application component's source code should contain: -
          Queue q = (Queue) ctx.lookup("java:comp/env/jms/stockQueue");
    -the mapping to the actual JNDI name (e.g. "myQueue") being defined in the -JOnAS-specific deployment descriptor in the following way: -
          <jonas-resource-env>
-      <resource-env-ref-name>jms/stockQueue</resource-env-ref-name>
-      <jndi-name>myQueue<jndi-name>
-      </jonas-resource-env>
    - -

    Writing JMS Operations

    -A typical method performing a message sending JMS operations looks like the -following: -
         void sendMyMessage() {
-
-       ConnectionFactory cf = (ConnectionFactory)
-               ctx.lookup("java:comp/env/jms/conFact");
-       Queue queue = (Queue) ctx.lookup("java:comp/env/jms/stockQueue");
-       Connection conn = cf.createConnection();
-       Session sess = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
-
-
-
-       MessageProducer  mp = sess.createProducer((Destination)queue);
-       ObjectMessage msg = sess.createObjectMessage();
-       msg.setObject("Hello");
-       sender.send(msg);
-       sess.close();
-       conn.close();
-     }
    -It is also possible for an application component to synchronously -receive a message. An EJB method performing synchronous message reception on -a queue is illustrated in the following: -
        public String recMsg() {
-        ConnectionFactory cf = (ConnectionFactory)
-               ctx.lookup("java:comp/env/jms/conFact");
-        Queue queue = (Queue) ctx.lookup("java:comp/env/jms/stockQueue");
-        Connection conn = cf.createConnection();
-        Session sess = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
-        MessageConsumer mc = sess.createConsumer((Destination)queue);
-        conn.start();
-        ObjectMessage msg = (ObjectMessage) mc.receive();
-        String msgtxt =  (String) msg.getObject();
-        sess.close();
-        conn.close();
-        return msgtxt;
-    }
    -A method that performs JMS operations should always contain the session -create and close statements, as follows: -
         public void doSomethingWithJMS (...) {
-       ...
-       session = connection.createSession(...);
-       ... // JMS operations
-       session.close();
-     }
    -The contained JMS operations will be a part of the transaction, if there is -one, when the JOnAS server executes the method. - -

    Be sure to never send and receive a particular message in the same -transaction, since the JMS sending operations are actually performed at -commit time only.

    - -

    The previous examples illustrate point-to-point messaging. However, -application components can also be developed using the publish/subscribe JMS -API, i.e. using the Topic instead of the Queue -destination type. This offers the capability of broadcasting a message to -several message consumers at the same time. The following example illustrates -a typical method for publishing a message on a JMS topic and demonstrates how -interfaces have been simplified since JMS 1.1.

    -
        public void sendMsg(java.lang.String s) {
-        ConnectionFactory cf = (ConnectionFactory)
-                       ictx.lookup("java:comp/env/jms/conFactSender");
-        Topic topic = (Topic) ictx.lookup("java:comp/env/jms/topiclistener");
-        Connection conn = cf.createConnection();
-        Session session = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
-        MessageConsumer mc = session.createConsumer((Destination)topic);
-        ObjectMessage message = session.createObjectMessage();
-        message.setObject(s);
-        mc.send(message);
-        session.close();
-        conn.close();
-    }
    - -

    Transactions and JMS sessions within an application component

    -JMS session creation within an application component will result in different -behaviors, depending on whether the session is created at execution time -within or outside a transaction. In fact, the parameters of the -createSession(boolean transacted, int acknowledgeMode) method are -never taken into account. -
      -
    • If the session creation occurs outside a transaction, the parameters is - considered as being transacted = false and acknowledgeMode = - AUTO_ACKNOWLEDGE. This means that each operation of the session is - immediately executed.
      • -
    • If the session creation occurs inside a transaction, the parameters - have no meaning, the session may be considered as transacted, and the - commit and rollback operations are handled by the JOnAS server at the - level of the associated XA resource.
      • -
    - -

    Authentication

    -If your JMS implementation performs user authentication, the following -methods can be used on Connection Factories: -
      -
    • createConnection(String userName, String password) on - ConnectionFactory
      • -
    • createQueueConnection(String userName, String password) on - QueueConnectionFactory
      • -
    • createTopicConnection(String userName, String password) on - TopicConnectionFactory
      • -
    - -

    Some programming rules and restrictions -when using JMS within EJB

    -This section presents some programming restrictions and rules for using JMS -operations within entity components. - -

    Connection Management

    -Depending on the JMS implementation and the application, it may be desirable -to keep the JMS connections open for the life of the bean instance or for the -duration of the method call. These two programming modes are illustrated in -the following example (this example illustrates a stateful session bean): -
    public class EjbCompBean implements SessionBean {
-    ...
-    QueueConnectionFactory qcf = null;
-    Queue queue = null;
-
-    public void ejbCreate() {
-       ....
-       ictx = new InitialContext();
-       qcf = (QueueConnectionFactory)
-          ictx.lookup("java:comp/env/jms/conFactSender");
-       queue = (Queue) ictx.lookup("java:comp/env/jms/queue1");
-    }
-
-    public void doSomethingWithJMS (...) {
-       ...
-       Connection conn = qcf.createConnection();
-       Session session = conn.createSession(...);
-       ... // JMS operations
-       session.close();
-       conn.close();
-     }
-
-    ...
-}
    -To keep the connection open during the life of a bean instance, the -programming style shown in the following example is preferred, since it -avoids many connection opening and closing operations: -
    public class EjbCompBean implements SessionBean {
-    ...
-    ConnectionFactory qcf = null;
-    Queue queue = null;
-    Connection conn = null;
-
-    public void ejbCreate() {
-       ....
-       ictx = new InitialContext();
-       cf = (ConnectionFactory)
-          ictx.lookup("java:comp/env/jms/conFactSender");
-       queue = (Queue) ictx.lookup("queue1");
-       conn = cf.createConnection();
-    }
-
-    public void doSomethingWithJMS (...) {
-       ...
-       Session session = conn.createSession(...);
-       ... // JMS operations
-       session.close();
-    }
-
-    public void ejbRemove() {
-       conn.close();
-    }
-
-    ...
-}
    -Be aware that maintaining JMS objects in the bean state is not always -possible, depending on the type of bean. -
      -
    • For a stateless session bean, the bean state is not maintained across - method calls. Therefore, the JMS objects should always be initialized and - defined in each method that performs JMS operations.
      • -
    • For an entity bean, an instance may be passivated, and only the - persistent part of the bean state is maintained. Therefore, it is - recommended that the JMS objects be initialized and defined in each - method performing JMS operations. If these objects are defined in the - bean state, they can be initialized in the ejbActivate method - (if the connection is created in the ejbActivate method, be sure - to close it in the ejbPassivate method).
      • -
    • For a stateful session bean (as shown in the previous example), JMS - objects can be defined in the bean state. Stateful session bean instances - can be passivated (not in the current version of JOnAS). Since connection - factories and destinations are serializable objects, they can be - initialized only in ejbCreate. However, be aware that a connection must - be closed in ejbPassivate (with the state variable set to - null) and recreated in ejbActivate.
      • -
    - -

    Note that, due to a known problem with the Sun JDK 1.3 on Linux, the close -of the connection can block. The problem is fixed with JDK 1.4.

    - -

    Starting Transactions after JMS Connection or Session creation

    -Currently, it is not possible to start a bean-managed transaction after the -creation of a JMS session and have the JMS operations involved in the -transaction. In the following code example, the JMS operations will not occur -within the ut transaction: -
    public class EjbCompBean implements SessionBean {
-    ...
-
-    public void doSomethingWithJMS (...) {
-       ...
-       Connection conn = cf.createConnection();
-       Session session = conn.createSession(...);
-       ut = ejbContext.getUserTransaction();
-       ut.begin();
-       ... // JMS operations
-       ut.commit();
-       session.close();
-       conn.close();
-     }
-
-    ...
-}
    -To have the session operations involved in the transaction, the session -creation and close should be inside the transaction boundaries, and the -connection creation and close operations can either be both outside the -transaction boundaries or both inside the transaction boundaries, as follows: -
    public class EjbCompBean implements SessionBean {
-    ...
-
-    public void doSomethingWithJMS (...) {
-       ...
-       Connection conn = qcf.createConnection();
-       ut = ejbContext.getUserTransaction();
-       ut.begin();
-       Session session = conn.createSession(...);
-       ... // JMS operations
-       session.close();
-       ut.commit();
-       conn.close();
-     }
-
-    ...
-}
    -or -
    public class EjbCompBean implements SessionBean {
-    ...
-
-    public void doSomethingWithJMS (...) {
-       ...
-       ut = ejbContext.getUserTransaction();
-       ut.begin();
-       Connection conn = cf.createConnection();
-       Session session = conn.createSession(...);
-       ... // JMS operations
-       session.close();
-       conn.close();
-       ut.commit();
-     }
-
-    ...
-}
    -Programming EJB components with bean-managed transactions can result in -complex code. Using container-managed transactions can help avoid problems -such as those previously described. - -

    JMS administration

    -Applications using messaging require some JMS-administered objects: -connection factories and destinations. These objects are -created via the proprietary administration interface (not standardized) of -the JMS provider. For simple cases, it is possible to have either the -jms service or the JMS resource adapter perform administration -operations during startup. - -

    As provided, the default JMS service and JORAM adapter configurations -automatically create six connection factories and two destination objects.

    - -

    The six connection factories automatically created are described in the -following table:

    -  - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    JNDI nameJMS typeUsage
    CFConnectionFactoryTo be used by an application component to create a Connection.
    QCFQueueConnectionFactoryTo be used by an application component to create a - QueueConnection.
    TCFTopicConnectionFactoryTo be used by an application component to create a - TopicConnection.
    JCFConnectionFactoryTo be used by any other Java component (for instance a client) to - create a Connection.
    JQCFQueueConnectionFactoryTo be used by any other Java component (for instance a client) to - create a QueueConnection.
    JTCFTopicConnectionFactoryTo be used by any other Java component (for instance a client) to - create a TopicConnection.
    -
    - -

    The CF, QCF and TCF connection factories are managed connection -factories. The application components should use only managed connection -factories to allow JOnAS to manage the JMS resources created via these -connection factories (the JMS sessions).
    -In contrast, JCF, JQCF and JTCF are non-managed connection factories. -They are used by Java components implementing a JMS client behavior, but -running outside the application server.

    - -

    The two destinations automatically created are described in the following -table:

    - -
    - - - - - - - - - - - - - - - - - - - -
    JNDI nameJMS typeUsage
    sampleQueueQueueCan be equally used by an EJB component or a Java component.
    sampleTopicTopicCan be equally used by an EJB component or a Java component.
    -
    - -

    JMS service administration

    -For using the JMS service in the default configuration, it is only necessary -to require the use of the JMS service in the jonas.properties file: -
        jonas.services           security,jtm,dbm,jms,ejb
    - -

    JOnAS will not create additional connection factories when using the -default configuration. However, JOnAS can create requested destination -objects at server launching time, if specified in the jonas.properties -file. To do this, specify the JNDI names of the Topic and Queue destination -objects to be created in a jonas.service.jms.topics and -jonas.service.jms.queues property respectively, as follows:

    -
        jonas.service.jms.topics    t1,t2    // JOnAS server creates 2 topic destinations (t1,t2)
-    jonas.service.jms.queues    myQueue  // JOnAS server creates 1 queue destination (myQueue)
    -It is recommended that programmers use resource references and -resource environment references to access the connection factories and -destination objects created by JOnAS, as already presented in the "Writing JMS operations within an application -component" section. - -

    JMS resource adapter configuration

    - -

    Starting with JOnAS release 4.1, it is recommended that a JMS resource -adapter be deployed instead of using the jms service. Refer to the -JMS Resource Adapters configuration -guide for an explanation.

    - -

    Running an EJB performing JMS -operations

    -All that is necessary to have an Enterprise Bean perform JMS operations is: - -

    -
    jonas start
    - -

    The Message-Oriented Middleware (the JMS provider implementation) is -automatically started (or at least accessed) and the JMS-administered objects -that will be used by the Enterprise Beans are automatically created and -registered in JNDI.

    - -

    Then, the EJB can be deployed as usual with:

    -
    jonas admin -a XX.jar
    - -

    Accessing the Message-Oriented -Middleware...

    - -

    as a service...

    -If the JOnAS property jonas.services contains the jms service, -the JOnAS JMS service will be launched and will eventually try to launch a -JMS implementation (e.g. the JORAM MOM or the SwiftMQ MOM). - -

    For launching the MOM, consider the following possibilities:

    -
      -
    1. Launching the MOM automatically in the JOnAS JVM
      - This is done using the default values for the configuration options, i.e. - keeping the JOnAS property jonas.service.jms.collocated value - true in the jonas.properties file (see the - jonas.properties file provided in $JONAS_ROOT/conf - directory). - 
          jonas.service.jms.collocated true
      - In this case, the MOM will be launched automatically at server launching - time (command jonas start). - - Note for using the JORAM MOM from a distant host: - To use the JMS resources from a distant host, the hostname - property value in the default a3servers.xml - configuration file must be changed from localhost to the - actual host name. See case 4 (Launching the MOM on another port - number) for details on the JORAM configuration. - -
      2. -
    2. Launching the MOM in a separate JVM on the same host
      - The JORAM MOM can be launched with its default options using the command: -
      -   JmsServer -

      For other MOMs, use the proprietary command.

      -


      - In this case, the JOnAS property jonas.service.jms.collocated must - be set to false in the jonas.properties file.

      - 
          jonas.service.jms.collocated false
      -
      3. -
    3. Launching the MOM on another host
      - The MOM can be launched on a separate host. In this case, the JOnAS - server must be notified that the MOM is running on another host via the - JOnAS property jonas.service.jms.url in the - jonas.properties file. For JORAM, its value should be the JORAM - URL joram://host:port where host is the host name, and - port the default JORAM port number, i.e. 16010 (For SwiftMQ, the - value of the URL is similar to smqp://host:4001/timeout=10000). - 
          jonas.service.jms.collocated false
-    jonas.service.jms.url        joram://host2:16010
      -
      4. -
    4. Launching the MOM on another port number (for JORAM)
      - To change the default JORAM port number requires a JORAM-specific - configuration operation (modifying the a3servers.xml - configuration file located in the directory where JORAM is explicitly - launched). A default a3servers.xml file is provided in the - $JONAS_ROOT/conf directory; this a3servers.xml file specifies - that the MOM runs on the localhost using the JORAM default port number. -
      - To launch the MOM on another port number, change the args attribute of - the service class="fr.dyade.aaa.mom.ConnectionFactory" element in the - a3servers.xml file and update the jonas.service.jms.url - property in the jonas.properties file.
      -
      - The default a3servers.xml file is located in $JONAS_ROOT/conf. To change - the location of this file, the system property - -Dfr.dyade.aaa.agent.A3CONF_DIR="your directory for a3.xml" must - be passed.
      -
      -
      5. -
    5. Specifying JORAM's persistence mode
      - When automatically starting JORAM, or when starting JORAM with the - JmsServer command, the default mode is non-persistent. Meaning - that in the event of a crash, the non-delivered and non-acknowledged - messages are lost.
      -
      - In order to start a persistent JORAM server, guaranteeing message - delivery even in case of failures, the Transaction system property - should be set to fr.dyade.aaa.util.NTransaction. -

      Note: the MOM may be directly launched by the proprietary - command. The command for JORAM is:
      -   java -DTransaction=fr.dyade.aaa.util.NullTransaction - fr.dyade.aaa.agent.AgentServer 0 ./s0

      -

      This command corresponds to the default options used by the - JmsServer command.

      -

      The server is not persistent when launched with this command. If - persistence is required, the - -DTransaction=fr.dyade.aaa.util.NullTransaction option should be - replaced with the -DTransaction=fr.dyade.aaa.util.NTransaction - option.

      -

      To change other MOM configurations (distribution, multi-servers, ...), - refer to the JORAM documentation on http://joram.objectweb.org.

      -
      6. -
    - -

    ... or as a J2EE1.4 adapter

    - -

    Starting with JOnAS release 4.1, a JMS server can be accessed through a -resource adapter which may be deployed.

    - -

    For deploying such a resource adapter, place the corresponding archive -file (*.rar) in the JOnAS's rars/autoload -directory, or declare it at the end of the jonas.properties -file, or deploy it manually through the jonasAdmin tool.

    - -

    Configuring and deploying such adapters is explained in the Configuring JMS Resource Adapters -section.

    - -

    A JMS EJB example

    -This example shows an EJB application that combines an Enterprise Bean -sending a JMS message and an Enterprise Bean writing a Database (an Entity -Bean) within the same global transaction. It is composed of the following -elements: -
      -
    • A Session Bean, EjbComp, with a method for sending a message to a JMS - topic.
      • -
    • An Entity Bean, Account (the one used in the sample eb with - container-managed persistence), which writes its data into a relational - database table and is intended to represent a sent message (i.e. each - time the EjbComp bean sends a message, an entity bean instance will be - created).
      • -
    • An EJB client, EjbCompClient, which calls the sendMsg method of the - EjbComp bean and creates an Account entity bean, both within the same - transaction. For a transaction commit, the JMS message is actually sent - and the record corresponding to the entity bean in the database is - created. For a rollback, the message is not sent and nothing is created - in the database.
      • -
    • A pure JMS client MsgReceptor, outside the JOnAS server, the role of - which is to receive the messages sent by the Enterprise Bean on the - topic.
      • -
    - -

    The Session Bean performing JMS operations

    -The bean should contain code for initializing the references to JMS -administered objects that it will use. To avoid repeating this code in each -method performing JMS operations, it can be introduced in the -ejbCreate method. -
    public class EjbCompBean implements SessionBean {
-    ...
-    ConnectionFactory cf = null;
-    Topic topic = null;
-
-    public void ejbCreate() {
-       ....
-       ictx = new InitialContext();
-       cf = (ConnectionFactory)
-          ictx.lookup("java:comp/env/jms/conFactSender");
-       topic = (Topic) ictx.lookup("java:comp/env/jms/topiclistener");
-    }
-    ...
-}
    -This code has been intentionally cleared from all the elements in which it is -not necessary for understanding the JMS logic aspects of the example, e.g. -exception management. - -

    The JMS-administered objects ConnectionFactory and Topic -have been made available to the bean by a resource reference in the -first example, and by a resource environment reference in the second -example.
    -The standard deployment descriptor should contain the following element:

    -
          <resource-ref>
-        <res-ref-name>jms/conFactSender</res-ref-name>
-        <res-type>javax.jms.ConnectionFactory</res-type>
-        <res-auth>Container</res-auth>
-      </resource-ref>
    -
          <resource-env-ref>
-        <resource-env-ref-name>jms/topiclistener</resource-env-ref-name>
-        <resource-env-ref-type>javax.jms.Topic</resource-env-ref-type>
-      </resource-env-ref>
    -The JOnAS-specific deployment descriptor should contain the following element: -
          <jonas-resource>
-        <res-ref-name>jms/conFactSender</res-ref-name>
-        <jndi-name>TCF</jndi-name>
-      </jonas-resource>
    -
          <jonas-resource-env>
-        <resource-env-ref-name>jms/topiclistener</resource-env-ref-name>
-        <jndi-name>sampleTopic</jndi-name>
-      </jonas-resource-env>
    -Note that the EjbComp SessionBean will use the administered objects -automatically created by JOnAS in the default JMS configuration. - -

    Because the administered objects are now accessible, it is possible to -perform JMS operations within a method. The following occurs in the -sendMsg method:

    -
    public class EjbCompBean implements SessionBean {
-    ...
-    public void sendMsg(java.lang.String s) {
-        // create Connection, Session and MessageProducer
-        Connection conn = null;
-        Session session = null;
-        MessageProducer mp = null;
-        try {
-            conn = cf.createConnection();   
-            session = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
-            mp = session.createProducer((Destination)topic);
-        }
-        catch (Exception e) {e.printStackTrace();}
-
-        // send the message to the topic
-        try {
-            ObjectMessage message;
-            message = session.createObjectMessage();
-            message.setObject(s);
-            mp.send(message);
-            session.close();
-            conn.close();
-        } catch (Exception e) {
-            e.printStackTrace();
-        }
-    }
-    ...
-}
    -This method sends a message containing its String argument. - -

    The Entity Bean

    -The example uses the simple entity bean Account for writing data into a -database. Refer to the sample eb. - -

    The Client Application

    -The client application calls the sendMsg method of the EjbComp bean and -creates an AccountImpl entity bean, both within the same transaction. -
    public class EjbCompClient {
-    ...
-    public static void main(String[] arg) {
-    ...
-    utx = (UserTransaction) initialContext.lookup("javax.transaction.UserTransaction");
-    ...
-    home1 = (EjbCompHome) initialContext.lookup("EjbCompHome");
-    home2 = (AccountHome) initialContext.lookup("AccountImplHome");
-    ...
-    EjbComp aJmsBean = home1.create();
-    Account aDataBean = null;
-    ...
-    utx.begin();
-    aJmsBean.sendMsg("Hello commit"); // sending a JMS message
-    aDataBean = home2.create(222, "JMS Sample OK", 0);
-    utx.commit();
-
-    utx.begin();
-    aJmsBean.sendMsg("Hello rollback"); // sending a JMS message
-    aDataBean = home2.create(223, "JMS Sample KO", 0);
-    utx.rollback();
-    ...
-    }
-}
    -The result of this client execution will be that: -
      -
    • the "Hello commit" message will be sent and the [222, 'JMS - Sample OK', 0] record will be created in the database (corresponding - to the entity bean 109 creation).
      • -
    • the "Hello rollback" message will never be sent and the - [223, 'JMS Sample KO', 0] record will not be created in the - database (since the entity bean 110 creation will be - canceled).
      • -
    - -

    A pure JMS client for receiving messages

    -In this example, the messages sent by the EJB component are received by a -simple JMS client that is running outside the JOnAS server, but listening for -messages sent on the JMS topic "sampleTopic." It uses the ConnectionFactory -automatically created by JOnAS named "JCF." -
    public class MsgReceptor {
-
-    static Context ictx = null;
-    static ConnectionFactory cf = null;
-    static Topic topic = null;
-
-    public static void main(String[] arg) {
-
-        ictx = new InitialContext();
-        cf = (ConnectionFactory) ictx.lookup("JCF");
-        topic = (Topic) ictx.lookup("sampleTopic");
-        ...
-        Connection conn = cf.createConnection();       
-        Session session = 
-               conn.createSession(false, Session.AUTO_ACKNOWLEDGE);  
-        MessageConsumer mc = session.createConsumer((Destination)topic);
-
-        MyListenerSimple listener = new MyListenerSimple();
-            mc.setMessageListener(listener);
-        conn.start();
-
-        System.in.read(); // waiting for messages
-
-        session.close();
-        conn.close();
-        ...
-    }
-}
    -
    public MyListenerSimple implements javax.jms.MessageListener {
-   MyListenerSimple() {}
-
-   public void onMessage(javax.jms.Message msg) {
-      try {
-      if(msg==null)
-        System.out.println("Message: message null ");
-      else {
-        if(msg instanceof ObjectMessage) {
-            String m = (String) ((ObjectMessage)msg).getObject();
-            System.out.println ("JMS client: received message ======> " + m);
-        } else if(msg instanceof TextMessage) {
-            String m = ((TextMessage)msg).getText();
-            System.out.println ("JMS client: received message ======> " + m);
-        }
-      }catch(Exception exc) {
-          System.out.println("Exception caught :" + exc);
-          exc.printStackTrace();
-      }
-   } 
-}
    - - diff --git a/jonas_doc/olddoc/PG_LogModules.html b/jonas_doc/olddoc/PG_LogModules.html deleted file mode 100644 index 132d2640a34ea3899a95731d52df5ef04dbc7123..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/PG_LogModules.html +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Login Modules Guide - - - - -

    Login Modules in a Java Client Guide

    - -

    - -

    The content of this guide is the following:

    -
      -
    1. Configuring an environment to use login - modules with java clients
      2. -
    2. Example of a client
      3. -
    - - -

    Configuring an environment to use login modules with java clients

    - -

    The login modules for use by clients are defined in the file -$JONAS_ROOT/conf/jaas.config. Example:

    -
    jaasclient {
-    // Login Module to use for the example jaasclient.
-
-    //First, use a LoginModule for the authentication
-    // Use the resource memrlm_1
-    org.objectweb.jonas.security.auth.spi.JResourceLoginModule required
-    resourceName="memrlm_1"
-        ;
-
-    // Use the login module to propagate security to the JOnAS server
-    // globalCtx is set to true in order to set the security context
-    // for all the threads of the client container instead of only
-    // on the current thread.
-    // Useful with multithread applications (like Swing Clients)
-    org.objectweb.jonas.security.auth.spi.ClientLoginModule  required
-    globalCtx="true"
-        ;
-};
-
    - -

    This file is used when a java client is launched with -jclient, as a result of the following property being set by -jclient: --Djava.security.auth.login.config==$JONAS_ROOT/conf/jaas.config
    -
    -For more information about the JAAS authentication, refer to the -JAAS -authentication tutorial.

    - - -

    Example of a client

    -
      -
    • First, the CallbackHandler to use is declared. It can be a simple - command line prompt, a dialog, or even a login/password to use.
      - Example of CallbackHandler that can be used within JOnAS. - 
          CallbackHandler handler1 = new LoginCallbackHandler();
-    CallbackHandler handler2 = new DialogCallbackHandler();
-    CallbackHandler handler3 = new NoInputCallbackHandler("jonas_user", "jonas_password");
-
      -
      • -
    • Next, the LoginContext method with the previously defined - CallbackHandler and the entry to use from the - JONAS_ROOT/conf/jaas.config file is called.
      - This example uses the dialog callbackhandler. - 
              LoginContext loginContext = new LoginContext("jaasclient", handler2);
-
      -
      • -
    • Finally, the login method on the LoginContext instance is called.
      - - 
                  loginContext.login();
-
      - If there are no exceptions, the authentication is successful.
      - Authentication can fail if the supplied password is incorrect.
      • -
    - - diff --git a/jonas_doc/olddoc/PG_MsgDrvBean.html b/jonas_doc/olddoc/PG_MsgDrvBean.html deleted file mode 100644 index b5626e2cc891fb89e29c0499eb96cd5cd2ff0bf8..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/PG_MsgDrvBean.html +++ /dev/null @@ -1,520 +0,0 @@ - - - - - - Message-driven Beans - - - - -

    EJB Programmer's Guide: Message-driven -Beans

    - -

    The content of this guide is the following:

    -
      -
    1. Description of a Message-driven - Bean
      2. -
    2. Developing a Message-driven - Bean
      3. -
    3. Administration aspects
      4. -
    4. Running a Message-driven Bean
      5. -
    5. Transactional aspects
      6. -
    6. Example
      7. -
    7. Tuning Message-driven Bean Pool
      8. -
    - -

    The EJB 2.1 specification defines a new kind of EJB component for -receiving asynchronous messages. This implements some type of "asynchronous -EJB component method invocation" mechanism. The Message-driven Bean (also -referred to as MDB in the following) is an Enterprise JavaBean, not an Entity -Bean or a Session Bean, which plays the role of a JMS MessageListener.

    - -

    The EJB 2.1 specification contains detailed information about MDB. The Java -Message Service Specification 1.1 contains detailed information about JMS. -This chapter focuses on the use of Message-driven beans within the JOnAS -server.

    - -

    Description of a Message-driven Bean

    -A Message-driven Bean is an EJB component that can be considered as a JMS -MessageListener, i.e., processing JMS messages asynchronously; it implements -the onMessage(javax.jms.Message) method, defined in the -javax.jms.MessageListener interface. It is associated with a JMS -destination, i.e., a Queue for "point-to-point" messaging or a Topic for -"publish/subscribe." The onMessage method is activated on receipt of -messages sent by a client application to the corresponding JMS destination. -It is possible to associate a JMS message selector to filter the messages -that the Message-driven Bean should receive. - -

    JMS messages do not carry any context, thus the onMessage method -will execute without pre-existing transactional context. However, a new -transaction can be initiated at this moment (refer to the "Transactional aspects" section for more -details). The onMessage method can call other methods on the MDB -itself or on other beans, and can involve other resources by accessing -databases or by sending messages. Such resources are accessed the same way as -for other beans (entity or session), i.e., through resource references -declared in the deployment descriptor.

    - -

    The JOnAS container maintains a pool of MDB instances, allowing large -volumes of messages to be processed concurrently. An MDB is similar in some -ways to a stateless session bean: its instances are relatively short-lived, -it retains no state for a specific client, and several instances may be -running at the same time.

    - -

    Developing a Message-driven -Bean

    - -

    The MDB class must implement the javax.jms.MessageListener and the -javax.ejb.MessageDrivenBean interfaces. In addition to the -onMessage method, the following must be implemented:

    -
      -
    • A public constructor with no argument.
      • -
    • public void ejbCreate(): with no arguments, called at the bean - instantiation time. It may be used to allocate some resources, such as - connection factories, for example if the bean sends messages, or - datasources or if the bean accesses databases.
      • -
    • public void ejbRemove(): usually used to free the resources - allocated in the ejbCreate method.
      • -
    • public void setMessageDrivenContext(MessageDrivenContext mdc): - called by the container after the instance creation, with no transaction - context. The JOnAS container provides the bean with a container context - that can be used for transaction management, e.g., for calling - setRollbackOnly(), getRollbackOnly(), getUserTransaction().
      • -
    - -

    The following is an example of an MDB class:

    -
    public class MdbBean  implements MessageDrivenBean, MessageListener {
-
-    private transient MessageDrivenContext mdbContext;
-
-    public MdbBean() {}
-
-    public void setMessageDrivenContext(MessageDrivenContext ctx) {
-        mdbContext = ctx;
-    }
-
-    public void ejbRemove() {}
-
-    public void ejbCreate() {}
-
-    public void onMessage(Message message) {
-        try {
-            TextMessage mess = (TextMessage)message;
-            System.out.println( "Message received: "+mess.getText());
-        }catch(JMSException ex){
-            System.err.println("Exception caught: "+ex);
-        }
-    }
-}
-
    - -

    The destination associated to an MDB is specified in the deployment -descriptor of the bean. A destination is a JMS-administered object, -accessible via JNDI. The description of an MDB in the EJB 2.0 deployment -descriptor contains the following elements, which are specific to MDBs:

    -
      -
    • the JMS acknowledgment mode: auto-acknowledge or dups-ok-acknowledge - (refer to the JMS specification for the definition of these modes)
      • -
    • an eventual JMS message selector: this is a JMS concept which allows - the filtering of the messages sent to the destination
      • -
    • a message-driven-destination, which contains the destination type - (Queue or Topic) and the subscription durability (in case of Topic)
      • -
    - -

    The following example illustrates such a deployment descriptor:

    -
      <enterprise-beans>
-    <message-driven>
-      <description>Describe here the message driven bean Mdb</description>
-      <display-name>Message Driven Bean Mdb</display-name>
-      <ejb-name>Mdb</ejb-name>
-      <ejb-class>samplemdb.MdbBean</ejb-class>
-      <transaction-type>Container</transaction-type>
-      <message-selector>Weight >= 60.00 AND LName LIKE 'Sm_th'</message-selector>
-      <message-driven-destination>
-        <destination-type>javax.jms.Topic</destination-type>
-        <subscription-durability>NonDurable</subscription-durability>
-      </message-driven-destination>
-      <acknowledge-mode>Auto-acknowledge</acknowledge-mode>
-    </message-driven>
-  </enterprise-beans>
-
    - -

    If the transaction type is "container," the transactional behavior of the -MDB's methods are defined as for other enterprise beans in the deployment -descriptor, as in the following example:

    -
      <assembly-descriptor>
-    <container-transaction>
-      <method>
-        <ejb-name>Mdb</ejb-name>
-        <method-name>*</method-name>
-      </method>
-      <trans-attribute>Required</trans-attribute>
-    </container-transaction>
-  </assembly-descriptor>
-
    - -

    For the onMessage method, only the Required or -NotSupported transaction attributes must be used, since there can be -no pre-existing transaction context.

    - -

    For the message selector specified in the previous example, the sent JMS -messages are expected to have two properties, "Weight" and "LName," for -example assigned in the JMS client program sending the messages, as -follows:

    -
            message.setDoubleProperty("Weight",75.5);
-        message.setStringProperty("LName","Smith");
-
    - -

    Such a message will be received by the Message-driven bean. The message -selector syntax is based on a subset of the SQL92. Only messages whose -headers and properties match the selector are delivered. Refer to the JMS -specification for more details.

    - -

    The JNDI name of a destination associated with an MDB is defined in the -JOnAS-specific deployment descriptor, within a jonas-message-driven -element, as illustrated in the following:

    -
      <jonas-message-driven>
-    <ejb-name>Mdb</ejb-name>
-    <jonas-message-driven-destination>
-      <jndi-name>sampleTopic</jndi-name>
-    </jonas-message-driven-destination>
-  </jonas-message-driven>
-
    - -

    Once the destination is established, a client application can send -messages to the MDB through a destination object obtained via JNDI as -follows:

    - -

    Queue q = context.lookup("sampleTopic");

    - -

    If the client sending messages to the MDB is an EJB component itself, it -is preferable that it use a resource environment reference to obtain the -destination object. The use of resource environment references is described -in the JMS -User's Guide (Writing JMS operations within an application component / -Accessing the destination object section).

    - -

    Administration aspects

    -It is assumed at this point that the JOnAS server will make use of an -existing JMS implementation, e.g., Joram, SwiftMQ. - -

    The default policy is that the MDB developer and deployer are not -concerned with JMS administration. This means that the developer/deployer -will not create or use any JMS Connection factories and will not create a JMS -destination (which is necessary for performing JMS operations within an EJB -component, refer to the JMS User's Guide); they will simply define the type of -destination in the deployment descriptor and identify its JNDI name in the -JOnAS-specific deployment descriptor, as described in the previous section. -This means that JOnAS will implicitly create the necessary administered -objects by using the proprietary administration APIs of the JMS -implementation (since the administration APIs are not standardized). To -perform such administration operations, JOnAS uses wrappers to the JMS -provider administration API. For Joram, the wrapper is -org.objectweb.jonas_jms.JmsAdminForJoram (which is the default wrapper -class defined by the jonas.service.jms.mom property in the -jonas.properties file). For SwiftMQ, a -com.swiftmq.appserver.jonas.JmsAdminForSwiftMQ class can be obtained -from the SwiftMQ site.

    - -

    For the purpose of this implicit administration phase, the deployer must -add the 'jms' service in the list of the JOnAS services. For the example -provided, the jonas.properties file should contain the following:

    -
    -jonas.services                 registry,security,jtm,dbm,jms,ejb // The jms service must be added
-jonas.service.ejb.descriptors  samplemdb.jar
-jonas.service.jms.topics       sampleTopic    // not mandatory
    - -

    The destination objects may or may not pre-exist. The EJB server will not -create the corresponding JMS destination object if it already exists. (Refer -also to JMS -administration). The sampleTopic should be explicitly -declared only if the JOnAS Server is going to create it first, even if the -Message-driven bean is not loaded, or if it is used by another client before -the Message-driven bean is loaded. In general, it is not necessary to declare -the sampleTopic.

    - -

    JOnAS uses a pool of threads for executing Message-driven -bean instances on message reception, thus allowing large volumes of messages -to be processed concurrently. As previously explained, MDB instances are -stateless and several instances may execute concurrently on behalf of the -same MDB. The default size of the pool of thread is 10, and it may be -customized via the jonas property -jonas.service.ejb.mdbthreadpoolsize, which is specified in -the jonas.properties file as in the following example:

    -
        jonas.service.ejb.mdbthreadpoolsize   50
-
    - -

    Running a Message-driven Bean

    - -

    To deploy and run a Message-driven Bean, perform the following steps:

    -
      -
    • Verify that a registry is running.
      • -

    • Start the Message-Oriented Middleware (the JMS provider - implementation). Refer to the section "Launching the Message-Oriented - Middleware."

      -
      • -

    • Create and register in JNDI the JMS destination object that will be - used by the MDB.

      -

      This can be done automatically by the JMS service or explicitly by the - proprietary administration facilities of the JMS provider (JMS - administration). The JMS service creates the destination object if - this destination is declared in the jonas.properties - file (as specified in the previous section).

      -
      • -

    • Deploy the MDB component in JOnAS.

      -

      Note that, if the destination object is not already created when - deploying an MDB, the container asks the JMS service to create it based - on the deployment descriptor content.

      -
      • -
    • Run the EJB client application.
      • -
    • Stop the application. -

      When using JMS, it is very important to stop JOnAS using the - jonas stop command; it should not be stopped directly by - killing it.

      -
      • -
    - -

    Launching the Message-Oriented -Middleware

    - -

    If the configuration property jonas.services contains the -jms service, then the JOnAS JMS service will be launched and may try to -launch a JMS implementation (a MOM).

    - -

    For launching the MOM, three possibilities can be considered:

    -
      -
    1. Launching the MOM in the same JVM as JOnAS -

      This is the default situation obtained by assigning the - true value to the configuration property - jonas.service.jms.collocated in the - jonas.properties file.

      - 
      -jonas.services                security,jtm,dbm,jms,ejb // The jms service must be in the list
-jonas.service.jms.collocated  true
      -

      In this case, the MOM is automatically launched by the JOnAS JMS - service at the JOnAS launching time (command jonas - start).

      -
      2. -
    2. Launching the MOM in a separate JVM -

      The Joram MOM can be launched using the command:

      -

      JmsServer

      -

      For other MOMs, the proprietary command should be used.

      -

      The configuration property - jonas.service.jms.collocated must be set to - false in the jonas.properties file. Setting - this property is sufficient if the JORAM's JVM runs on the same host as - JONAS, and if the MOM is launched with its default options (unchanged - a3servers.xml configuration file under JONAS_BASE/conf - or JONAS_ROOT/conf if JONAS_BASE not defined).

      - 
      -jonas.services               security,jtm,dbm,jms,ejb // The jms service must be in the list
-jonas.service.jms.collocated false
      -

      To use a specific configuration for the MOM, such as changing the - default host (which is localhost) or the default connection port number - (which is 16010), requires defining the additional - jonas.service.jms.url configuration property as - presented in the following case.

      -
      3. -
    3. Launching the MOM on another host -

      This requires defining the jonas.service.jms.url - configuration property. When using Joram, its value should be the Joram - URL joram://host:port where host is the host - name, and port is the connection port (by default, 16010). - For SwiftMQ, the value of the URL is similar to the following: - smqp://host:4001/timeout=10000.

      - 
      -jonas.services                security,jtm,dbm,jms,ejb // The jms service must be in the list
-jonas.service.jms.collocated  false
-jonas.service.jms.url         joram://host2:16010
-
      -
      4. -
    -
      -
    • Change Joram default configuration -

      As mentioned previously, the default host or default connection port - number may need to be changed. This requires modifying the - a3servers.xml configuration file provided by the JOnAS - delivery in JONAS_ROOT/conf directory. For this, JOnAS must be configured - with the property jonas.service.jms.collocated set to - false, and the property - jonas.service.jms.url set to - joram://host:port. Additionally, the MOM must have been - previously launched with the JmsServer command. This command defines a - Transaction property set to - fr.dyade.aaa.util.NullTransaction. If the messages need to - be persistent, replace the - -DTransaction=fr.dyade.aaa.util.NullTransaction option with - the -DTransaction=fr.dyade.aaa.util.NTransaction option. - Refer to the Joram documentation for more details about this command. To - define a more complex configuration (e.g., distribution, multi-servers), - refer to the Joram documentation on http://joram.objectweb.org.

      -
      • -
    - -

    Transactional aspects

    -Because a transactional context cannot be carried by a message (according to -the EJB 2.0 specification), an MDB will never execute within an existing -transaction. However, a transaction may be started during the onMessage -method execution, either due to a "required" transaction attribute -(container-managed transaction) or because it is explicitly started within -the method (if the MDB is bean-managed transacted). In the second case, the -message receipt will not be part of the transaction. In the first case, -container-managed transaction, the container will start a new transaction -before de-queueing the JMS message (the receipt of which will, thus, be part -of the started transaction), then enlist the resource manager associated with -the arriving message and all the resource managers accessed by the onMessage -method. If the onMessage method invokes other enterprise beans, the container -passes the transaction context with the invocation. Therefore, the -transaction started at the onMessage method execution may involve -several operations, such as accessing a database (via a call to an entity -bean, or by using a "datasource" resource), or sending messages (by using a -"connection factory" resource). - -

    Example

    -JOnAS provides examples that are located in the -examples/src/mdb install directory.
    -samplemdb is a very simple example, the code of which is -used in the previous topics for illustrating how to use Message-driven beans. -
    -sampleappli is a more complex example that shows how the -sending of JMS messages and updates in a database via JDBC may be involved in -the same distributed transaction.
    -The following figure illustrates the architecture of this example -application.
    -
    -eb
    - - -

    There are two Message-driven beans in this example:

    -
      -
    • StockHandlerBean - is a Message-driven bean listening to a topic and receiving Map messages. - The onMessage method runs in the scope of a transaction started - by the container. It sends a Text message on a Queue (OrdersQueue) and - updates a Stock element by decreasing the stock quantity. If the stock - quantity becomes negative, an exception is received and the current - transaction is marked for rollback.
      • -

    • OrderBean - is another Message-driven bean listening on the OrdersQueue Queue. On - receipt of a Text message on this queue, it writes the corresponding - String as a new line in a file ("Order.txt").

      -
      • -
    - -

    The example also includes a CMP entity bean Stock that -handles a stock table.

    - -

    A Stock item is composed of a Stockid (String), which is the primary key, -and a Quantity (int). The method decreaseQuantity(int qty) decreases the -quantity for the corresponding stockid, but can throw a RemoteException -"Negative stock."

    - -

    The client application SampleAppliClient -is a JMS Client that sends several messages on the topic -StockHandlerTopic. It uses Map messages with three fields: -"CustomerId," "ProductId," "Quantity." Before sending messages, this client -calls the EnvBean -for creating the StockTable in the database with known values in order -to check the results of updates at the end of the test. Eleven messages are -sent, the corresponding transactions are committed, and the last message sent -causes the transaction to be rolled back.

    - -

    Compiling this example

    - -

    To compile examples/src/mdb/sampleappli, use Ant -with the $JONAS_ROOT/examples/src/build.xml file.

    - -

    Running this example

    -
    -The default configuration of the JMS service in jonas.properties -is the following: -
    - jonas.services                 jmx,security,jtm,dbm,jms,ejb  // The jms service must be added
- jonas.service.ejb.descriptors  sampleappli.jar
- jonas.service.jms.topics       StockHandlerTopic
- jonas.service.jms.queues       OrdersQueue
- jonas.service.jms.collocated   true
-
    -This indicates that the JMS Server will be launched in the same JVM as the -JOnAS Server, and the JMS-administered objects StockHandlerTopic -(Topic) and OrdersQueue (Queue) will be created and registered -in JNDI, if not already existing. -
      -
    • Run the JOnAS Server.
      - - 
      jonas start
      -
      • -
    • Deploy the sampleappli container.
      - - 
      jonas admin -a sampleappli.jar
      -
      • -
    • Run the EJB client.
      - - 
      jclient sampleappli.SampleAppliClient
      -
      • -
    • Stop the server.
      - - 
      jonas stop
      -
      • -
    - -

    Tuning Message-driven Bean Pool

    -A pool is handled by JOnAS for each Message-driven bean. The pool can be -configured in the JOnAS-specific deployment descriptor with the following -tags: - -

    min-pool-size

    -This optional integer value represents the minimum instances that will be -created in the pool when the bean is loaded. This will improve bean instance -creation time, at least for the first beans. The default value is 0. - -

    max-cache-size

    -This optional integer value represents the maximum number of instances of -ServerSession that may be created in memory. The purpose of this value -is to keep JOnAS scalable. The policy is the following:
    -When the ConnectionConsumer ask for a ServerSession instance -(in order to deliver a new message) JOnAS tries to give an instance from the -ServerSessionPool. If the pool is empty, a new instance is created -only if the number of yet created instances is smaller than the max-cache-size -parameter. When the max-cache-size is reached, the ConnectionConsumer -is blocked and it cannot deliver new messages until a ServerSession is -eventually returned in the pool. A ServerSession is pushed into the -pool at the end of the onMessage method.
    -The default value is no limit (this means that a new instance of -ServerSession is always created when the pool is empty). -

    -The values for max-cache-size should be set accordingly to jonas.service.ejb.maxworkthreads value. -See Configuring JMS Service. -

    -

    example

    -
      <jonas-ejb-jar>
-    <jonas-message-driven>
-      <ejb-name>Mdb</ejb-name>
-      <jndi-name>mdbTopic</jndi-name>
-      <max-cache-size>20</max-cache-size>
-      <min-pool-size>10</min-pool-size>
-    </jonas-message-driven>
-  </jonas-ejb-jar>
-
    - - diff --git a/jonas_doc/olddoc/PG_Packaging.html b/jonas_doc/olddoc/PG_Packaging.html deleted file mode 100644 index 5cb776900f40fb4aefcb70474e542381aaedbe92..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/PG_Packaging.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - - - - EJB Packaging - - - -

    EJB Programmer's Guide: EJB Packaging

    - -

    Target Audience and Content

    - -

    The target audience for this guide is the Enterprise Bean provider, i.e. -the person in charge of developing the software components on the server -side. It describes how the bean components should be packaged.

    - -

    The content of this guide is the following:

    -
      -
    1. Target Audience and Content
      2. -
    2. Principles
      3. -
    - -

    Principles

    - -

    Enterprise Beans are packaged for deployment in a standard Java -programming language Archive file, called an ejb-jar file. This file -must contain the following:

    -
    -
    The beans' class files
    -
    The class files of the remote and home interfaces, of the beans' - implementations, of the beans' primary key classes (if there are any), - and of all necessary classes.
    -
    The beans' deployment descriptor
    -
    The ejb-jar file must contain the deployment descriptors, which are - made up of: -
      -
    • The standard xml deployment descriptor, in the format defined in - the EJB 2.1 specification. Refer - to $JONAS_ROOT/xml/ejb-jar_2_1.xsd or  - http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd - . This deployment descriptor must be stored with the name - META-INF/ejb-jar.xml in the ejb-jar file.
      • -
    • The JOnAS-specific XML deployment descriptor in the format - defined in $JONAS_ROOT/xml/jonas-ejb-jar_X_Y.xsd. This - JOnAS deployment descriptor must be stored with the name - META-INF/jonas-ejb-jar.xml in the ejb-jar file.
      • -
    -
    -
    - -

    Example

    - -

    Before building the ejb-jar file of the Account entity bean example, the -java source files must be compiled to obtain the class files and the two XML -deployment descriptors must be written.

    - -

    Then, the ejb-jar file (OpEB.jar) can be built using the jar -command:

    -
        cd your_bean_class_directory
-    mkdir META-INF
-    cp .../eb/*.xml META-INF
-    jar cvf OpEB.jar sb/*.class META-INF/*.xml
-
    - - diff --git a/jonas_doc/olddoc/PG_Security.html b/jonas_doc/olddoc/PG_Security.html deleted file mode 100644 index 8e07f9467b6bcacd8a29ff020436af4faa85a333..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/PG_Security.html +++ /dev/null @@ -1,255 +0,0 @@ - - - - - - - Security Management - - - -

    EJB Programmer's Guide: Security Management

    - -

    Target Audience and Content

    - -

    The target audience for this guide is the Enterprise Bean provider, i.e. -the person in charge of developing the software components on the server -side. It explains how security behavior should be defined.

    - -

    The content of this guide is the following:

    -
      -
    1. Target Audience and Content
      2. -
    2. Introduction
      3. -
    3. Declarative Security - Management
      4. -
    4. Programmatic Security - Management
      5. -
    - -

    Introduction

    - -

    The EJB architecture encourages the Bean programmer to implement the -enterprise bean class without hard-coding the security policies and -mechanisms into the business methods.

    - -

    Declarative Security -Management

    - -

    The application assembler can define a security view of the -enterprise beans contained in the ejb-jar file.
    -The security view consists of a set of security roles. A security -role is a semantic grouping of permissions for a given type of application -user that allows that user to successfully use the application.
    -The application assembler can define (declaratively in the deployment -descriptor) method permissions for each security role. A method -permission is a permission to invoke a specified group of methods for the -enterprise beans' home and remote interfaces.
    -The security roles defined by the application assembler present this -simplified security view of the enterprise beans application to the deployer; -the deployer's view of security requirements for the application is the small -set of security roles, rather than a large number of individual methods.

    - -

    Security roles

    - -

    The application assembler can define one or more security roles -in the deployment descriptor. The application assembler then assigns groups -of methods of the enterprise beans' home and remote interfaces to the -security roles in order to define the security view of the application.

    - -

    The scope of the security roles defined in the security-role -elements is the ejb-jar file level, and this includes all the enterprise -beans in the ejb-jar file.

    -
       ...
-   <assembly-descriptor>
-      <security-role>
-         <role-name>tomcat</role-name>
-      </security-role>
-      ...
-   </assembly-descriptor>
-
    - -

    Method permissions

    - -

    After defining security roles for the enterprise beans in the ejb-jar -file, the application assembler can also specify the methods of the remote -and home interfaces that each security role is allowed to invoke.

    - -

    Method permissions are defined as a binary relationship in the deployment -descriptor from the set of security roles to the set of methods of the home -and remote interfaces of the enterprise beans, including all their super -interfaces (including the methods of the javax.ejb.EJBHome and -javax.ejb.EJBObject interfaces). The method permissions -relationship includes the pair (R, M) only if the security role -R is allowed to invoke the method M.

    - -

    The application assembler defines the method permissions relationship in -the deployment descriptor using the method-permission element as -follows:

    -
      -
    • Each method-permission element includes a list of one or - more security roles and a list of one or more methods. All the listed - security roles are allowed to invoke all the listed methods. Each - security role in the list is identified by the role-name - element, and each method is identified by the method - element.
      • -
    • The method permissions relationship is defined as the union of all the - method permissions defined in the individual - method-permission elements.
      • -
    • A security role or a method can appear in multiple - method-permission elements.
      • -
    - -

    It is possible that some methods are not assigned to any security roles. -This means that these methods can be accessed by anyone.

    - -

    The following example illustrates how security roles are assigned to -methods' permissions in the deployment descriptor:

    -
       ...
-   <method-permission>
-      <role-name>tomcat</role-name>
-      <method>
-         <ejb-name>Op</ejb-name>
-         <method-name>*</method-name>
-      </method>
-   </method-permission>
-   ...
-
    - -

    Programmatic Security -Management

    - -

    Because not all security policies can be expressed declaratively, the EJB -architecture also provides a simple programmatic interface that the Bean -programmer can use to access the security context from the business -methods.

    - -

    The javax.ejb.EJBContext interface provides two methods that -allow the Bean programmer to access security information about the enterprise -bean's caller.

    -
    public interface javax.ejb.EJBContext {
-   ...
-   //
-   // The following two methods allow the EJB class
-   // to access security information
-   //
-   java.security.Principal getCallerPrincipal() ;
-   boolean isCallerInRole (String roleName) ;
-   ...
-}
-
    - -

    Use of getCallerPrincipal()

    - -

    The purpose of the getCallerPrincipal() method is to allow -the enterprise bean methods to obtain the current caller principal's name. -The methods might, for example, use the name as a key to access information -in a database.

    - -

    An enterprise bean can invoke the getCallerPrincipal() method -to obtain a java.security.Principal interface representing the -current caller. The enterprise bean can then obtain the distinguished name of -the caller principal using the getName() method of the -java.security.Principal interface.

    - -

    Use of isCallerInRole(String roleName)

    - -

    The main purpose of the isCallerInRole(String roleName) -method is to allow the Bean programmer to code the security checks that -cannot be easily defined declaratively in the deployment descriptor using -method permissions. Such a check might impose a role-based limit on a -request, or it might depend on information stored in the database.

    - -

    The enterprise bean code uses the isCallerInRole(String -roleName) method to test whether the current caller has been assigned -to a given security role or not. Security roles are defined by the -application assembler in the deployment descriptor and are assigned to -principals by the deployer.

    - -

    Declaration of security roles referenced from the bean's code

    - -

    The Bean programmer must declare in the security-role-ref -elements of the deployment descriptor all the security role names used in the -enterprise bean code. Declaring the security roles' references in the code -allows the application assembler or deployer to link the names of the -security roles used in the code to the actual security roles defined for an -assembled application through the security-role elements.

    -
       ...
-   <enterprise-beans>
-      ...
-      <session>
-         <ejb-nameOp</ejb-name>
-         <ejb-class>sb.OpBean</ejb-class>
-         ...
-         <security-role-ref>
-            <role-name>role1</role-name>
-         </security-role-ref>
-         ...
-      </session>
-      ...
-   </enterprise-beans>
-   ...
-
    - -

    The deployment descriptor in this example indicates that the enterprise -bean Op makes the security checks using -isCallerInRole("role1") in at least one of its business -methods.

    - -

    Linking security role references and security roles

    - -

    If the security-role elements have been defined in the -deployment descriptor, all the security role references declared in the -security-role-ref elements must be linked to the security roles -defined in the security-role elements.

    - -

    The following deployment descriptor example shows how to link the security -role references named role1 to the security role named -tomcat.

    - -

    -
       ...
-   <enterprise-beans>
-      ...
-      <session>
-         <ejb-name>Op</ejb-name>
-         <ejb-class>sb.OpBean</ejb-class>
-         ...
-         <security-role-ref>
-            <role-name>role1</role-name>
-            <role-link>tomcat</role-link>
-         </security-role-ref>
-         ...
-      </session>
-      ...
-   </enterprise-beans>
-   ...
-
    - -

    In summary, the role names used in the EJB code (in the isCallerInRole -method) are, in fact, references to actual security roles, which makes the -EJB code independent of the security configuration described in the -deployment descriptor. The programmer makes these role references available -to the Bean deployer or application assembler via the -security-role-ref elements included in the session -or entity elements of the deployment descriptor. Then, the Bean -deployer or application assembler must map the security roles defined in the -deployment descriptor to the "specific" roles of the target operational -environment (e.g. groups on Unix systems). However, this last mapping step is -not currently available in JOnAS.

    - - diff --git a/jonas_doc/olddoc/PG_Session.html b/jonas_doc/olddoc/PG_Session.html deleted file mode 100644 index cf7779c5abfeb4fc724c0297d1bdf8d5962d5bc3..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/PG_Session.html +++ /dev/null @@ -1,320 +0,0 @@ - - - - - - - Developing Session Beans - - - -

    EJB Programmer's Guide: Developing Session -Beans

    - -

    Target Audience and Content

    - -

    The target audience for this guide is the Enterprise Bean provider, i.e. -the person in charge of developing the software components on the server side -and, more specifically, the Session Beans.

    - -

    The content of this guide is the following:

    -
      -
    1. Target Audience and Content
      2. -
    2. Introduction
      3. -
    3. The Home Interface
      4. -
    4. The Component Interface
      5. -
    5. The Enterprise Bean Class
      6. -
    6. Tuning Stateless Session Bean Pool
      7. -
    - -

    Introduction

    - -

    A Session Bean is composed of the following parts, which are developed by -the Enterprise Bean Provider:

    -
      -
    • The Component Interface is the client view of the bean. It - contains all the "business methods" of the bean.
      • -
    • The Home Interface contains all the methods for the bean life - cycle (creation, suppression) used by the client application.
      • -
    • The bean implementation class implements the business methods - and all the methods (described in the EJB specification), allowing the - bean to be managed in the container.
      • -
    • The deployment descriptor contains the bean properties that can - be edited at assembly or deployment time.
      • -
    - -

    Note that, according to the EJB 2.0 specification, the couple "Component -Interface and Home Interface" may be either local or remote. Local -Interfaces (Home and Component) are to be used by a client running in the -same JVM as the EJB component. Create and finder methods of a local or remote -home interface return local or remote component interfaces respectively. An -EJB component can have both remote and local interfaces, even if typically -only one type of interface is provided.

    - -

    The description of these elements is provided in the following -sections.

    - -

    Note: in this documentation, the term "Bean" always means "Enterprise -Bean."

    - -

    A session bean object is a short-lived object that executes on behalf of a -single client.There are stateless and stateful session beans. -Stateless beans do not maintain state across method calls. Any instance of -stateless beans can be used by any client at any time. Stateful session beans -maintain state within and between transactions. Each stateful session bean -object is associated with a specific client. A stateful session bean with -container-managed transaction demarcation can optionally implement the -SessionSynchronization interface. In this case, the bean objects will -be informed of transaction boundaries. A rollback could result in a session -bean object's state being inconsistent; in this case, implementing the -SessionSynchronization interface may enable the bean object to update its -state according to the transaction completion status.

    - -

    The Home Interface

    - -

    A Session bean's home interface defines one or more create(...) -methods. Each create method must be named create and must -match one of the ejbCreate methods defined in the enterprise Bean class. The -return type of a create method must be the enterprise Bean's remote interface -type.
    -The home interface of a stateless session bean must have one create -method that takes no arguments.

    - -

    All the exceptions defined in the throws clause of an ejbCreate -method must be defined in the throws clause of the matching create -method of the home interface.

    - -

    A remote home interface extends the javax.ejb.EJBHome -interface, while a local home interface extends the -javax.ejb.EJBLocalHome interface.

    - -

    Example:

    - -

    The following examples use a Session Bean named Op.

    -
        public interface OpHome extends EJBHome {
-        Op create(String user) throws CreateException, RemoteException;
-    }
-
    - -

    A local home interface could be defined as follows (LocalOp -being the local component interface of the bean):

    -
        public interface LocalOpHome extends EJBLocalHome {
-        LocalOp create(String user) throws CreateException;
-    }
-
    - -

    The Component Interface

    - -

    The Component Interface is the client's view of an instance of the session -bean. This interface contains the business methods of the enterprise bean. -The interface must extend the javax.ejb.EJBObject interface if it is -remote, or the javax.ejb.EJBLocalObject if it is local. The methods -defined in a remote component interface must follow the rules for Java RMI -(this means that their arguments and return value must be valid types for -java RMI, and their throws clause must include the -java.rmi.RemoteException). For each method defined in the component -interface, there must be a matching method in the enterprise Bean's class -(same name, same arguments number and types, same return type, and same -exception list, except for RemoteException).

    - -

    Example:

    -
        public interface Op extends EJBObject {
-        public void buy (int Shares)  throws RemoteException;
-        public int  read ()           throws RemoteException;
-    }
-
    - -

    The same type of component interface could be defined as a local interface -(even if it is not considered good design to define the same interface as -both local and remote):

    -
        public interface LocalOp extends EJBLocalObject {
-        public void buy (int Shares);
-        public int  read ();
-    }
-
    - -

    The Enterprise Bean Class

    - -

    This class implements the Bean's business methods of the component -interface and the methods of the SessionBean interface, which are -those dedicated to the EJB environment. The class must be defined as public -and may not be abstract. The Session Bean interface methods that the -EJB provider must develop are the following:

    -
      -
    • public void - setSessionContext(SessionContext ic); -

      This method is used by the container to pass a reference to the - SessionContext to the bean instance. The container invokes this method on - an instance after the instance has been created. Generally, this method - stores this reference in an instance variable.

      -
      • -
    • public void ejbRemove(); -

      This method is invoked by the container when the instance is in the - process of being removed by the container. Since most session Beans do - not have any resource state to clean up, the implementation of this - method is typically left empty.

      -
      • -
    • public void ejbPassivate(); -

      This method is invoked by the container when it wants to passivate the - instance. After this method completes, the instance must be in a state - that allows the container to use the Java Serialization protocol to - externalize and store the instance's state.

      -
      • -
    • public voidejbActivate(); -

      This method is invoked by the container when the instance has just - been reactivated. The instance should acquire any resource that it has - released earlier in the ejbPassivate() method.

      -
      • -
    - -

    A stateful session Bean with container-managed transaction demarcation can -optionally implement the javax.ejb.SessionSynchronization interface. -This interface can provide the Bean with transaction synchronization -notifications. The Session Synchronization interface methods that the -EJB provider must develop are the following:

    -
      -
    • public void afterBegin(); -

      This method notifies a session Bean instance that a new transaction - has started. At this point the instance is already in the transaction and - can do any work it requires within the scope of the transaction.

      -
      • -
    • public void afterCompletion(boolean - committed); -

      This method notifies a session Bean instance that a transaction commit - protocol has completed and tells the instance whether the transaction has - been committed or rolled back.

      -
      • -
    • public void beforeCompletion(); -

      This method notifies a session Bean instance that a transaction is - about to be committed.

      -
      • -
    - -

    Example:

    -
    package sb;
-
-import java.rmi.RemoteException;
-import javax.ejb.EJBException;
-import javax.ejb.EJBObject;
-import javax.ejb.SessionBean;
-import javax.ejb.SessionContext;
-import javax.ejb.SessionSynchronization;
-import javax.naming.InitialContext;
-import javax.naming.NamingException;
-
-// This is an example of Session Bean, stateful, and synchronized.
-
-public class OpBean implements SessionBean, SessionSynchronization {
-
-    protected int total = 0;        // actual state of the bean
-    protected int newtotal = 0;        // value inside Tx, not yet committed.
-    protected String clientUser = null;
-    protected SessionContext sessionContext = null;
-
-    public void  ejbCreate(String user) {
-        total = 0;
-        newtotal = total;
-        clientUser = user;
-    }
-
-    public void ejbActivate() {
-        // Nothing to do for this simple example
-    }    
-
-    public void ejbPassivate() {
-        // Nothing to do for this simple example
-    }
-
-    public void ejbRemove() {
-        // Nothing to do for this simple example
-    }
-
-    public void setSessionContext(SessionContext sessionContext) {
-        this.sessionContext = sessionContext;
-    }
-
-    public void afterBegin() {
-        newtotal = total;
-    }
-
-    public void beforeCompletion() {
-        // Nothing to do for this simple example
-
-        // We can access the bean environment everywhere in the bean,
-        // for example here!
-        try {
-            InitialContext ictx = new InitialContext();
-            String value = (String) ictx.lookup("java:comp/env/prop1");
-            // value should be the one defined in ejb-jar.xml
-        } catch (NamingException e) {
-            throw new EJBException(e);
-        }
-    }
-
-    public void afterCompletion(boolean committed) {
-        if (committed) {
-            total = newtotal;
-        } else {
-            newtotal = total;
-        }
-    }
-
-    public void buy(int s) {
-        newtotal = newtotal + s;
-        return;
-    }
-
-    public int read() {
-        return newtotal;
-    }
-}
-
    - -

    Tuning Stateless Session Bean Pool

    -JOnAS handles a pool for each stateless session bean. The pool can be -configured in the JOnAS-specific deployment descriptor with the following -tags: - -

    min-pool-size

    -This optional integer value represents the minimum instances that will be -created in the pool when the bean is loaded. This will improve bean instance -creation time, at least for the first beans. The default value is 0. - -

    max-cache-size

    -This optional integer value represents the maximum of instances in memory. -The purpose of this value is to keep JOnAS scalable. The policy is the -following:
    -At bean creation time, an instance is taken from the pool of free instances. -If the pool is empty, a new instance is always created. When the instance -must be released (at the end of a business method), it is pushed into the -pool, except if the current number of instances created exceeds the -max-cache-size, in which case this instance is dropped. The default -value is no limit. - -

    example

    -
      <jonas-ejb-jar>
-    <jonas-session>
-      <ejb-name>SessSLR</ejb-name>
-      <jndi-name>EJB/SessHome</jndi-name>
-      <max-cache-size>20</max-cache-size>
-      <min-pool-size>10</min-pool-size>
-    </jonas-session>
-  </jonas-ejb-jar>
-
    - - diff --git a/jonas_doc/olddoc/PG_Transaction.html b/jonas_doc/olddoc/PG_Transaction.html deleted file mode 100644 index 28603499ad78f395a31112824ed9d7d16fc8c4c2..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/PG_Transaction.html +++ /dev/null @@ -1,307 +0,0 @@ - - - - - - - Transactional Behaviour - - - -

    EJB Programmer's Guide: Transactional -Behaviour

    - -

    Target Audience and Content

    - -

    The target audience for this guide is the Enterprise Bean provider, i.e. -the person in charge of developing the software components on the server -side. It describes how to define the transactional behaviour of an EJB -application.

    - -

    The content of this guide is the following:

    -
      -
    1. Target Audience and Content
      2. -
    2. Declarative Transaction - Management
      3. -
    3. Bean-managed Transaction
      4. -
    4. Distributed Transaction - Management
      5. -
    - -

    Declarative Transaction -Management

    - -

    For container-managed transaction management, the transactional behaviour -of an enterprise bean is defined at configuration time and is part of the -assembly-descriptor element of the standard deployment descriptor. It is -possible to define a common behaviour for all the methods of the bean, or to -define the behaviour at the method level. This is done by specifying a -transactional attribute, which can be one of the following:

    -
      -
    • NotSupported: if the method is called within a - transaction, this transaction is suspended during the time of the method - execution.
      • -
    • Required: if the method is called within a - transaction, the method is executed in the scope of this transaction, - else, a new transaction is started for the execution of the method, and - committed before the method result is sent to the caller.
      • -
    • RequiresNew: the method will always be executed within - the scope of a new transaction. The new transaction is started for the - execution of the method, and committed before the method result is sent - to the caller. If the method is called within a transaction, this - transaction is suspended before the new one is started and resumed when - the new transaction has completed.
      • -
    • Mandatory: the method should always be called within - the scope of a transaction, else the container will throw the - TransactionRequired exception.
      • -
    • Supports: the method is invoked within the caller - transaction scope; if the caller does not have an associated transaction, - the method is invoked without a transaction scope.
      • -
    • Never: The client is required to call the bean without - any transaction context; if it is not the case, a - java.rmi.RemoteException is thrown by the container.
      • -
    -This is illustrated in the following table: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Transaction Attribute Client transaction Transaction associated with enterprise Bean's - method 
    NotSupported -  - -

    T1

    -     		-  - -

    -

    -
    Required -  - -

    T1

    -     		T2  - -

    T1

    -
    RequiresNew -  - -

    T1

    -     		T2  - -

    T2

    -
    Mandatory -  - -

    T1

    -     		error  - -

    T1

    -
    Supports-  - -

    T1

    -     		-  - -

    T1

    -
    Never- - -

    T1

    -     		- - -

    error

    -
    - -

    - -

    In the deployment descriptor, the specification of the transactional -attributes appears in the assembly-descriptor as follows:

    -
      <assembly-descriptor>
-    <container-transaction>
-      <method>
-      <ejb-name>AccountImpl</ejb-name>
-      <method-name>*</method-name>
-      </method>
-      <trans-attribute>Supports</trans-attribute>
-    </container-transaction>
-    <container-transaction>
-      <method>
-      <ejb-name>AccountImpl</ejb-name>
-      <method-name>getBalance</method-name>
-      </method>
-      <trans-attribute>Required</trans-attribute>
-    </container-transaction>
-    <container-transaction>
-      <method>
-      <ejb-name>AccountImpl</ejb-name>
-      <method-name>setBalance</method-name>
-      </method>
-      <trans-attribute>Mandatory</trans-attribute>
-    </container-transaction>
-  </assembly-descriptor>
-
    - -

    In this example, for all methods of the AccountImpl bean which are not -explicitly specified in a container-transaction element, the default -transactional attribute is Supports (defined at the bean-level), and the -transactional attributes are Required and Mandatory (defined at the -method-name level) for the methods getBalance and setBalance respectively.

    - -

    Bean-managed Transaction

    - -

    A bean that manages its transactions itself must set the -transaction-type element in its standard deployment descriptor -to:

    -
      <transaction-type>Bean</transaction-type>
-
    - -

    To demarcate the transaction boundaries in a bean with bean-managed -transactions, the bean programmer should use the -javax.transaction.UserTransaction interface, which is defined on an -EJB server object that may be obtained using the -EJBContext.getUserTransaction() method (the SessionContext object or -the EntityContext object depending on whether the method is defined on a -session or on an entity bean). The following example shows a session bean -method "doTxJob" demarcating the transaction boundaries; the UserTransaction -object is obtained from the sessionContext object, which should have been -initialized in the setSessionContext method (refer to the example of the session -bean).

    -
    public void doTxJob() throws  RemoteException {
-     UserTransaction ut = sessionContext.getUserTransaction();
-     ut.begin();
-     ... // transactional operations
-     ut.commit();
-}
    - -

    Another way to do this is to use JNDI and to retrieve UserTransaction with -the name java:comp/UserTransaction in the initial context.

    - -

    Distributed Transaction -Management

    - -

    As explained in the previous section, the transactional behaviour of an -application can be defined in a declarative way or coded in the bean and/or -the client itself (transaction boundaries demarcation). In any case, the -distribution aspects of the transactions are completely transparent to the -bean provider and to the application assembler. This means that a transaction -may involve beans located on several JOnAS servers and that the platform -itself will handle management of the global transaction. It will perform the -two-phase commit protocol between the different servers, and the bean -programmer need do nothing.

    - -

    Once the beans have been developed and the application has been assembled, -it is possible for the deployer and for the administrator to configure the -distribution of the different beans on one or several machines, and within -one or several JOnAS servers. This can be done without impacting either the -beans code or their deployment descriptors. The distributed configuration is -specified at launch time. In the environment properties of an EJB server, the -following can be specified:

    -
      -
    • which enterprise beans the JOnAS server will handle,
      • -
    • if a Java Transaction Monitor will be located in the same Java Virtual - Machine (JVM) or not.
      • -
    - -

    To achieve this goal, two properties must be set in the -jonas.properties file, jonas.service.ejb.descriptors and -jonas.service.jtm.remote. The first one lists the beans that will be -handled on this server (by specifying the name of their ejb-jar files), and -the second one sets the Java Transaction Monitor (JTM) launching mode:

    -
      -
    • if set to true, the JTM is remote, i.e. the JTM must be - launched previously in another JVM,
      • -
    • if set to false, the JTM is local, i.e. it will run in the - same JVM as the EJB Server.
      • -
    - -

    Example:

    -
      jonas.service.ejb.descriptors       Bean1.jar, Bean2.jar
-  jonas.service.jtm.remote            false
-
    - -

    The Java Transaction Monitor can run outside any EJB server, in which case -it can be launched in a stand-alone mode using the following command:

    -
    TMServer
    - -

    - -

    Using these configuration facilities, it is possible to adapt the beans -distribution to the resources (cpu and data) location, for optimizing -performance.

    - -

    The following figure illustrates four cases of distribution configuration -for three beans.

    - -

    Figure illustrating beans distr

    -
      -
    1. Case 1: The three beans B1, B2, and B3 are located on the same JOnAS - server, which embeds a Java Transaction Monitor.
      2. -
    2. Case 2: The three beans are located on different JOnAS servers, one of - them running the Java Transaction Monitor, which manages the global - transaction.
      3. -
    3. Case 3: The three beans are located on different JOnAS servers, the - Java Transaction Monitor is running outside of any JOnAS server.
      4. -
    4. Case 4: The three beans are located on different JOnAS servers. Each - server is running a Java Transaction Monitor. One of the JTM acts as the - master monitor, while the two others are slaves.
      5. -
    - -

    These different configuration cases may be obtained by launching the JOnAS -servers and eventually the JTM (case 3) with the adequate properties. The -rational when choosing one of these configurations is resources location and -load balancing. However, consider the following pointers:

    -
      -
    • if the beans should run on the same machine, with the same server - configuration, case 1 is the more appropriate;
      • -
    • if the beans should run on different machines, case 4 is the more - appropriate, since it favours local transaction management;
      • -
    • if the beans should run on the same machine, but require different - server configurations, case 2 is a good approach.
      • -
    - - diff --git a/jonas_doc/olddoc/PG_War.html b/jonas_doc/olddoc/PG_War.html deleted file mode 100644 index 0bda251516cf9a3b697b3650294e1df4a27e1b0b..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/PG_War.html +++ /dev/null @@ -1,646 +0,0 @@ - - - - - - - Web Application Programmer's Guide - - - -

    Web Application Programmer's Guide

    - -

    Target Audience and Content

    - -

    The target audience for this guide is the Web component provider, i.e. the -person in charge of developing the Web components on the server side. It -describes how the Web component provider should build the deployment -descriptors of its Web components and how the web components should be -packaged.

    - -

    The content of this guide is the following:

    -
      -
    1. Target Audience and Content
      2. -
    2. Developing Web Components - -
      3. -
    3. Defining the Web Deployment Descriptor - -
      4. -
    4. WAR Packaging
      5. -
    - -

    Developing Web Components

    - -

    Introduction

    - -

    A Web Component is a generic term which denotes both JSP pages and -Servlets. Web components are packaged in a .war file and can be -deployed in a JOnAS server via the web container service. Web -components can be integrated in a J2EE application by packing the -.war file in an .ear file (refer to the J2EE Application Programmer's -Guide).

    - -

    The JOnAS distribution includes a Web application example: The EarSample example.

    - -

    The directory structure of this application is the following:

    - - - - - - - - - - - - - - - - - - - - -
    etc/xmlcontains the web.xml file describing the web application
    etc/resources/webcontains html pages and images; JSP pages can also be placed - here.
    src/org/objectweb/earsample/servletsservlet sources
    src/org/objectweb/earsample/beansbeans sources
    - -

    The bean directory is not needed if beans coming from another application -will be used.

    - -

    The JSP pages

    - -

    Java Server Pages (JSP) is a technology that allows regular, static HTML, -to be mixed with dynamically-generated HTML written in Java programming -language for encapsulating the logic that generates the content for the page. -Refer to the Java Server -PagesTM and the Quickstart guide for -more details.

    - -

    Example:

    - -

    The following example shows a sample JSP page that lists the content of a -cart.

    -
        <!-- Get the session -->
-    <%@ page session="true" %>
-
-    <!-- The import to use -->
-    <%@ page import="java.util.Enumeration" %>
-    <%@ page import="java.util.Vector"      %>
-
-    <html>
-    <body bgcolor="white">
-      <h1>Content of your cart</h1><br>
-      <table>
-        <!-- The header of the table -->
-        <tr bgcolor="black">
-          <td><font color="lightgreen">Product Reference</font></td>
-          <td><font color="lightgreen">Product Name</font></td>
-          <td><font color="lightgreen">Product Price</font></td>
-        </tr>
-
-        <!-- Each iteration of the loop display a line of the table -->
-        <%
-          Cart cart = (Cart) session.getAttribute("cart");
-          Vector products = cart.getProducts();
-          Enumeration enum = products.elements();
-          // loop through the enumeration
-          while (enum.hasMoreElements()) {
-              Product prod = (Product) enum.nextElement();
-        %>
-        <tr>
-          <td><%=prod.getReference()%></td>
-          <td><%=prod.getName()%></td>
-          <td><%=prod.getPrice()%></td>
-        </tr>
-        <%
-        } // end loop
-        %>
-      </table>
-    </body>
-    </html>
-
    - -

    It is a good idea to hide all the mechanisms for accessing EJBs from JSP -pages by using a proxy java bean, referenced in the JSP page by the -usebean special tag. This technique is shown in the alarm example, where the .jsp files -communicate with the EJB via a proxy java bean ViewProxy.java.

    - -

    The Servlets

    - -

    Servlets are modules of Java code that run in an application server for -answering client requests. Servlets are not tied to a specific client-server -protocol. However, they are most commonly used with HTTP, and the word -"Servlet" is often used as referring to an "HTTP Servlet."

    - -

    Servlets make use of the Java standard extension classes in the packages -javax.servlet (the basic Servlet framework) and -javax.servlet.http (extensions of the Servlet framework for -Servlets that answer HTTP requests).

    - -

    Typical uses for HTTP Servlets include:

    -
      -
    • processing and/or storing data submitted by an HTML form,
      • -
    • providing dynamic content generated by processing a database query,
      • -
    • managing information of the HTTP request.
      • -
    - -

    For more details refer to the JavaTM Servlet -Technology and the Servlets -tutorial.

    - -

    Example:

    - -

    The following example is a sample of a Servlet that lists the content of a -cart.
    -This example is the servlet version of the previous JSP page example.

    -
        import java.util.Enumeration;
-    import java.util.Vector;
-    import java.io.PrintWriter;
-    import java.io.IOException;
-    import javax.servlet.ServletException;
-    import javax.servlet.http.HttpServlet;
-    import javax.servlet.http.HttpServletRequest;
-    import javax.servlet.http.HttpServletResponse;
-    import javax.servlet.http.HttpSession;
-
-    public class GetCartServlet extends HttpServlet {
-
-        protected void doGet(HttpServletRequest req, HttpServletResponse res)
-                             throws ServletException, IOException {
-
-            res.setContentType("text/html");
-            PrintWriter out = res.getWriter();
-
-            out.println("<html><head><title>Your cart</title></head>");
-            out.println("<body>");
-            out.println("<h1>Content of your cart</h1><br>");
-            out.println("<table>");
-
-            // The header of the table
-            out.println("<tr>");
-            out.println("<td><font color="lightgreen">Product Reference</font></td>");
-            out.println("<td><font color="lightgreen">Product Name</font></td>");
-            out.println("<td><font color="lightgreen">Product Price</font></td>");
-            out.println("</tr>");
-
-            // Each iteration of the loop display a line of the table
-            HttpSession session = req.getSession(true);
-            Cart cart = (Cart) session.getAttribute("cart");
-            Vector products = cart.getProducts();
-            Enumeration enum = products.elements();
-            while (enum.hasMoreElements()) {
-                Product prod = (Product) enum.nextElement();
-                int prodId = prod.getReference();
-                String prodName = prod.getName();
-                float prodPrice = prod.getPrice();
-                out.println("<tr>");
-                out.println("<td>" + prodId + </td>);
-                out.println("<td>" + prodName + </td>);
-                out.println("<td>" + prodPrice + </td>);
-                out.println("</tr>");
-            }
-
-            out.println("</table>");
-            out.println("</body>");
-            out.println("</html>");
-            out.close();
-        }
-    }
-
    - -

    Accessing an EJB from a Servlet or JSP -page

    -Through the JOnAS web container service, it is possible to access an -enterprise java bean and its environment in a J2EE-compliant way. - -

    The following sections describe:

    -
      -
    1. How to access the Remote Home interface of a bean.
      2. -
    2. How to access the Local Home interface of a bean.
      3. -
    3. How to access the environment of a bean.
      4. -
    4. How to start transactions in servlets.
      5. -
    -Note that all the following code examples are taken from the The EarSample example provided in the JOnAS -distribution. - -

    Accessing the Remote Home interface of a bean:

    -In this example the servlet gets the Remote Home interface OpHome -registered in JNDI using an EJB reference, then creates a new instance of the -session bean: -
    import javax.naming.Context;
-import javax.naming.InitialContext;
-
-//remote interface
-import org.objectweb.earsample.beans.secusb.Op;
-import org.objectweb.earsample.beans.secusb.OpHome;
-
-        Context initialContext = null;
-        try {
-            initialContext = new InitialContext();
-        } catch (Exception e) {
-            out.print("<li>Cannot get initial context for JNDI: ");
-            out.println(e + "</li>");
-            return;
-        }
-      // Connecting to OpHome thru JNDI
-        OpHome opHome = null;
-        try {
-            opHome = (OpHome) PortableRemoteObject.narrow(initialContext.lookup
-                     ("java:comp/env/ejb/Op"),OpHome.class);
-        } catch (Exception e) {
-            out.println("<li>Cannot lookup java:comp/env/ejb/Op: " + e + "</li>");
-            return;
-        }
-        // OpBean creation
-        Op op = null;
-        try {
-            op = opHome.create("User1");
-        } catch (Exception e) {
-            out.println("<li>Cannot create OpBean: " + e + "</li>");
-            return;
-        }
    -Note that the following elements must be set in the web.xml file -tied to this web application: -
      <ejb-ref>
-    <ejb-ref-name>ejb/Op</ejb-ref-name>
-    <ejb-ref-type>Session</ejb-ref-type>
-    <home>org.objectweb.earsample.beans.secusb.OpHome</home>
-    <remote>org.objectweb.earsample.beans.secusb.Op</remote>
-    <ejb-link>secusb.jar#Op</ejb-link>
-  </ejb-ref>
    - -

    Accessing the Local Home of a bean:

    -The following example shows how to obtain a local home interface -OpLocalHome using an EJB local reference: -
    //local interfaces
-import org.objectweb.earsample.beans.secusb.OpLocal;
-import org.objectweb.earsample.beans.secusb.OpLocalHome;
-
-
-      // Connecting to OpLocalHome thru JNDI
-        OpLocalHome opLocalHome = null;
-        try {
-            opLocalHome = (OpLocalHome)
-                initialContext.lookup("java:comp/env/ejb/OpLocal");
-        } catch (Exception e) {
-            out.println("<li>Cannot lookup java:comp/env/ejb/OpLocal: " + e + "</li>");
-            return;
-        }
    -This is found in the web.xml file: -
      <ejb-local-ref>
-    <ejb-ref-name>ejb/OpLocal</ejb-ref-name>
-    <ejb-ref-type>Session</ejb-ref-type>
-    <local-home>org.objectweb.earsample.beans.secusb.OpLocalHome</local-home>
-    <local>org.objectweb.earsample.beans.secusb.OpLocal</local>
-    <ejb-link>secusb.jar#Op</ejb-link>
-  </ejb-local-ref>
    - -

    Accessing the environment of the component:

    -In this example, the servlet seeks to access the component's environment: -
           String envEntry = null;
-        try {
-            envEntry = (String) initialContext.lookup("java:comp/env/envEntryString");
-        } catch (Exception e) {
-            out.println("<li>Cannot get env-entry on JNDI " + e + "</li>");
-            return;
-        }
    -This is the corresponding part of the web.xml file: -
      <env-entry>
-    <env-entry-name>envEntryString</env-entry-name>
-    <env-entry-value>This is a string from the env-entry</env-entry-value>
-    <env-entry-type>java.lang.String</env-entry-type>
-  </env-entry>
    - -

    Starting transactions in servlets:

    -The servlet wants to start transactions via the UserTransaction: -
    import javax.transaction.UserTransaction;
-
-       // We want to start transactions from client: get UserTransaction
-        UserTransaction utx = null;
-        try {
-            utx = (UserTransaction) initialContext.lookup("java:comp/UserTransaction");
-        } catch (Exception e) {
-            out.println("<li>Cannot lookup java:comp/UserTransaction: " + e + "</li>");
-            return;
-        }
-
-        try {
-            utx.begin();
-            opLocal.buy(10);
-            opLocal.buy(20);
-            utx.commit();
-
-        } catch (Exception e) {
-            out.println("<li>exception during 1st Tx: " + e + "</li>");
-            return;
-        }
    - -

    Defining the Web Deployment -Descriptor

    - -

    Principles

    - -

    The Web component programmer is responsible for providing the deployment -descriptor associated with the developed web components. The Web component -provider's responsibilities and the application assembler's responsibilities -are to provide an XML deployment descriptor that conforms to the deployment -descriptor's XML schema as defined in the Java TM Servlet -Specification Version 2.4. (Refer to -$JONAS_ROOT/xml/web-app_2_4.xsd or  -http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd).

    - - -

    To customize the Web components, information not defined in the standard -XML deployment descriptor may be needed. For example, the information may -include the mapping of the name of referenced resources to its JNDI name. -This information can be specified during the deployment phase, within another -XML deployment descriptor that is specific to JOnAS. The JOnAS-specific -deployment descriptor's XML schema is located in -$JONAS_ROOT/xml/jonas-web-app_X_Y.xsd. The file name of the -JOnAS-specific XML deployment descriptor must be the file name of the -standard XML deployment descriptor prefixed by 'jonas-'.

    - -

    The parser gets the specified schema via the classpath (schemas are packaged -in the $JONAS_ROOT/lib/common/ow_jonas.jar file).

    - -

    The standard deployment descriptor (web.xml) should contain structural -information that includes the following:

    -
      -
    • The Servlet's description (including Servlet's name, Servlet's class or - jsp-file, Servlet's initialization parameters),
      • -
    • Environment entries,
      • -
    • EJB references,
      • -
    • EJB local references,
      • -
    • Resource references,
      • -
    • Resource env references.
      • -
    - -

    The JOnAS-specific deployment descriptor (jonas-web.xml) may contain -information that includes:

    -
      -
    • The JNDI name of the external resources referenced by a Web - component,
      • -
    • The JNDI name of the external resources environment referenced by a Web - component,
      • -
    • The JNDI name of the referenced bean's by a Web component,
      • -
    • The name of the virtual host on which to deploy the servlets,
      • -
    • The name of the context root on which to deploy the servlets,
      • -
    • The compliance of the web application classloader to the java 2 - delegation model or not.
      • -
    - -

    <host> element: If the configuration file of the web container -contains virtual hosts, the host on which the WAR file is deployed can be -set.

    - -

    <context-root> element: The name of the context on which the -application will be deployed should be specified. If it is not specified, the -context-root used can be one of the following:

    -
      -
    • If the war is packaged into an EAR file, the context-root used is the - context specified in the application.xml file.
      • -
    • If the war is standalone, the context-root is the name of the war file - (i.e, the context-root is jonasAdmin for jonasAdmin.war).
      • -
    -If the context-root is / or empty, the web application is deployed as ROOT -context (i.e., http://localhost:9000/). - -

    <java2-delegation-model> element: Set the compliance to the java 2 -delegation model.

    -
      -
    • If true: the web application context uses a classloader, using the Java - 2 delegation model (ask parent classloader first).
      • -
    • If false: the class loader searches inside the web application first, - before asking parent class loaders.
      • -
    - -

    - -

    Examples of Web Deployment Descriptors

    -
      -
    • Example of a standard Web Deployment Descriptor (web.xml): - 
      <?xml version="1.0" encoding="ISO-8859-1"?>
-
-<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
-         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
-         version="2.4">
-
-  <servlet>
-    <servlet-name>Op</servlet-name>
-      <servlet-class>org.objectweb.earsample.servlets.ServletOp</servlet-class>
-  </servlet>
-
-  <servlet-mapping>
-    <servlet-name>Op</servlet-name>
-    <url-pattern>/secured/Op</url-pattern>
-  </servlet-mapping>
-
-  <security-constraint>
-    <web-resource-collection>
-      <web-resource-name>Protected Area</web-resource-name>
-        <!-- Define the context-relative URL(s) to be protected -->
-        <url-pattern>/secured/*</url-pattern>
-        <!-- If you list http methods, only those methods are protected -->
-        <http-method>DELETE</http-method>
-        <http-method>GET</http-method>
-        <http-method>POST</http-method>
-        <http-method>PUT</http-method>
-    </web-resource-collection>
-    <auth-constraint>
-      <!-- Anyone with one of the listed roles may access this area -->
-      <role-name>tomcat</role-name>
-      <role-name>role1</role-name>
-    </auth-constraint>
-  </security-constraint>
-
-  <!-- Default login configuration uses BASIC authentication -->
-  <login-config>
-    <auth-method>BASIC</auth-method>
-    <realm-name>Example Basic Authentication Area</realm-name>
-  </login-config>
-
-  <env-entry>
-    <env-entry-name>envEntryString</env-entry-name>
-    <env-entry-value>This is a string from the env-entry</env-entry-value>
-    <env-entry-type>java.lang.String</env-entry-type>
-  </env-entry>
-
-  <!-- reference on a remote bean without ejb-link-->
-  <ejb-ref>
-    <ejb-ref-name>ejb/Op</ejb-ref-name>
-    <ejb-ref-type>Session</ejb-ref-type>
-    <home>org.objectweb.earsample.beans.secusb.OpHome</home>
-    <remote>org.objectweb.earsample.beans.secusb.Op</remote>
-  </ejb-ref>
-
-  <!-- reference on a remote bean using ejb-link-->
-  <ejb-ref>
-    <ejb-ref-name>ejb/EjbLinkOp</ejb-ref-name>
-    <ejb-ref-type>Session</ejb-ref-type>
-    <home>org.objectweb.earsample.beans.secusb.OpHome</home>
-    <remote>org.objectweb.earsample.beans.secusb.Op</remote>
-    <ejb-link>secusb.jar#Op</ejb-link>
-  </ejb-ref>
-
-  <!-- reference on a local bean -->
-  <ejb-local-ref>
-    <ejb-ref-name>ejb/OpLocal</ejb-ref-name>
-    <ejb-ref-type>Session</ejb-ref-type>
-    <local-home>org.objectweb.earsample.beans.secusb.OpLocalHome</local-home>
-    <local>org.objectweb.earsample.beans.secusb.OpLocal</local>
-    <ejb-link>secusb.jar#Op</ejb-link>
-  </ejb-local-ref>
-</web-app>
-
      -
      • -
    • Example of a specific Web Deployment Descriptor (jonas-web.xml): - 
      <?xml version="1.0" encoding="ISO-8859-1"?>
-
-<jonas-web-app xmlns="http://www.objectweb.org/jonas/ns"
-	       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-	       xsi:schemaLocation="http://www.objectweb.org/jonas/ns
-	       http://www.objectweb.org/jonas/ns/jonas-web-app_4_0.xsd" >
-
-  <!-- Mapping between the referenced bean and its JNDI name, override the ejb-link if
-       there is one in the associated ejb-ref in the standard Web Deployment Descriptor -->
-  <jonas-ejb-ref>
-    <ejb-ref-name>ejb/Op</ejb-ref-name>
-    <jndi-name>OpHome</jndi-name>
-  </jonas-ejb-ref>
-
-  <!-- the virtual host on which deploy the web application -->
-  <host>localhost</host>
-
-  <!-- the context root on which deploy the web application -->
-  <context-root>web-application</context-root>
-</jonas-web-app>
-
-
      -
      • -
    - -

    Tips

    - -

    Although some characters, such as ">", are legal, it is good practice -to replace them with XML entity references. The following is a list of the -predefined entity references for XML:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    &lt;<less than
    &gt;>greater than
    &amp;&ampersand
    &apos;'apostrophe
    &quot;"quotation mark
    - -

    - -

    WAR Packaging

    - -

    Web components are packaged for deployment in a standard Java programming -language Archive file called a war file (Web ARchive), which is a -jar similar to the package used for Java class libraries. A -war has a specific hierarchical directory structure. The top-level -directory of a war is the document root of the application.

    - -

    The document root is where JSP pages, client-side classes and archives, -and static web resources are stored. The document root contains a -subdirectory called WEB-INF, which contains the following files and -directories:

    -
      -
    • web.xml: The standard xml deployment descriptor in the format - defined in the Java Servlet 2.4 Specification. Refer to - $JONAS_ROOT/xml/web-app_2_4.xsd.
      • -
    • jonas-web.xml: The optional JOnAS-specific XML deployment - descriptor in the format defined in - $JONAS_ROOT/xml/jonas-web_X_Y.xsd.
      • -
    • classes: a directory that contains the servlet classes and - utility classes.
      • -
    • lib: a directory that contains jar archives of libraries (tag - libraries and any utility libraries called by server-side classes). If - the Web application uses Enterprise Beans, it can also contain - ejb-jars. This is necessary to give to the Web components the - visibility of the EJB classes.
      - However, if the war is intended to be packed in a ear, the - ejb-jars must not be placed here. In this case, they are directly - included in the ear. Due to the use of the class loader hierarchy, - Web components have the visibility of the EJB classes.
      - Details about the class loader hierarchy are described in JOnAS class loader - hierarchy.
      • -
    - -

    Example

    - -

    Before building a war file, the java source files must be compiled -to obtain the class files (located in the WEB-INF/classes directory) -and the two XML deployment descriptors must be written.

    - -

    Then, the war file (<web-application>.war) is built using the -jar command:

    -
        cd <your_webapp_directory>
-    jar cvf <web-application>.war *
-
    - -

    During the development process, an 'unpacked version' of the war file can -be used. Refer to Configuring Web -Container Service for information about how to use directories for the -web application.

    - - diff --git a/jonas_doc/olddoc/Services.html b/jonas_doc/olddoc/Services.html deleted file mode 100644 index afaf15ff649e5ba6d29ae7ffbbb81d751f62212f..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/Services.html +++ /dev/null @@ -1,229 +0,0 @@ - - - - - - - JOnAS Services - - - - -

    Creating a New JOnAS Service

    - -

    The content of this guide is the following:

    -
      -
    1. Target Audience and Rationale
      2. -
    2. Introducing a new Service
      3. -
    3. Advanced Understanding
      4. -
    - -

    Target Audience and Rationale

    - -

    This chapter is intended for advanced JOnAS users who require that some -"external" services run along with the JOnAS server. A service is something -that may be initialized, started, and stopped. JOnAS itself already defines a -set of services, some of which are cornerstones of the JONAS Server. The -JOnAS pre-defined services are listed in Configuring JOnAS services.

    - -

    J2EE application developers may need to access other services, for example -another Web container or a Versant container, for their components. Thus, it -is important that such services be able to run along with the application -server. To achieve this, it is possible to define them as JOnAS services.

    - -

    This chapter describes how to define a new JOnAS service and how to -specify which service should be started with the JOnAS server.

    - -

    Introducing a new Service

    - -

    The customary way to define a new JOnAS service is to encapsulate it in a -class whose interface is known by JOnAS. More precisely, such a class -provides a way to initialize, start, and stop the service. Then, the -jonas.properties file must be modified to make JOnAS aware of this -service.

    - -

    Defining the Service class

    - -

    A JOnAS service is represented by a class that implements the interface -org.objectweb.jonas.service.Service, and, thus should implement -the following methods:

    -
      -
    • public void init(Context ctx) throws ServiceException;
      • -
    • public void start() throws ServiceException;
      • -
    • public void stop() throws ServiceException;
      • -
    • public boolean isStarted();
      • -
    • public String getName();
      • -
    • public void setName(String name);
      • -
    - -

    It should also define a public constructor with no argument.

    - -

    These methods will be called by JOnAS for initializing, starting, and -stopping the service. Configuration parameters are provided to the -initialization method through a naming context. This naming context is built -from properties defined in the jonas.properties file as -explained in the following section.

    - -

    The Service class should look like the following:

    -
    package a.b;
    import javax.naming.Context;
    import javax.naming.NamingException;
    import org.objectweb.jonas.service.Service;
    import org.objectweb.jonas.service.ServiceException;
    .....
    public class MyService implements Service {
        private String name = null;
        private boolean started = false;
        .....
        public void init(Context ctx) throws ServiceException {
            try {
                String p1 = (String) ctx.lookup("jonas.service.serv1.p1");
                .....
            } catch (NamingException e) {
                throw new ServiceException("....", e);
            }
            .....
        }
        public void start() throws ServiceException {
            .....
            this.started = true;
        }
        public void stop() throws ServiceException {
            if (this.started) {
                this.started = false;
                .....
            }
        }
        public boolean isStarted() {
            return this.started;
        }
        public String getName() {
            return this.name;
        }
        public void setName(String name) {
            this.name = name;
        }
    }
    - -

    Modifying the jonas.properties file

    - -

    The service is defined and its initialization parameters specified in the -jonas.properties file. First, choose a name for the service -(e.g. "serv1"), then do the following:

    -
      -
    • add this name to the jonas.services property; this - property defines the set of services (comma-separated) that will be - started with JOnAS, in the order of this list.
      • -
    • add a jonas.service.serv1.class property specifying the - service class.
      • -
    • add as many jonas.service.serv1.XXX properties specifying - the service initialization parameters, as will be made available to the - service class via the Context argument of the init - method.
      • -
    - -

    This is illustrated as follows:

    -
      jonas.services                   .......,serv1
      jonas.service.serv1.class        a.b.MyService
      jonas.service.serv1.p1           value
    - -

    Using the New Service

    -The new service has been given a name in jonas.properties. With -this name, it is possible to get a reference on the service implementation -class by using the ServiceManager method: getService(name). The -following is an example of accessing a Service: -
    import org.objectweb.jonas.service.ServiceException;
    import org.objectweb.jonas.service.ServiceManager;

        MyService sv = null;

            // Get a reference on MyService.
            try {
                sv = (MyService) ServiceManager.getInstance().getService("serv1");
            } catch (ServiceException e) {
                Trace.errln("Cannot find MyService:"+e);
            }
    - -

    Adding the class of the new service to JOnAS

    - -

    Package the class of the service into a .jar file and add the jar in the -JONAS_ROOT/lib/ext directory.
    -All the libraries required by the service can also be placed in this -directory.

    - -

    Advanced Understanding

    - -

    Refer to the JOnAS sources for more details about the classes mentioned in -this section.

    - -

    JOnAS built-in services

    - -

    The existing JOnAS services are the following:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Service nameService class
    registryRegistryServiceImpl
    ejbEJBServiceImpl
    webCatalinaJWebContainerServiceImpl / - JettyJWebContainerServiceImpl
    earEarServiceImpl
    dbmDataBaseServiceImpl
    jmsJmsServiceImpl
    jmxJmxServiceImpl
    jtmTransactionServiceImpl
    mailMailServiceImpl
    resourceResourceServiceImpl
    securityJonasSecurityServiceImpl
    ws
    -     		AxisWSService
    -
    - -

    If all of these services are required, they will be launched in the -following order: registry, jmx, security, -jtm,dbm,mail,jms,resource,ejb, ws, -web, ear.
    -jmx, security, dbm, mail, resource are -optional when you are using service ejb.

    - -

    registry must be launched first.
    -(Note that for reasons of compatability with previous versions of JOnAS, if -registry is unintentionally not set as the first service to launch, -JOnAS will automatically launch the registry service.)

    -
    -Note that dbm, jms, resource, and ejb depend on -jtm.
    -Note that ear depends on ejb and web (that provide the -ejb and web containers), thus these services must be launched before the -ear service.
    -Note that ear and web depends on ws, thus the ws service must be launched before the -ear and web service.
    -
    -It is possible to launch a stand-alone Transaction Manager with only the -registry and jtm services. - -

    A jonas.properties file looks like the following:

    -
      .....
      .....

      jonas.services                registry,jmx,security,jtm,dbm,mail,jms,ejb,resource,serv1 

      jonas.service.registry.class  org.objectweb.jonas.registry.RegistryServiceImpl
      jonas.service.registry.mode        automatic

      jonas.service.dbm.class       org.objectweb.jonas.dbm.DataBaseServiceImpl
      jonas.service.dbm.datasources Oracle1

      jonas.service.ejb.class       org.objectweb.jonas.container.EJBServiceImpl
      jonas.service.ejb.descriptors ejb-jar.jar
      jonas.service.ejb.parsingwithvalidation  true
      jonas.service.ejb.mdbthreadpoolsize      10

      jonas.service.web.class        org.objectweb.jonas.web.catalina.CatalinaJWebContainerServiceImpl
      jonas.service.web.descriptors        war.war
      jonas.service.web.parsingwithvalidation  true

      jonas.service.ear.class       org.objectweb.jonas.ear.EarServiceImpl
      jonas.service.ear.descriptors j2ee-application.ear
      jonas.service.ear.parsingwithvalidation  true

      jonas.service.jms.class       org.objectweb.jonas.jms.JmsServiceImpl
      jonas.service.jms.mom         org.objectweb.jonas_jms.JmsAdminForJoram
      jonas.service.jms.collocated  true
      jonas.service.jms.url         joram://localhost:16010

      jonas.service.jmx.class       org.objectweb.jonas.jmx.JmxServiceImpl

      jonas.service.jtm.class       org.objectweb.jonas.jtm.TransactionServiceImpl
      jonas.service.jtm.remote      false
      jonas.service.jtm.timeout     60

      jonas.service.mail.class        org.objectweb.jonas.mail.MailServiceImpl
      jonas.service.mail.factories  MailSession1

      jonas.service.security.class  org.objectweb.jonas.security.JonasSecurityServiceImpl

      jonas.service.resource.class        org.objectweb.jonas.resource.ResourceServiceImpl
      jonas.service.resource.resources         MyRA

      jonas.service.serv1.class     a.b.MyService
      jonas.service.serv1.p1        John
    - -

    The ServiceException

    - -

    The org.objectweb.jonas.service.ServiceException exception is -defined for Services. Its type is java.lang.RuntimeException. -and it can encapsulate any java.lang.Throwable.

    - -

    The ServiceManager

    - -

    The org.objectweb.jonas.service.ServiceManager class is -responsible for creating, initializing, and launching the services. It can -also return a service from its name and list all the services.

    - - diff --git a/jonas_doc/olddoc/ant-ejbjar.html b/jonas_doc/olddoc/ant-ejbjar.html deleted file mode 100644 index 854fb237edfff6951c13a10c56d75c93a100f7cb..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/ant-ejbjar.html +++ /dev/null @@ -1,477 +0,0 @@ - - - - - - - EJB Tasks - - - -

    Ant EJB Tasks User Manual

    - -

    New JOnAS (Java Open Application -Server) element for the current JOnAS version

    - -

    The <jonas> nested element uses the -GenIC-specific tool to build JOnAS-specific stubs and skeletons -and construct a JAR file which may be deployed to the JOnAS Application -Server. The build process will always determine if the EJB stubs/skeletons -and the EJB-JAR file are up to date, and it will perform the minimum amount -of work required.

    - -

    A naming convention for the EJB descriptors is most commonly used to -specify the name for the completed JAR file. For example, if the EJB -descriptor ejb/Account-ejb-jar.xml is located in the descriptor -directory, the <jonas> element will search for a -JOnAS-specific EJB descriptor file named -ejb/Account-jonas-ejb-jar.xml, and a JAR file named -ejb/Account.jar will be written in the destination directory. -The <jonas> element can also use the JOnAS naming -convention. Using the same example, the EJB descriptor can also be named -ejb/Account.xml (no base name terminator here) in the descriptor -directory. The <jonas> element will then search for a -JOnAS-specific EJB descriptor file called ejb/jonas-Account.xml. -This convention does not strictly follow the ejb-jar naming convention -recommendation, but it is supported for backward compatibility with previous -version of JOnAS.

    - -

    Note that when the EJB descriptors are added to the JAR file, they are -automatically renamed META-INF/ejb-jar.xml and -META-INF/jonas-ejb-jar.xml.

    - -

    Furthermore, this naming behaviour can be modified by specifying -attributes in the ejbjar task (for example, basejarname, basenameterminator, -and flatdestdir) as well as the iplanet element (for example, suffix). Refer -to the appropriate documentation for more details.

    - -

    Parameters:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    AttributeDescriptionRequired
    destdirThe base directory into which the generated JAR files - will be written. Each JAR file is written in directories which - correspond to their location within the "descriptordir" - namespace.Yes
    jonasrootThe root directory for JOnAS.Yes
    jonasbaseThe base directory for JOnAS. If omitted, it defaults - to jonasroot.No
    classpathThe classpath used when generating EJB stubs and - skeletons. If omitted, the classpath specified in the "ejbjar" parent - task will be used. If specified, the classpath elements will be - prefixed to the classpath specified in the parent "ejbjar" task. A - nested "classpath" elements can also be used. Note that the needed - JOnAS JAR files are automatically added to the classpath.No
    keepgeneratedtrue if the intermediate Java source - files generated by GenIC must not be deleted. If omitted, it defaults - to false.No
    nofastrmicif true, the external RMIC compiler is used - by GenIC. The default is false, which means the internal - fast RMIC compiler is used.No
    nocompiltrue if the generated source files must - not be compiled via the java and rmi compilers. If omitted, it - defaults to false.No
    novalidationtrue if the XML deployment descriptors - must be parsed without validation. If omitted, it defaults to - false.No
    javacJava compiler to use. If omitted, it defaults to the - value of build.compiler property.No
    javacoptsOptions to pass to the java compiler.No
    protocolsComma-separated list of protocols (chosen within - jeremie, jrmp, iiop, cmi) for which stubs should be generated. - Default is jrmp,jeremie.No
    rmicoptsOptions to pass to the rmi compiler.No
    verboseIndicates whether or not to use -verbose switch. If - omitted, it defaults to false.No
    additionalargsAdd additional args to GenIC.No
    keepgenerictrue if the generic JAR file used as - input to GenIC must be retained. If omitted, it defaults to - false.No
    suffixString value appended to the JAR filename when creating each JAR. - If omitted, it defaults to ".jar".No
    nogenicIf this attribute is set to true, JOnAS's - GenIC will not be run on the EJB JAR. Use this if you prefer to run - GenIC at deployment time. If omitted, it defaults to - false.No
    jvmoptsAdditional args to pass to the GenIC JVM.No
    invokecmdIf this attribute is set to true, GenIC will - use the Javac sun class to avoid using 'javac' command line. This is - useful for users getting 'java.io.Exception CreateProcess' because of too - long command lines. Defaults to false.No
    - -

    As noted above, the jonas element supports additional <classpath> -nested elements.

    - -

    Examples

    - -

    -Note : To avoid java.lang.OutOfMemoryError, the element -jvmopts can be used to change the default memory usage. -

    - -

    This example shows ejbjar being used to generate deployment jars using a -JOnAS EJB container. This example requires the naming standard to be used for -the deployment descriptors. Using this format creates a EJB JAR file for each -variation of  '*-jar.xml' that is located in the deployment descriptor -directory. 

    -
          <ejbjar srcdir="${build.classes}"
-              descriptordir="${descriptor.dir}">
-        <jonas destdir="${deploymentjars.dir}"
-               jonasroot="${jonas.root}"
-               protocols="jrmp,iiop"/>
-        <include name="**/*.xml"/>
-        <exclude name="**/jonas-*.xml"/>
-        <support dir="${build.classes}">
-             <include name="**/*.class"/>
-        </support>
-      </ejbjar>
    - -

    This example shows ejbjar being used to generate a single deployment jar -using a JOnAS EJB container. This example does require the deployment -descriptors to use the naming standard. This creates only one ejb jar file - -'TheEJBJar.jar'.

    -
          <ejbjar srcdir="${build.classes}"
-              descriptordir="${descriptor.dir}"
-              basejarname="TheEJBJar">
-        <jonas destdir="${deploymentjars.dir}"
-               jonasroot="${jonas.root}"
-               suffix=".jar"
-               protocols="${genic.protocols}"/>
-        <include name="**/ejb-jar.xml"/>
-        <exclude name="**/jonas-ejb-jar.xml"/>
-      </ejbjar>
    - - -

    GenIC Ant Task

    - -

    Why is there a new task?

    - -

    Previous versions of the JOnAS EjbJar Ant task have some -limitations—especially when you are developing webservices.

    - -

    In previous versions of JOnAS, jonas-ejb-jar constructed the JAR for you, using -information gathered from the ejb-jar.xml and from the classes themselves -(dependencies using BCEL). -But if you have a Session Bean exposed as a webservice, -you want to have more files in your archive (webservices.xml, -JAX-RPC mapping file, WSDL + imported WSDL -definitions + imported XML Schema).

    - -

    The older task did not package these files inside the archive, and -therefore, when GenIC loaded the descriptors, some dependencies were -missing, causing GenIC to throw an exception.

    - -

    The solution is to let the developer create the JAR file, so that -the exact content of the file can be controlled.

    - -

    The file should have at least the following content: -

    - -
      -
    • META-INF/ejb-jar.xml
      • -
    • META-INF/jonas-ejb-jar.xml
      • -
    • **/*.class
      • - -
    - -

    Notice that webservices files are optional. -

    - -

    Task Attributes

    - -

    The genic task supports most attributes of the -jonas-ejb-jar task.

    - -

    Differences:

    -
      -
    • Removed destdir: JAR files are directly modified
      • -
    • Removed classpath: classpath is now set as inner element
      • -
    • Removed novalidation: validation attribute is used now
      • -
    • Removed keepgeneric: not meaningful (input JAR is already specific)
      • - -
    • Removed suffix: not meaningful (no JAR generated)
      • -
    • Removed nogenic: not meaningful (we want to run GenIC)
      • -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    AttributeDescriptionRequired
    jonasrootThe root directory for JOnAS.Yes (Can be read from ${jonas.root} property if not set)
    jonasbaseThe base directory for JOnAS. If omitted, it defaults - to jonasroot.No
    keepgeneratedtrue if the intermediate Java source - files generated by GenIC must not be deleted. If omitted, it defaults - to false.No
    nofastrmicif true, the external RMIC compiler is used - by GenIC. The default is false, which means the internal - fast RMIC compiler is used.No
    nocompiltrue if the generated source files must - not be compiled via the Java and RMI compilers. If omitted, it - defaults to false.No
    validationtrue if the XML deployment descriptors - must be parsed with validation. If omitted, it defaults to - true.No
    javacJava compiler to use. If omitted, it defaults to the - value of build.compiler property.No
    javacoptsOptions to pass to the Java compiler.No
    protocolsComma-separated list of protocols (chosen from - jeremie, jrmp, iiop, cmi) for which stubs should be generated. - Default is jrmp,jeremie.No
    rmicoptsOptions to pass to the RMI compiler.No
    verboseIndicates whether or not to use -verbose switch. If - omitted, it defaults to false.No
    additionalargsAdd additional arguments to GenIC.No
    jvmoptsAdditional arguments to pass to the GenIC JVM.No
    jvmdebugIndicates whether you want to debug the forked JVM; it - defaults to false. The JVM will be suspended and waiting - a connection on port 12345.No
    invokecmdIf this attribute is set to true, GenIC will - use the Javac sun class to avoid using 'javac' command line. This is - useful for users getting 'java.io.Exception CreateProcess' because of too - long command lines. Defaults to false.No
    - -

    - - - - - - - - - - - - - - - - - - - - -
    Nested ElementDescriptionRequired
    classpathThe additional classpath entries used when generating EJB stubs and - skeletons.No
    filesetPoints out the ejb-jars that will be processed by GenIC. - Note that you can add as many filesets as you want (useful if - your JARs are in different directories).Yes (at least 1)
    - -

    Example:

    - -
      -
    1. First, define this new task: -
      <taskdef name="genic"
-    classname="org.objectweb.jonas.ant.GenICTask"
-    classpath="${jonas.root}/lib/common/ow_jonas_ant.jar" />
-
      -
      2. - -
    2. Then use it: - -
        -
      1. Create the JAR file : -
        -<jar destfile="${temp.ejbjars.dir}/my-ejbjar.jar">
-    <metainf dir="${etc.dir}/META-INF" />
-
-    <fileset dir="${classes.dir}">
-        <include name="org/objectweb/jonas/myejbjar/*.class" />
-    </fileset>
-</jar>
-
        -
        2. - -
      2. Process this JAR with the GenIC task : -
        -<genic keepgenerated="true"
-       protocols="${protocols.names}">
-
-    <fileset dir="${temp.dir}">
-        <include name="ejbjars/my-ejbjar.jar" />
-    </fileset>
-</genic>
-
        -
        3. - -
      - -
      3. -
    - - diff --git a/jonas_doc/olddoc/clusterd.html b/jonas_doc/olddoc/clusterd.html deleted file mode 100644 index 030e0074310760357d10e8303eeffc6f6a0dfedf..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/clusterd.html +++ /dev/null @@ -1,319 +0,0 @@ - - - - - - - Cluster daemon - - - - -

    Cluster Daemon

    - -

    Introduction

    - -

    The intent of the cluster daemon is to enable the remote control of the JOnAS clustered -instances through a JMX interface.

    - -

    In a cluster configuration, the cluster daemon is the bootstrap of the JOnAS instances.

    - -

    There is at least one cluster daemon instance per machine.

    - -

    Cluster daemon

    - -

    Configuration

    - -

    In the same manner as a classic JOnAS instance, the cluster daemon reads its configuration -in a directory pointed to by a JONAS_BASE variable (or JONAS_ROOT if JONAS_BASE is not set). -All the default JONAS_BASE subdirectories and files are not required; the mandatory ones are:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    elementdescription
    $JONAS_BASE/confConfiguration directory
    $JONAS_BASE/logsLog directory
    $JONAS_BASE/conf/carol.propertiesCarol configuration file describing the protocol and its parameters (used for the JMX interface)
    $JONAS_BASE/conf/trace.propertiesTrace/Error log configuration file
    $JONAS_BASE/conf/jonas.propertiesThis file must be present for enabling the cluster daemon starting but - its content is not read, the file can be empty -
    $JONAS_BASE/conf/clusterd.xmlCluster daemon configuration file, lists the local JOnAS instances and describes - their environment (see below)
    - -

    clusterd.xml

    - -

    The JOnAS instances controlled by a cluster daemon are configured in the clusterd.xml file.

    - -
    -
-<?xml version="1.0"?>
-<cluster-daemon xmlns="http://www.objectweb.org/jonas/ns"
-	  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-	  xsi:schemaLocation="http://www.objectweb.org/jonas/ns
-	  http://www.objectweb.org/jonas/ns/jonas-clusterd_4_8.xsd">
-
-   <name>cd1</name>
-   <domain-name>domainSample</domain-name>
-   <jonas-interaction-mode>loosely-coupled</jonas-interaction-mode>
-
-   <server>
-      <name>node1</name>
-      <description>Web instance</description>
-      <java-home>/usr/java/jdk-ia32/sun/j2sdk1.4.2_10</java-home>
-      <jonas-root>/home/pelletib/pkg/jonas_root_sb48</jonas-root>
-      <jonas-base>/home/pelletib/tmp/newjc48/jb1</jonas-base>
-      <xprm></xprm>
-      <auto-boot>false</auto-boot>
-      <jonas-cmd></jonas-cmd>
-   </server>
-
-...
-
-</cluster-daemon>
-
-
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    elementdescription
    nameCluster daemon instance name. Used for building the connector url.
    domain-nameDomain name to use for launching the JOnAS instance when it is not specified in the start command
    jonas-interaction-modeStarting mode of the JOnAS instances: loosely-coupled corresponds to background and tighly-coupled - corresponds to foreground
    server/nameName of the JOnAS instance
    server/descriptionDescription of the JOnAS instance
    server/java-homeJDK home directory to use for launching the JOnAS instance
    server/jonas-rootJOnAS binaries directory to use for launching the JOnAS instance
    server/jonas-baseJOnAS configuration directory to use for launching the JOnAS instance
    server/xprmsJVM parameters to set when launching the JOnAS instance
    server/auto-bootIf true, start the JOnAS instance when launching the cluster daemon
    server/jonas-cmdOptional parameter. If set, specifies the script to use for starting/stopping the JOnAS instance. This user script can set the required environnement and perform some pre or post processing. By default, the jonas command is used.
    - -

    domain.xml

    - -

    The cluster daemons must be specified and associated to the JOnAS instances in the domain.xml file -for permitting the remote control of the cluster.

    - -
    -...
-<cluster-daemon>
-   <name>cd1</name>
-   <description>cluster daemon 1</description>
-   <location>
-      <url>service:jmx:rmi://host/jndi/rmi://host:port/jrmpconnector_cd</url>
-   </location>
-</cluster-daemon>
-...
-<server>
-  <name>node1</name>
-  <cluster-daemon>cd1</cluster-daemon>
-  ...
-</server>
-...
-
    - -

    The JMX remote url of the cluster daemon adheres to the following syntax:

    -

    service:jmx:rmi://host/jndi/rmi://host:port/protocolconnector_name - with the following meanings:

    -
      -
    • host: ip alias or ip address of the machine that hosts the cluster daemon - (by default localhost, can be overridden through the carol.properties file) -
      • -
    • port: tcp listen port of the registry embedded in the cluster daemon - (by default 1806, can be overridden through the carol.properties file) -
      • -
    • protocol: protocol used for accessing the JMX interface (by default irmi, can be overridden - through the carol.properties file)
      • -
    • name: cluster daemon instance name (defined in the clusterd.xml file)
      • -
    - -

    Running the Cluster Daemon

    - -

    The cluster daemon is started using the command jclusterd. The possible options are:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    optiondescription
    startStart the cluster daemon. -
    stopStop the cluster daemon. -
    -DdomainNameDomain name to use for starting the JOnAS instance. This value is used when it is defined both here and in the clusterd.xml file. -
    -carolFile <my-carol.properties>Path to the carol.properties file to use. If not specified, the file is loaded from $JONAS_BASE/conf. - If the file is not found, the default values (localhost, 1806, irmi) are used.
    -confFile <my-clusterd.xml>Path to the clusterd.xml file to load. If not specified, the file is loaded from $JONAS_BASE/conf.
    - -

    JMX Interface

    - -

    The cluster daemon provides a JMX interface that enables control of the JOnAS instances. The following operations are -available:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    OperationDescription
    String getServersList()Return the list of JOnAS instances
    int pingJOnAS(String name)Ping a JOnAS instance identified by its name
    void startJOnAS(String name)Start a JOnAS instance identified by its name
    String startAllJOnAS(String domainName, String prm)Start all the JOnAS instances known in the cluster daemon configuration. - The parameter domainName (optional) enables the ability to specifiy the domain name. - The parameter prm (optional) enables the ability to set some JVM parameters. -
    void stopJOnAS(String name)Stop a JOnAS instance identified by its name
    String stopAllJOnAS()Stop all the JOnAS instances known in the cluster daemon configuration
    String getJavaHome4Server(String name)Get the JAVA_HOME defined for a JOnAS server
    String getJonasRoot4Server(String name)Get the JONAS_ROOT defined for a JOnAS server
    String getJonasBase4Server(String name)Get the JONAS_BASE defined for a JOnAS server
    void reloadConfiguration()Reload the configuration file of the cluster daemon
    void addServer(String name, String description, String javaHome, String jonasRoot, String jonasBase)Add a definition of a JOnAS instance to the cluster daemon configuration. The change is saved in the - configuration file.
    void removeServer(String name)Remove a definition of a JOnAS instance in the cluster daemon configuration. The change is saved in the - configuration file.
    void modifyServer(String name, String description, String javaHome, String jonasRoot, String jonasBase)Modify the definition of a JOnAS instance in the cluster daemon configuration. The change is saved in the - configuration file.
    - - - - diff --git a/jonas_doc/olddoc/clustering.html b/jonas_doc/olddoc/clustering.html deleted file mode 100644 index 997e876d50e6bd9609b051ba6cb807878ed4f414..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/clustering.html +++ /dev/null @@ -1,53 +0,0 @@ - - - - - - - Clustering guide - - - - -

    Clustering Guide

    - -

    Introduction

    - -

    JOnAS provides a full solution for clustering that ensures high availability and -scalability of J2EE applications.

    -
      -
    • At the web level through -
        -
      • Apache/mod_jk for equilibrating the HTTP flow between multiple - JOnAS/Tomcat instances
        • -
      • Tomcat for providing a TCP-based solution and replicating the HTTP - session, thus ensuring their high availability
        • -
      -
      • -
    • At the JNDI level through CMI and its replicated registry
      • -
    • At the EJB level (RMI requests) through CMI and its cluster stub
      • -
    • At the JMS level through JORAM server and JORAM HA
      • -
    • At the JDBC level through C_JDBC/Sequoia
      • -
    - -

    The Howto document JOnAS clustering -is a guide for configuring the clustering features of JOnAS.

    - -

    Cluster management is described in Domain and Cluster Management in -JOnAS chapter.

    - -

    Clustering : end to end solution

    - - diff --git a/jonas_doc/olddoc/common.css b/jonas_doc/olddoc/common.css deleted file mode 100644 index 6cf7e7d67212c268d7a64ef3ddc821883a08c2f4..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/common.css +++ /dev/null @@ -1,228 +0,0 @@ -/* - JOnAS css. based on http://jonas.objectweb.org/common.css - Use a local css as it is distributed with JOnAS binary packages. -*/ - -body -{ - background-color: #FFFFFF; - margin: 10px; - color: black; - font-family: Arial,Helvetica, sans-serif; - font-size: 12px; - line-height: 16px; - font-weight: normal; -} - -/*HTML elements */ - - -select, input { font-size: 10px; } - -form -{ - padding: 0px 0px 0px 0px; - margin: 0px 0px 3px 0px; -} - -.contenu { padding: 0px 30px 0px 0px; } - - -h1 -{ - color: #E06611; - font-family: Arial, Helvetica, sans-serif; - font-size: 22px; - line-height: 27px; - font-weight: bold; - border-color: #99C; - border-width: 0 0 4px 0; - border-style: none none solid none; - margin: 10px 0px 5px 0px; -} - -h2 -{ - color: #99C; - font-family: Arial, Helvetica, sans-serif; - font-size: 20px; - line-height: 27px; - font-weight: normal; - border-color: #E06611; - border-width: 0 0 4px 0; - border-style: none none solid none; - margin: 10px 0px 5px 0px; - -} - -h3 -{ - color: #E06611; - font-family: Arial, Helvetica, sans-serif; - font-size: 16px; - line-height: 27px; - font-weight: bold; - border-color: #E8EAF0; - border-width: 0 0 2px 0; - border-style: none none solid none; - margin: 10px 0px 5px 0px; - -} -h4 -{ - color: #99C; - font-family: Arial, Helvetica, sans-serif; - font-size: 16px; - line-height: 24px; - font-weight: normal; - border-color: #E8EAF0; - border-width: 0 0 2px 0; - border-style: none none solid none; - margin: 10px 0px 5px 0px; - -} -h5 -{ - color: #E06611; - font-family: Arial, Helvetica, sans-serif; - font-size: 14px; - line-height: 24px; - font-weight: normal; - border-color: #E8EAF0; - border-width: 0 0 2px 0; - border-style: none none solid none; - margin: 10px 0px 5px 0px; - -} -h6 -{ - color: #99C; - font-family: Arial, Helvetica, sans-serif; - font-size: 14px; - line-height: 22px; - font-weight: normal; - border-color: #E8EAF0; - border-width: 0 0 2px 0; - border-style: none none solid none; - margin: 10px 0px 5px 0px; - -} - -td -{ - color: black; - font-family: Arial,Helvetica, sans-serif; - font-size: 12px; - font-weight: normal; -} - -p -{ - color: black; - font-family: Arial,Helvetica, sans-serif; - font-size: 12px; - line-height: 16px; - font-weight: normal; - margin: 10px 10px 5px 0px; -} - -p.error -{ - color: red; -} - - -a -{ - color: #3F3975; - background-color: transparent; - text-decoration: underline; -} - -a:visited -{ - color: #9898CB; - background-color: transparent; - text-decoration: underline; -} - -a:hover -{ - color: #E06611; - background-color: transparent; - text-decoration: underline; -} - - -a:active -{ - color: #FFFFFF; - background-color: #E06611; - text-decoration: underline; -} - -blockquote -{ - color: black; - font-family: Arial,Helvetica, sans-serif; - font-size: 11px; - line-height: 15px; - font-weight: normal; - margin: 20px 0px 5px 0px; -} - - -ul, ol, dl -{ - color: black; - font-family: Arial,Helvetica, sans-serif; - font-size: 12px; - line-height: 16px; - font-weight: normal; -} -dt -{ - color: black; - font-family: Arial,Helvetica, sans-serif; - font-size: 12px; - line-height: 16px; - font-weight: bold; -} -dd -{ - color: black; - font-family: Arial,Helvetica, sans-serif; - font-size: 11px; - line-height: 16px; - font-weight: normal; - margin: 0px 0px 0px 20px -} -address -{ - color: black; - font-family: Arial, Helvetica, sans-serif; - font-style: normal; - font-size: 10px; - line-height: 16px; - border-width: 4px 0 0 0; - border-style: solid none none none; - border-color: #E06611; - margin: 30px 0px 20px 0px; - padding: 10px 0px 0px 0px; - -} -code, pre -{ - color: #433C7B; -} - -th -{ - font-family: Arial,Helvetica, sans-serif; - font-size: 14px; - line-height: 15px; - color: #433C7B; - font-weight: bold; - background-color: #E8EAF0; - padding: 2px; -} diff --git a/jonas_doc/olddoc/howto/Clustering.html b/jonas_doc/olddoc/howto/Clustering.html deleted file mode 100644 index 94047cc8d1cf6820dd0cf93504147d3f09a12a11..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/Clustering.html +++ /dev/null @@ -1,929 +0,0 @@ - - - - - - -Clustering with JOnAS - - - - -
    -

    Howto: Clustering with JOnAS

    -


    -Authors : Georges Goebel, Marc Calvisi, Rod Schultz, Jerome Pioux, Benoit Pelletier
    -October 16, 2006
    -Version : 3.2
    -

    -

     

    -

    Introduction

    -

    Architecture

    -

            -Used symbols 

    -

            -Load balancing at web level with -mod_jk

    -

            -Session Replication at web level

    -

            -Load Balancing at EJB level

    -

            -Session Replication at EJB level

    -

            -Clustering databases with -C-JDBC

    -

    SampleCluster2 Practical Example

    -

            -Products Installation

    -

                    -Installing Java, Ant and JOnAS / Tomcat

    -

                    -Installing Apache

    -

                   -Installing the JK Module

    -

            -Configuring the network

    -

            -Configuring the Cluster

    -

                    -Configuring the JOnAS nodes

    -

                    -Configure the WebApp

    -

                    -Database Concurrent Access

    -

            -SampleCluster2 Deployment

    -

                    -Directory Structure

    -

                    -Compiling sampleCluster2

    -

            -Running sampleCluster2

    -

                    -Description of the sampleCluster2 Web -Interface

    -

    References

    -

     

    -

     

    -
    -

    Introduction

    -

     

    -

    This guide describes how to configure Apache, Tomcat, and JOnAS -to install a cluster.

    -

    Clustering with JOnAS uses the following:

    -
      -
    • the Apache/Tomcat plug-in mod_jk. This -plug-in allows use of the Apache HTTP server in front of one or -several Tomcat JSP/Servlet engines, and provides the capability of -forwarding some of the HTTP requests (typically those concerning -the dynamic pages, i.e., JSP and Servlet requests) to Tomcat -instances.
      -
      -
      • -
    • the In-Memory-Session-Replication technique based -on the TCP based group communication protocol to provide failover -at servlet/JSP level.
      -
      -
      • -
    • the CMI protocol to support load balancing at EJB -level for stateless beans and replications for stateful session -beans.
      • -
    -

    This document describes one architecture with all the clustering -functionalities available in JOnAS, the configuration of -architectures integrating one of those functionalities, and other -possible configurations.

    -

    For hands-on practice, this document uses the sampleCluster2 -JOnAS example.

    -

     

    -
    -

    Architecture

    -

    The architecture shown in the following illustration provides -all the clustering functionality available in JOnAS: 1) Apache as the -front-end HTTP server, 2) JOnAS/Tomcat as the J2EE Container, and 3) a shared database.

    -

    This architecture provides:

    -
      -
    • Load balancing: Requests can be dispatched over a set of -servers to distribute the load. This improves the "scalability" by -allowing more requests to be processed concurrently.
      -
      -
      • -
    • High Availability (HA): Having several servers able to -fulfill a request makes it possible to ensure that, if a server -dies, the request can be sent to an available server (thus the -load-balancing algorithm ensures that the server to which the -request will be sent is available). Therefore, "Service -Availability" is achieved.
      -
      -
      • -
    • Failover: This feature ensures that, at the web level (JSP/Servlet), if one server goes - down another server is able to -transparently take over.  Similarly, at the EJB level, if one server -goes down another transparently takes over.  That is, requests will be -switched to another server without service disruption, thus achieving - Continuity.
    -

    - At the Servlet / JSP level, the mod_jk plug-in -provides Load Balancing / High Availability and the -Tomcat-Replication module provides Failover.
    - At the EJB level, the CMI protocol and JNDI replication provides Load Balancing / High Availability.  -Replication of Stateful EJBs provides failover.
    - The database is shared by the JOnAS servers.

    -

    The sampleCluster2 application, presented later in this document, can be deployed on such an architecture.

    -

    -"architecture"

    -
    -

    Used - symbols

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    -

    node

    		 -

    A node (computer) that hosts one or more servers 

    		 -

     

    		 -

     

    -

    WebCont

    		 -

    A web container

    		 -

    EJBCont

    		 -

    An ejb container

    -

    JOnASWeb

    		 -

    A JOnAS instance that hosts a web container

    		 -

    JOnASEJB

    		 -

    A JOnAS instance that hosts an ejb container

    -

    FullJOnAS

    		 -

    A JOnAS instance that hosts a web container and an ejb -container

    		 -

     

    		 -

     

    -

    Apache

    		 -

    An Apache server with the mod_jk module

    		 -

     

    		 -

     

    -

     

    -

     

    -
    - 

    Load - balancing at web level with mod_jk

    -

    The following illustration describes how Apache, mod_jk, and -JOnAS/Tomcat Containers interact:

    -

    archi1

    -

    This example uses mod_jk, but an alternative configuration -using Enhydra Director -is also possible. (see -config)

    -

    Mod_jk is a plug-in (module) that handles the communication and -load balancing between Apache and Tomcat.

    -

    Mod_jk uses the concept of worker.  A worker is a Tomcat instance -that is running to perform servlet requests coming from the web -server.  Each worker is identified to the web server by the host on -which it is located, the port where it listens, and the -communication protocol that is used to exchange messages.

    -

    AJP13 is the preferred TCP/IP sockets protocol that mod_jk uses -for communicating between the web server and Tomcat workers.

    -

    In this configuration there is one worker for each Tomcat -instance and one worker (this -is a specific worker with no host and no port number) that will handle the load balancing.  -All workers -are defined in a file called worker.properties.

    -

    Note: this module can also be used for site partitioning.

    -

     

    -
    -

    Session - Replication at web level

    -

    The following illustration shows that the HTTP session replication -feature has been added to the architecture:

    -

    archi2

    -

    The term "session replication" is used when the current service -state is being replicated across multiple application instances.  Session replication occurs when the information stored in an -HttpSession is replicated from, in this example, one servlet engine -instance to another.  This could be almost any type of data, such as items contained in -a shopping cart or information being entered on an insurance -application.  Anything being stored in the session must be -replicated for the service to failover without a disruption.

    -

    The solution chosen for achieving Session replication is called -all-to-all replication.  Tomcat uses a proprietary protocol based on -TCP for the all-to-all replication.

    -

     

    -
    -

    Load - Balancing at EJB level

    -

    The following illustration shows that load balancing at EJB -level is now included in the architecture:

    -

    archi3

    -

    CMI is a new ORB used by JOnAS to provide clustering for load -balancing and high availability.  It provides replication of the -JNDI registries among all EJB containers.  Several instances of -JOnAS can be started together in a cluster to share their EJBs.  It -is possible to start the same EJB on each JOnAS, or to distribute -their load.  A URL referencing several JOnAS instances can be -provided to the clients.  At lookup time, a client randomly chooses -one of the available servers to request the required bean.  Each -JOnAS instance has the knowledge (through JGroups) of the -distribution of the Beans in the cluster.  An answer to a lookup is -a special clustered stub, containing stubs to each instance known -in the cluster.  Each method call on the Home (or Remote for the SSB) -of the bean can be issued by the stub to a new instance in order to balance the load on the -cluster.  The default algorithm used for load distribution is -currently a weighted round robin with local preference.

    - -

    Session Replication at EJB level

    -

    The following illustration shows that the EJB session replication -feature has been added to the architecture:

    -

    archi3

    -

    The term "session replication" is used when the current service -state is being replicated across multiple application instances.  -Session replication occurs when the information stored in an SFSB state -is replicated from, in this example, one EJB container -instance to another.  This could be almost any type of data (that is serializable), -such as items contained in -a shopping cart or information being entered on an insurance -application.  Anything being stored in the session must be -replicated for the service to failover without a disruption.

    -

    The solution chosen for achieving Session replication is based on a horizontal -approach implemented both through CMI and the JOnAS's ha service. -See here for more detailed information

    -
    -

    Clustering - databases with C-JDBC

    -

    With C-JDBC it is possible to cluster databases. Refer to - -HowTo setup a C-JDBC Database.

    -

     

    -
    -

    SampleCluster2 Practical Example

    -

    sampleCluster2 is an application that demonstrates the clustering features. -A jsp/servlet follows the requests movements across the cluster. -As shown in the illustration below, it can be deployed over four -JOnAS instances.  Two -have WEB containers and the other two have EJB containers.

    -

    archi5

    -

    The application is composed of three EJBs: a stateful session bean, a stateless -session bean, and an entity bean.  These EJBs are instantiated by the web interface.  -When the user connects to the web interface for the first time, an HTTP session is created.  -During this process a -stateful session bean is created in one of the JOnAS nodes where -the EJB container is started.  The handle of this stateful session -bean is added to the HTTP session (see note).  Next, the web -interface creates a new instance of the stateless session bean.  The -first time, no entity bean is created.  The useful information from -the stateless session bean (JOnAS node name, number of instances) -is set in the stateful session bean.

    -

    The user can see the result in the web interface where all the -necessary information is displayed.  The user should now execute the -same servlet several times in order to see the changes made by the -cluster.  Each time the servlet is executed, it may be -executed on a different node (JOnAS with web container).

    -

    The servlet gets a reference to the stateful session bean -(through the handle). After that, a new stateless session bean is -created and its information is passed to the stateful session bean.  On -every tenth instantiation of the stateless session bean, an entity bean is created.

    -

    However,  the stateless session bean may be instantiated in a -different EJB container than the stateful session bean.  This -sample uses local interfaces between the stateless session bean -and the entity bean.  As a result, the entity bean is created in the -same EJB container as the stateless session bean.

    -

    The entity bean writes the time and the name of the node in the -database.

    -

    Note:   The handle enables getting a reference to the stateful session bean -when the JVM has changed.

    -

    See also description of the -SampleCluster2 Web interface for a description of using sampleCluster2 to -demonstrate cluster features.

    -

     

    -
    -

    Product Installation

    -

    This section provides information about installing JOnAS /Tomcat, Apache, mod_jk.

    -

    The versions assumed here are: JOnAS 4.8.x /Tomcat 5.5.x, Apache -2.2.x, and mod_jk 1.2.15 (or later).

    -
      -
    1. Logon as any user <user> on the host <hostname> -that will run the cluster.
      - Note that you do not need to be ‘root’ to -perform any of these steps or to run the cluster.
      -
      -
      2. -
    2. Enter  mkdir cluster
      - to make a directory in which the -supporting software (apache…) will be installed and the cluster will be - deployed (in the next section also).
      -
      -
      3. -
    3. Enter  cd cluster
      - to change directory to cluster.
      4. -
    -
    -

    Installing Java, Ant, and JOnAS / - Tomcat

    -

    Perform steps one through three in -Installing JOnAS with a web container from scratch.

    -

    Linux Notes:

    -
      -
    • For the sampleCluster2, JONAS_ROOT=$HOME/cluster/JONAS_4_8_3 (or later) is assumed.
      -
      -
      • -
    • A JOnAS instance, also called a worker for mod_jk, is -JONAS_ROOT and a JONAS_BASE.
      -
      -
      • -
    • Even though there are four JOnAS instances (four JONAS_BASE), only -one installation of JOnAS (one JONAS_ROOT) is needed.
      -
      -
      • -
    • It is recommended that the environment variables set in the -<user>’s .bash_profile (.profile on AIX) file be added.
    -

    export JAVA_HOME=<location where java was installed>

    -

    export ANT_HOME=<location where ant was installed>

    -

    export JONAS_ROOT=$HOME/cluster/JONAS_4_8_3

    -

    export PATH=$PATH:$JAVA_HOME/bin:$ANT_HOME/bin

    -

    Windows Notes:

    -
      -
    • For the sampleCluster2,  JONAS_ROOT=c:\cluster\JONAS_4_8_3 (or later) is assumed.
      -
      -
      • -
    • A JOnAS instance, also called a worker for mod_jk, is -JONAS_ROOT and a JONAS_BASE.
      -
      -
      • -
    • Even though there are four JOnAS instances (four JONAS_BASE) only -one installation of JOnAS (one JONAS_ROOT) is needed.
      -
      -
      • -
    • It is recommended that the environment variables set in -the user environment variables
      - My Computer | Properties | Advanced | Environment Variables be added.
    -

    JAVA_HOME   <location where java was -installed>

    -

    ANT_HOME       <location where ant was -installed>

    -

    -JONAS_ROOT                   -c:\cluster\JONAS_4_8_3

    -

    Add to PATH   ;$JAVA_HOME/bin;$ANT_HOME/bin

    -

     

    -

    Installing Apache

    -
    -

    -Install Apache HTTP server  from -source on linux
    -

    For this sample, Apache will run as <user> (rather than -'root').
    -Below, <prefix> refers to the install folder for Apache.
    -This sample uses prefix = $APACHE_HOME= -$HOME/cluster/apache2.

    -
      -
    1. Download under cluster, the Apache server tarball source code -from the Apache -site.
      -Extract the source code.
      - tar xvfz httpd-2_0_XX.tar.gz
      -
      -
      2. -
    2. Choose an available listen -port above 1024 (since this is not being run as ‘root’).
      - This sample uses 8080. To verify that it is unused, use the following command.
      - -netstat -an | grep 8080
      -
      -
      3. -
    3. Configure, compile, and install.
      - -cd $HOME/cluster/httpd-2.2.0
      -./configure -–-prefix=$HOME/cluster/apache2 --with-port=8080
      - -make
      -make install       - -
      -       -
      Note: The $HOME/cluster/apache2/conf/httpd.conf file may need to be edited to change the "User" and "Group" lines to match the desired user and group.

      4. -
      Note: A binary version is also available at the Apache -site. -
    -

    Run and Stop Apache HTTP server to verify the installation.

    -
      -
    1. Run Apache HTTP server.
      - -<prefix>/bin/apachectl start
      -
      -
      2. -
    2. Verify at least one httpd process is running.
      -ps -ef | grep httpd
      -
      -
      3. -
    3. Verify that there is a listener.
      - -netstat -an | grep 8080
      -
      -
      4. -
    4. Use a web browser to connect to -http://<hostname>:8080
      -Check that apache returns the string ‘It -Works!’
      -
      -
      5. -
    5. Stop Apache HTTP server for now – it will be restarted -later after the JOnAS instances have been started.
      - -<prefix>/bin/apachectl stop
      6. -
    -

    Notes:

    -
      -
    • The following environment variables are not required but are convenient. They are used in sampleCluster2.
      - -export APACHE_HOME=$HOME/cluster/apache2
      - export PATH=$PATH:$APACHE_HOME/bin
      -
      -
      • -
    • It is also recommended that the <user>’s -.bash_profile (.profile on AIX) file be updated with the lines -above.
    -
    -
    Installing the Apache Server on -Windows
    -<prefix> is the install folder for Apache.  By default, it -is C:\Program Files\Apache Group. -
      -
    1. Download the Apache HTTP installer from the Apache site.
      -       The current version is apache_2.0.55-win32-x86-no_ssl.msi.
      -
      -
      2. -
    2. Choose a Listen port, for example, 8080
      -
      -
      3. -
    3. Enter  netstat -an  to verify it is unused. 
      - If either -port 80 or 8080 is not available, the -<prefix>\Apache2\conf\http.conf file must be edited after -installation. 
      - Edit the line 'Listen 8080'.
      -
      -
      4. -
    4. Install by running the installer.
      - The installer creates an 'Apache HTTP Server' group in the Start -Menu.
      5. -
    -

    Run and Stop Apache HTTP server:

    -
      -
    1. Select  StartMenu -> Programs -> -Apache HTTP Server -> Control Apache Server --- Start Apache Server in Console.
      -
      -
      2. -
    2. Open 'Task Manager', select 'Applications', verify 'Start -Apache in Console' is running.
      -
      -
      3. -
    3. Enter netstat -an  to verify that there is a - listener.
      -
      -
      4. -
    4. Stop Apache HTTP server.
      -
      -
      5. -
    5. - Click on exit button on the windows title bar.
      -
      -
      6. -
    -

    For further information about installing Apache HTTP server -please refer to the Apache -Site.

    -

     

    -
    -

    Installing - the JK Module

    -

    Mod_jk will be installed in the same <user> account as -Apache.

    -
    -
    Install mod_jk connector from source -on linux
    -
      -
    1. Download under cluster, the mod_jk tarball source code from the -Tomcat Site. - 
      -Extract the source code.
      - -tar xvfz jakarta-tomcat-connectors-1-2-15-src.tar.gz
      -
      -
      2. -
    2. Configure, compile and install.
      - -cd $HOME/cluster/jakarta-tomcat-connectors-1.2.15-src/native
      -./configure –-prefix=$APACHE_HOME --with-apxs=$APACHE_HOME/bin/apxs
      -make - -
      -       -make install -
      3. -
    -

    A mod_jk.so file should now have been created under $APACHE_HOME/modules.
    -The process for making apache aware of this new file will be performed in the -next chapter.
    -
    -Note: For some distributions, a binary version may be -available at the Tomcat  site.

    -

    For further installation information, refer to the -Tomcat -Site.

    -
    Install mod_jk connector on Windows
    -
      -
    1. Download the mod_jk connector.
      -
      - - Connect to the following url in a browser
      -      -http://tomcat.apache.org/download-connectors.cgi
      - - - Select the browse download area link. This will take you to a -mirror site.
      - - Select jk
      - - Select binaries
      - - Select win32
      - - Select  jk-1.2.15
      - - Select mod_jk-apache-2.0.55.so to start the download.
      -
      -
    2. Copy the downloaded file to <prefix>/apache2/modules.
      -
      -
      3. -
    3. Rename the file mod_jk.so.
      4. -
    -  -

    For further - installation information, refer to the Tomcat - Site.

    -

     

    -
    -

    Configuring the network

    -
    -

    -The localhost must be mapped to a non lookback IP by editing the hosts file: either /etc/hosts in a linux system or c:/Windows/system32/etc/hosts for -the Windows OS. -

    -
    - -

    Configuring the Cluster

    - -

    Configuring the JOnAS nodes

    - -
    The cluster configurations can be built either manually or automatically by the newjc tool provided with JOnAS. Note that this tool -is tailored for quickly generating a cluster configuration collocated to a single machine. If the cluster is spanned over several machines, either -the configuration can be manually created from scratch or it can be generated by newjc. Then it must be modified to take into account -the distributed aspects. Both methods are described below.
    - - - -

    Configure the WebApp

    -

    Note: A WebApp deployed into a Cluster must have a -special distributable element set in its WEB-INF/web.xml.
    -The following is an example of a web.xml deployment descriptor: -

    -

    <web-app . . .>
    -  . . .
    -  <distributable />
    -  . . .
    -</web-app>

    -

    Please carefully read the - -Tomcat Clustering Guide for additional information.

    - -

    Database - Concurrent Access

    -

    Note: For sampleCluster2, in the JOnAS-specific deployment -descriptor, tag shared is set to true for the entity beans involved.  When this flag is set to true, multiple instances of the same -entity bean in different JOnAS servers can access a common database -concurrently.

    -

    The following is an example of a deployment descriptor generated by newjc with the -flag shared set to true. Deployment descriptors are in jonas_ejb_jar.xml in the ejbs.jar file in sampleCluster2.ear.

    -

    <jonas-ejb-jar>
    -  <jonas-entity>
    -           . -. .

    -

        -<shared>true</shared>
    -           . -. .

    -

      </jonas-entity>
    -</jonas-ejb-jar>

    -

     

    -
    -

    SampleCluster2 Deployment

    -
    -

    Directory - Structure:

    -

    sampleCluster2 is located under -$JONAS_ROOT/examples/sampleCluster2.

    -

    /lib     libraries needed by the aplication -to run

    -

    /output  generated ear, jar, war files

    -

    /src         source code

    -
    -

    Compiling sampleCluster2:

    -
      -
    1. Logon as user <user>.
      -Make sure this user has the Java, Ant, and JOnAS environment set -(from the above installation).
      -
      -
      2. -
    2. cd $JONAS_ROOT/examples/sampleCluster2
      -       -
      -
      3. -
    3. export JONAS_BASE=$HOME/cluster/jb1
      -to set JONAS_BASE for the first instance.
      - -
      -       -
      4. -
    4. ant install
      -
      -As a result, the application file sampleCluster2.ear is copied to -the $JONAS_BASE/apps/autoload directory for the first instance.
      -Since the ear is copied to the autoload directory, deployment will -be automatic at JOnAS startup.
      -
      -
      5. -
    5. Repeat steps 3 and 4 for the three remaining -instances (steps will be shorter as the compile has been done in step 1).
      6. -
    -

    Note: sampleCluster2 contains both a war file for the web -application and a jar file for the EJB.  JOnAS will only deploy the -war file to instances with a web container.  Similarly, it will only -deploy the jar file on instances with an EJB container.

    -

     

    -
    -

    Running sampleCluster2

    -
      -
    1. Logon as user <user>.
      -
      -
      2. -
    2. cd $JONAS_ROOT/examples/sampleCluster2
      -
      -
      3. -
    3. Start all four JOnAS instances:
      - -./jcl4sc2 (jcl4sc2.bat for a Windows environment)
      -
      - -This script executes
      -jonas start –n nodeX, for X=1,2,3,4.
      - -
      -
      4. -
    4. Restart Apache: <prefix>/bin/apachectl -restart.
      -
      -
      5. -
    5. In a browser go to http://hostname:<apache listening -port>/sampleCluster2
      6. -
    -
    -

    Description of the sampleCluster2 Web - Interface

    - -

    The following graphic shows an example "SessionServlet Output" page.

    -     -

     

    -

    --"sampleCluster2"

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

     

    - -

    The following is an explanation of the information shown in the "SessionServlet -Output" page above. 

    -

    Home of sampleCluster2

    -
      -
    • Open a -session:  creates a new session
      -
      • -
    • Release -a session:  invalidates the http session and if a cookie is -present, it will be made obsolete
      -
      • -
    • Check a -session:  checks to see if a session is valid
      • -
    -

    After click on open session link

    -
      -
    • getRequestURL:  -indicates the number of requests for the indicated URL
      -
      • -
    • from -<Client_IP>: Client requesting the page
      -
      • -
    • to -<JOnAS_IP>:  JOnAS web-container that has executed the servlet
      -
      • -
    • Request -path:
      - -  Servlet: -the node-name(-n nodeX) of the -JOnAS web-container that has executed the servlet 
      - -  Stateless EJB:  the node-name(-n nodeX) of the JOnAS ejb-container where the stateless session 
      -    bean has been -created
      -
      • -
    • Session -Data : New Session : false:  indicates if a new http session has been created in the web -container
      -
      • -
    • Session -ID:  id of the http session
      -
      • -
    • Creation Time:  -date of the http session creation
      -
      • -
    • Last -Accessed:  -date of the last access to the session
      -
      • -
    • JOnAS -instance=<node-name>:  ejb-container where the stateful ejb has been created
      -
      • -
    • Table
      - -  servlet running on:  web-container that has executed the servlet
      - -  stateless bean created:  ejb-container that has created the stateless session bean
      - -  stateless bean total calls:  number of instantiations of the stateless bean on a specific -node
      - -  stateless bean instance count
      - -  entity bean created:  if an entity bean has been created, this indicates the - node-name of the EJB 
      -    container that created the entity bean links
      - -  Ask again:  executes the servlet again
      - -  release session:  invalidates the opened http session and if a cookie is present, -it will be made obsolete
      - -  check session:  checks to see if the session is valid
      - -  home:  returns to the main page
      • -
    -

    After click on check session link

    -
      -
    • -JSessionID:  id of the http session
      • -
    • -links:
      - -  go to session:  returns to the opened session
      - -  check session:  checks to see if the session is valid
      - -  home:  returns to the main page
      • -
    -
    -

    References

    - - - \ No newline at end of file diff --git a/jonas_doc/olddoc/howto/Firewall.html b/jonas_doc/olddoc/howto/Firewall.html deleted file mode 100644 index 4e280d7d2e2b012b7b35bc8d3ef8e4d344a2c487..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/Firewall.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - - -Using JOnAS through a Firewall - - - - -

    Configuring RMI for use through a Firewall

    - -

    By default, the RMI protocol in JOnAS uses a random port at each startup, -which implies that there is no way to configure a firewall as the port number -changes each time the system restarts. -

    - -

    However, as of JOnAS version 4.4.1, you can easily configure the RMI port number -by setting only one property per protocol in the -$JONAS_BASE/conf/carol.properties file. -

    - -

    To configure the RMI exported-port number, edit the -$JONAS_BASE/conf/carol.properties file -to change the following protocols from 0 (choose a random port number) to the -port number you want: -

    - -
      -
    • For the RMI/JRMP protocol, change: -
      -carol.jrmp.server.port=0
-
      -
      • - -
    • For the RMI/Jeremie protocol, change: -
      -carol.jeremie.server.port=0
-
      -
      • - -
    • For the RMI/IIOP protocol, change: -
      -carol.iiop.server.port=0
-
      -
      • -
    - -

    Note: -The jonas.orb.port property has been moved from the -$JONAS_BASE/conf/jonas.properties file to the -$JONAS_BASE/conf/carol.properties file, as the latter is the file -in which the registry ports and protocols were already being set. -In previous JOnAS versions the jonas.orb.port property -was not useful in multi-protocols mode as it allowed only one port number -to be set for a single protocol. -Also, the jonas.orb.port property was working only for RMI/JRMP -and for objects using the PortableRemoteObject class for their export. -

    - - - diff --git a/jonas_doc/olddoc/howto/JMSClustering.html b/jonas_doc/olddoc/howto/JMSClustering.html deleted file mode 100644 index 4b2b3870d7d274b9e8285312b4dde8080e54b4cc..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/JMSClustering.html +++ /dev/null @@ -1,808 +0,0 @@ - - - - - - Clustering JMS with JOnAS - - - - -

    Howto: Clustering JMS with JOnAS

    -

    -Authors : Yannick Braeuner, Benoit Pelletier
    -February 12, 2008
    -Version : 2.0
    -

    -

    Introduction

    -

    Load balancing

    - -

                    -JORAM distributed configuration

    - -

                    -Why use clustered Topic?

    - -

                    -General scenario for Topic

    - -

                    -Load-balancing for Queue

    - -

                    -First scenario for Queue : distribution of the load at the server side

    - -

                    -Second scenario for Queue : load-balancing at the client side

    - -

    JORAM HA and JOnAS

    -

    MDB Clustering

    - - -

    Introduction

    - -

    Generalities about Clustering JMS

    - -

    The JMS API provides a separate domain for each messaging approach, point-to-point or -publish/subscribe. The point-to-point domain is built around the concept of queues, senders and receivers. -The publish/subscribe domain is built around the concept of topic, publisher and subscriber. -Additionally it provides a unified domain with common interfaces that enable the use of queue and topic. -This domain defines the concept of producers and consumers. -The classic sample uses a very simple configuration (centralized) made of one server hosting a queue and a topic. -The server is administratively configured for accepting connection requests from the anonymous user. -

    -

    JMS clustering aims to offer a solution for both the scalability and the high availability for the JMS accesses. -This document gives an overview of the JORAM capabilities for clustering a JMS application in the J2EE context. -The load-balancing and fail-over mechanisms are described and a user guide describing how to build such a configuration -is provided. Further information is available in the JORAM documentation here.

    - -

    Configuration

    - -

    The following information will be presented:

    -
      -
    • Load balancing throw cluster topic and cluster queue. - The distributed capabilities of JORAM will be examined.
      • -
    • How to present the JORAM HA enabling to ensure the high availability of the JORAM server.
      • -
    • How to build an MDB clustering architecture with both JOnAS and JORAM enabling to build - an MDB based application ensuring the high availability.
      • -
    - -

    Getting started :

    -
      -
    • Install and configure two JOnAS instances (see here). The newjc tool may be used for generating the initial configuration of the JMS cluster. The tool may be run with the default inputs except for the architecture (bothWebEjb) and number of nodes (2). See here for further information about the newjc tool.
      • -
    • JOnAS's examples newsamplemdb and newsamplemdb2 will be used to illustrate the configuration. First they must be compiled. Go to $JONAS_ROOT/examples/src and do ant install.
      • -
    - -

    Load balancing

    - -

    JORAM distributed configuration

    - -

    Two instances of JOnAS are configured ("J1" and "J2"). Each JOnAS instance has a dedicated collocated JORAM server: server - "S1" for JOnAS "J1", "S2" for "J2". Those two servers are aware of each other.

    - -

    Set a JORAM distributed configuration:

    - -
      -
    1. Go to $JONAS_BASE/conf and edit the a3servers.xml file (same for the 2 instances). 2 instances are defined in the same domain network. The persistent mode is enabled. - 
      -<?xml version="1.0"?>
-<config
-  <domain name="D1"/>
-  <property name="Transaction" value="fr.dyade.aaa.util.NTransaction"/>
-  <server id="1" name="S1" hostname="localhost">
-    <network domain="D1" port="16301"/>
-    <service class="org.objectweb.joram.mom.proxies.ConnectionManager"
-             args="root root"/>
-    <service class="org.objectweb.joram.mom.proxies.tcp.TcpProxyService"
-             args="16010"/>
-  </server>
-  <server id="2" name="S2" hostname="localhost">
-    <network domain="D1" port="16302"/>
-    <service class="org.objectweb.joram.mom.proxies.ConnectionManager"
-             args="root root"/>
-    <service class="org.objectweb.joram.mom.proxies.tcp.TcpProxyService"
-             args="16020"/>
-  </server>
-</config>
-
      -
      2. - -
    2. For each instance, edit the ra.xml embedded in the joram_for_jonas_ra.rar (by using unjar command manually or with the jonasAdmin's RA editor) and check the following element according to the a3servers.xml content -
        -
      • server id (1 or 2) - 
        -      <config-property>
-         <config-property-name>ServerId</config-property-name>
-         <config-property-type>java.lang.Short</config-property-type>
-         <config-property-value>1</config-property-value>
-      </config-property>
-
        -
        • -
      • server name (S1 or S2) - 
        -      <config-property>
-         <config-property-name>ServerName</config-property-name>
-         <config-property-type>java.lang.String</config-property-type>
-         <config-property-value>s1</config-property-value>
-      </config-property>
-
        -
        • -
      • hostname - 
        -      <config-property>
-         <config-property-name>HostName</config-property-name>
-         <config-property-type>java.lang.String</config-property-type>
-         <config-property-value>localhost</config-property-value>
-      </config-property>
-
        -
        • -
      • network port (16010 or 16020) - 
        -      <config-property>
-         <config-property-name>ServerPort</config-property-name>
-         <config-property-type>java.lang.Integer</config-property-type>
-         <config-property-value>16010</config-property-value>
-      </config-property>
-
        -
        • -
      • persistent mode - 
        -      <config-property>
-         <config-property-name>PersistentPlatform</config-property-name>
-         <config-property-type>java.lang.Boolean</config-property-type>
-         <config-property-value>true</config-property-value>
-      </config-property>
-
        -
        • -
      -
      3. -
    3. For each instance, edit the joramAdmin.xml, update the connection factories definition, the user definition -according to the local JORAM server configuration -
        -
      • server id (1 or 2) - 
        -    <User name="anonymous"
-             password="anonymous"
-             serverId="1"/>
-
        -
        • -
      • server port number (16010 or 16020) - 
        -    <ConnectionFactory className="org.objectweb.joram.client.jms.tcp.TcpConnectionFactory">
-       <tcp host="localhost"
-            port="16010"/>
-       <jndi name="JCF"/>
-    </ConnectionFactory>
-
-    <ConnectionFactory className="org.objectweb.joram.client.jms.tcp.QueueTcpConnectionFactory">
-       <tcp host="localhost"
-            port="16010"/>
-       <jndi name="JQCF"/>
-    </ConnectionFactory>
-
-    <ConnectionFactory className="org.objectweb.joram.client.jms.tcp.TopicTcpConnectionFactory">
-       <tcp host="localhost"
-            port="16010"/>
-       <jndi name="JTCF"/>
-    </ConnectionFactory>
-
        -
        • -
      -
      4. -
    -

    See here for more information about a JORAM distributed configuration.

    - -

    Why use clustered Topic?

    - -

    A non hierarchical topic might also be distributed among many servers. Such a topic, to be -considered as a single logical topic, is made of topic representatives, one per server. Such an architecture allows a publisher to publish messages on a representative of the topic. In the example, the publisher works with the representative on server 1. If a subscriber subscribed to any other representative (on server 2 in the example), it will get the messages produced by the publisher.

    - -

    Load balancing of topics is very useful because it allows distributed topic subscriptions across the cluster.

    - -

    node

    - - -

    General scenario for Topic

    - -

    The following scenario and general settings are proposed:

    -
      -
    • The cluster topic is composed of two elements : mdbTopic1 defined hosted by JORAM server S1 and mdbTopic2 hosted by JORAM server S2.
      • -
    • The jndi name 'mdbTopic' is set for the local representative, ie mdbTopic1 for S1 et mdbTopic2 for S2.
      • -
    • At the server side, a MDB is listening the local representative 'mdbTopic'.
      • -
    • A client connects to the J1 or J2 server and sends 10 messages to the topic 'mdbTopic'.
      • -
    • Each message is received twice, one per cluster element.
      • -
    - -

    node

    - - -

    Topic cluster definition in joramAdmin.xml

    - -

    -The cluster definition with the topics must be added in $JONAS_BASE/conf/joramAdmin.xml file. -The connection factories and the anonymous user must be defined with the local server id and the local server port number -according to the a3servers.xml content. Here only the cluster related elements are shown: -

    - -
      -
    • For the server id 1 : - 
      -  <Topic name="mdbTopic1" serverId="1">
-    <freeReader/>
-    <freeWriter/>
-    <jndi name="mdbTopic"/>
-  </Topic>
-
-  <Topic name="mdbTopic2" serverId="2">
-    <freeReader/>
-    <freeWriter/>
-    <jndi name="mdbTopic2"/>
-  </Topic>
-
-  <ClusterTopic>
-      <ClusterElement name="mdbTopic1" location="s1"/>
-      <ClusterElement name="mdbTopic2" location="s2"/>
-      <jndi name="clusterMdbTopic"/>
-  </ClusterTopic>
-
      -
      • - -
    • For the server id 1 : - 
      -  <Topic name="mdbTopic1" serverId="1">
-    <freeReader/>
-    <freeWriter/>
-    <jndi name="mdbTopic1"/>
-  </Topic>
-
-  <Topic name="mdbTopic2" serverId="2">
-    <freeReader/>
-    <freeWriter/>
-    <jndi name="mdbTopic"/>
-  </Topic>
-
-  <ClusterTopic>
-    <ClusterElement name="mdbTopic1" location="s1"/>
-    <ClusterElement name="mdbTopic2" location="s2"/>
-    <jndi name="clusterMdbTopic"/>
-  </ClusterTopic>
-
      -
      • -
    - -

    The joramAdmin.xml file has to be loaded when all cluster members are started since some remote - cluster elements are defined. An alternative consists in splitting the configuration into two different files - joramAdmin-local.xml and joramAdmin-cluster.xml, the first one containing only the local elements and the - second one, both local and remote elements. At the JOnAS starting, a script could copy the right file - to joramAdmin.xml according to the others members presence (joramAdmin-local.xml if it's the first member - which starts and joramAdmin-cluster.xml if all the cluster members are started).

    - -

    Run the sample

    - -

    Deploy the application, for example, create a deploy.sh file:

    -
    -#!/bin/ksh
-
-export JONAS_BASE=$PWD/jb1
-cp $JONAS_ROOT/examples/output/ejbjars/newsamplemdb.jar $JONAS_BASE/ejbjars/
-jonas admin -a newsamplemdb.jar -n node1
-
-export JONAS_BASE=$PWD/jb2
-cp $JONAS_ROOT/examples/output/ejbjars/newsamplemdb.jar $JONAS_BASE/ejbjars/
-jonas admin -a newsamplemdb.jar -n node2
-
    - -

    Finally launch the client

    - -
    jclient newsamplemdb.MdbClient
    - -

    Something similar to this should appear in the client console :

    -
    -ClientContainer.info : Starting client...
-JMS client: tcf = TCF:localhost-16010
-JMS client: topic = topic#1.1.1026
-JMS client: tc = Cnx:#0.0.1026:5
-MDBsample is Ok
-
    - -

    In addition, the following should appear on each JOnAS instance console:

    - -
    -Message received: Message6
-MdbBean onMessage
-Message received: Message7
-MdbBean onMessage
-Message received: Message8
-
    - -

    The fact that each message appears on the two different JOnAS servers consoles shows the messages broadcasting between the -topic elements.

    - -

    Load-balancing for Queue

    - -

    Globally, the load balancing in the context of queues may be meaningless in comparison of load balancing topic. -It would be a bit like load balancing a stateful session bean instance (which just requires failover). -But the JORAM distributed architecture enables :

    -
      -
    • equilibrating the load of the queue access between several JORAM server nodes, it's a queue load-balancing at the server side.
      • -
    • load-balancing the load at the client side.
      • -
    - -

    First scenario for Queue : distribution of the load at the server side

    - -

    Here is a diagram of what is going to happen for the Queue and the message:

    - -

    node

    - -

    A load balancing message queue may be needed for a high rate of messages. -A clustered queue is a cluster of queues exchanging messages depending on their load. The example has a cluster of two queues. -A heavy producer accesses its local queue and sends messages. It quickly becomes loaded and decides to forward messages to the other queue of its cluster which is not under heavy load.

    - -

    For this case some parameters must be set:

    -
      -
    • period: period (in ms) of activation of the load factor evaluation routine for a queue
      • -
    • producThreshold: number of messages above which a queue is considered loaded, a load factor evaluation launched, messages forwarded to other queues of the cluster
      • -
    • consumThreshold: number of pending "receive" requests above which a queue will request messages from the other queues of the cluster
      • -
    • autoEvalThreshold: set to "true" for requesting an automatic revaluation of the queues' thresholds values according to their activity
      • -
    • waitAfterClusterReq: time (in ms) during which a queue that requested something from the cluster is not authorized to do it again
      • -
    - -

    For further information, see the JORAM documentation here.

    - -

    The scenario for Queue is similar to the topic one. A client sent messages to a queue in S1. MDB gets messages -from each local cluster queue representative. After having sent a burst of messages to the server S1, -the load distribution should occur and message should be moved to S2.

    - - -

    The Queue definition in $JONAS_BASE/conf/joramAdmin.xml file is as following :

    - -
      -
    • For server 1
      • -
      -<Queue name="mdbQueue1"
-          serverId="1"
-          className="org.objectweb.joram.mom.dest.ClusterQueue">
-  <freeReader/>
-  <freeWriter/>
-  <property name="period" value="10000"/>
-  <property name="producThreshold" value="50"/>
-  <property name="consumThreshold" value="2"/>
-  <property name="autoEvalThreshold" value="false"/>
-  <property name="waitAfterClusterReq" value="1000"/>
-  <jndi name="mdbQueue"/>
-</Queue>
-
-<Queue name="mdbQueue2"
-          serverId="2"
-          className="org.objectweb.joram.mom.dest.ClusterQueue">
-  <freeReader/>
-  <freeWriter/>
-  <property name="period" value="10000"/>
-  <property name="producThreshold" value="50"/>
-  <property name="consumThreshold" value="2"/>
-  <property name="autoEvalThreshold" value="false"/>
-  <property name="waitAfterClusterReq" value="1000"/>
-  <jndi name="mdbQueue2"/>
-
-<ClusterQueue>
-    <ClusterElement name="mdbQueue1" location="s1"/>
-    <ClusterElement name="mdbQueue2" location="s2"/>
-    <jndi name="mdbQueueCluster"/>
-</ClusterQueue>
-
-
      - -
    • For server 2
      • - -
      -<Queue name="mdbQueue1"
-          serverId="1"
-          className="org.objectweb.joram.mom.dest.ClusterQueue">
-  <freeReader/>
-  <freeWriter/>
-  <property name="period" value="10000"/>
-  <property name="producThreshold" value="50"/>
-  <property name="consumThreshold" value="2"/>
-  <property name="autoEvalThreshold" value="false"/>
-  <property name="waitAfterClusterReq" value="1000"/>
-  <jndi name="mdbQueue1"/>
-</Queue>
-
-<Queue name="mdbQueue2"
-          serverId="2"
-          className="org.objectweb.joram.mom.dest.ClusterQueue">
-  <freeReader/>
-  <freeWriter/>
-  <property name="period" value="10000"/>
-  <property name="producThreshold" value="50"/>
-  <property name="consumThreshold" value="2"/>
-  <property name="autoEvalThreshold" value="false"/>
-  <property name="waitAfterClusterReq" value="1000"/>
-  <jndi name="mdbQueue"/>
-
-<ClusterQueue>
-    <ClusterElement name="mdbQueue1" location="s1"/>
-    <ClusterElement name="mdbQueue2" location="s2"/>
-    <jndi name="mdbQueueCluster"/>
-</ClusterQueue>
-
      -
    - -

    Run the sample

    - -

    The procedure is similar to the topic example described above, just use the newsamplemdb2 example rather than -newsample one.

    - -

    Second scenario for Queue : load-balancing at the client side

    - -

    Principle

    - -

    The load-balancing is done at the client side. A server is selected randomly among the cluster members -at the first message sending or through the 'location' java property. And then, for a given client, all the messages -are sent to the same server unless the java property resetting.

    - -

    node

    - -

    For setting the load-balancing at the client side, the client application must use a clustered connection factory that -embeds the network connection parameters of the cluster members. This factory must be registered in the JORAM's -distributed JNDI for ensuring that the client gets an up to date object. A complete description of the -JORAM JNDI setting is given here and the main parameters -are given below :

    - -

    Setting of the JORAM's distributed jndi

    - -

    At first, the a3servers.xml file must enhanced with the JORAM's jndi service as following :

    - -
    -<?xml version="1.0"?>
-<config>
-  <domain name="D1"/>
-  <property name="Transaction" value="fr.dyade.aaa.util.NTransaction"/>
-
-  <server id="0" name="s0" hostname="localhost">
-    <network domain="D1" port="16301"/>
-    <service class="org.objectweb.joram.mom.proxies.ConnectionManager"
-             args="root root"/>
-    <service class="org.objectweb.joram.mom.proxies.tcp.TcpProxyService"
-             args="16010"/>
-    <service class="fr.dyade.aaa.jndi2.distributed.DistributedJndiServer"
-               args="16401 0 1"/>
-  </server>
-
-  <server id="1" name="s1" hostname="localhost">
-     <network domain="D1" port="16302"/>
-     <service class="org.objectweb.joram.mom.proxies.ConnectionManager"
-             args="root root"/>
-    <service class="org.objectweb.joram.mom.proxies.tcp.TcpProxyService"
-             args="16020"/>
-    <service class="fr.dyade.aaa.jndi2.distributed.DistributedJndiServer"
-               args="16402 1 0"/>
-  </server>
-
-</config>
-
    - -

    Only the JMS objects must be registered in the JORAM's jndi. The standard routing mechanism is used through a jndi.properties file -put in each $JONAS_BASE/conf directory :

    - -
      -
    • port number (16401 or 16402)
      • - 
      -  java.naming.factory.url.pkgs    org.objectweb.jonas.naming:fr.dyade.aaa.jndi2
-  scn.naming.factory.host         localhost
-  scn.naming.factory.port         16402
-
      -
    - -

    The port number must be adapted according to the local server configuration (16401 for S1 and 16402 for S2). The 'scn' prefix -is defined for identifying the objects to bind or to lookup in this registry.

    - -

    Setting of the clustered connection factories

    - -

    The clustered connection factories are defined in the $JONAS_BASE/conf/joramAdmin.xml file as following :

    - -
    -<ConnectionFactory name="JQCF1" className="org.objectweb.joram.client.jms.tcp.QueueTcpConnectionFactory">
-  <tcp host="localhost"
-       port="16010"/>
-  <jndi name="scn:comp/JQCF1"/>
-</ConnectionFactory>
-<ConnectionFactory name="JQCF2" className="org.objectweb.joram.client.jms.tcp.QueueTcpConnectionFactory">
-  <tcp host="localhost"
-       port="16020"/>
-  <jndi name="scn:comp/JQCF2"/>
-</ConnectionFactory>
-<ClusterCF>
-    <ClusterElement name="JQCF1" location="s1"/>
-    <ClusterElement name="JQCF2" location="s2"/>
-    <jndi name="scn:comp/clusterJQCF"/>
-</ClusterCF>
-
    - -

    The 'scn:comp/' prefix in the jndi name indicates that the object must be bound in the JORAM's jndi.

    - -

    Cluster queue definition

    - -

    The cluster queue is defined in the $JONAS_BASE/conf/joramAdmin.xml file :

    - -
    -<Queue name="mdbQueue0" serverId="1"
-       className="org.objectweb.joram.mom.dest.ClusterQueue">
-   <freeReader/>
-   <freeWriter/>
-   <jndi name="scn:comp/mdbQueue1"/>
-</Queue>
-
-<Queue name="mdbQueue1" serverId="2"
-       className="org.objectweb.joram.mom.dest.ClusterQueue">
-   <freeReader/>
-   <freeWriter/>
-   <jndi name="scn:comp/mdbQueue2"/>
-</Queue>
-
-<ClusterQueue>
-   <ClusterElement name="mdbQueue1" location="s1"/>
-   <ClusterElement name="mdbQueue2" location="s2"/>
-   <jndi name="scn:comp/mdbQueue"/>
-</ClusterQueue>
-
    - -

    Note that the cluster queue definition is symetric accross the cluster members. The well known jndi name is set -on the cluster object (and not in the local representative as for the topic cluster).

    - -

    Note that same for the topic declaration, the joramAdmin.xml file has to be loaded when all cluster members - are started since some remote cluster elements are defined. - An alternative consists in splitting the configuration into two different files - joramAdmin-local.xml and joramAdmin-cluster.xml, the first one containing only the local elements and the - second one, both local and remote elements. At the JOnAS starting, a script could copy the right file - to joramAdmin.xml according to the others members presence (joramAdmin-local.xml if it's the first member - which starts and joramAdmin-cluster.xml if all the cluster members are started).

    - -

    MDB configuration

    - -

    The message driven bean must be configured with the queue registered in the JORAM jndi ('scn:/comp' selector). - Edit the deployment descriptor file (ejb-jar.xml) :

    - -
    -  <message-driven>
-      <description>Describe here the message driven bean Mdb</description>
-      <display-name>Message Driven Bean Mdb</display-name>
-      <ejb-name>Mdb</ejb-name>
-      <ejb-class>newsamplemdb2.MdbBean</ejb-class>
-      <messaging-type>javax.jms.MessageListener</messaging-type>
-      <transaction-type>Container</transaction-type>
-      <message-destination-type>javax.jms.Queue</message-destination-type>
-      <activation-config>
-          <activation-config-property>
-            <activation-config-property-name>destination</activation-config-property-name>
-            <activation-config-property-value>scn:comp/mdbQueue</activation-config-property-value>
-          </activation-config-property>
-          <activation-config-property>
-            <activation-config-property-name>destinationType</activation-config-property-name>
-            <activation-config-property-value>javax.jms.Queue</activation-config-property-value>
-          </activation-config-property>
-          <activation-config-property>
-            <activation-config-property-name>subscriptionDurability</activation-config-property-name>
-            <activation-config-property-value>NonDurable</activation-config-property-value>
-          </activation-config-property>
-      </activation-config>
-  </message-driven>
-
    - -

    Client code

    - -

    The client must lookup the clustered objects in the JORAM's jndi by using the 'scn:/comp' selector.

    - -
    -static String queueName = "scn:comp/mdbQueue";
-static String conFactName = "scn:comp/clusterJQCF";
-Context ictx = new InitialContext();
-ConnectionFactory qcf = (ConnectionFactory) ictx.lookup(conFactName );
-Queue queue = (Queue) ictx.lookup(queueName);
-
    - -

    The connection creation, session creation and producer are quite classic:

    -
    -Connection qc = qcf.createConnection();
-Session session = qc.createSession(false, Session.AUTO_ACKNOWLEDGE);
-MessageProducer qp = session.createProducer(queue);
-
    - -

    A server is chosen at the first message sending. A switch may be forced through the resetting of the 'location' java -property. Below a new server election is requested for each odd iteration.

    - -
    -TextMessage message;
-for (int i = 0; i < 10; i++) {
-  message = session.createTextMessage();
-  message.setText("Msg "+i);
-  qp.send(message);
-  System.out.println("location=" + System.getProperty("location"));
-  if (i%2 == 0) {
-    System.setProperty("location", "");
-  }
-}
-
    - -

    Run the sample

    - -

    The procedure is similar to the topic and queue ones described above, just adapt the newsamplemdb2 example with -the configuration and code given previously.

    - - -

    JORAM HA and JOnAS

    - -

    Generality

    - -

    node

    - -

    An HA server is actually a group of servers, one of which is the master server that coordinates the other slave servers. An external server that communicates with the HA server is actually connected to the master server.

    -

    Each replicated JORAM server executes the same code as a standard server except for the communication with the clients.

    -

    In the example, the collocated clients use a client module (newsamplemdb). If the server replica is the master, then the connection is active enabling the client to use the HA JORAM server. If the replica is a slave, then the connection opening is blocked until the replica becomes the master.

    - -

    Configuration

    - -

    Several files must be changed to create a JORAM HA configuration:

    - -

    a3servers.xml

    - -

    A clustered server is defined by the element "cluster". A cluster owns an identifier and a name defined by the attributes "id" and "name" (exactly like a standard server). Two properties must be defined:

    -
      -
    • "Engine" must be set to "fr.dyade.aaa.agent.HAEngine" which is the class name of the engine that provides high availability.
      • -
    • "nbClusterExpected" defines the number of replicas that must be connected to the group communication channel used before this replica starts. By default it is set to 2. If there are more than two clusters, this specification must be inserted in the configuration file. If there are two clusters, this specification is not required.
      • -
    -

    In the case of one server and one replica, the value must be set to 1.

    -
    -<?xml version="1.0"?/>
-<config>
-  <domain name="D1"/>
-
-  <property name="Transaction" value="fr.dyade.aaa.util.NullTransaction"/>
-
-  <cluster id="0" name="s0">
-
-    <property name="Engine" value="fr.dyade.aaa.agent.HAEngine" />
-    <property name="nbClusterExpected" value="1" />
-
    - -

    For each replica, an element "server" must be added. The attribute "id" defines the identifier of the replica inside the cluster. The attribute "hostname" gives the address of the host where the replica is running. The network is used by the replica to communicate with external agent servers, i.e., servers located outside of the cluster and not replicas.

    - -

    This is the entire configuration for the a3servers.xml file of the first JOnAS instance jb1:

    - -
    -<?xml version="1.0"?>
-<config<
-  <domain name="D1"/>
-
-  <property name="Transaction" value="fr.dyade.aaa.util.NullTransaction"/>
-
-  <cluster id="0" name="s0">
-
-    <property name="Engine" value="fr.dyade.aaa.agent.HAEngine" />
-    <property name="nbClusterExpected" value="1" />
-
-    <server id="0" hostname="localhost">
-      <network domain="D1" port="16300"/>
-      <service class="org.objectweb.joram.mom.proxies.ConnectionManager" args="root root"/>
-      <service class="org.objectweb.joram.mom.proxies.tcp.TcpProxyService" args="16010"/>
-      <service class="org.objectweb.joram.client.jms.ha.local.HALocalConnection"/>
-    </server>
-
-    <server id="1" hostname="localhost">
-      <network domain="D1" port="16301"/>
-      <service class="org.objectweb.joram.mom.proxies.ConnectionManager" args="root root"/>
-      <service class="org.objectweb.joram.mom.proxies.tcp.TcpProxyService" args="16020"/>
-      <service class="org.objectweb.joram.client.jms.ha.local.HALocalConnection"/>
-    </server>
-
-  </cluster>
-
-</config>
-
    - -

    The cluster id = 0 and the name S0. It is exactly the same file for the second instance of JOnAS.

    - -

    joramAdmin.xml

    - -

    Here is the joramAdmin.xml file configuration:

    - -
    -<?xml version="1.0"?>
-
-<JoramAdmin>
-
-<AdminModule>
-  <collocatedConnect name="root" password="root"/>
-</AdminModule>
-
-<ConnectionFactory className="org.objectweb.joram.client.jms.ha.tcp.HATcpConnectionFactory">
-  <hatcp url="hajoram://localhost:16010,localhost:16020" reliableClass="org.objectweb.joram.client.jms.tcp.ReliableTcpClient"/>
-  <jndi name="JCF"/>
-</ConnectionFactory>
-
-<ConnectionFactory className="org.objectweb.joram.client.jms.ha.tcp.QueueHATcpConnectionFactory">
-  <hatcp url="hajoram://localhost:16010,localhost:16020" reliableClass="org.objectweb.joram.client.jms.tcp.ReliableTcpClient"/>
-  <jndi name="JQCF"/>
-</ConnectionFactory>
-
-<ConnectionFactory className="org.objectweb.joram.client.jms.ha.tcp.TopicHATcpConnectionFactory">
-  <hatcp url="hajoram://localhost:16010,localhost:16020" reliableClass="org.objectweb.joram.client.jms.tcp.ReliableTcpClient"/>
-  <jndi name="JTCF"/>
-</ConnectionFactory>
-
    - -

    Each connection factory has its own specification. One is in case of the Queue, one for Topic, and one for no define arguments. Each time the hatcp url must be entered, the url of the two instances. In the example, it is localhost:16010 and localhost:16020. It allows the client to change the instance when the first one is dead.

    -

    After this definition the user, the queue and topic can be created.

    - -

    ra and jonas-ra.xml files

    - -

    First, in order to recognize the cluster, a new parameter must be declared in these files.

    -
    -      <config-property>
-         <config-property-name>ClusterId</config-property-name>
-         <config-property-type>java.lang.Short</config-property-type>
-         <config-property-value>0</config-property-value>
-      </config-property>
-
    -

    Here the name is not really appropriate but in order to keep some coherence this name was used. In fact it represents a replica so it would have been better to call it replicaId.

    - -

    Consequently, for the first JOnAS instance, copy the code just above. For the second instance, change the value to 1 (in order to signify this is another replica).

    - -

    Illustration

    -

    First launch the two JOnAS bases. Create a runHa.sh file in which the following code will be added:

    -
    -export JONAS_BASE=$PWD/jb1
-export CATALINA_BASE=$JONAS_BASE
-rm -f $JONAS_BASE/logs/*
-jonas start -win -n node1 -Ddomain.name=HA
-
    -

    Then do the same for the second JOnAS base. After that launch the script.

    -

    One of the two JOnAS bases (the one which is the slowest) will be in a waiting state when reading the joramAdmin.xml

    -
    -JoramAdapter.start :   - Collocated JORAM server has successfully started.
-JoramAdapter.start :   - Reading the provided admin file: joramAdmin.xml
-
    -

    whereas the other one is launched successfully.

    -

    Then launch (through a script or not) the newsamplemdb example:

    -
    -jclient -cp /JONAS_BASE/jb1/ejbjars/newsamplemdb.jar:/JONAS_ROOT/examples/classes  -carolFile clientConfig/carol.properties newsamplemdb.MdbClient
-
    -

    Messages are sent on the JOnAS base which was launched before. Launch it again and kill the current JOnAS. The second JOnAS will automatically wake up and take care of the other messages.

    - - -

    MDB Clustering

    - -

    Generality

    - -

    This is a proposal for building an MDB clustering based application.

    - -

    This is like contested Queues. i.e., there is more than one receiver on different machines receiving from the queue. This load balances the work done by the queue receiver, not the queue itself.

    - -

    The HA mechanism can be mixed with the load balancing policy based on clustered destinations. The load is balanced between several HA servers. Each element of a clustered destination is deployed on a separate HA server.

    - -

    node

    - -

    Configuration

    -

    Here is the supposed configuration (supposed because it has not been verifed).

    - -

    node

    - - -

    Illustration

    -

    The configuration must now be tested, as follows: -

    -
  • First make JA1 crash and verify that messages are spread between JB1 and JB2.
    • -
  • Then make JB2 crash and verify that messages are spread between JA1 and JA2.
    • -
  • Finally make JA1 and JB2 crash and verify that messages are spread between JA2 and JB1.
    • -
    -

    - - diff --git a/jonas_doc/olddoc/howto/JORAMdistributed_JOnAS_4_1.html b/jonas_doc/olddoc/howto/JORAMdistributed_JOnAS_4_1.html deleted file mode 100644 index 7512e1d46be2927e9232bc9a95292edfe50734fa..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/JORAMdistributed_JOnAS_4_1.html +++ /dev/null @@ -1,202 +0,0 @@ - - - - - - Distributed Message Beans in JOnAS 4.1 - - - - -

    Howto: Distributed Message Beans in JOnAS 4.x

    - -

    JOnAS release 4.1 dramatically simplifies the use of a distributed JORAM -platform from within JOnAS servers. For example, such a configuration allows -a bean hosted by JOnAS instance "A" to send messages on a JORAM queue, to -which a MDB hosted by JOnAS instance "B" listens.

    - -

    This advancement is due to the following:

    -
      -
    • JORAM Resource Adapter allows a much more refined configuration than - the JMS service did.
      • -
    • JORAM provides a distributed JNDI server which allows JOnAS instances - to share information.
      • -
    - -

    Before going through this chapter, it is highly recommended that the JORAM Resource Adapter -configuration guide be reviewed.

    - -

    Scenario and general architecture

    - -

    The following scenario and general settings are proposed:

    -
      -
    • Two instances of JOnAS are run (JOnAS "A" and JOnAS "B"). JOnAS A hosts - a simple bean providing a method for sending a message on a JORAM queue. - JOnAS B hosts a message-driven bean listening on the same JORAM - queue.
      • -
    • Each JOnAS instance has a dedicated collocated JORAM server: server - "s0" for JOnAS A, "s1" for JOnAS B. Those two servers are aware of each - other.
      • -
    • The queue is hosted by JORAM server s1.
      • -
    • An additional JNDI service is provided by the JORAM servers that will - be used for storing the shared information (basically, the queue's naming - reference).
      • -
    - -

    Common configuration

    - -

    The JORAM servers are part of the same JORAM platform described by the -following a3servers.xml configuration file:

    -
    <?xml version="1.0"?>
-<config>
-    <domain name="D1"/>
-    <server id="0" name="S0" hostname="hostA">
-      <network domain="D1" port="16301"/>
-      <service class="org.objectweb.joram.mom.proxies.ConnectionManager"
-               args="root root"/>
-      <service class="org.objectweb.joram.mom.proxies.tcp.TcpProxyService"
-               args="16010"/>
-      <service class="fr.dyade.aaa.jndi2.distributed.DistributedJndiServer"
-               args="16400 0"/>
-    </server>
-    <server id="1" name="S1" hostname="hostB">
-      <network domain="D1" port="16301"/>
-      <service class="org.objectweb.joram.mom.proxies.ConnectionManager"
-               args="root root"/>
-      <service class="org.objectweb.joram.mom.proxies.tcp.TcpProxyService"
-               args="16010"/>
-      <service class="fr.dyade.aaa.jndi2.distributed.DistributedJndiServer"
-               args="16400 0 1"/>
-
-    </server>
-</config>
    - -

    This configuration describes a platform made up of two servers, "s0" and -"s1", hosted by machines "hostA" and "hostB", listening on ports 16010, -providing a distributed JNDI service (more info on JORAM's JNDI may be found -here).

    - -

    Each JOnAS server must hold a copy of this file in its conf/ -directory. In its jonas.properties file, each must declare the -joram_for_jonas_ra.rar as a resource to be deployed (and each -should remove jms from its list of services).

    - -

    Specific configuration

    - -

    JOnAS A embeds JORAM server s0. The -jonas-ra.xml descriptor packaged in the -joram_for_jonas_ra.rar archive file must provide the following -information:

    -
    <jonas-config-property>
-    <jonas-config-property-name>HostName</jonas-config-property-name>
-    <jonas-config-property-value>hostA</jonas-config-property-value>
-</jonas-config-property>
    - -

    The other default settings do not need to be changed.

    - -

    JOnAS B embedds JORAM server s1. The -jonas-ra.xml descriptor packaged in the -joram_for_jonas_ra.rar archive file must provide the following -properties values:

    -
    <jonas-config-property>
-    <jonas-config-property-name>ServerId</jonas-config-property-name>
-    <jonas-config-property-value>1</jonas-config-property-value>
-</jonas-config-property>
-<jonas-config-property>
-    <jonas-config-property-name>ServerName</jonas-config-property-name>
-    <jonas-config-property-value>s1</jonas-config-property-value>
-</jonas-config-property>
-<jonas-config-property>
-    <jonas-config-property-name>HostName</jonas-config-property-name>
-    <jonas-config-property-value>hostB</jonas-config-property-value>
-</jonas-config-property>
    - -

    The other default settings do not need to be changed.

    - -

    The shared queue will be hosted by JORAM server s1. It -must then be declared in the JOnAS B's joramAdmin.xml file as -follows:

    -
    -        <Queue name="sharedQueue">
-          <freeReader/>
-          <freeWriter/>
-          <jndi name="scn:comp/sharedQueue"/>
-        </Queue>
-
    - -

    The scn:comp/ prefix is a standard way to specify which JNDI -provider should be used. In this case, the shared queue will be bound to -JORAM's distributed JNDI server, and may be retrieved from both JOnAS A and -JOnAS B. To provide this mechanism, both JOnAS servers must provide access to -a standard jndi.properties file. For JOnAS A, the file looks as -follows, and should be placed in its conf/ directory:

    -
    java.naming.factory.url.pkgs    org.objectweb.jonas.naming:fr.dyade.aaa.jndi2
-scn.naming.factory.host         hostA
-scn.naming.factory.port         16400
    - -

    For JOnAS B, the file looks as follows, and should be placed in the right -conf/ directory:

    -
    java.naming.factory.url.pkgs    org.objectweb.jonas.naming:fr.dyade.aaa.jndi2
-scn.naming.factory.host         hostB
-scn.naming.factory.port         16400
    - -

    And now, the beans!

    - -

    The simple bean on JOnAS A needs to connect to its local -JORAM server and access the remote queue. The following is an example of -consistent resource definitions in the deployment descriptors:

    - -

    Standard deployment descriptor:

    -
    <resource-ref>
-  <res-ref-name>jms/factory</res-ref-name>
-  <res-type>javax.jms.ConnectionFactory</res-type>
-  <res-auth>Container</res-auth>
-</resource-ref>
-<resource-env-ref>
-  <resource-env-ref-name>jms/sharedQueue</resource-env-ref-name>
-  <resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
-</resource-env-ref>
    - -

    Specific deployment descriptor:

    -
    <jonas-resource>
-  <res-ref-name>jms/factory</res-ref-name>
-  <jndi-name>CF</jndi-name>
-</jonas-resource>
-<jonas-resource-env>
-  <resource-env-ref-name>jms/sharedQueue</resource-env-ref-name>
-  <jndi-name>scn:comp/sharedQueue</jndi-name>
-</jonas-resource-env>
    - -

    The ConnectionFactory is retrieved from the local JNDI registry of the -bean. However, the Queue is retrieved from the distributed JORAM JNDI server, -because its name starts with the scn:comp/ prefix. It is the same -queue to which the message-driven bean on JOnAS B listens. -For doing so, its activation properties should be set as follows:

    -
    <activation-config>
-   <activation-config-property>
-      <activation-config-property-name>destination</activation-config-property-name>
-      <activation-config-property-value>scn:comp/sharedQueue</activation-config-property-value>
-   </activation-config-property>
-   <activation-config-property>
-      <activation-config-property-name>destinationType</activation-config-property-name>
-      <activation-config-property-value>javax.jms.Queue</activation-config-property-value>
-   </activation-config-property>
-</activation-config>
    - - diff --git a/jonas_doc/olddoc/howto/JSR160_support.html b/jonas_doc/olddoc/howto/JSR160_support.html deleted file mode 100644 index d5616cd625c679913a63d51288e26cf03e742888..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/JSR160_support.html +++ /dev/null @@ -1,108 +0,0 @@ - - - - - - JSR 160 support in JOnAS - - - - -

    Howto: JSR 160 support in JOnAS

    - -

    The content of this document is the following:

    -
      -
    1. Target Audience and Rationale
      2. -
    2. What is JSR 160 ?
      3. -
    3. Connector servers created by JOnAS
      4. -
    - -

    Target Audience and Rationale

    -Starting with version 4.1.4 JOnAS provides support for remote connection to the -MBean server in a standard way. - -

    The target audience for this document is the management application - developer or the administrator, intending to use standard JMX RMI - connectors to access the MBean Server running in a JOnAS server. -

    - -

    What is JSR 160 ?

    -The JSR 160 is a JMX Remoting specification which extends the JSR 3 specification -by providing a standard API to connect to remote JMX-enabled applications. -

    -Currently, JSR 160 has defined a mandatory connector based on RMI (that -supports both RMI/JRMP and RMI/IIOP). -

    -

    Support for JSR 160 connectors in JOnAS is based on the - MX4J JMX - implementation. -

    - -

    Connector servers created by JOnAS

    -Previous and current JOnAS versions implement a proprietary remote object allowing -connection to the MBean server. This object is registered in JNDI under the name -'RMIConnector_jonasServerName'. It can be accessed using any of -the communication protocols support by JOnAS (RMI/JRMP, RMI/IIOP, JEREMIE - -see Choosing the Protocol). -

    -JSR 160 support implies providing standard connector server objects. The JMX service -creates at start-up one or several such objects, depending on the JOnAS configuration -(in this case, depending on the content of carol.properties file). -To create a client connector, the client side needs to know the URL of the connector -server. Below we present the URLs that can be used by the clients depending on the -protocol they choose.

    -

    Currently only 2 protocols can be used by JSR-160 connectors: -RMI/JRMP and RMI/IIOP. -

    -

    Using a RMI/JRMP Connector

    -This connector can be used if the jrmp protocol is set in the - carol.protocols list. -

    -The client has to construct a JMXServiceURL using the following -String, possibly modified according to the JOnAS-specific configuration: -service:jmx:rmi:///jndi/rmi://host:port/jrmpconnector_jonasServerName -where host is the host on which is running the JOnAS server to be managed. -The port number is given in the carol.properties file.

    -

    Then, a JMXConnector has to be created and connected to the connector server - using the JMX Remote API. -

    - -

    Example 1:

    -
     
-	Hashtable environment = null;   
-	JMXServiceURL address = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://host:1099/jrmpconnector_jonas");
-	JMXConnector connector = JMXConnectorFactory.newJMXConnector(address, environment);
-	connector.connect(environment);
-
    - -

    Using a RMI/IIOP Connector

    -This connector can be used if the iiop protocol is set in the - carol.protocols list. -

    -The client code is similar to the JRMP case, but the String to be used to construct the JMXServiceURL -must adhere to the following model: -"service:jmx:iiop:///jndi/iiop://host:port/iiopconnector_jonasServerName"

    - -

    Example 2:

    -
     
-	Hashtable environment = null;   
-	JMXServiceURL address = new JMXServiceURL("service:jmx:iiop:///jndi/iiop://host:2001/iiopconnector_jonas");
-	JMXConnector connector = JMXConnectorFactory.newJMXConnector(address, environment);
-	connector.connect(environment);
-
    - - \ No newline at end of file diff --git a/jonas_doc/olddoc/howto/JonasArchi.html b/jonas_doc/olddoc/howto/JonasArchi.html deleted file mode 100644 index 8aab71f598bbcb18447a818aae1b72f983eb9168..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/JonasArchi.html +++ /dev/null @@ -1,1005 +0,0 @@ - - - - - The JOnAS Platform - - - - - -

    Java Open Application Server (JOnAS): Architecture and Design

    - -

    Last modified at 2005-04-22, JOnAS 4.3

    -Logo JOnAS - - -

    - -

    This document provides an overview of the JOnAS platform architecture -design. The content of this document is the following:

    - - -

    Introduction

    - -

    This document presents the internal architectural design of the JOnAS -application server. It contains many links toward the JOnAS documentation, -for detailed descriptions of some aspects.

    - -

    JOnAS Service based Architecture

    - -

    Design Principles

    - -

    JOnAS's service-based architecture provides for high modularity and -configurability of the server. It allows to apply a component-model approach -at the middleware level, and makes the integration of new modules easy (e.g. -for open source contributors). It also provides a way to start only the -services needed by a particular application, thus saving valuable system -resources. JOnAS services are manageable through JMX.

    - -

    JOnAS is designed with services in mind. A service typically provides -system resources to containers. Most of the components of the JOnAS -application server are pre-defined JOnAS services. However, it is possible -and easy for an advanced JOnAS user to define a service and to integrate it -into JOnAS. Because J2EE applications do not necessarily need all services, -it is possible to define, at JOnAS server configuration time, the set of -services that are to be launched at server start.

    - -

    The JOnAS architecture is illustrated in the following figure, showing WEB -and EJB containers relying on JOnAS services. Two thin clients are also shown -in this figure, one of which is the JOnAS administration console (called -JonasAdmin).

    -J2EE Architecture - -

    All these services correspond to JOnAS components. The JOnAS Service -principle is described in detail within the JOnAS documentation, in the Creating -a New JOnAS Service section of the Advanced Topic chapter. Please read -this document to understand the JOnAS components wrapping within services. -Generally, a JOnAS service Serv1 implementation may be found -in the package org.objectweb.jonas.serv1, where an interface -of the service may be found, Serv1Service, with an -implementation, Serv1ServiceImpl, and an MBean for the -service management purpose (as described below in the JOnAS Management -Architecture section), Serv1ServiceImplMBean class.

    - -

    An application server such as JOnAS must provide a complex class loading -scheme, which is described in the JOnAS -classloader hierarchy section of the J2EE Application Programmer's Guide -of the JOnAS documentation.

    - -

    The following of this section describes the existing JOnAS services.

    - -

    Communication and Naming Service

    - -

    This service (also called "Registry") is used for launching the RMI -registry, the CosNaming and/or the CMI registry -depending on the JOnAS configuration (CAROL configuration, which specifies -which communication protocols are to be used). There are different registry -launching modes: in the same JVM or not, automatically if not already -running. CAROL enables multi-protocol runtime support and deployment, which -avoids having to redeploy components when changing the communication -protocol.

    - -

    JOnAS may run several distributed processing environments, thanks to the -integration of the CAROL (Common -Architecture for RMI ObjectWeb Layer) ObjectWeb project, which allows -simultaneous support of several communication protocols:

    -
      -
    • RMI using the Sun proprietary protocol JRMP
      • -
    • RMI on IIOP
      • -
    • CMI, the "Cluster aware" distribution protocol of JOnAS
      • -
    - -

    This service provides the JNDI API to application components and to other -services in order to bind and lookup remote objects (e.g. EJB Homes) and -resource references (JDBC DataSource, Mail and JMS connection factories, -etc.).

    - -

    - -

    EJB Container Service

    - -

    This service is in charge of loading the EJB components and their -containers. EJB containers consist of a set of Java classes that implement -the EJB specification and a set of interposition classes that interface the -EJB components with the services provided by the JOnAS application server. -The role of the interposed classes is to manage transactions, security, ... -Interposition classes are specific to each EJB component and are generated by -the deployment tool called GenIC. -This tool is developed using the Velocity template based generation tool.

    - -

    For each EJB component XXX, GenIC generates the following classes:

    -
      -
    • JOnASXXXBean = bean instance
      • -
    • JOnASXXXHandle = handle
      • -
    • JOnASXXXHome = Home implementation
      • -
    • JOnASXXXLocalHome = LocalHome implementation
      • -
    • JOnASXXXRemote = implements the bean Remote interface
      • -
    • JOnASXXXLocal = implements the bean Local interface
      • -
    - -

    These files are generated with Velocity from templates located in org.objectweb.jonas_ejb.genic -(*.vm). Moreover, stubs and skeletons are generated, depending on the -specified protocol (jrmp/iiop), several protocols may be specified, -in this case several stubs/skeletons will be generated. CAROL is used to hide -the differencies between protocols.

    - -

    For implementing Container-Managed Persistence of EJB 2.0 and EJB 2.1 -(CMP2), JOnAS relies on the ObjectWeb JORM (Java Object Repository Mapping) -and MEDOR (Middleware Enabling -Distributed Object Requests) frameworks. JORM supports complex mappings of -EJBs to database tables, as well as several types of persistency support -(relational databases, object databases, LDAP repositories, etc.). JORM is -responsible for bean persistence. MEDOR is used to evaluate ejb-ql -queries.

    - -

    Generic objects used for entity beans are derived to be used by JORM:

    -
      -
    • JEntitySwitch implements PBinding (JORM), and is responsible for - Database accesses
      • -
    • The bean instance implements the PAccessor interface.
      • -
    - -

    Typically, the PBinding uses the PAccessor to set and get field values in -the bean instance.

    - -

    The lock policy is enforced in the JEntitySwitch class. Actually, this -class is specialized depending on the lock policy used:

    -
      -
    • JEntitySwitchCS = container serialized
      • -
    • JEntitySwitchCRC = container read committed
      • -
    • JEntitySwitchCRU = container read uncommitted
      • -
    • JEntitySwitchDB = database
      • -
    • JEntitySwitchRO = read only
      • -
    - -

    The detailed picture of the JOnAS CMP architecture is provided below:

    -J2EE Architecture - -

    Each jar file is implemented in a separate Container. Each Container has a -swapper that is used to periodically write bean instances

    - -

    on disk, and release memory instances from the cache when JOnAS needs more -memory.

    - -

    For Message driven beans, the factory implements ServerSessionPool -interface. For each instance, an object (JMessageDrivenBean) is created : It -implements ServerSession, MessageListener, Runnable, and MessageDrivenContext -interfaces.

    - -

    JOnAS configuration provides a means for specifying a set of ejb-jar files -to be loaded at server startup by the EJB container service. Ejb-jar files -can also be deployed at server runtime using the JOnAS administration -tools.

    - -

    JOnAS also implements the Timer Service features as specified in EJB -2.1.

    - -

    WEB Container Service

    - -

    This service is in charge of running a Servlet/JSP Engine in the JVM of -the JOnAS server and of loading web applications ("war" files) within this -engine. Currently, this service can be configured to use Tomcat or Jetty. Servlet/JSP engines are -integrated within JOnAS as "web containers," i.e. such containers provide the -web components with access to the system resources (of the application -server) and to EJB components, in a J2EE-compliant way.

    - -

    JOnAS configuration provides a means for specifying that this service be -launched during JOnAS initialization. Additionally, JOnAS configuration -provides a means for specifying a set of war files to be loaded at JOnAS -startup. War files may also be deployed at server runtime using the JOnAS -administration tools. User management for Tomcat/Jetty and JOnAS has been -unified. The class-loading delegation policy (priority to the Webapp -classloader or to the parent classloader) can be configured.

    - -

    The -web container service is implemented by using an abstract -class (AbsJWebContainerServiceImpl) which needs to be extended to -implement the specific Tomcat -or Jetty -part.
    -The interface -of this service defines common methods like starting, stopping the -embedded server, or deploy/undeploy war files. Also, these public methods are -available through an MBean.
    -The class for Catalina 5.0 is named CatalinaJWebContainerServiceImpl -and for Jetty 5.5 it is JettyJWebContainerServiceImpl. -For Catalina 5.5, the name of the package is -org.objectweb.jonas.web.catalina55 instead of -org.objectweb.jonas.web.catalina50.
    -To integrate a new web container, a new package -org.objectweb.jonas.web.xxx should be added and the service -class should extend AbsJWebContainerServiceImpl class.

    - -

    For Tomcat, there are wrapper -classes to use a specific -classloader (Tomcat Classloader) instead of using the default classloader -of all services running in JOnAS which is commons -classloader.
    -

    - -

    Common tools to unpack wars, used by all implementations are in the -package org.objectweb.jonas.web.lib

    - -

    There is another package for all the stuff concerning the parsing and the -handling of web deployment descriptors. This is the package org.objectweb.jonas_web.deployment -which is composed of api package (used by web container service) and the -other subpackages are only used internally for parsing and managing the XML -files.
    -The only import which should occur within a web container service -implementation should be the api package and not the other subpackages. This -allows to change the implementation of parsing/analyzing XML files without -changing the services code.

    - -

    Ear Service

    - -

    This service is used for deploying complete J2EE applications, i.e. -applications packaged in EAR files, which themselves contain ejb-jar files -and/or war files. This service handles the EAR files and delegates the -deployment of the war files to the WEB Container service and the ejb-jar -files to the EJB Container service. It handles creating the appropriate class -loaders, in order for the J2EE application to execute properly.

    - -

    For deploying J2EE applications, JOnAS must be configured to launch the -EAR service and to specify the set of EAR files to be loaded. EAR files can -also be deployed at server runtime using the JOnAS administration tools.

    - -

    This service is implemented by the EarServiceImpl -class. This class is linked to other services which should be started. The -ear service needs an EJB service and a WebContainer service to allow to send -EJBs of an EAR to the EJB service and to send web components to the web -container service.
    -This service is pretty simple, it unpacks EAR, resolves "Class-Path:" entries -of MANIFEST files and ejb-link elements, and set up JACC security. Once -everything is correctly setup, it send components to each service (ejb or -web) which will deploy them by using information provided by the Ear -service.

    - -

    As explained in web container service, all the parsing/handling of XML -deployment descriptors is done in another package which is for Ear service -the org.objectweb.jonas_ear.deployment -package.

    - -

    Transaction Service

    - -

    This service encapsulate a Java Transaction Monitor called JOTM (a project from ObjectWeb). It is a -mandatory service which handles distributed transactions. It provides -transaction management for EJB components as defined in their deployment -descriptors. It handles two-phase commit protocol against any number of -Resource Managers (XA Resources). For J2EE, a transactional resource may be a -JDBC connection, a JMS session, or a J2EE CA Resource Adapter connection. The -transactional context is implicitly propagated with the distributed requests. -The Transaction Monitor can be distributed across one or more JOnAS servers; -thus a transaction may involve several components located on different JOnAS -servers. This service implements the JTA 1.0.1 specification, thus allowing -transactions from application components or from application clients to be -explicitly started and terminated. Starting transactions from application -components is only allowed from Web components, session beans, or -message-driven beans (only these two types of beans, which is called -"Bean-managed transaction demarcation").

    - -

    The Transaction service may be found in the org.objectweb.jonas.jtm -package.

    - -

    Database Service

    - -

    This service is responsible for handling Datasource objects. A Datasource -is a standard JDBC administrative object for handling connections to a -database. The Database service creates and loads such datasources on the -JOnAS server. Datasources to be created and deployed can be specified at -JOnAS configuration time, or they can be created and deployed at server -runtime using the JOnAS administration tools. The Database service is also -responsible for connection pooling; it manages a pool of database connections -to be used by the application components, thus avoiding many physical -connection creations, which are time-consuming operations.

    -

    The database service should now be replaced by the JDBC Resource Adapter, to be deployed -by the J2EE CA Resource Service (see below), which additionally provides JDBC -PreparedStatement pooling. - -

    The Database Service is implemented in the org.objectweb.jonas.dbm -package.

    - -

    Messaging Service

    - -

    For supporting Message-driven Beans and JMS operations coded within -application components, the JOnAS application server relies on a JMS -implementation. JOnAS makes use of a third-party JMS implementation; -currently the JORAM open source -software is integrated and delivered with JOnAS, the SwiftMQ product has also been used in -previous versions of JOnAS, and other JMS provider implementations can easily -be integrated. JORAM provides several noteworthy features: in particular, -reliability (with a persistent mode), distribution (transparently to the JMS -client, it can run as several servers, thus allowing load balancing), and the -choice of TCP or SOAP as communication protocol for transmitting messages.

    - -

    The JMS service is in charge of launching (or establishing connection to) -the integrated JMS server, which may or may not run in the same JVM as JOnAS. -It also provides connection pooling and thread pooling (for Message-driven -Beans). Through this service, JOnAS provides facilities to create -JMS-administered objects such as the connection factories and the -destinations, either at server launching time or at runtime using the JOnAS -administration tools.

    - -

    This service is implemented in the org.objectweb.jonas.jms -package.

    - -

    Note that the same function of JMS implementation integration should now -be achieved through a Resource Adapter, to be deployed by the J2EE CA -Resource Service (see below). Such a Resource Adapter (J2EE CA 1.5) is provided for -JORAM. The Messaging service will become deprecated.

    - -

    J2EE CA Resource Service

    - -

    The J2EE Connector Architecture (J2EE CA) allows the connection of -different Enterprise Information Systems (EIS) to a J2EE application server. -It is based on the Resource Adapter (RA), an architecture component -comparable to a software driver, which connects the EIS, the application -server, and the enterprise application (J2EE components). The RA is generally -provided by an EIS vendor and provides a Java interface (the Common Client -Interface or CCI) to the J2EE components for accessing the EIS (this can also -be a specific Java interface). The RA also provides standard interfaces for -plugging into the application server, allowing them to collaborate to keep -all system-level mechanisms (transactions, security, and connection -management) transparent from the application components.

    -The application performs "business logic" operations on the EIS data using -the RA client API (CCI), while transactions, connections (including pooling), -and security on the EIS are managed by the application server through the RA -(system contract). - -

    The JOnAS Resource service is in charge of deploying J2EE CA-compliant -Resource Adapters (connectors), packaged as RAR files, on the JOnAS server -(such connectors will be loaded in the Application classloader). RAR files -can also be included in EAR files, in which case the connector will be loaded -by classloader of the EAR. Once Resource Adapters are deployed, a connection -factory instance is available in the JNDI namespace to be looked up by -application components.

    - -

    The Resource Service is implemented in the org.objectweb.jonas.resource -package.

    - -

    A J2EE CA 1.5 Resource Adapter for JDBC is available with JOnAS. It can -replace the current JOnAS database service for plugging JDBC drivers and -managing connection pools. It also provides JDBC PreparedStatement -pooling.

    - -

    A J2EE CA 1.5 Resource Adapter for JMS is available with JOnAS. It can -replace the current JOnAS Messaging service for plugging JORAM.

    - - -

    Security Service

    - -

    This service implements the authorization mechanisms for accessing J2EE -components, as specified in the J2EE specification.

    - -

    In JOnAS, the mapping between roles and user identification is done in the -user identification repository. This user identification repository can be -stored either in files, in a JNDI repository (such as LDAP), or in a -relational database. This is achieved through a JOnAS implementation of the -Realm for each Web container and through the JAAS login modules for Java -clients. These Realms use authentication resources provided by JOnAS, which -rely either on files, LDAP or JDBC. These realms are in charge of propagating -the security context to the EJB container during EJB calls. JAAS login -modules are provided for user authentication of Web Container and Java -clients. Certificate-based authentication is also available, with -CRLLoginModule login module for certificate revocation.

    - -

    JOnAS also implements the Java Authorization Contract for Containers (JACC -1.0) specification, allowing authorizations to be managed as java security -permissions, and providing the ability to plug any security policy -provider.

    - -

    More details about security handling within JOnAS is provided within the -Configuring -Security section of the JOnAS Configuration Guide.

    - -

    There are 3 major packages for implementing the security in JOnAS.

    -
      -
    1. The first package is org.objectweb.security - which is composed of two important classes. A SecurityContext class which - contains Principal names, J2EE roles, etc. and the SecurityCurrent which - manages the current SecurityContext of each J2EE component. - SecurityContext object is associated to a ThreadLocal object. There is an - exception for the client container: In this case, the SecurityContext is - available for all the JVM and not only for one thread. This allows to - have multi-thread applications like swing/awt applications to have always - a SecurityContext object.
      -
      2. -
    2. The second package is org.objectweb.jonas.security.
      - This package contains the implementation of the security service, the - JAAS login modules (and the JAAS callbacks) provided by JOnAS. The - classes used to interact with external authentication like - Datasource/LDAP/Files are present in the realm subpackage. It contains - also RMI interceptors for JOnAS protocols like rmi/jrmp, - rmi/iiop. For IIOP protocol, this package contains CSIv2 interceptors to - allow security propagation over iiop which is required for J2EE 1.4. - (org.objectweb.jonas.security.iiop).
      - To be compliant with J2EE 1.4, JOnAS setup the JACC provider with classes - which are in the package org.objectweb.jonas.security.jacc. - Note that this package doesn't contains the JACC provider, but only the - classes to configure the JACC provider which is set by JOnAS - administrator. The last subpackage and not the least is the subpackage - implementing the specific Realm for Tomcat or Jetty by relying on - existing JOnAS classes. It consists in simple wrapper classes. These - classes are in package - org.objectweb.jonas.security.realm.web.xxx where xxx is - catalina50, catalina55, jetty50, etc.
      -
      3. -
    3. The third package is the org.objectweb.jonas_lib.security - package.
      - This package contains the JACC provider which is used by default. Users - can use their own JACC provider by setting properties at the JVM startup. - The classes in this package implement/extend classes defined by the JSR 115
      4. -
    - - - -

    Management Service

    - -

    The Management service is needed to administrate a JOnAS server from the -JOnAS administration console. Each server running this service is visible -from the administration console. This service is based on JMX. Standard -MBeans are defined within the JOnAS application server; they expose the -management methods of the instrumented JOnAS server objects such as services, -containers, the server itself. These MBeans implements the management model -as specified in the J2EE Management Specification. The Management service -runs a JMX server - , and is implemented in the org.objectweb.jonas.jmx -package. The MBeans of the JOnAS server are registered within this JMX -server. The JOnAS administration console is a Struts-based Web application -(servlet/JSP) that accesses the JMX server to present the managed features -within the administration console. Thus, through a simple Web browser, it is -possible to manage one or several JOnAS application servers. The -administration console provides a means for configuring all JOnAS services -(and making the configuration persistent), for deploying any type of -application (EJB-JAR, WAR, EAR) and any type of resource (DataSources, JMS -and Mail connection factories, J2EE CA connectors), all without the need to -stop or restart the server. The administration console displays information -for monitoring the servers and applications, such as used memory, used -threads, number of EJB instances, which component currently uses which -resources, etc.. When Tomcat is used as Web Container, the Tomcat Management -is integrated within the JOnAS console. A Management EJB (MEJB) is also -delivered, providing access to the management features, as specified in the -J2EE Management Specification.

    - -

    Discovery Service

    - -

    The discovery service is used to support domain management. A JOnAS -management domain is composed of a set of JOnAS servers that are running -under the same management authority and are identified by a domain name. The -servers in a domain may be administred by a management application running on -one server in the domain; this is the master server. The managed servers are -slaves. The discovery service is based on a mutlicast communication -infrastructure allowing message broadcasting in order to publish the -connector-server addresses and state changes of the servers in the domain. -The master servers listen to these discovery messages. Moreover, they are -able to broadcast messages asking the servers in the domain to identify -themselves

    - -

    Mail Service

    - -

    A J2EE application component can send e-mail messages using JavaMailTM. The -Mail service of the JOnAS application server provides the necessary resources -to such application components. The Mail service creates mail factories and -registers these resources in the JNDI namespace in the same way that the -database service or the JMS service creates Datasources or -ConnectionFactories and registers these objects in the JNDI namespace. There -are two types of mail factories: javax.mail.Session and -javax.mail.internet.MimePartDataSource.

    - -

    The Mail service is implemented in the org.objectweb.jonas.mail -package.

    - -

    WebServices Service

    - -

    This service is implemented on top of AXIS and is used for the deployment of -Web Services. Only a very small part of the deployment work is done during -the installation time: most of the work is done offline with a tool like -GenIC, WsGen. -
    -

    - -

    Offline ws processing (WsGen)
    -

    -
    -WsGen -is the offline tool that is responsible of all generation operations for a -given archive. It can process EjbJar, WebApp, AppClient and Ear. It will -unpack the input archive if needed (ear/war case), read the deployment -descriptor of the given component and will generate artifact accordingly. 3 -types of artifacts can be generated:
    - -
      -
        -
          -
        • axis specific deployment descriptor (*.wsdd) for client and server - side
          • -
        • java classes representing client WS Stubs and some Helper classes - for complex types
          • -
        • new archives: a configured webapp for each EjbJar with WS, and an - Ear that wraps EjbJar + generated WebApp
          • -
        -
      -
    - -

    - -

    WsGen will build server side artifacts if a webservices.xml descriptor is -found in the archive (can be an EjbJar or a WebApp):
    -

    -
      -
        -
          -
        • If the processed archive is an EjbJar, a WebApp will be generated - and its web.xml customized for Axis, a Wrapping Ear will be generated - too (only if the EjbJar is not part of an application yet)
          • -
        • a server side axis deployment descriptor is generated accordingly - to the WSDL, Mapping file and Service Endpoint Interface
          • -
        -
      -
    - -

    - -

    Client side artifacts are generated only if WsGen find some service-ref -elements in web.xml, ejb-jar.xml or application-client.xml:
    -

    -
      -
        -
          -
        • Service implementation + Stub(s) implementation of the SEI(s) are - generated from WSDL + mapping file (we use EWS: a specialized WSDL2Java tool - that looks inside jaxrpc mapping file)
          -
          • -
        • client side axis deployment descriptor is generated for JAX-RPC - Handler setup and operations descriptions
          • -
        • for each serialized bean, an Helper class is built to help during - ser/deser process
          • -
        -
      -
    - -

    Runtime processing

    -
      -
        -
      • Webservice service
        • -
      -
    -This JOnAS service is used to set some Axis property at JOnAS startup and is -in charge of some webservice specific deployment operations:
    - -
      -
        -
          -
        • Endpoint URL creation from hostname, HTTP port and webapp - configuration
          • -
        • WSDL Publication with WSDLHandler: J2EE server are required to - publish all WSDL definitions of exposed components, from now, JOnAS - can publish the WSDLs in the file system or inside a registry (jUDDI, - ...). Notice that Registry publication is a minimalist - implementation
          • -
        -
      -
    -
      -
        -
      • component context update
        • -
      -
    -Each component that want to be client of a webservices has to declare a -dependency on that webservice using service-ref (like ejb-ref, ...). At -deploy time, each container (web, ejb and client) is responsible to create -and fill the Context of each deployed component. Each container has a -createCompponentContext() method (web, ejb, client) that have been updated to -handle service-ref.
    -Each service-ref is bound in the Component Context as a Reference configured -to permit the javax.xml.rpc.Service creation (using an ObjectFactory) when -the client performs the lookup.
    - -
      -
        -
      • WSDL publication by URL
        • -
      -
    -Besides WSDL publication done by the ws service with WSDLHandler, Axis give -us an elegant way to obtain the service WSDL with just a simple URL: you just -have to append to the endpoint URL the String ?WSDL to retrieve the desired -WSDL.
    -In JOnAS, this idea has been reused and enhanced for allowing handling of -import/include of WSDL definition to other XML Document (WSDL or Schema) and -this, recursivly ! Append ?JWSDL (Notice the J !) to your endpoint URL and -you'll see the WSDL packaged inside your webapp (no runtime generation) with -some updates (URL endpoints + imports/includes).
    -
    - - -

    2 main packages:
    -

    -
      -
    1. org.objectweb.jonas_ws: contains all XML descriptors handling code - (deployment/xml deployment/api + deployment/lib) and WsGen code
      2. -
    2. org.objectweb.jonas.ws: contains runtime classes WSService + Axis glue - for JOnAS
      3. -
    - -

    - -

    Webservices related documentation :
    -

    - - -

    - -

    JOnAS Management Architecture

    - -

    As previously explained, JOnAS Management is based on JMX. Standard MBeans -are defined within the JOnAS application server; they expose the management -methods of the instrumented JOnAS server objects such as services, -containers, the server itself. They are registered within the JMX server -embedded within the JOnAS Management Service, and may then be accessed by any -JMX client.

    - -

    - -

    JOnAS JMX Management

    - -

    - -

    Related documentation:

    - -

    Domain -Management in JOnAS (explain the domain management feature of JOnAS, -available from JOnAS 4.4 only)

    - -

    Discovery -Service Configuration (description of the discovery service, used for -domain support, available from JOnAS 4.4 only)

    - -

    JSR160 -Support in JOnAS (explain the principles to remotely access to the JOnAS -MBeans server, e.g. for remote management, used by the domain management -features)

    - -

    Administration -Guide (JonasAdmin console principles, MEJB description)

    - -

    Working with -Management Beans (key and short document to understand JOnAS management -principles)

    - -

    JOnAS -and JMX, registering and manipulating MBeans (contributed document -explaining how to register applicative MBeans within the JOnAS JMX server)

    - -

    - -

    Clustering and Performance

    - -

    Clustering for an application server generally makes use of three -features: Load Balancing (LB), High Availability (HA) and Failover. Such -mechanisms can be provided at the Web container level by dispatching requests -to several Servlet/JSP engine instances, at the EJB container level by -dispatching EJB requests to several EJB container instances, and at the -database level by using several databases. A replicated JNDI naming is also -necessary.

    - -

    JOnAS provides Load Balancing, HA, and Failover at the WEB container level -using the Apache Tomcat mod_jk plugin and an HTTP in memory -session-replication mechanism provided with Tomcat. The plugin dispatches -HTTP requests from the Apache web server to Tomcat instances running as JOnAS -web containers. Server fluctuations are automatically taken into account. -This plugin supports round-robin and weighted round-robin load-balancing -algorithms, with a sticky session option.

    - -

    Load balancing and HA are provided at the EJB container level in JOnAS. -Operations invoked on EJB Home interfaces (EJB creation and retrieval) are -dispatched on the nodes of the cluster. The mechanism is based on a -"clustered-aware" replicated JNDI registry using a Clustered remote Method -Invocation protocol (CMI). The stubs contain the knowledge of the cluster and -implement the load-balancing policy, which may be random, round-robin and -weighted round-robin. Failover at the EJB level will be provided by -implementing a stateful session bean state replication mechanism.

    - -

    The JOnAS clustering architecture is illustrated in the following -figure.

    -Clustered Architecture - -

    JOnAS provides documentation for configuring such an architecture, the JOnAS -Clustering Document.

    - -

    The use of the C-JDBC ObjectWeb -project offers load balancing and high availability at the database level. -The use of C-JDBC is transparent to the application (in our case to JOnAS), -since it is viewed as a standard JDBC driver. However, this "driver" -implements the cluster mechanisms (reads are load-balanced and writes are -broadcasted). The database is distributed and replicated among several nodes, -and C-JDBC load balances the queries between these nodes. An evaluation of -C-JDBC using the TPC-W benchmark on a 6-node cluster has shown performance -scaling linearly up to six nodes.

    - -

    In addition to clustering solutions, JOnAS provides many mechanisms, -intrinsic to the JOnAS server, for being highly scalable and efficient. This -includes the following:

    -
      -
    • A pool of stateless session bean instances
      • -
    • A pool of entity bean instances, configurable for each entity bean - within its deployment descriptor
      • -
    • Activation/passivation of entity beans, passivation can be controlled - through the management console
      • -
    • Pools of connections, for JDBC, JMS, J2EE CA connectors. For database - connection pooling, many tuning capabilities are provided: see the - section JDBC connection pool configuration of the Configuring - JDBC DataSource section of the JOnAS configuration guide.
      • -
    • A pool of threads for message-driven beans
      • -
    • Session bean timeout can be specified at deployment
      • -
    • A "shared" flag in the specific deployment descriptor of an entity bean - indicates whether the persistent representation of this entity bean is - shared by several servers/applications, or whether it is dedicated to the - JOnAS server where it is loaded. In the latter case, the optimization - performed by JOnAS consists of not reloading the corresponding data - between transactions.
      • -
    • The usual EJB 1.1 "isModified" (or "Dirty") mechanism is available for - avoiding storage of unmodified data.
      • -
    • An optimization called "Data Prefetching" provides JDBC resultsets - re-use by the EJB container (this optimization reduces the number of SQL - statements executed by the EJB container)
      • -
    • Adapting the entity bean lock policy to the application, the following - policies are available: container-serialized, container-read-committed, - container-read-uncommitted, database, read-only.
      • -
    - -

    Optimizations related to entity beans are described in the Tuning -Container for Entity Bean Optimizations section of the JOnAS -documentation. More details about available CMP tuning features are provided -below.

    - -

    CMP Tuning Features

    - -

    JOnAS provides many CMP tuning features, which may be specified through -server specific deployment elements, at the entity bean level (so that one -policy per component may be defined).

    - -

    - -

    1) Lock Policy (Concurrent Access)

    - -

    The <lock-policy> elements may have the following value:

    -
      -
    1. Container-serialized (default): The container ensures - the transaction serialization. This policy is suitable for most entity - beans, particularly if the bean is accessed only from this container - (shared = false).
      2. -
    2. Container-read-committed: This policy is similar to - container-serialized, except that accesses outside transaction do not - interfere with transactional accesses. This can avoid deadlocks in - certain cases, when accessing a bean concurrently with and without a - transactional context. The only drawback of this policy is that it - consumes more memory (2 instances instead of 1).
      3. -
    3. Container-read-uncommitted: all methods share the same - instance (like container-serialized), but there is no synchronization. - For example, this policy is of interest for read-only entity beans, or if - the bean instances are very rarely modified. It will fail if 2 or more - threads try to modify the same instance concurrently.
      4. -
    4. Database: Let the database deal with transaction - isolation. With this policy, you can choose the transaction isolation in - your database. This may be of interest for applications that heavily use - transactional read-only operations, or when the flag shared is needed. It - does not work with all databases and is not memory efficient.
      5. -
    5. Read-only: The bean is never written to database. If - the bean is shared, the bean state is read from database regularly.
      6. -
    - -

    Note: If you deploy CMP1 beans, you should use the default policy only -(container-serialized), unless your beans are "read-only". In this latter -case, you can use container-read-uncommitted.

    - -

    2) Database dedicated access

    - -

    JOnAS can do some data access optimization if the persistent state of an -entity bean is accessed only by the JOnAS server. The optimization consists -in not re-reading the bean state before starting a new transaction if the -bean is already in memory. Indeed, as nobody else can modify the state of the -bean on the persistent support, it is not necessary to re-read it. This may -be specified to JOnAS by using the <shared> element -and setting it to false. If the <shared> element is set to true, it -means that the bean persistent state can be accessed outside the JOnAS -Server, and then the optimization cannot be done. The default value is false -if lock-policy is container-serialized, and true in the other cases.

    - -

    3) Data pre-fetching

    - -

    The <prefetch> element is a CMP2-specific option. -The default is false. This can be set to true if it is desirable to have a -cache managed after finder methods execution, in order to optimize further -accesses, inside the same transaction.

    - -

    Important notes:

    -
      -
    • The prefetch is not be used for methods that have no transactional - context.
      • -
    • It is impossible to set the prefetch option if the lock policy is - container-read-uncommitted.
      • -
    - -

    4) Instances pooling / caching

    - -

    Four elements allow specifying entity beans instances management.

    - -

    - The first one, <max-cache-size>, is an integer -value that represents the maximum number of instances in memory. The purpose -of this value is to keep JOnAS scalable. The default value is "no limit". To -save memory, this value should be set very low if you know that instances -will not be reused.

    - -

    - The second one, <min-pool-size>, is an integer -value representing the number of instances that will be created in the pool -when the bean is loaded. This will improve bean instance creation time, at -least for the first instances. The default value is 0.

    - -

    - The third one, <passivation-timeout>, allows -tuning the entity bean instances passivation activity (saving memory by -sending instances on the persistent support), in accordance with the previous -persistence tuning elements. Entity bean instances are passivated at the end -of each transaction and reactivated at the beginning of the next transaction, -when the shared flag has been set to true. In case shared has been set to -false, a passivation will occur only if max-cache-size has been reached. In -the event that these instances are accessed outside a transaction, their -state is kept in memory to improve performance. However, a passivation will -occur in three situations:

    -
      -
    1. When the bean is unloaded from the server, at least when the server is - stopped.
      2. -
    2. When a transaction is started on this instance.
      3. -
    3. After a configurable timeout. If the bean is always accessed with no - transaction, it may be prudent to periodically store the bean state on - disk.
      4. -
    - -

    - The fourth one is <inactivity-timeout>: Bean -passivation sends to persistent storage the state of the bean and removes -from memory only the bean instance objects holding this state. All container -objects handling bean access (remote object, interceptors ...) are kept in -memory so that future access will work, only requiring a reload operation -(getting the state). You may want to save more memory and completely remove -the bean instance from memory, this may be achieved through the -<inactivity-timeout> element. This element is used to save memory when -a bean has not been used for a long time. After the time specified, in -seconds, and if the bean has not been used meanwhile, all its container -objects are removed from the server. If a client has kept a reference on a -remote object, it will get an exception if it tries to use it.

    - -

    5) Db Connections pooling

    - -

    For database access, JOnAS provides a sophisticated connection pools -management. See the Configuring -JDBC Datasource section of the JOnAS Configuration Guide (available soon -for the JDBC connector). Connection pooling saves the high cost of physical -connection creation by maintaining a pool of such connections. Connection -pools may be tuned using the following properties:

    -
      -
    • Conmaxage: number of minutes a connection can be kept - in the pool. After this time, the connection will be closed, if - minconpool limit has not been reached.
      • -
    • Maxopentime: Maximum time (in mn) a connection can be - left busy. If the caller has not issued a close() during this time, the - connection will be closed automatically.
      • -
    • Minconpool: Minimum number of connections in the pool. - Setting a positive value here ensures that the pool size will not go - below this limit during the datasource lifetime.
      • -
    • Maxconpool: Maximum number of connections in the pool. - Limiting the max pool size avoids errors from the database.
      • -
    • Samplingperiod: Sampling period for JDBC monitoring. - nb of seconds between 2 measures.
      • -
    • Maxwaittime: Maximum time (in seconds) to wait for a - connection in case of shortage. Valid only if maxconpool has been - set.
      • -
    • Maxwaiters: Maximum of concurrent waiters for a JDBC - Connection. Valid only if maxconpool has been set.
      • -
    - -

    6) PreparedStatement pooling

    - -

    The JOnAS JDBC connector manages pools of JDBC PreparedStatements.

    - -

    - -

    Sun, Java, and all -Java-based trademarks are trademarks or registered trademarks of Sun -Microsystems, Inc. in the U.S. and other countries.

    - - diff --git a/jonas_doc/olddoc/howto/JonasMBeansHowTo.html b/jonas_doc/olddoc/howto/JonasMBeansHowTo.html deleted file mode 100644 index b2e3f43e5a5d4b004e1ea61573d70548955a369b..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/JonasMBeansHowTo.html +++ /dev/null @@ -1,419 +0,0 @@ - - - - - - JOnAS and JMX, registering and manipulating MBeans - - - - -

    Howto: JOnAS and JMX, registering and manipulating MBeans

    -

    By Jonny Way.

    -

    Introduction

    - -

    JMX (Java Management eXtensions) is an API for managing, among other -things, J2EE applications. JOnAS (version 4 and above) integrates the MX4J -open-source JMX server and registers a number of MBeans. The web-based -JonasAdmin application acts as a JMX client, enabling viewing and -manipulation of these MBeans.

    - -

    It maybe desirable for an application to expose its own MBeans via the JMX -server to allow application management (using, for example, MC4J). JOnAS -currently does not provide a prebuilt method for registering MBeans with its -JMX server. The intent of this document is to illustrate one method of registering -application-specific MBeans with the JOnAS JMX server based on the m-let -service.

    - -

    ServletContextListener

    - -

    The basic task of registering an MBean with the JOnAS JMX server is -accomplished by the following implementation of the ServletContextListener -interface. This implementation reads a number of MLet files, which specify the -MBeans to be registered, and attempts to register those beans during the web -application context initialization.

    -
                    
-import java.net.MalformedURLException;
-import java.net.URL;
-import java.util.Iterator;
-import java.util.ArrayList;
-import java.util.List;
-import java.util.Set;
-import java.util.StringTokenizer;
-
-import javax.management.InstanceAlreadyExistsException;
-import javax.management.InstanceNotFoundException;
-import javax.management.ReflectionException;
-import javax.management.MBeanServer;
-import javax.management.MBeanException;
-import javax.management.MBeanRegistrationException;
-import javax.management.MBeanServerFactory;
-import javax.management.MalformedObjectNameException;
-import javax.management.NotCompliantMBeanException;
-import javax.management.ObjectInstance;
-import javax.management.ObjectName;
-import javax.management.loading.MLet;
-import javax.management.loading.MLetMBean;
-import javax.servlet.ServletContextEvent;
-import javax.servlet.ServletContext;
-import javax.servlet.ServletContextListener;
-
-import org.apache.log4j.Logger;
-
-/**
- * ServletContextListener designed to register JMX MBeans into 
- * an existing JMX server when the application starts up. The
- * MBeans to be loaded are specified in the MLet files whose
- * names are given in the servlet context parameter with the name mletFiles,
- * in a semi-colon delminated list (although this is not really
- * needed as multiple mlets can be specifyed in one file, it might
- * be useful). Note that the filename are relative to the WEB-INF
- * directory of the servlet context being listened to.
- * 
- * Note, that this listener should precede (in web.xml) any other that depend
- * on the MBeans being registered. 
- * 
- * Note that the MBean registration is sensitive to classloader issues. For
- * example, when registering the MBeans in the JMX server provided by
- * the Jonas application server any libraries required by the MBeans need
- * to be in the central lib directory (lib/ext).
- * 
- * 
- * @author Jonny Wray
- *
- */
-public class MBeanRegistrationListener implements ServletContextListener {
-        
-        private static final String MLET_DOMAIN = "MBeanRegistrationListener";
-        private static final String MLET_BEAN_NAME = MLET_DOMAIN+":Name=MLet";
-        private static final String MLETFILE_INITPARAM_NAME = "mletFiles";
-        private static final Logger log = Logger.getLogger(MBeanRegistrationListener.class);
-        
-        
-        private MBeanServer lookForExistingServer(){
-                List mbeanServers = MBeanServerFactory.findMBeanServer(null);
-                if(mbeanServers != null && mbeanServers.size() > 0){
-                        return (MBeanServer)mbeanServers.get(0);
-                }
-                return null;
-        }
-        
-        private MBeanServer getMBeanServer(){
-                MBeanServer server = lookForExistingServer();
-                if(server == null){
-                        server = MBeanServerFactory.createMBeanServer(MLET_DOMAIN);
-                }
-                return server;
-        }
-        
-        
-        public void contextDestroyed(ServletContextEvent arg0) {
-                log.info("Destroy event");
-                // Anything that needs to be done here on deregistering of the
-                // web application?
-        }
-
-        
-        private List getMLetURLs(String filenames){
-                List urls = new ArrayList();
-                StringTokenizer tok =
-                        new StringTokenizer(filenames, ";");
-                while(tok.hasMoreTokens()){
-                        String filename = tok.nextToken();
-                        URL configURL = Thread.currentThread().getContextClassLoader().getResource(filename);
-                        if(configURL == null){
-                                log.error("Cound not load MLet file resource from "+filename+" using current thread context classloader");
-                        }
-                        else{
-                                urls.add(configURL);
-                        }
-                }
-                return urls;
-        }
-        
-        private List getMLetURLs(ServletContext context, String filenames){
-                List urls = new ArrayList();
-                StringTokenizer tok =
-                        new StringTokenizer(filenames, ";");
-                while(tok.hasMoreTokens()){
-                        String filename = "/WEB-INF/"+tok.nextToken();
-                        URL configURL = null;
-                        try {
-                                configURL = context.getResource(filename);
-                        } 
-                        catch (MalformedURLException e) {
-                                log.error("URL for "+filename+" is malformed", e);
-                        }
-                        if(configURL == null){
-                                log.error("Cound not find MLet file resource from "+filename+" in servlet context");
-                        }
-                        else{
-                                urls.add(configURL);
-                        }
-                }
-                return urls;
-        }
-        
-        /**
-         * Dynamically register the MBeans specified in the list
-         * of MLet files (relative to /WEB-INF/) specified in servlet context parameter
-         * mletFiles as a semi-colon deliminated list of file names.
-         * 
-         * The algorithm looks for already running JMX servers and uses
-         * the first it comes across. If no servers are running, then
-         * it creates one.
-         * 
-         * Note, the interface does not define any exceptions to be
-         * thrown. Currently, any exceptions thrown during registration
-         * are logged at error level and then ignored. This seems 
-         * reasonable, as these may or may not be a fatal event. In 
-         * this way the registration process reports its failure and
-         * the application context initialization continues.
-         */
-        public void contextInitialized(ServletContextEvent arg0) {
-                log.info("Initializing event");
-                String filenames = arg0.getServletContext().getInitParameter(MLETFILE_INITPARAM_NAME);
-                if(filenames != null && filenames.length() > 0){
-                        MBeanServer server = getMBeanServer();
-                        if(server != null){
-                                try{
-                                        ObjectName name = new ObjectName(MLET_BEAN_NAME);
-                                        if(!server.isRegistered(name)){
-                                                log.info("Creating new MLetMBean for dynamic registration");
-                                                MLetMBean mletService = new MLet();
-                                                server.registerMBean(mletService, name);
-                                        }
-                                        List urls = getMLetURLs(arg0.getServletContext(), filenames);
-                                        for(int i=0;i < urls.size();i++){
-                                                URL url = (URL)urls.get(i);
-                                                try {
-                                                        log.info("Registering MBeans from MLet file "+url);
-                                                        Set loadedMBeans = (Set)server.invoke(name, "getMBeansFromURL", 
-                                                                        new Object[]{url}, new String[]{URL.class.getName()});
-        
-                                                        processRegisteredMBeans(loadedMBeans);
-                                                } 
-                                                catch (InstanceNotFoundException e) {
-                                                        log.error("Unable to register MBeans from MLet file "+url, e);
-                                                } 
-                                                catch (MBeanException e) {
-                                                        log.error("Unable to register MBeans from MLet file "+url, e);
-                                                } 
-                                                catch (ReflectionException e) {
-                                                        log.error("Unable to register MBeans from MLet file "+url, e);
-                                                }
-                                        }
-                                }
-                                catch(MalformedObjectNameException e){
-                                        log.error("Unable to register the MLetMBean", e);
-                                }
-                                catch(NotCompliantMBeanException e){
-                                        log.error("Unable to register the MLetMBean", e);
-                                }
-                                catch(MBeanRegistrationException e){
-                                        log.error("Unable to register the MLetMBean", e);
-                                }
-                                catch(InstanceAlreadyExistsException e){
-                                        log.error("Unable to register the MLetMBean", e);
-                                }
-                        }
-                        else{
-                                log.error("MBeanServer not found and could not be created. Not registering MBeans.");
-                        }
-                }
-                else{
-                        log.error("No mletFiles servlet context parameter found.");
-                }
-        }
-        
-        private void processRegisteredMBeans(Set loadedMBeans) {
-                log.debug("Loaded beans: "+loadedMBeans.size());
-                Iterator it = loadedMBeans.iterator();
-                while(it.hasNext()){
-                        Object o = it.next();
-                        if(o instanceof ObjectInstance){
-                                ObjectInstance inst = (ObjectInstance)o;
-                                log.info("Registered: "+inst.getObjectName());
-                        }
-                        else if(o instanceof Throwable){
-                                Throwable err = (Throwable)o;
-                                log.error("Error registering MBeans", err);
-                        }
-                }
-        }
-
-}
-
    - - -

    Configuration

    - -

    In order to use the above ServletContextListener, it must be configured -in the web.xml of the web application that wants to register the MBeans. For -example, the following lines added to the web.xml will result in the -registeration of the MBeans specified in the application.mlet file under the -WEB-INF directory. Multiple MLet files can be specified in a comma-separated -list.

    -
    
-        <context-param>
-                <param-name>mletFiles</param-name>
-                <param-value>application.mlet</param-value>
-        </context-param>
-
-        <listener>
-                <listener-class>net.fiveprime.jmx.MBeanRegistrationListener</listener-class>
-        </listener>
-
    - - -

    An example MLet file to load an extension (detailed below) of the -HibernateService MBean is:

    -
    <mlet code="ConfigurableHibernateService"
-                name="HibernateService:Name=HibernateService"
-                archive="mbeans.jar">
-        <arg type="java.lang.String" value="hibernate.cfg.xml">
-        <arg type="java.lang.String" value="hibernate/HibernateSessionFactory">
-        <arg type="java.lang.String" value="DefaultDS">
-</mlet>
-
    - -

    Library Dependences

    - -

    Registration of MBeans results in their construction by the JMX server. As -such, any classes the MBean is dependent on must be available to the JMX -server, in lib/ext.

    - -

    HibernateService Extension

    - -

    The Hibernate distribution provides an implementation of -HibernateServiceMBean in the class HibernateService. In the MLet file above, -an extension of this class is specified that allows the HibernateService to be -configured from an external file, such as the standard hibernate.cfg.xml -file. There are a number of situations where it is desirable to use the Hibernate mapped -classes outside of Jonas running a JMX server. This allows the -Hibernate mapping files and properties to be specified in one place and used in multiple -situations. If this is not needed, then the HibernateService class can be -used directly.

    -
    
-import java.io.IOException;
-import java.net.URL;
-import java.util.ArrayList;
-import java.util.HashMap;
-import java.util.Iterator;
-import java.util.List;
-import java.util.Map;
-
-import net.sf.hibernate.HibernateException;
-import net.sf.hibernate.jmx.HibernateService;
-
-import org.apache.commons.digester.Digester;
-import org.apache.commons.logging.Log;
-import org.apache.commons.logging.LogFactory;
-import org.xml.sax.SAXException;
-/**
- * Extension of the HibernateService class to add configuration
- * ability from a Hibernate XML configuration file.
- * 
- * @author Jonny Wray
- *
- */
-public class ConfigurableHibernateService extends HibernateService {
-
-        private static Log log = LogFactory.getLog(ConfigurableHibernateService.class);
-        
-        /**
-         * Configure this HibernateService from an XML file
-         * 
-         * @param filename The Hibernate XML configuration file, for example hibernate.cfg.xml
-         * @param jndiName The JNDI name that the session factory will be registered under
-         * @param datasourceName The name of the datasource used by the session factory
-         * @throws HibernateException If there's a problem reading the configuration file
-         */
-        public ConfigurableHibernateService(String filename, String jndiName, String datasourceName) 
-                throws HibernateException{
-                
-                init(filename, jndiName, datasourceName);
-                start();
-        }
-        
-        private void init(String filename, String jndiName, String datasourceName) throws HibernateException {
-                if(log.isDebugEnabled()){
-                        log.debug("Configuring Hibernate JMX MBean with filename "+filename+
-                                ", JNDI name "+jndiName+" and datasource "+datasourceName);
-                }
-                try{
-                        URL url = this.getClass().getClassLoader().getResource(filename);
-                        Digester mappingDigester = configureMappingDigester();
-                        List results = (List)mappingDigester.parse(url.openStream());
-                        Iterator it = results.iterator();
-                        while(it.hasNext()){
-                                StringBuffer buffer = (StringBuffer)it.next();
-                                addMapResource(buffer.toString());
-                                log.debug("Adding mapping resource "+buffer.toString());
-                        }
-                        
-                        Digester propertyDigester = configurePropertyDigester();
-                        Map resultMap = (Map)propertyDigester.parse(url.openStream());
-                        it = resultMap.keySet().iterator();
-                        while(it.hasNext()){
-                                String key = (String)it.next();
-                                String value = (String)resultMap.get(key);
-                                setProperty("hibernate."+key, value);
-                                log.debug("Adding property ("+key+","+value+")");
-                        }
-                        setJndiName(jndiName);
-                        setDatasource(datasourceName);
-                }
-                catch(IOException e){
-                        throw new HibernateException(e);
-                }
-                catch(SAXException e){
-                        throw new HibernateException(e);
-                }
-        }
-        
-        private Digester configureMappingDigester(){
-                Digester digester = new Digester();
-                digester.setClassLoader(this.getClass().getClassLoader());
-                digester.setValidating(false);
-                digester.addObjectCreate("hibernate-configuration/session-factory", ArrayList.class);
-                
-                digester.addObjectCreate("hibernate-configuration/session-factory/mapping", StringBuffer.class);
-                digester.addCallMethod("hibernate-configuration/session-factory/mapping", "append", 1);
-                digester.addCallParam("hibernate-configuration/session-factory/mapping", 0, "resource");
-                digester.addSetNext("hibernate-configuration/session-factory/mapping", "add");
-                
-                return digester;
-        }
-        
-        private Digester configurePropertyDigester(){
-                Digester digester = new Digester();
-                digester.setClassLoader(this.getClass().getClassLoader());
-                digester.setValidating(false);
-                digester.addObjectCreate("hibernate-configuration/session-factory", HashMap.class);
-                
-                digester.addCallMethod("hibernate-configuration/session-factory/property", "put", 2);
-                digester.addCallParam("hibernate-configuration/session-factory/property", 0, "name");
-                digester.addCallParam("hibernate-configuration/session-factory/property", 1);
-
-                return digester;
-        }
-}
-
-
    - - diff --git a/jonas_doc/olddoc/howto/WebSphereMQ.html b/jonas_doc/olddoc/howto/WebSphereMQ.html deleted file mode 100644 index 4786a4fc54eb0987698721899a7fbac5e6847da1..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/WebSphereMQ.html +++ /dev/null @@ -1,309 +0,0 @@ - - - - - - Using WebSphere MQ JMS guide - - - - -

    Howto: Using WebSphere MQ JMS guide

    - -

    This document explains how WebSphere MQ (formerly MQSeries) can be used as -JMS provider within a JOnAS application server.

    - -

    WebSphere MQ is the messaging platform developed by IBM. It provides Java -and JMS interfaces. Documentation is located at -http://www-3.ibm.com/software/integration/mqfamily/library/manualsa/.

    - -

    This document was written after integration work done with JOnAS 3.3 and -3.3.1 and WebSphere MQ 5.3.

    -

    This document may be used only when working with JOnAS 3.3

    -

    Since JOnAS 4.8 a specific resource adaptor JCA JOnAS-MQ is available for accessing to WebSphere MQ. -The corresponding documentation is currently being written and will be available soon.

    - -

    The content of this guide is the following:

    - - -

    Architectural rules

    - -

    WebSphere MQ, contrary to JORAM or SwiftMQ, cannot run collocated with -JOnAS. WebSphere MQ is an external software which must be independently -administered and configured.

    - -

    Administering WebSphere MQ consists of the following:

    -
      -
    • Creating and configuring resources (such as queues) through the - WebSphere MQ Explorer tool.
      • -
    • Creating the corresponding JMS objects (javax.jms.Queue, - javax.jms.Topic, javax.jms.QueueConnectionFactory, - etc.), and binding them to a registry.
      • -
    - -

    The link between JOnAS and WebSphere MQ is established via the registry. -WebSphere MQ JMS objects are bound to the JOnAS registry. JMS lookups will -then return the WebSphere MQ JMS objects, and messaging will take place -through these objects.

    - -

    Given the complex configuration of WebSphere MQ JMS objects, it is not -possible to create these objects from JOnAS. Therefore, during the starting -phase, a JOnAS server expects that WebSphere MQ JMS objects have already been -bound to the registry. Thus it is necessary to start an independent registry -to which WebSphere MQ can bind its JMS objects, and which can also be used by -the starting JOnAS server. The start-up sequence looks like the following:

    -
      -
    1. Starting a registry.
      2. -
    2. Creating and binding WebSphere MQ JMS objects.
      3. -
    3. Launching the JOnAS server.
      4. -
    - -

    The following architecture is proposed:

    -
      -
    • A JOnAS server (e.g., called "Registry") providing only a registry.
      • -
    • A JOnAS server (e.g., called "EJB") using the registry service of - server "Registry."
      • -
    • A WebSphere MQ server running locally.
      • -
    - -

    Setting the JOnAS Environment

    - -

    The proposed architecture requires running two JOnAS server instances. For -this, the following steps are proposed:

    -
      -
    1. Create two base directories: e.g., JONAS_REGISTRY and - JONAS_EJB.
      2. -
    2. Set the JONAS_BASE environment variable so that it points to the - JONAS_REGISTRY directory.
      3. -
    3. In the $JONAS_ROOT directory, type: ant create_jonasbase.
      4. -
    4. Set the JONAS_BASE environment variable so that it points to the - JONAS_EJB directory.
      5. -
    5. In the $JONAS_ROOT directory, type: ant create_jonasbase.
      6. -
    - -

    The JOnAS servers can now be configured independently.

    - -

    Configuring the "Registry" server

    - -

    The "Registry" server is the JOnAS server that will host the registry -service. Its configuration files are in JONAS_REGISTRY/conf.

    - -

    In the jonas.properties files, declare only the registry and jmx -services:

    - -

    jonas.services    registry,jmx

    - -

    In the carol.properties file, declare the jeremie protocol:

    - -

    carol.protocols=jeremie

    - -

    Its port can also be configured:

    - -

    carol.jeremie.url=jrmi://localhost:2000

    - -

    Configuring the "EJB" server

    - -

    The "EJB" server is the JOnAS server that will be used as the application -server. Its configuration files are in JONAS_EJB/conf. Libraries -must be added in JONAS_EJB/lib/ext.

    - -

    In the jonas.properties files, set the registry service as remote:

    - -

    jonas.service.registry.mode    remote

    - -

    ... and the JMS service as WebSphere MQ:

    - -

    jonas.service.jms.mom    org.objectweb.jonas_jms.JmsAdminForWSMQ

    - -

    In the carol.properties file, declare the jeremie protocol and set the -correct port:

    - -

    carol.protocols=jeremie
    -carol.jeremie.url=jrmi://localhost:2000

    - -

    In lib/ext, the following libraries must be added:

    -
      -
    • com.ibm.mqjms.jar, including WebSphere MQ JMS classes.
      • -
    • com.ibm.mq.jar, also a WebSphere MQ library.
      • -
    - -

    Configuring WebSphere -MQ

    - -

    WebSphere MQ JMS administration is documented in chapter 5 of the -"WebSphere MQ Using Java" document.

    - -

    The configuration file of the JMS administration tool must be edited so -that the JOnAS registry is used for binding the JMS objects. This file is the -JMSAdmin.config file located in WebSphereMQ's Java/bin -directory. Set the factory and provider URL as follows:

    - -

    INITIAL_CONTEXT_FACTORY=org.objectweb.jeremie.libs.services.registry.
    -               -         jndi.JRMIInitialContextFactory
    -PROVIDER_URL=jrmi://localhost:2000

    - -

    The JOnAS's client.jar library must also be added to the -classpath for WebSphere MQ.

    - -

    When starting, JOnAS expects JMS objects to have been created and bound to -the registry. Those objects are connection factories, needed for connecting -to WebSphere MQ destinations, and destinations.

    - -

    JOnAS automatically tries to access the following factories:

    -
      -
    • An XAConnectionFactory, bound with name "wsmqXACF".
      • -
    • An XAQueueConnectionFactory, bound with name "wsmqXAQCF".
      • -
    • An XATopicConnectionFactory, bound with name "wsmqXATCF".
      • -
    • A ConnectionFactory, bound with name "JCF".
      • -
    • A QueueConnectionFactory, bound with name "JQCF".
      • -
    • A TopicConnectionFactory, bound with name "JTCF".
      • -
    - -

    If one of these objects cannot be found, JOnAS will print a message that -looks like the following:

    - -

        JmsAdminForWSMQ.start : WebSphere MQ -XAConnectionFactory could not be retrieved from JNDI

    - -

    This does not prevent JOnAS from working. However, if there is no -connection factory available, no JMS operations will be possible from -JOnAS.

    - -

    If destinations have been declared in the jonas.properties file, -JOnAS will also expect to find them. For example, if the following -destinations are declared:

    - -

    jonas.service.jms.topics    sampleTopic
    -jonas.service.jms.queues    sampleQueue

    - -

    The server expects to find the following JMS objects in the registry:

    -
      -
    • A Queue, bound with name "sampleQueue".
      • -
    • A Topic, bound with name "sampleTopic".
      • -
    - -

    If one of the declared destination cannot be retrieved, the following -message appears and the server stops:

    - -

        JOnAS error: -org.objectweb.jonas.service.ServiceException : Cannot init/start service -jms': org.objectweb.jonas.service.ServiceException : JMS Service Cannot -create administered object: java.lang.Exception: WebSphere MQ Queue creation -impossible from JOnAS

    - -

    Contrary to connection factories, the JOnAS administration tool allows -destinations to be created. Since it is not possible to create WebSphere MQ -JMS objects from JOnAS, this will work only if the destinations are -previously created and bound to the registry.

    - -

    For example, if you want to create a queue named "myQueue" through the -JonasAdmin tool, this will only work if:

    -
      -
    • A queue has been created through the WebSphere MQ Explorer tool.
      • -
    • The corresponding JMS Queue has been created and bound to the - registry with the name "myQueue".
      • -
    - -

    To launch WebSphere MQ administration tool, type: JMSAdmin

    - -

    The following prompt appears: InitCtx>

    - -

    To create a QueueConnectionFactory and binding it with name -"JQCF", type:

    - -

        InitCtx> DEF QCF(JQCF)

    - -

    More parameters can be entered (for example for specifying the queue -manager).

    - -

    To create a Queue that represents a WebSphere MQ queue named -"myWSMQqueue", and to bind it with name "sampleQueue", type:

    - -

        InitCtx> DEF Q(sampleQueue) -QUEUE(myWSMQqueue)

    - -

    Objects bound in the registry can be viewed by typing:

    - -

        InitCtx> DIS CTX

    - -

    Starting the application

    - -

    To start the registry server:

    -
      -
    1. Clean the local CLASSPATH: set/export CLASSPATH="".
      2. -
    2. Set the JONAS_BASE variable so that it points to - JONAS_REGISTRY.
      3. -
    3. Start the JOnAS server: jonas start -n Registry.
      4. -
    - -

    To administer WebSphere MQ:

    -
      -
    1. In WebSphere MQ's Java/bin directory, launch the JMSAdmin - tool: JMSAdmin.
      2. -
    2. Create the needed JMS objects.
      3. -
    - -

    To start the EJB server:

    -
      -
    1. Clean the local CLASSPATH: set/export CLASSPATH="".
      2. -
    2. Set the JONAS_BASE variable so that it points to - JONAS_EJB.
      3. -
    3. Start the JOnAS server: jonas start -n EJB.
      4. -
    - -

    To start an EJB client:

    -
      -
    1. Add in the jclient classpath the ibm.com.mq.jar and - ibm.com.mqjms.jar libraries.
      2. -
    2. Launch the client: jclient ...
      3. -
    - -

    Limitations

    - -

    Using WebSphere MQ as JMS transport within JOnAS has some limitations, as -compared with using JORAM or SwiftMQ.

    - -

    First of all, WebSphere MQ is compliant with the old 1.0.2b JMS -specifications. Code that is written following the JMS 1.1 latest spec (such -as the jms samples provided with JOnAS) will not work with WebSphere MQ.

    - -

    Depending on the WebSphere MQ distribution, JMS Publish/Subscribe may not -be available. In this case, the message-driven bean samples provided with -JOnAS will not work. For this reason, a specific sample is provided.

    - -

    Finally, for an unknown reason, asynchronous consumption of messages -(through message-driven beans) does not work in transactional mode. Further -inquiry is needed to resolve this issue.

    - - diff --git a/jonas_doc/olddoc/howto/Win32Service.html b/jonas_doc/olddoc/howto/Win32Service.html deleted file mode 100644 index 8e846bdcbe4a036374a7190b9eb3cf7ac642a54d..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/Win32Service.html +++ /dev/null @@ -1,261 +0,0 @@ - - - - - Execute JOnAS as WIN32 Service - - - - -

    Howto: Execute JOnAS as a WIN32 Service

    - -

    This document describes the procedures necessary to run JOnAS as a system -service on Microsoft Windows platforms. This applies starting from JOnAS -3.3.2.

    - -

    Instructions

    - -

    This procedure uses ANT targets that are introduced in JOnAS 3.3.2. The -procedure also uses the Java Service Wrapper open source project which must -be downloaded and installed separately.

    - -

    Download and Install Java Service Wrapper

    -
      -
    1. Download Java - Service Wrapper version 3.0.5 or later, and unzip the package to a - directory in the local filesystem.
      2. -
    2. Set WRAPPER_HOME environment variable to the root - directory for Java Service Wrapper. -

      For example, if the package for Wrapper version 3.0.5 is unzipped into - c:\jsw, then SET WRAPPER_HOME=c:\jsw\wrapper_win32_3.0.5

      -
      3. -
    - -

    create_win32service

    - -

    Before JOnAS can be run as a WIN32 service, it is necessary to create a -Java Service Wrapper configuration file. Prior to executing the steps in this -section, it is necessary to create a JONAS_BASE directory as described in the -JOnAS Configuration Guide.

    -
      -
    1. Verify that JAVA_HOME is set as a system environment variable.
      2. -
    2. Verify that JONAS_BASE and WRAPPER_HOME environment variables are - set.
      3. -
    3. Set %JONAS_ROOT% as the current directory.
      4. -
    4. Set environment variables required for JOnAS execution - (see list below).
      5. -
    5. Execute ant [-Djonas.name=<server_name>] - create_win32service.
      6. -
    - -
    -

    The -Djonas.name=<server_name> parameter is optional. If - not specified, the default server name is 'jonas'.

    -
    - -

    Environment Variables

    -

    -Prior to executing create_win32service it is necessary to -set environment variables as required for JOnAS execution. The values -of the environment variables are saved in the wrapper_ext.conf file -as wrapper properties. -

    -
      -
    • CLASSPATH (*)
      • -
    • JAVA_OPTS
      • -
    • JONAS_OPTS
      • -
    • TOMCAT_OPTS
      • -
    • JETTY_OPTS
      • -
    -

    -* The config_env.bat file is used to configure JDBC drivers -in the CLASSPATH. Any changes to config_env.bat will affect the -CLASSPATH environment variable, and therefore requires that -the wrapper configuration be updated by running -create_win32service. -

    -

    The wrapper configuration must be updated whenever any of these -environment variables are modified. -Refer to the Modify JOnAS -Configuration section for more information.

    - - -

    install_win32service

    - -

    After the %JONAS_BASE% directory has been updated for use with Java -Service Wrapper, JOnAS can be installed as a WIN32 service using the -install_win32service ant target. Prior to installing the -configuration as a WIN32 service, the configuration can be tested as a -standard console application. Refer to the -Testing configuration section for more -information. The following steps will install the service.

    -
      -
    1. Verify that JONAS_BASE and WRAPPER_HOME environment variables are - set.
      2. -
    2. Set %JONAS_ROOT% as the current directory.
      3. -
    3. Execute ant install_win32service. As an alternative, - the service may be installed from a DOS command window using the - jonas ntservice install command.
      4. -
    - -

    By default, the service is configured to start automatically each time -Windows starts. If the administrator would prefer to start the service -manually, modify the wrapper.ntservice.starttype parameter in the -%JONAS_BASE%\conf\wrapper.conf file. Set the value as described in the -comments found in the wrapper.conf file.

    - -

    uninstall_win32service

    - -

    When it is no longer desirable to run JOnAS as a Windows service, the -service can be uninstalled using the uninstall_win32service ant -target.

    -
      -
    1. Verify that JONAS_BASE and WRAPPER_HOME environment variables are - set.
      2. -
    2. Set %JONAS_ROOT% as the current directory.
      3. -
    3. Verify that the service has been stopped.
      4. -
    4. Execute ant uninstall_win32service. As an alternative, - the service may be uninstalled from a DOS command window using the - jonas ntservice uninstall command.
      5. -
    - -

    Start JOnAS Service

    - -

    To start the JOnAS service, open the Service Control Manager (Control -Panel Services) window, select the JOnAS service and start the service. -As an alternative, the service may be started from a DOS command window -using the jonas ntservice start command.

    - -

    By default, JOnAS will be started automatically each time Windows is -started. After installing the service, it can be started manually to avoid -the need to reboot Windows.

    - -

    NOTE: -Any environment variables referenced within either of the -wrapper.conf and wrapper_ext.conf files must be defined as system -environment variables. -

    - -

    Stop JOnAS Service

    - -

    To stop the JOnAS service, open the Service Control Manager window, select -the JOnAS service and stop the service. As an alternative, the service may be stopped -from a DOS command window using the -jonas ntservice stop command.

    - -

    Status of JOnAS Service

    - -

    The status of the JOnAS service may be obtained from a DOS command window using the -jonas ntservice status command.

    - -

    Files Managed by -create_win32service

    - -

    The create_win32service ant target copies files from -the Java Service Wrapper installation directory and generates a configuration -file in the %JONAS_BASE% directory. The following files are managed by the -create_win32service ant target.

    -
      -
    • lib\wrapper.jar
      • -
    • lib\wrapper.dll
      • -
    -
      -
    • conf\wrapper.conf (*)
      • -
    • conf\wrapper_ext.conf (**)
      • -
    - -

    *   wrapper.conf contains Java Service Wrapper -configuration properties. This file is copied to the conf directory -by the CREATE_JONASBASE command. Changes made to this file are -not affected by subsequent execution of the create_win32service target.

    -

    ** wrapper_ext.conf contains Java Service Wrapper -configuration properties specific to the JOnAS service. This file is -generated by the create_win32service ant target. Any changes made to -this file will be lost when the create_win32service target is -executed.

    - -

    Modify JOnAS Configuration

    - -

    In addition to the files located in the conf directory, JOnAS -configuration is affected by the contents of -%JONAS_ROOT%\bin\nt\config_env.bat, and by the following environment variables, -CLASSPATH, JAVA_OPTS, JONAS_OPTS, TOMCAT_OPTS, JETTY_OPTS. -If changes are made to config_env.bat, or any of these -environment variables, it is necessary to update the -Java Service Wrapper configuration files.

    -

    -JOnAS memory usage is controlled by the -Xms and -Xms JVM arguments. Prior -to running create_win32service, set the JAVA_OPTS environment variable with -the desired values for -Xms and -Xmx. The create_win32service target will -generate these values as wrapper.java.additional parameters in the -wrapper_ext.conf file. -

    -

    Update Wrapper Configuration

    -
      -
    1. Stop the JOnAS service using the Windows Service Control Manager, - or the jonas ntservice stop command line.
      2. -
    2. Make changes to config_env.bat, and the - CLASSPATH, JAVA_OPTS, JONAS_OPTS, TOMCAT_OPTS, JETTY_OPTS - environment variables as needed.
      3. -
    3. Update the Java Service Wrapper configuration. Refer to the create_win32service section for - details.
      4. -
    4. Test the updated configuration. Refer to the Testing configuration section for more - information.
      5. -
    5. Restart the JOnAS service using the Windows Service Control Manager, - or the jonas ntservice start command line.
      6. -
    - -

    -Note: Changes to the JOnAS configuration files located in the -%JONAS_BASE%\conf directory do not affect the contents of the -wrapper_ext.conf file. When making changes to the files located in the -conf directroy, it is only necessary to stop the service and restart -the service for the changes to take effect. -

    - - -

    Testing Configuration

    - -

    After the Java Service Wrapper configuration files have been generated, it -is possible to test the configuration in a console window before installing -the configuration as a WIN32 service.

    -
      -
    1. Verify that JONAS_BASE environment variable is set.
      2. -
    2. Execute jonas ntservice console.
      3. -
    - -

    The Java Service Wrapper will start as a console application and load -JOnAS using the configuration generated by the create_win32service -ant target.

    - -
    Note that this test procedure is using environment variables that -are set for the current user. Verify that any environment -variables used in the wrapper.conf and/or wrapper_ext.conf files -are also set as system environment variables. -
    - -

    Enter CTRL-C to terminate JOnAS. After pressing Ctrl-C, the -Java Service Wrapper displays the following messages to the execution report, -and/or log file.

    -
    wrapper  | CTRL-C trapped.  Shutting down.
-jvm 1    | 2003-12-02 15:25:20,578 : AbsJWebContainerServiceImpl.unRegisterWar 
-                                   : War /G:/w32svc/webapps/autoload/ctxroot.war no longer available
-jvm 1    | Stopping service Tomcat-JOnAS.
-wrapper  | JVM exited unexpectedly while stopping the application.
-wrapper  | <-- Wrapper Stopped.
    - - diff --git a/jonas_doc/olddoc/howto/clusterdetails/AutomaticClusterConfiguration.html b/jonas_doc/olddoc/howto/clusterdetails/AutomaticClusterConfiguration.html deleted file mode 100644 index d62d88f8b79dfba580e1e44bcb1b3d292db67d93..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/clusterdetails/AutomaticClusterConfiguration.html +++ /dev/null @@ -1,181 +0,0 @@ - - - - - - - Generating the JOnAS's cluster configuration with newjc - - - - -

    Running newjc

    -

    Review newjc output

    -

    Tell Apache about mod_jk 

    - - -

    Generating the JOnAS's cluster configuration with newjc

    - -

    Running newjc

    -

    newjc is a tool included in - JOnAS that constructs and configures the JOnAS bases (JOnAS - instances) for the cluster.  It also creates the configuration - files needed for mod_jk.
    -This tool is located under -$JONAS_ROOT/examples/sampleCluster2/newjc.

    -

    newjc can be used to configure cluster configurations other than -sampleCluster2.  These configuration files are basic and can -be edited as needed to fit site requirements.

    -

    newjc can customize some of the characteristics of the cluster through -the build-jc.properties, build-db.properties, build-master.properties and jonas-newjc.properties files.

    -

    The default configuration is located at -$JONAS_ROOT/examples/sampleCluster2/newjc/build-jc.properties.  This -file should not require modifications for sampleCluster2, unless there -are port conflicts.  Port assignments for sampleCluster2 are -also summarized in -$JONAS_ROOT/examples/sampleCluster2/PortConfiguration.txt.  This -file is for documentation only and is not used by newjc.

    -
    -

    Running newjc to configure sampleCluster2

    - -

    Before newjc is run for the first time on Linux, create -the following directory: $HOME/jc.config/lib

    -

        mkdir –p $HOME/jc.config/lib

    -

    Run newjc.

    -

        cd $JONAS_ROOT/examples/sampleCluster2/newjc

    -

        ./newjc.sh

    -

    Here is an example output. Script output is in gray. User inputs are black -and bold.

    -
    -
    -
    -

          Buildfile: ./build-jc.xml

    -

          init:

    -

          create_jonas_cluster:

    -

              [input] Choose your output directory : -[default : ${myenv.JONAS_BASE}] :

    -

          /home/<user>/cluster

    -

              [input] Choose your prefix for the JONAS_BASE -directories : [default : jb] :

    -

          jb

    -

                 [input] Choose your protocol : [default : -cmi] :(jrmp,jeremie,iiop,cmi,)

    -

          cmi

    -

              [input] Choose your database : [default : -hsql] :

    -

          hsql

    -

              [input] Choose your WebContainer : [default : -tomcat] :(tomcat,)

    -

          tomcat

    -

              [input] Choose your cluster architecture -[bothWebEjb/diffWebEjb] : [default : diffWebEjb] :(bothWebEjb,diffWebEjb,)

    -

          diffWebEjb

    -

              [input] Choose the number of web instances : -[default : 2] :

    -

          2

    -

              [input] Choose the number of ejb instances : -[default : 2] :

    -

          2

    -
    -
    -
    -

    /// newjc output deleted for brevity

    -

    Files created by newjc will be discussed in the following -section.

    -

    Note: On Windows the steps are the same, except,

    -

        create the folder C:\Documents and -Settings\<user>\jc.config\lib

    -

        Run the newjc.cmd

    -

    For more information about newjc refer -to the ObjectWeb site.

    -

     

    -
    -

    -Review newjc output

    -

    Newjc created tomcat_jk.conf -and -workers.properties files.  For sampleCluster2 they are located in -/home/<user>/cluster/conf/jk.
    -The #Web section of build-jc.properties defines configuration -parameters set in these files by newjc.

    -

    -Refer to -workers how to documentation on the Tomcat site.

    -


    -tomcat_jk.conf  contains apache directives supported in -httpd.conf or apache2.conf.  They are isolated in a separate file for modularity, -then included in -httpd.conf or apache2.conf.
    -
    -newjc also generated four JOnAS instances -(JONAS_BASE) in directories jb1, jb2, jb3 and jb4 under -/home/<user>/cluster.  Configuration files are all in the conf -directory of each JOnAS instance.  The files pertinent to cluster -are described below.

    -

    jb1 and jb2 are sampleCluster2 JOnAS web container instances.  jb3 and jb4 are sampleCluster2 JOnAS EJB container instances.

    -

    newjc generated a script (jcl4sc2) for controlling the cluster (start/stop/kill). -

    -

    carol.properties and jgroups-cmi.xml

    -

    The #Carol section of build-jc.properties defines configuration -parameters set in the carol.propetries file and jgroups-cmi.xml by -newjc.

    -

    This allows JNDI replication to support load balancing at the -EJB level using the CMI protocol.

    -

    Note: The multicast address and port must be identically -configured for all JOnAS/Tomcat instances.

    -
    -

    jonas.properties

    -

    The #Services section of build-jc.properties defines -configuration parameters set in the jonas.properties file by -newjc.

    -
    -

    server.xml

    -

    The #Web section of build-jc.properties defines some -configuration parameters set in the server.xml file by newjc.
    -In particular, a connector XML element for AJP1.3 protocol is -defined, as well as a jvmRoute to support load balancing at the -web level, via this connector.

    -

    A Cluster XML element was also added.  It defines parameters for -achieving Session replication at the web level with -JOnAS.

    -

    Refer to the AJP -Connector and the -Engine Container documentation.

    -

     Note: The jvmRoute name generated by newjc is the -same as the name of the associated worker defined in -worker.properties.  This will ensure the Session -affinity.

    -
    -

    jcl4sc2 (jcl4sc2.bat)

    -

    These files are scripts to run the sampleCluster2 cluster on Linux and Windows.

    - -

    Tell Apache about mod_jk

    - -To make apache aware of this new file, edit <prefix>/conf/httpd.conf.
    -Copy and paste the following line after the Dynamic Shared Object -(DSO) Support section. -

    -Include -conf/jk/tomcat_jk.conf


    -

    Move the jk directory created by newjc under the APACHE structure:

    -<mv /home/<user>/cluster/conf/jk $APACHE_HOME/conf>


    -Restart apache so that apache can load the jk_module:

    -<apachectl stop && apachectl start>

    -

    Note that some UNIX distributions may locate the module in the -folder libexec instead of the folder modules.

    - - - diff --git a/jonas_doc/olddoc/howto/clusterdetails/ManualClusterConfiguration.html b/jonas_doc/olddoc/howto/clusterdetails/ManualClusterConfiguration.html deleted file mode 100644 index 1433613ab44bde9b64a990d2e00f39e6fbf6e374..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/clusterdetails/ManualClusterConfiguration.html +++ /dev/null @@ -1,403 +0,0 @@ - - - - - - - Building the JOnAS's cluster configuration - - - - - -

    Web clustering

    -

            -Load-balancing at the web level with mod_jk

    -

            -Configure HTTP session replication with Tomcat

    -

    Ejb clustering

    -

            -CMI Configuration (JNDI & EJB load balancing)

    -

            -EJB high availability

    - - -

    Building the JOnAS's cluster configuration

    - -

    Web clustering

    - -

    Load-balancing at the web level with mod_jk

    - -

    Configure Mod_jk

    -

    This depends on the distribution being used. Create a file tomcat_jk.conf and workers.properties in "$APACHE_HOME/conf/jk/".

    -
      -
    • -

      tomcat_jk.conf:

      -

      # Location of the worker file
      - JkWorkersFile "conf/jk/workers.properties"

      - # Location of the log file
      - JkLogFile "conf/jk/mod_jk.log"

      - # Log level : debug, info, error or emerg
      - JkLogLevel emerg

      - # Shared Memory Filename ( Only for Unix platform )
      - # required by loadbalancer
      - JkShmFile conf/jk/jk.shm

      - # Assign specific URL to Tomcat workers
      - # A mount point from a context to a Tomcat worker
      - JkMount /sampleCluster2 loadbalancer
      - JkMount /sampleCluster2/* loadbalancer

      - # A mount point to the status worker
      - JkMount /jkmanager jkstatus
      - JkMount /jkmanager/* jkstatus

      - # Enable the Jk manager access only from localhost
      - <Location /jkmanager/>
      -     JkMount jkstatus
      -     Order deny,allow
      -     Deny from all
      -     Allow from 127.0.0.1
      - </Location> -

      - -
      • -
    • workers.properties

      - - This file should contain the list of workers first:
      - - worker.list=<a comma separated list of worker names>
      - then the properties of each worker:
      - worker.<worker name>.<property>=<property - value>
      -

      The following is an example of a workers.properties file:


      -

      # List the workers' names
      - worker.list=loadbalancer,jkstatus

      - # ----------------
      - # First worker
      - # ----------------
      - worker.worker1.port=9010
      - worker.worker1.host=server1
      - worker.worker1.type=ajp13
      - # Load balance factor
      - worker.worker1.lbfactor=1
      - # Define preferred failover node for worker 1
      - #worker.worker1.redirect=worker2

      - # ----------------
      - # Second worker
      - # ----------------
      - worker.worker2.port=9011
      - worker.worker2.host=server2
      - worker.worker2.type=ajp13
      - worker.worker2.lbfactor=1
      - # Disable worker2 for all requests except failover
      - #worker.worker2.disabled=True

      - # ----------------------
      - # Load Balancer worker
      - # ----------------------
      - worker.loadbalancer.type=lb
      - worker.loadbalancer.balanced_workers=worker1,worker2
      - #Specifies whether requests with session's id should be routed to the same worker
      - #worker.loadbalancer.sticky_session=false

      - # ----------------------
      - # jkstatus worker
      - # ----------------------
      - worker.jkstatus.type=status -

      - - - - - - - - - - - - -
      Explanations:
        port: Port number of the remote Tomcat instance listening for defined protocol requests
        host: Host name or IP address of the backend JOnAS/Tomcat node. - Can be set to localhost when the cluster members are collocated to a single machine.
        type: Type of the worker (can be one of ajp13, ajp14, jni, status or lb)
         The status worker makes it possible to manage loadbalancing parameters and status through a web interface. In the above example, use URL http://localhost/jkmanager
        lbfactor: An integer number indicating how much a worker has to work
       example:
      - worker1.lbfactor = 2
      - worker2.lbfactor = 1
      - worker1 receives 2 times more requests than worker2
        sticky_session: - Round robin where the mod_jk sends the request to a server. When session replication is activated in JOnAS, the session will not be lost.
        redirect: worker name to use when the current worker is in error state
        disabled: True/False - default status of the current worker
         The redirect/disabled parameters make it possible to define a failover configuration between 2 workers. In the above example, the lb redirects the requests to worker 2 if worker 1 is in error state. In other cases, worker 2 will not receive any requests, thus acting as a hot standby.
      - -

      Note: Refer to the workers.properties and workers howto documentation.

      - -

      Other possible mod_jk configurations (includes mod_jk2, mod_jk, migration mod_jk2 to mod_jk)
      - Attention: mod_jk2 is deprecated. -

      -
      • -
    -

    Configure Apache 2

    -
      -
    • apache2.conf -

      - This depends on the distribution being used. Here apache 2 is assumed and it is considered - that mod_jk.so is available.

      - - # Include the user configurations:
      - Include conf/jk/tomcat_jk.conf -

      -
      • -
    - -

    Configure Tomcat

    -To configure Tomcat, perform the following configuration steps for each -Tomcat server with the right AJP port number. -
      -
    1. Configure Tomcat for the connector AJP13. In the file conf/server.xml - of the JOnAS installation directory, add the AJP connector related to the worker - (if not already there): -

      <!-- Define an AJP 1.3 Connector on port 9010 -->
      - <Connector -
      -     port="9010" minProcessors="5" - maxProcessors="75"
      -     acceptCount="10" debug="20" protocol="AJP/1.3"/>
      - - - - - - - - - - - - - - - - - - - - - - -
      Explanations:
        port: The TCP port number on which this Connector will create a server socket and await incoming connections.
        minProcessor: The minimum number of processors to start at intialization time. If not specified, this attribute is set to 5.
        maxProcessor: The maximum number of processors allowed.
        acceptCount: The maximum queue length for incoming connection requests when all possible requests processing threads are in use. Any requests received when the queue is full will be refused. -
        debug: The debugging detail level of log messages generated by this component, with higher numbers creating more detailed output.
        protocol: This attribute must be AJP/1.3 to use the AJP handler.
      -

      -

      Note: Refer to the AJP Connector documentation. -

      -
      2. -
    2. Define the jvmRoute.
      - In the file conf/server.xml of the JOnAS installation directory, add a - unique route to the Catalina engine with the right worker name.
      - Replace the line:
      - <Engine name="Standalone" defaultHost="localhost" - debug="0">
      - with:
      - <Engine jvmRoute="worker1" name="Standalone" - defaultHost="localhost" debug="0">

      - - - - - - - - - - - - - - -
      Explanations:
        name: Logical name of this Engine, used in log and error messages
        jvmRoute: Uniquely identifies the Tomcat server to the Apache server
      - Name has been specified in workers.properties -
        defaultHost: Identifies the Host that will process requests directed to host names on this server
        debug: The level of debugging detail logged by this Engine
      - -

      Note: The jvmRoute name should be the same as the name of the - associated worker defined in workers.properties. This will ensure the - Session affinity.
      -            - Refer to the Engine Container documentation.

      -
      3. -
    - -

    Configure HTTP session replication with Tomcat

    - -
      -
    • The mod_jk is used to illustrate the Session Replication. Therefore, - first perform the configuration steps presented in the chapter Load - Balancing at Web level with mod_jk.
      • -
    • On the JOnAS servers, open the - <JONAS_BASE>/conf/server.xml file and configure the - <context> as described:
      - - 
      -    <Cluster className="org.apache.catalina.cluster.tcp.SimpleTcpCluster"
-                 clusterName="myTomcatCluster"
-                 managerClassName="org.apache.catalina.cluster.session.DeltaManager"
-                 expireSessionsOnShutdown="false"
-                 useDirtyFlag="true">
-            <Membership
-                 className="org.apache.catalina.cluster.mcast.McastService"
-                 mcastAddr="228.0.0.4"
-                 mcastPort="45564"
-                 mcastFrequency="500"
-                 mcastDropTime="3000"
-                 debug = "9"
-            />
-            <Receiver
-                    className="org.apache.catalina.cluster.tcp.ReplicationListener"
-                    tcpListenAddress="auto"
-                    tcpListenPort="4001"
-                    tcpSelectorTimeout="100"
-                    tcpThreadCount="6"
-            /> 
-
-            <Sender
-                    className="org.apache.catalina.cluster.tcp.ReplicationTransmitter"
-                    replicationMode="pooled"
-            />
-
-            <Valve className="org.apache.catalina.cluster.tcp.ReplicationValve"
-                    filter=".*\.gif;.*\.js;.*\.jpg;.*\.htm;.*\.html;.*\.txt;"
-            />
-
-            <Deployer className="org.apache.catalina.cluster.deploy.FarmWarDeployer"
-                    tempDir="/tmp/war-temp/"
-                    deployDir="/tmp/war-deploy/"
-                    watchDir="/tmp/war-listen/"
-                    watchEnabled="false"
-            />
-        </Cluster>

      -

      Note1: The multicast address and multicast port of the Membership element must be identically configured - for all JOnAS/Tomcat instances.

      -

      Note2: When the nodes are collocated to the same machine, the tcpListenPort of the Receiver element must - be unique per JOnAS/Tomcat instance.

      -
      • -
    - -

    Running the Web Application

    -The web application is now ready to run in the cluster: -
      -
    1. Start the JOnAS servers: jonas start.
      2. -
    2. Restart Apache: /usr/local/apache2/bin/apachectl restart.
      3. -
    3. Use a browser to access the welcome page, usually index.html.
      4. -
    - -

    Ejb clustering

    - -

    Note: More detailed information is available in the CMI guide .

    - -

    CMI Configuration (JNDI & EJB load balancing)

    - -

    In the case of EJB level clustering (CMI), the client may be either a fat -Java client (e.g., a Swing application), or a Web application (i.e., -Servlets/JSPs running within JOnAS). In the second case, the JOnAS server -running the Web client should be configured in the same way as the other -nodes of the cluster.

    -
      -
    • In the build.properties of the application, set the protocol name to - cmi before compilation:
      -   protocols.names=cmi
      • -
    • In the file $JONAS_BASE/conf/carol.properties of each server (in the directory - $JONAS_BASE/conf) and of a fat Java client, set the protocol to cmi:
      -   carol.protocols=cmi
      • -
    • In the file $JONAS_BASE/conf/carol.properties of each server of the cluster, configure - the url, the jgroups stack, the jgroups group name and the round-robin weight factor, - etc.
      -
      - The following is a configuration example:
      - # java.naming.provider.url property
      - carol.cmi.url=cmi://localhost:2002
      -
      - # JGroups configuration file
      - carol.cmi.jgroups.conf=jgroups-cmi.xml
      -
      - - # Groupname for Javagroups
      - carol.cmi.multicast.groupname=G1
      -
      - # Factor used for this server in weighted round robin algorithms
      - carol.cmi.rr.factor=100
      • -
    • For a fat Java client, specify the list of registries available in the - carol.properties file:
      - carol.cmi.url=cmi://server1:port1[,server2:port2...]       -
      • -
    • The JGroups configuration stack is defined in the file $JONAS_BASE/conf/jgroups-cmi.xml. - It describes the protocols list and their parameters, e.g., the UDP protocol contains - the multicast address parameter. UDP protocol is set by default and can be changed - dynamically. -
      • -
    - -

    Note 1: The multicast address and port defined in the $JONAS_BASE/conf/jgroups-cmi.xml -and the group name defined in the $JONAS_BASE/conf/carol.properties file must be the same for all -JOnAS nodes in the cluster.

    - -

    Note 2: If Tomcat Replication associated to cmi is used, the multicast -addresses of the two configurations must be different. Same requirement for -the EJB high availability configuration.

    - -

    Note 3: If the cluster is defined across several machines, the CMI url has to be set with the real ip -address or ip alias and not the loopback address.Otherwise, the EJBs won't be reachable from the remote machines.

    - -

    EJB high availability

    - -

    This section describes how to enable the EJB replication framework (SFSB).

    -
      -
    • - 1) enable and configure the ha service in the jonas.properties file of each ejb container. For example,
      -

      - # Set the ha service
      - jonas.services registry,jmx,jtm,db,security,resource,ejb,ws,web,ear,ha,discovery
      -
      - # Set the name of the implementation class of the HA service.
      - jonas.service.ha.class org.objectweb.jonas.ha.HaServiceImpl
      -
      - # Set the group communication framework to use
      - jonas.service.ha.gcl jgroups
      -
      - # Set the JGroups configuration file name
      - jonas.service.ha.jgroups.conf jgroups-ha.xml
      -
      - # Set the JGroups group name
      - jonas.service.ha.jgroups.groupname jonas-rep
      -
      - # Set the SFSB backup info timeout. The info stored in the backup node is
      # removed when the timer expires.
      - jonas.service.ha.timeout 600
      -
      - # Set the datasource for the tx table
      - jonas.service.ha.datasource jdbc_1
      -

      -
      • -
    • - 2) Create a table ha_transactions in the database related to the specified datasource for handling the transaction context. For example,
      -

      - create TABLE ha_transactions (txid varchar(60));
      -

      -
      • -
    • - 3) Configure the application for enabling the replication in the JOnAS deployment descriptor. For example
      -

      - <jonas-session>
      - <ejb-name>DummySFSB</ejb-name>
      - <jndi-name>DummySFSB</jndi-name>
      - ...
      - <cluster-replicated>true</cluster-replicated>
      - <cluster-home-distributor>Dummy_HomeDistributor.vm</cluster-home-distributor>
      - <cluster-remote-distributor>Dummy_RemoteDistributor.vm</cluster-remote-distributor>
      - </jonas-session>

      -

      -
      • -
    - - - diff --git a/jonas_doc/olddoc/howto/clusterdetails/c-jdbc.html b/jonas_doc/olddoc/howto/clusterdetails/c-jdbc.html deleted file mode 100644 index 2b3f66fdd1f9807a23b0b7eb4403022b33786020..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/clusterdetails/c-jdbc.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - - - - How To Setup A C-JDBC Database Cluster - - - -

    How To Setup A C-JDBC Database Cluster

    -Note: for further information about configuration of a RAIDB1 C-JDBC cluster, refer to the C-JDBC documentation. This configuration starts three HSQLDB instances that are formed by C-JDBC as RAIDB1. This means that the same data is stored in two different databases and one database is used as a recovery log. -
      -
    1. - Download the C-JDBC binaries from the C-JDBC Forge site. -

      -
      2. -
    2. - Extract the C-JDBC archive in a folder.
      - tar xvfz c-jdbc-xx-bin.tar.gz -

      -
      3. -
    3. - Set the environment variables.
      - export JAVA_HOME=<Path to JDK HOME>
      - export CJDBC_HOME=<Path to the CJDBC HOME> -

      -
      4. -
    4. - Modify the $CJDBC_HOME/demo/demo-raidb1.sh file.
      - The ports for the HSQLDB instances must be modified to - match the sampleCluster2 configuration. Change the ports for the three databases - to 11001, 11002, 11003. -

      -
      5. -
    5. -Edit the C-JDBC virtual database file:
      $CJDBC_HOME/config/virtualdatabase/hsqldb-raidb1.xml
      -Modify the ports according to the values defined in the section above. To avoid problems in the Datasource configuration of JOnAS, you must also set a password for the user to log in (VirtualLogin element). Warning if you choose another username than default value user, modify also the vLogin attribute of ConnectionManager elements.
      6. -
    6. - Start the cluster (HSQLDB instances and then C-JDBC controller).
      - $CJDBC_HOME/demo/demo-raidb1.sh -

      -
      7. -
    7. - Connect to the C-JDBC controller using the JDBC driver ($CJDBC_HOME/drivers/c-jdbc-driver.jar) and the URL:
      - jdbc:cjdbc://localhost:25322/myDB with username: <user> and password: <pass>
      - Use the password you set in $CJDBC_HOME/config/virtualdatabase/hsqldb-raidb1.xml file. - -

      Sample C-JDBC DataSource configuration file to use in JOnAS:

      -
      -###################### C-JDBC DataSource configuration example
-#
-#####
-#DataSource configuration
-#
-#datasource.name jdbc_1
-datasource.url jdbc:cjdbc://localhost:25322/myDB
-datasource.classname org.objectweb.cjdbc.driver.Driver
-datasource.username user
-datasource.password pass
-# WARNING: you must specify the mapper of the databases used as
-# backend by C-JDBC. It is not possible to use a heterogenious c-jdbc
-# configuration here.
-datasource.mapper rdb.hsql
-
      -
      8. -
    - - diff --git a/jonas_doc/olddoc/howto/clusterdetails/director.html b/jonas_doc/olddoc/howto/clusterdetails/director.html deleted file mode 100644 index 586fdfc98d52eaed644066fbc00fa20dc67cc87b..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/clusterdetails/director.html +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - Load Balancing with Enhydra Director - - - -

    Load Balancing with Enhydra Director

    -
      -
    1. - Download the Tomcat (or Jetty) module from the ObjectWeb site. -
      -
      -
      2. -
    2. - Download the binaries or sources for the Apache module.
      - Remark: You can also download an entire distribution of Apache webserver in which the module is already included and configured. -
      -
      -
      3. -
    3. - Configure the apache director module.
      - File: $APACHE_HOME/conf/enhydra_director.conf
      -
      - Example configuration:
      -
      - <?xml version="1.0"?>
      - <!DOCTYPE EnhydraDirectorConfig SYSTEM "EnhydraDirectorConfig.dtd">
      - <EnhydraDirectorConfig>
      -   <Application prefix="/sampleCluster2/">
      -     <AppServer host="localhost" port="9999" weight="1" />
      -     <AppServer host="localhost" port="8888" weight="1" />
      -   </Application>
      -   <Status prefix="/status">
      -     <Restrict server="127.0.0.1" />
      -     <Restrict client="127.0.0.1" />
      -   </Status>
      - </EnhydraDirectorConfig>
      -
      - Remark: In this configuration, the connector is configured to forward the requests for one web application (load balancing and fail over). The second (sampleCluster2 example) is running on one machine, but on different ports. Furthermore, the /status context allows you to enable, disable and change some parameters of the director configuration. The /status context is only available on the machine where director is running in this sample configuration. -

      -
      4. -
    4. Copy the tomcat module (tomcat-director.jar) to $CATALINA_HOME/server/lib or $JONAS_ROOT/lib/catalina/server/lib.
      -  Note: For the JOnAS+Tomcat package use: $JONAS_ROOT/lib/catalina/server/lib
      -             For a standalone Tomcat installation use: $CATALINA_HOME/server/lib -

      5. -
    5. - Configure the connector in the tomcat configuration ($CATALINE_HOME/conf/server.xml).
      - Example configuration:
      -Add these lines to the configuration where the other connectors (AJP, ...) are defined: -
      -Using TomCat 5.0.x as servlet container
      - <!-- Define a Director Connector on port 8888 -->
      - <Connector className="org.enhydra.servlet.connectionMethods.EnhydraDirector.EnhydraDirectorConnectionMethod"
      -       port = "8888"
      -       threadTimeout = "300"
      -       clientTimeout = "30"
      -       sessionAffinity = "false"
      -       queueSize = "400"
      -       numThreads = "200"
      -       bindAddress = "(All Interfaces)"
      -       authKey = "(Unauthenticated)"
      - />
      - -Using TomCat 5.5.x as servlet container
      -<!-- Define a Director Connector on port 8888 -->
      -<Connector className="org.enhydra.servlet.connectionMethods.EnhydraDirector.DirectorProtocol"
      -      port = "8888"
      -      threadTimeout = "300"
      -      clientTimeout = "30"
      -      sessionAffinity = "false"
      -      queueSize = "400"
      -      numThreads = "200"
      -      bindAddress = "(All Interfaces)"
      -      authKey = "(Unauthenticated)"
      -/>
      -
      -Remark: The session affinity attribute is set to false because the session replication is activated in JOnAS. Otherwise, a new session is created when Director switches between the instances. - The Director connector may coexiste with the mod_jk connector.

      -
    6. -Restart Apache. -

      7. -
    7. -Restart JOnAS. -
      8. -
    - - diff --git a/jonas_doc/olddoc/howto/clusterdetails/mod_jk2-to-mod_jk.html b/jonas_doc/olddoc/howto/clusterdetails/mod_jk2-to-mod_jk.html deleted file mode 100644 index 494db8c0406a704c4313ef39b0f245304591a774..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/clusterdetails/mod_jk2-to-mod_jk.html +++ /dev/null @@ -1,152 +0,0 @@ - - - - - - - Migrating from mod_jk2 to mod_jk with embedded Tomcat - - - -

    Migrating from mod_jk2 to mod_jk with embedded Tomcat
    -

    -
    Note: This document shows one of several -ways to migrate mod_jk2 settings to work
    -with mod_jk instead. The mod_jk2 reference setup can be found here.
    -Also, all references to jonas-server should be replaced by the hostname of -the target machine
    -for which you want to configure mod_jk.
    -Replace ${JONAS_BASE} and ${APACHE_HOME} with appropriate values. -
    -

    1. Edit the file $JONAS_BASE/conf/server.xml; locate and uncomment -the -following line:
    -

    -
    	<!--
        		<Connector port="9009"
                   		enableLookups="false" redirectPort="9043" debug="0"
                   		protocol="AJP/1.3" />
        	-->
    -   Change it to look like the following:
    -
    	<Connector port="9009"
            	       enableLookups="false" redirectPort="9043" debug="0"
                   	       protocol="AJP/1.3" />


    -  Next, comment out the existing mod_jk2-oriented connector and -engine elements:
    - -

    ...      
    	<Connector className="org.apache.coyote.tomcat5.CoyoteConnector"
              port="9009" minProcessors="5" maxProcessors="75"              
    	  enableLookups="true" redirectPort="9043"              
    	  acceptCount="10" debug="0" connectionTimeout="0"               
    	  useURIValidationHack="false" 
    	  protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/>

    -  Replace the  base Engine tag in which a jvmRoute -with the standard engine is used.
    -  For example, comment out the line that looks similar to the -following:
    -
    	<Engine name="Tomcat-JOnAS-Engine" defaultHost="localhost" debug="0"
    								jvmRoute="jonas01">
    -  and uncomment the following line:
    -
    	<Engine name="Tomcat-JOnAS-Engine" defaultHost="localhost" debug="0">
    -
    -    -Note: Always -backup files like server.xml before editing.
    -
    -2.  Now you can -either let tomcat generate the mod_jk.conf file automatically,
    -         which will setup forwarding for a -limited set of applications, or you can create a
    -      custom mod_jk.conf file where you can specify -applications to forward and
    -     customize configuration information.
    -
    -         Note: The -automatically generated file cannot be customized since it is re-written
    -     -every time tomcat is restarted by the user.
    -
    -            a)   -To enable automatic generation, insert the following into the -server.xml
    -            -      file nested under the base <Server> tag: -
    -
    - -
    	<Listener className="org.apache.jk.config.ApacheConfig" 
      			modJk="$APACHE_HOME/modules/mod_jk.so" />
    -
    -        and insert the following under -the <Host> element:
    -
    	<Listener className="org.apache.jk.config.ApacheConfig" 
    				append="true" forwardAll="false" 
    				 modJk="$APACHE_HOME/modules/mod_jk.so"/>
    -        When jonas/tomcat is restarted, there will be - a file created under
    -        -$JONAS_BASE/lib/catalina/conf/auto called mod_jk.conf.
    -
    -
    -            -b)   If you want to create a custom file, the recommendation is to place -a file
    -                  named -mod_jk.conf under $JONAS_BASE/conf/jk.
    -                -  You can view this file as the equivalent of the -$APACHE_HOME/conf.d/JOnAS.conf in
    -            -      the mod_jk2 directions; however, it is -not a direct replacement.
    -
    -            -      A simple mod_jk.conf file that can be used is:
    -

       	  # Load the mod_jk module if not loaded.
    		<IfModule !mod_jk.c>
    	  		LoadModule jk_module "$APACHE_HOME/modules/mod_jk.so"
    		</IfModule>

       	  # Specify location of worker file and log file. Worker file will follow shortly.
    	    JkWorkersFile "$JONAS_BASE/conf/jk/workers.properties"
    	    JkLogFile "$JONAS_BASE/logs/mod_jk.log"

              # When and how much logging.
    	    JkLogLevel emerg

       	  # This is a little awkward. It seems mod_jk associates applications it will
       	  # map to tomcat based on the virtual host. If for instance I wish to visit
       	  # the jonasAdmin application through http://jonas-server/jonasAdmin from another
       	  # machine and I have the following setting then the application behaves
       	  # perfectly normally, i.e, behaves as one would expect if you
       	  # were using the application directly using the appropriate port (9000).
       	  # However, if you try using http://localhost/jonasAdmin from jonas-server
       	  # without the explicit VirtualHost declaration, only the directory contents
       	  # are mapped. No processing on the tomcat is carried out, so struts based 
              # applications will fail to work. That is the reason why we explicitly 
              # mention both virtual hosts.
    		<VirtualHost jonas-server>
        			ServerName jonas-server
        			JkMount /cmp2 ajp13
        			JkMount /cmp2/* ajp13
        			JkMount /alarm ajp13
    			JkMount /alarm/* ajp1
    			JkMount /earsample ajp13
    			JkMount /earsample/* ajp13
    			JkMount /jonasAdmin ajp13
    			JkMount /jonasAdmin/* ajp13
    		</VirtualHost>

    		<VirtualHost localhost>
    			ServerName localhost
    			JkMount /cmp2 ajp13
    			JkMount /cmp2/* ajp13
    			JkMount /alarm ajp13
    			JkMount /alarm/* ajp13
    			JkMount /earsample ajp13
    			JkMount /earsample/* ajp13
    			JkMount /jonasAdmin ajp13
    			JkMount /jonasAdmin/* ajp13
    		</VirtualHost>
    -

    -3.  Now tell apache to use this file.  Backup the -file: $APACHE_HOME/conf/httpd.conf.
    -     Edit the /etc/httpd/conf/httpd.conf file and -insert:
    -
    	Include ${JONAS_BASE}/conf/jk/mod_jk.conf
    -     Note: replace ${JONAS_BASE} with -appropriate value.
    -
    -        Locate -and comment out the following line in the same file:
    -     -
        LoadModule jk2_module modules/mod_jk2.so
    -
    -4. Now create -a workers.properties file. This can be placed in
    -    $JONAS_BASE/conf/jk/workers.properties.
    -    A sample that has been used successfully is:
    -

    	# workers.java_home should point to your Java installation. Normally
    	# you should have a bin and lib directories beneath it.
    	#
    	workers.java_home=/usr/lib/jvm/java

    	#
    	# You should configure your environment slash... ps=\ on NT and / on UNIX
    	# and maybe something different elsewhere.
    	#
    	ps=/

    	#
    	#------ ADVANCED MODE ------------------------------------------------
    	#---------------------------------------------------------------------
    	#

    	#
    	#------ DEFAULT worket list ------------------------------------------
    	#---------------------------------------------------------------------
    	#
    	#
    	# The workers that your plugins should create and work with
    	#
    	# Add 'inprocess' if you want JNI connector
    	worker.list=ajp13
    	# , inprocess


    	#
    	#------ DEFAULT worker1 WORKER DEFINITION ------------------------------
    	#---------------------------------------------------------------------
    	#

    	#
    	# Defining a worker named worker1 and of type worker1
    	# Note that the name and the type do not have to match.
    	#
    	worker.ajp13.port=9009
    	worker.ajp13.host=jonas-server
    	worker.ajp13.type=ajp13


    	#----------------------------------------------------------

    -
    Once all this is completed, restart jonas followed by httpd.
    -Follow that up with a quick test by visiting: http://${HOSTNAME}/jonasAdmin. -
    -You should be able to use the application as normal.
    -You can now use cmp2, earsample, alarm and jonasAdmin using mod_jk -instead.
    -
    -

    - - diff --git a/jonas_doc/olddoc/howto/clusterdetails/mod_jk2_embeddedtomcat.html b/jonas_doc/olddoc/howto/clusterdetails/mod_jk2_embeddedtomcat.html deleted file mode 100644 index 6dc24964316f726e66d88619735d01046c5a7fd1..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/clusterdetails/mod_jk2_embeddedtomcat.html +++ /dev/null @@ -1,176 +0,0 @@ - - - - - - - Setting up mod_jk2 with embedded Tomcat - - - -

    Setting up mod_jk2 with embedded Tomcat
    -

    -
    -Note: Replace ${JONAS_BASE} and ${APACHE_HOME} with appropriate values. -
    -

    1. Backup /$APACHE_HOME/conf/httpd.conf:
    -
    -    cp -$APACHE_HOME/conf/httpd.conf $APACHE_HOME/conf/httpd.conf.backup

    -

    2. Edit (~line 208) httpd.conf to add the loading of mod_jk2.so:
    -
    -# Adding jk2_module reference.
    -LoadModule jk2_module modules/mod_jk2.so
    -
    -

    -

    3. Edit $APACHE_HOME/conf.d/JOnAS.conf -with the following content:
    -
    -Alias /docs/jonas "$JONAS_BASE/doc/jonas-4.1.2"
    -<Directory "$JONAS_BASE/doc/jonas-4.1.2">
    -    Options Indexes MultiViews
    -    AllowOverride None
    -    Order allow,deny
    -    Allow from all
    -</Directory>
    - 
    -Alias /webapps/jonas "$JONAS_BASE/webapps/jonas"
    -<Directory "$JONAS_BASE/webapps/jonas">
    -    Options Indexes MultiViews
    -    AllowOverride None
    -    Order allow,deny
    -    Allow from all
    -</Directory>
    - 
    -<IfModule mod_jk2.c>
    - 
    -<Location /earsample>
    -    JkUriSet group jonas
    -</Location>
    - 
    -<Location /jonasAdmin>
    -    JkUriSet group jonas
    -</Location>
    - 
    -<Location /cmp2>
    -    JkUriSet group jonas
    -</Location>
    - 
    -<Location /alarm>
    -    JkUriSet group jonas
    -</Location>
    - 
    -</IfModule>
    -
    -

    -

    4. Edit/create $APACHE_HOME/conf/workers2.properties -with the following content:
    -
    -[logger]
    -level=DEBUG
    -                                                                                -
    -# Shared memory handling. Needs to be set.
    -[shm]
    -info=Scoreboard. Required for reconfiguration and status with -multiprocess servers
    -file=$APACHE_HOME/logs/jk2.shm
    -size=1048576
    -debug=0
    -disabled=0
    -                                                                                -
    -# The channel configuration shall be consistent with
    -# the configuration of JOnAS in server.xml
    -# port = port of the AJP (jk2) connector
    -# tomcatId = jvmRoute attribute of the <Engine> element
    -[channel.socket:toJonas01]
    -info=channel to a JOnAS instance - tomcatId shall be identical to -jvmRoute in the server.xml file of the JOnAS instance
    -host=localhost
    -port=9009
    -group=jonas
    -                                                                                -
    -[status:status]
    -info=provides info on the connecteur usage
    -                                                                                -
    -[uri:$/jkstatus*]
    -info=get the connector usage info at /jkstatus
    -group=status:status
    -

    -5. On the JOnAS side, edit $JONAS_BASE/conf/server.xml -with the following content:
    -


    -...
    -     -<Connector className="org.apache.coyote.tomcat5.CoyoteConnector"
    -                -port="9009" minProcessors="5" maxProcessors="75"
    -                -enableLookups="true" redirectPort="9043"
    -                 -acceptCount="10" debug="0" connectionTimeout="0"
    -                 -useURIValidationHack="false"
    -          -       -protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/>
    -...

    -

        -<Engine name="Tomcat-JOnAS-Engine" defaultHost="localhost" debug="0" -jvmRoute="jonas01">
    -
    -

    -6.  Comment out all lines in $JONAS_BASE/conf/jk2.properties.
    -
    -7. Restart jonas and httpd services:
    -
    -service jonas restart; service httpd restart
    -

    8. Deploy cmp2.ear and alarm.ear.
    -

    -

    9. Those apps are available at:
    -
    -http://<hostname>/cmp2
    -    http://<hostname>/earsample
    -    http://<hostname>/alarm
    -    http://<hostname>/jonasAdmin
    -

    - - - diff --git a/jonas_doc/olddoc/howto/clusterdetails/mod_jk_embeddedtomcat.html b/jonas_doc/olddoc/howto/clusterdetails/mod_jk_embeddedtomcat.html deleted file mode 100644 index 9410a93fe015a2c06ef4e6f0fa29d98cb9a9df52..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/clusterdetails/mod_jk_embeddedtomcat.html +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - - Setting up mod_jk with embedded Tomcat - - - -

    Setting up mod_jk with embedded Tomcat
    -

    -
    -Note: Replace ${JONAS_BASE} and ${APACHE_HOME} with appropriate values. -
    -

    1. Open the file $JONAS_BASE/conf/server.xml and uncomment the -following line:
    -

    -
     <!-- 
         <Connector port="9009"
                   enableLookups="false" redirectPort="9043" debug="0"
                   		protocol="AJP/1.3" />
      -->
    -

    Edit it to look like the following:
    -

    -
    <Connector port="9009"
           	       enableLookups="false" redirectPort="9043" debug="0"
    			protocol="AJP/1.3" />

    -2. Now you can -either let tomcat generate the mod_jk.conf file automatically,
    -    which will setup forwarding for a limited set of -applications, or you can create a
    -    custom mod_jk.conf file.
    -    The automatically generated file cannot be -customized since it is re-written every time
    -    tomcat is restarted by the user.
    -a) To enable automatic generation insert the following into the -server.xml file nested under the base <Server> -tag:
    -
       <Listener className="org.apache.jk.config.ApacheConfig"
       			modJk="$APACHE_HOME/modules/mod_jk.so" />

    -
    -    and insert the following under the <Host> -element:
    -
       <Listener className="org.apache.jk.config.ApacheConfig"
       				append="true" forwardAll="false"
       					modJk="$APACHE_HOME/modules/mod_jk.so"/>


    -    When jonas/tomcat is restarted, there will be a file -created under $JONAS_BASE/conf/auto called mod_jk.conf.
    -


    -b) If you want to create a custom file, the recommendation is to place -mod_jk.conf under $JONAS_BASE/conf/jk.
    -    A simple mod_jk.conf file that can be used is:
    -
       # Load the mod_jk module if not loaded.
    	<IfModule !mod_jk.c>
    	  LoadModule jk_module "$APACHE_HOME/modules/mod_jk.so"
    	</IfModule>

       # Specify location of worker file and log file. Worker file will follow shortly.
    	JkWorkersFile "$JONAS_BASE/conf/jk/workers.properties"
    	JkLogFile "$JONAS_BASE/logs/mod_jk.log"


       # When and how much logging.
    	JkLogLevel emerg

       # This is a little awkward. It seems mod_jk associates applications it will
       # map to tomcat based on the virtual host. If for instance I wish to visit
       # the jonasAdmin application through http://jonas-server/jonasAdmin from another
       # machine and I have the following setting then the application behaves
       # perfectly normally, i.e, struts kicks in as expected, form based
       # authentication and forwarding is done exactly as one would expect if you
       # were using the application directly using the appropriate port (9000).
       # However, if you try using http://localhost/jonasAdmin from jonas-server
       # without the explicit VirtualHost declaration, only the directory contents
       # are mapped. So we need to explicitly mention both virtual hosts.
    	<VirtualHost jonas-server>
        		ServerName jonas-server
        		JkMount /olstore ajp13
        		JkMount /olstore/* ajp13
        		JkMount /jonasAdmin ajp13
        		JkMount /jonasAdmin/* ajp13
    	</VirtualHost>
       # ajp13 is infact the worker name used in workers.properties.
    	<VirtualHost localhost>
        		ServerName localhost
        		JkMount /olstore ajp13
        		JkMount /olstore/* ajp13
        		JkMount /jonasAdmin ajp13
        		JkMount /jonasAdmin/* ajp13
    	</VirtualHost>
    -

    3. To tell apache to use this file, edit the -$APACHE_HOME/conf/httpd.conf file and insert:
    -

    -
     Include ${JONAS_BASE}/conf/jk/mod_jk.conf
    -Note: Replace ${JONAS_BASE} with appropriate value.
    -

    4. Create -a workers.properties file. This can be placed in
    -

    -
       $JONAS_ROOT/conf/jk/workers.properties

    -A sample that has been used successfully is:
    -
    # workers.java_home should point to your Java installation. Normally
    # you should have a bin and lib directories beneath it.
    #
    workers.java_home=/usr/lib/jvm/java

    #
    # You should configure your environment slash... ps=\ on NT and / on UNIX
    # and possibly something different elsewhere.
    #
    ps=/

    #
    #------ ADVANCED MODE ------------------------------------------------
    #---------------------------------------------------------------------
    #

    #
    #------ DEFAULT worket list ------------------------------------------
    #---------------------------------------------------------------------
    #
    #
    # The workers that your plugins should create and work with
    #
    # Add 'inprocess' if you want JNI connector
    worker.list=ajp13
    # , inprocess


    #
    #------ DEFAULT worker1 WORKER DEFINITION ------------------------------
    #---------------------------------------------------------------------
    #

    #
    # Defining a worker named worker1 and of type worker1
    # Note that the name and the type do not have to match.
    #
    worker.ajp13.port=9009
    worker.ajp13.host=jonas-server
    worker.ajp13.type=ajp13


    #----------------------------------------------------------
    -
    -Once all this is completed, restart httpd and ensure that -jonas/tomcat is up. You can follow that up with a quick test by visiting: http://host_name/jonasAdmin.
    -You should now be able to use the application as normal.
    -
    - - diff --git a/jonas_doc/olddoc/howto/clusterdetails/sequoia.html b/jonas_doc/olddoc/howto/clusterdetails/sequoia.html deleted file mode 100644 index f52292b6e1a6007c0461945ff463f331cfccc7b0..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/clusterdetails/sequoia.html +++ /dev/null @@ -1,88 +0,0 @@ - - - - - - -How To Setup A Sequoia Database Cluster - - - - -

    How To Setup A Sequoia Database Cluster

    - -

    Sequoia is a transparent middleware solution for offering clustering, load balancing and failover services for any database. The purpose of this howto is to explain how to setup a Sequoia database cluster with JOnAS, and more precisely a RAIDB1 cluster composed of three HSQLDB databases and one Sequoia controller. This configuration allows to replicate the data in two different databases. The third database is used as recovery log. For further informaton about Sequoia and its configuration, please refer to the Sequoia documentation.

    - -
      -
    1. -

      Download the Sequoia binaries from the Sequoia site.

      -
      2. - -
    2. -

      Extract the Sequoia archive in a folder. For instance:
      -tar xvfz sequoia-x.y-bin.tar.gz

      -
      3. - -
    3. -

      Set the environment variables.
      -export JAVA_HOME=<Path to JDK home>
      -export SEQUOIA_HOME=<Path to the Sequoia home>

      -
      4. - -
    4. -

      Modify the $SEQUOIA_HOME/demo/demo-raidb1.sh file.
      -The ports for the HSQLDB instances must be modified to match the sampleCluster2 configuration. Change the ports for the three databases to 11001, 11002, 11003.

      -
      5. - -
    5. -

      Modify the Sequoia virtual database file: $SEQUOIA_HOME/config/virtualdatabase/hsqldb-raidb1.xml
      -Change the ports according to the values defined in the section above. To avoid problems in the Datasource configuration of JOnAS, modify also the password for the user to log in (VirtualLogin element). Warning if you choose another username than default value (user), modify also the vLogin attribute of ConnectionManager elements.

      -
      6. - -
    6. -

      Start the cluster (HSQLDB instances and then Sequoia controller).
      -$SEQUOIA_HOME/demo/demo-raidb1.sh -

      -
      7. - -
    7. -

      Connect to the Sequoia controller using the $SEQUOIA_HOME/drivers/sequoia-driver.jar JDBC driver and the URL:
      -jdbc:sequoia://localhost:25322/myDB with username: <user> and password: <pass>
      -Use the password you set in $CJDBC_HOME/config/virtualdatabase/hsqldb-raidb1.xml file.

      - -

      Sample Sequoia DataSource configuration file to use in JOnAS:

      -
      -###################### Sequoia DataSource configuration example
-#
-#####
-DataSource configuration
-#
-datasource.name jdbc_1
-datasource.url jdbc:sequoia://localhost:25322/myDB
-datasource.classname org.continuent.sequoia.driver.Driver
-datasource.username user
-datasource.password pass
-# WARNING: you must specify the mapper of the databases used as
-# backend by Sequoia. It is not possible to use a heterogenious
-# Sequoia configuration here.
-datasource.mapper rdb.hsql
-
      -
      8. -
    - - - diff --git a/jonas_doc/olddoc/howto/common.css b/jonas_doc/olddoc/howto/common.css deleted file mode 100644 index 438cf540ca2ae7e7e141e1ca27264bab129cf51a..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/common.css +++ /dev/null @@ -1,246 +0,0 @@ -body { -/* background: white url(../../resources/images/draft.png) repeat right top; */ -font: verdana,sans-serif; - -} - - a:link { - color: #0000CC; - text-decoration: none; - font-style: normal; - } - - a:visited { - color: #0000CC; - text-decoration: none; - } - a:hover { - color: red; - text-decoration: none; - background-color: #ecf5ff; - } - a:active { - color: #0000CC; - text-decoration: none; - } - - -h1 -{ - border-width: 6px ; - border-style: none ; - - line-height: 27px; - border-color: #99C;/*#F8F6E2;*/ - - margin: 5px 5px 5px 5px; - background-color:#eff5fb; - width:85%; - color: #003399; - margin-top: 45px; - padding: 20px 50px; -} - -h2 -{ - - font-size: 20px; - line-height: 27px; - font-weight: normal; - border-color:#99C; - - border-width: 2px 0 0 0; - border-style: solid none none none; - background-color:#eff5fb; - width:45%; -} - - - -h3, h4, h5, h6 { - color: #003399; - font-weight: 500; - margin-top: 10px; - padding-top: 5px; -} - - - h1 { font-size: 150%; } - h2 { font-size: 140%; color: #3e80a2;} - h3 { font-size: 110%; font-weight: bold; } - h4 { font-size: 110%; font-weight: bold;} - h5 { font-size: 100%; font-style: italic; } - h6 { font-size: 100%; font-style: italic; } - - - - tt { - font-size: 90%; - font-style: monospace; - color: #111111; - } - - - pre { - font-size: 100%; - padding: 5px; - border-style: solid; - border-width: 1px; - border-color: #CCCCCC; - background-color: #F4F4F4; - } - - hr { - width: 100%; - height: 1px; - background-colorcolor:black; - background-color:white;: #CCCCCC; - border-width: 0px; - padding: 0px; - color: #CCCCCC; - } - - - - .variablelist { - padding-top: 10; - padding-bottom: 10; - margin: 0; - } - .itemizedlist { - padding-top: 0; - padding-bottom: 0; - margin: 0; - - } - .orderedlist{ - padding-top: 0; - padding-bottom: 0; - margin: 0; - } - .term { - font-weight: red;bold; - } - - - .warning - { - padding-bottom: 5px; - padding-left: 5px; - padding-right: 5px; - background-color: #FBDADA; - } - -.screen { - background-color: #edf8fd; - forground-color: black; - border: 1px solid #9999cc; - padding: 0.5em; - margin: 2em; - width:85%; - - } - -.informaltable table { - padding: 10px; - border: none; - -} - -.informaltable tr:first-child td { - background-color:#C0C9D8; - padding: 10px 8px 10px 8px; - font-weight:bold; - font-size: normal; - -} - - -.informaltable tr{ - - border-bottom: 5px solid #FFFFFF; - border-top: 5px solid #FFFFFF; - -} - -.informaltable td{ - - margin: 0px 0px 0px 0px; - padding: 10px 8px 10px 8px; - - background-color: #EAEDF2; - font-size: small; - -} -.informaltable td p { - background-color:#EAEDF2; -} -.informaltable li p{ - background-color:#EAEDF2; -} - -.calloutlist tr:first-child td { - background-color:FFFFFF; -} - -.calloutlist tr { - background-color:FFFFFF;font-size: small; -} - - .caution tr:first-child td{ - background-color:FFFFFF; -} - -.caution tr { - background-color:FFFFFF; - font-size: small; -} -.caution table { - border: none; - border-color: #C0C9D8; - margin: 5px; -} - -.note tr:first-child td{ - background-color:FFFFFF; -} - -.note tr { - background-color:FFFFFF; - font-size: small; -} - -.note table { - border: none; - border-color: #C0C9D8; - margin: 2px; -} - .note { - padding-bottom: 5px; - padding-left: 5px; - padding-right: 5px; - background-color:FFFFFF; - -} - -.mediaobject { - border-top: 5px solid #FFFFFF; - border-bottom: 5px solid #FFFFFF; - border-color:#EAEDF2; - margin: 10px; - padding:5px; -} - -.glossary dt { - background-color:#eff5fb; - width:5%; -} - -.programlisting { - overflow:auto;width:75%;height:200px; - border-top: 5px solid #FFFFFF; - border-bottom: 5px solid #FFFFFF; - border-color:black; - margin: 10px; - padding:5px; -} diff --git a/jonas_doc/olddoc/howto/emb-images/emb-component.png b/jonas_doc/olddoc/howto/emb-images/emb-component.png deleted file mode 100644 index 283d4dcdc7ed7831688c338b329cacf93981de3c..0000000000000000000000000000000000000000 Binary files a/jonas_doc/olddoc/howto/emb-images/emb-component.png and /dev/null differ diff --git a/jonas_doc/olddoc/howto/emb-images/emb-deps.png b/jonas_doc/olddoc/howto/emb-images/emb-deps.png deleted file mode 100644 index e22a9ff77bd2061f1e0413826764ac3a070b9567..0000000000000000000000000000000000000000 Binary files a/jonas_doc/olddoc/howto/emb-images/emb-deps.png and /dev/null differ diff --git a/jonas_doc/olddoc/howto/emb-images/mfb.png b/jonas_doc/olddoc/howto/emb-images/mfb.png deleted file mode 100644 index ee21aa9cdd124d99f1df267ad92feff97acf1bb4..0000000000000000000000000000000000000000 Binary files a/jonas_doc/olddoc/howto/emb-images/mfb.png and /dev/null differ diff --git a/jonas_doc/olddoc/howto/emb-images/src/emb-component.svg b/jonas_doc/olddoc/howto/emb-images/src/emb-component.svg deleted file mode 100644 index 9e89c6481fcfccd690be17c91af53729e99eb0ec..0000000000000000000000000000000000000000 --- a/jonas_doc/olddoc/howto/emb-images/src/emb-component.svg +++ /dev/null @@ -1,1527 +0,0 @@ - - - - - - image/svg+xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -