archive-es.com » ES » E » EPPA.ES

Total: 100

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Apache Tribes - The Tomcat Cluster Communication Module (7.0.22) - Apache Tribes - Introduction
    the feature set I will list it out here Some of the features are not yet completed if that is the case they are marked accordingly Pluggable modules Tribes is built using interfaces Any of the modules or components that are part of Tribes can be swapped out to customize your own Tribes implementation Guaranteed Messaging In the default implementation of Tribes uses TCP or UDP for messaging TCP already has guaranteed message delivery and flow control built in I believe that the performance of Java TCP will outperform an implementation of Java UDP flow control message guarantee since the logic happens further down the stack UDP messaging has been added in for sending messages over UDP instead of TCP when desired The same guarantee scenarios as described below are still available over UDP however when a UDP message is lost it s considered failed Tribes supports both non blocking and blocking IO operations The recommended setting is to use non blocking as it promotes better parallelism when sending and receiving messages The blocking implementation is available for those platforms where NIO is still a trouble child Different Guarantee Levels There are three different levels of delivery guarantee when a message is sent IO Based send guarantee fastest least reliable This means that Tribes considers the message transfer to be successful if the message was sent to the socket send buffer and accepted On blocking IO this would be socket getOutputStream write msg On non blocking IO this would be socketChannel write and the buffer byte buffer gets emptied followed by a socketChannel read to ensure the channel still open The read has been added since write will succeed if the connection has been closed when using NIO ACK based recommended guaranteed delivery When the message has been received on a remote node an ACK is sent back to the sender indicating that the message was received successfully SYNC ACK based guaranteed delivery guaranteed processed slowest When the message has been received on a remote node the node will process the message and if the message was processed successfully an ACK is sent back to the sender indicating that the message was received and processed successfully If the message was received but processing it failed an ACK FAIL will be sent back to the sender This is a unique feature that adds an incredible amount value to the application developer Most frameworks here will tell you that the message was delivered and the application developer has to build in logic on whether the message was actually processed properly by the application on the remote node If configured Tribes will throw an exception when it receives an ACK FAIL and associate that exception with the member that didn t process the message You can of course write even more sophisticated guarantee levels and some of them will be mentioned later on in the documentation One mentionable level would be a 2 Phase Commit where the remote applications don t receive the

    Original URL path: http://ticket.eppa.es/docs/tribes/introduction.html (2015-09-25)
    Open archived version from archive


  • Application Developer's Guide (7.0.22) - Introduction
    this manual is aimed at developers who will be using a text editor along with command line tools to develop and debug their applications As such the recommendations are fairly generic but you should easily be able to apply them in either a Windows based or Unix based development environment If you are utilizing an Interactive Development Environment IDE tool you will need to adapt the advice given here to the details of your particular environment Links The following links provide access to selected sources of online information documentation and software that is useful in developing web applications with Tomcat http java sun com products jsp JavaServer Pages JSP Specification Version 2 0 Describes the programming environment provided by standard implementations of the JavaServer Pages JSP technology In conjunction with the Servlet API Specification see below this document describes what a portable API page is allowed to contain Specific information on scripting Chapter 6 tag extensions Chapter 7 and packaging JSP pages Appendix A is useful The Javadoc API Documentation is included in the specification and with the Tomcat download http java sun com products servlet download html Servlet API Specification Version 3 0 Describes the programming environment that must

    Original URL path: http://ticket.eppa.es/docs/appdev/introduction.html (2015-09-25)
    Open archived version from archive

  • Application Developer's Guide (7.0.22) - Installation
    oracle com technetwork java javase downloads index html Tomcat Binary downloads of the Tomcat server are available from http tomcat apache org This manual assumes you are using the most recent release of Tomcat 7 Detailed instructions for downloading and installing Tomcat are available here In the remainder of this manual example shell scripts assume that you have set an environment variable CATALINA HOME that contains the pathname to the directory in which Tomcat has been installed Optionally if Tomcat has been configured for multiple instances each instance will have its own CATALINA BASE configured Ant Binary downloads of the Ant build tool are available from http ant apache org This manual assumes you are using Ant 1 8 or later The instructions may also be compatible with other versions but this has not been tested Download and install Ant Then add the bin directory of the Ant distribution to your PATH environment variable following the standard practices for your operating system platform Once you have done this you will be able to execute the ant shell command directly CVS Besides the required tools described above you are strongly encouraged to download and install a source code control system such

    Original URL path: http://ticket.eppa.es/docs/appdev/installation.html (2015-09-25)
    Open archived version from archive

  • Application Developer's Guide (7.0.22) - Deployment
    that contain Java class files and associated resources required for your application such as third party class libraries or JDBC drivers When you install an application into Tomcat or any other 2 2 2 3 compatible server the classes in the WEB INF classes directory as well as all classes in JAR files found in the WEB INF lib directory are made visible to other classes within your particular web application Thus if you include all of the required library classes in one of these places be sure to check licenses for redistribution rights for any third party libraries you utilize you will simplify the installation of your web application no adjustment to the system class path or installation of global library files in your server will be necessary Much of this information was extracted from Chapter 9 of the Servlet API Specification version 2 3 which you should consult for more details Shared Library Files Like most servlet containers Tomcat also supports mechanisms to install library JAR files or unpacked classes once and make them visible to all installed web applications without having to be included inside the web application itself The details of how Tomcat locates and shares such classes are described in the Class Loader HOW TO documentation The location commonly used within a Tomcat installation for shared code is CATALINA HOME lib JAR files placed here are visible both to web applications and internal Tomcat code This is a good place to put JDBC drivers that are required for both your application or internal Tomcat use such as for a JDBCRealm Out of the box a standard Tomcat installation includes a variety of pre installed shared library files including The Servlet 3 0 and JSP 2 1 APIs that are fundamental to writing servlets and JavaServer Pages An XML Parser compliant with the JAXP version 1 2 APIs so your application can perform DOM based or SAX based processing of XML documents Web Application Deployment Descriptor As mentioned above the WEB INF web xml file contains the Web Application Deployment Descriptor for your application As the filename extension implies this file is an XML document and defines everything about your application that a server needs to know except the context path which is assigned by the system administrator when the application is deployed The complete syntax and semantics for the deployment descriptor is defined in Chapter 13 of the Servlet API Specification version 2 3 Over time it is expected that development tools will be provided that create and edit the deployment descriptor for you In the meantime to provide a starting point a basic web xml file is provided This file includes comments that describe the purpose of each included element NOTE The Servlet Specification includes a Document Type Descriptor DTD for the web application deployment descriptor and Tomcat enforces the rules defined here when processing your application s WEB INF web xml file In particular you must enter your descriptor elements such as filter

    Original URL path: http://ticket.eppa.es/docs/appdev/deployment.html (2015-09-25)
    Open archived version from archive

  • Application Developer's Guide (7.0.22) - Source Organization
    to upgrade to a different version of that JAR file Therefore this manual recommends that you NOT store a copy of the packages you depend on inside the source control archives of your applications Instead the external dependencies should be integrated as part of the process of building your application In that way you can always pick up the appropriate version of the JAR files from wherever your development system administrator has installed them without having to worry about updating your application every time the version of the dependent JAR file is changed In the example Ant build xml file we will demonstrate how to define build properties that let you configure the locations of the files to be copied without having to modify build xml when these files change The build properties used by a particular developer can be customized on a per application basis or defaulted to standard build properties stored in the developer s home directory In many cases your development system administrator will have already installed the required JAR files into the lib directory of Tomcat If this has been done you need to take no actions at all the example build xml file automatically constructs a compile classpath that includes these files Source Code Control As mentioned earlier it is highly recommended that you place all of the source files that comprise your application under the management of a source code control system like the Concurrent Version System CVS If you elect to do this every directory and file in the source hierarchy should be registered and saved but none of the generated files If you register binary format files such as images or JAR libraries be sure to indicate this to your source code control system We recommended in the previous section that you should not store the contents of the build and dist directories created by your development process in the source code control system An easy way to tell CVS to ignore these directories is to create a file named cvsignore note the leading period in your top level source directory with the following contents build dist build properties The reason for mentioning build properties here will be explained in the Processes section Detailed instructions for your source code control environment are beyond the scope of this manual However the following steps are followed when using a command line CVS client To refresh the state of your source code to that stored in the the source repository go to your project source directory and execute cvs update dP When you create a new subdirectory in the source code hierarchy register it in CVS with a command like cvs add subdirname When you first create a new source code file navigate to the directory that contains it and register the new file with a command like cvs add filename If you no longer need a particular source code file navigate to the containing directory and remove the file Then deregister it in CVS

    Original URL path: http://ticket.eppa.es/docs/appdev/source.html (2015-09-25)
    Open archived version from archive

  • Application Developer's Guide (7.0.22) - Development Processes
    CVS commit your changes are local to your own development directory Committing makes those changes visible to other developers on your team that are sharing the same CVS repository The next step is to customize the Ant properties that are named in the build xml script This is done by creating a file named build properties in your project s top level directory The supported properties are listed in the comments inside the sample build xml script At a minimum you will generally need to define the catalina home property defining where Tomcat is installed and the manager application username and password You might end up with something like this Context path to install this application on app path hello Tomcat 7 installation directory catalina home usr local apache tomcat 7 0 Manager webapp username and password manager username myusername manager password mypassword In general you will not want to check the build properties file in to the CVS repository because it is unique to each developer s environment Now create the initial version of the web application deployment descriptor You can base web xml on the basic web xml file or code it from scratch cd my home directory cd myapp web WEB INF emacs web xml cvs add web xml cvs commit Note that this is only an example web xml file The full definition of the deployment descriptor file is in the Servlet Specification Edit Source Code and Pages The edit build test tasks will generally be your most common activities during development and maintenance The following general principles apply As described in Source Organization newly created source files should be located in the appropriate subdirectory under your project source directory Whenever you wish to refresh your development directory to reflect the work performed by other developers you will ask CVS to do it for you cd my home directory cd myapp cvs update dP To create a new file go to the appropriate directory create the file and register it with CVS When you are satisfied with it s contents after building and testing is successful commit the new file to the repository For example to create a new JSP page cd my home directory cd myapp web Ultimate destination is document root emacs mypage jsp cvs add mypage jsp build and test the application cvs commit Java source code that is defined in packages must be organized in a directory hierarchy under the src subdirectory that matches the package names For example a Java class named com mycompany mypackage MyClass java should be stored in file src com mycompany mypackage MyClass java Whenever you create a new subdirectory don t forget to register it with CVS To edit an existing source file you will generally just start editing and testing then commit the changed file when everything works Although CVS can be configured to required you to check out or lock a file you are going to be modifying this is generally not used Build

    Original URL path: http://ticket.eppa.es/docs/appdev/processes.html (2015-09-25)
    Open archived version from archive

  • Sample Application
    sure your browser doesn t change file extension or append a new one The easiest way to run this application is simply to move the war file to your CATALINA HOME webapps directory Tomcat will automatically expand and deploy the application for you You can view it with the following URL assuming that you re running tomcat on port 8080 as is the default http localhost 8080 sample If you

    Original URL path: http://ticket.eppa.es/docs/appdev/sample/ (2015-09-25)
    Open archived version from archive

  • Catalina Functional Specifications (7.0.22) - Administrative Apps - Supported Operations
    Resource Remove an associated JDBC Resource Create and configure a new Loader associated with this object Edit the configurable properties of the associated Loader Remove the associated Loader Create and configure a new Manager associated with this object Edit the configurable properties of the associated Manager Remove the associated Manager Create and configure a new Realm associated with this object Edit the configurable properties of the associated Realm Remove the associated Realm Create and configure a new Request Filter associated with this object Select and edit the configurable properties of an associated Request Filter Remove an associated Request Filter Default Context From the perspective of a particular Default Context it shall be possible to perform the following administrative operations Navigate to the owning Engine or Host Edit the configurable properties of this object Create and configure a new Environment Entry associated with this object Select and edit the configurable properties of an associated Environment Entry Remove an associated Environment Entry Create and configure a new JDBC Resource associated with this object Select and edit the configurable properties of an associated JDBC Resource Remove an associated JDBC Resource Engine From the perspective of a particular Engine it shall be possible to perform the following administrative operations Navigate to the owning Service Edit the configurable properties of this object Create and configure a new Access Logger associated with this object Edit the configurable properties of the associated Access Logger Remove the associated Access Logger Create and configure a new Default Context associated with this object Edit the configurable properties of the associated Default Context Remove the associated Default Context Create and configure a new Host associated with this object Select and edit the configurable properties of an associated Host Remove an associated Host Create and configure a new Realm associated with this object Edit the configurable properties of the associated Realm Remove the associated Realm Create and configure a new Request Filter associated with this object Select and edit the configurable properties of an associated Request Filter Remove an associated Request Filter Environment Entry From the perspective of a particular Environment Entry it shall be possible to perform the following administrative operations Navigate to the owning Context or Default Context Edit the configurable properties of this object Host From the perspective of a particular Host it shall be possible to perform the following administrative operations Navigate to the owning Engine Edit the configurable properties of this object Create and configure a new Access Logger associated with this object Edit the configurable properties of the associated Access Logger Remove the associated Access Logger Create and configure a new Context associated with this object Select and edit the configurable properties of an associated Context Remove an associated Context Create and configure a new Default Context associated with this object Edit the configurable properties of the associated Default Context Remove the associated Default Context Create and configure a new Realm associated with this object Edit the configurable properties of the associated Realm Remove the associated

    Original URL path: http://ticket.eppa.es/docs/funcspecs/fs-admin-opers.html (2015-09-25)
    Open archived version from archive