Centos Boot Linux Grub en Modo de usuario simple y Recuperar Clave Root

Tomado de:


Centos BootLinux en modo simple

Como inici Linixu Centos en single user mode?

A. Este modo es muy tulizado para corregir problemas del sistema operativo. Los siguientes pasos tiene que seguir para poder activarlo.

Procedimiento: Centos Boot Linux Grub Boot Loader en modo usuario simple

(1) En la pantalla del grub (Despues de Reiniciar)
(2) Selecione el kernel
(3) Presione e para editar la entrada.
(4) Selecione la 2da linea  (la linea que inicia con la palabra Kernel)

(5) Presione la letra e para editar  la entrada al kernel, ubiquese al final de la linea.
(6) Agregue la letra  S (o la palabra Single) al fin de la linea que contiene la palabra (kernel).

(7) Presione la tecla ENTER.
(8) Ahora presione la letra b para iniciar Centos - Linux  en modo usuario simple(single user mode)
(9) Cuando solciite el password de root, responda con el dato correcto para iniciar en modo simple


 

Recuperar clave de root en sistema Linux - CentOS

¿Has perdido la clave de root de tu sistema Linux? Tranquilo, calma… que ya te veo formateando…

Hoy voy a explicar como recuperar (más bien regenerar) la clave de root en un sistema CentOS Linux.

Lo primero que tenemos que hacer es reiniciar el sistema, y estar atentos al momento en el que se presente el GRUB en el arranque:

Una vez nos encontremos en el Grub, seleccionamos con las flechas el Kernel con el que queremos arrancar (o con el que arranquemos normalmente), y presionamos la letra E para editar la línea de arranque del Kernel, veremos algo parecido a esto:

Ahora usamos las flechas para ubicarnos sobre la línea que comienza por kernel… presionamos de nuevo la letra E para editar la línea, añadimos al final de la misma el número 1:

Presionamos la letra B, el kernel arrancará en modo single-user, en el cual podemos cambiar la clave de root con el comando passwd:

# passwd
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully

Finalmente, reiniciamos el sistema en modo normal y podremos loguearnos con el nuevo password de root.

 

 

Ideas sobre Tomcat y Jboss

Tomado de:
Comentarios sobre Tomcat y Jboss

Hola, Voy a desarrollar una aplicación web y estoy mirando que servidor de aplicaciones voy a utilizar. El servidor de aplicaciones lo voy a contratar con algún proveedor. Estoy informandome y estoy mirando servidores. He leido en varios sitios cual es la diferencia entre tomcat y los servidores de aplicaciones. Básicamente que tomcat no incluye contenedor de ejbs. Por ejemplo comparándolo con jboss: Servidor Web Container EJB Container Licencia TOMCAT SI NO OPEN-SOURCE JBOSS SI SI OPEN-SOURCE He seguido leyendo sobre ejbs, conceptualmente entiendo la diferencia (componentes que están contenidos en servidor en el ejb container), pero a efectos prácticos, por ejemplo, los ejbs de sesión (he leido sobre ellos) no me aportan nada funcion con respecto a beans de sesión que puedo usar en tomcat... ¿Alguien puede ponerme un ejemplo de algo que solo se pueda hacer por ejbs y que no se va a poder hacer con tomcat? ¿Cual es la diferencia entre un ejb y un servlet? ¿Cuando se debe utilizar cada uno?
RE: tomcat jboss ...		18/06/2010 08:13
izaera	Sin intención de ser exhaustivo: Primero distinguir entre EJBs y servlets. Los EJBs son servicios y los servlets son generadores de contenido (principalmente HTML). Es decir, un EJB es parecido a un objeto CORBA o COM (de M$) que exporta un servicio a traves de una interfaz conocida y que puede ser accedido de forma remota o local. Un servlet es una evolución de los CGI. Dicho esto, se puede conseguir algo similar a los EJBs con servlets. Por ejemplo: usando web services. Entonces, ¿cual es la ventaja de los EJBs? Que los gestiona el servidor de aplicaciones y por tanto los puedes configurar. Por ejemplo: puedes ejecutar cada EJB en una maquina distinta, puedes decir cuantas instancias quieres de cada EJB, puedes coordinar varios EJBs es una transacción distribuida, etc. Si usas POJOs (plain old java objects), es decir, implementas las funciones de tu aplicacion con Java pelado, el servidor de aplicaciones no puede controlar las instancias de tus objetos y si quieres una funcionalidad similar te lo tienes que hacer tu. Vista la diferencia, parece que mola usar EJBs, pero luego viene la realidad, como siempre, y ya la cosa no esta tan clara. Porque para obtener esa funcionalidad "extra" el nivel de complejidad de tus sistemas y de tu aplicacion se incrementa en varios ordenes de magnitud. Así que mi consejo es: usa Tomcat mientras puedas y pasa de JBoss. Y si en algun momento tenéis algun requisito que os obliga a usar funcionalidad de un servidor de aplicaciones, pues os pasais a JBoss y listos. Ten en cuenta que el "motor de servlets" de JBoss es Tomcat, asi que el paso no va a ser nada traumatico. Una cosa mas: esto que te he contado aplicaria a EJB2 y a EJB3, salvo a los "EJBs" de persistencia de EJB3 (los que representan filas de la BD), que se pueden ejecutar en Tomcat usando JPA (no necesitar servidor de aplicaciones, es una libreria, como por ejemplo Hibernate). Por supuesto, esta es mi opinion, otra gente puede tener otra y les animo a que la expongan pero cortesmente. Gracias majos :-P.
RE: tomcat jboss ...		18/06/2010 09:57
coutemeier	Coincido con Izaera, y aún más. Como veo que te estás introduciendo en el mundillo te sugiero dos cosas: Que no trates de entrar de golpe y porrazo con los EJB's, aprende antes las bases con tecnologías más ligeras. Quizás servlets sea un buen comienzo, mas yo intentaría aprender las bases de servlets para meterme con JavaServerFaces. Es una pasada para la inmensa mayoría de aplicaciones. En relación al servidor, antes que JBoss yo te propondría usar Glassfish por tres razones fundamentalmente: licencia CDDL y GPL, es comparable al JBoss y posee un ESB, ideal para webservices. A medida que vayas aprendiendo cosillas verás como compensa.
RE: tomcat jboss ...		18/06/2010 10:42
izaera	Respecto a JSF (antes de que se me adelante greeneyed :-)): Yo llevo usandolo casi desde que salio en conjuncion con Icefaces+facelets y la verdad, cada vez me decepciona mas. Se que es el estandar y que lo sera, y que se acabara imponiendo, y cada vez lo demandara mas gente. Y por ende, se acabara puliendo y acabara siendo medio util. Y que yo lo seguire usando durante bastante mas tiempo porque no me queda mas remedio. Sin embargo, desde que hicimos el famoso podcast de SPI jmarrranz y yo, y a raiz de mas conversaciones en los foros, pruebas con GWT, lecturas sobre otros frameworks, y cosas que he ido sufriendo en mis propias carnes, cada vez me gusta menos. Entre otras razones no me gusta: -El uso excesivo de memoria -El que tenga que ser centrico en el servidor por fuerza (con HTML5 yo soy de la opinion de que cada vez mas cosas van a ir al cliente, de ahi la importancia de GWT como framework cliente productivo) -La interaccion entre el arbol de componentes de JSF y los JSPS/Facelets esta especificada mal y es incoherente. Por mucho que se pula, siempre sera dificil saber donde se pueden usar determinados tags (c:if, c:choose) y donde no. -Las referencias "lazy" a las expresiones EL suponen una carga de CPU exagerada que en no todos los contextos esta justificada. -La curva de aprendizaje es alta porque el ciclo de vida de las peticiones es complejo y por la incoherencia en el uso de tags en facelets. Con esto no digo que se deje de usar y que sea una basura, porque funcionar funciona y lo tenemos en producción en varios clientes y hace su función. Solo digo que hay que pensarselo antes de escogerlo ciegamente, especialmente habiendo otros frameworks con filosofias muy diferentes y supuestamente mas sencillos. La elección de JSF en bastantes ambientes puede ser sub-optima. Por ultimo, no estoy seguro de que JSF vaya a ser un fiasco como EJB2, pero para mi gusto se esta acercando peligrosamente a serlo. Veremos si se endereza. Ojo: todo esto lo digo sin haber usado JSF2, pero por lo que se de JSF1 y por lo que he leido no creo que mejore drasticamente la situación. Y ahora si alguien es tan amable de argumentar a favor de JSF se lo agradeceré mucho puesto que me gustaría seguir creyendo, ya que lo voy a tener que seguir usando bastante tiempo, como he dicho.
RE: tomcat jboss ...		18/06/2010 12:15
anonymous	Estoy parcialmente de acuerdo contigo, pero hay algunos puntos que merece la pena revisar. Sí, consume mucha memoria, pero he visto algún artículo en el que se puede resolver por medio de compresión zip del estado. No puedo asegurarlo, pero creo que es la estrategia de JSF2 Estoy parcialmente de acuerdo con lo del centrismo en el servidor y con lo de HTML5. En realidad yo creo que se debe centrar en el servidor, pero que las especificaciones HTML deberían adaptar los controles que suministran (los input, select...) para tener de modo natural un comportamiento AJAX, más controles nuevos (date, combo editable, listas más potentes...) y reducir la dependencia del javascript o del código centrado en el servidor. Nunca se llegará a esto, poner de acuerdo a varios fabricantes es algo imposible, pero un acuerdo de mínimos podría reducir el coste del desarrollo de componentes visuales, que, al final, es lo que ve un usuario de una aplicación. JSF y Facelets se integran perfectamente, pero pretender que JSP y JSF y Faceletes se integren sin problemas es otro cantar. Cuando te refieres a las etiquetas c:if y c:choose te estás refiriendo a la jstl:core, que se debería evitar usar, puesto que es una adaptación de JSP, y el EL unificado, aunque resuelve, puede no resolver como esperamos en JSF, de ahí la diferencia entre el # y el $ (y aunque le pongamos # a la expresión, es el contexto del c:if el que determina cómo se resuelve). Yo no tuve excesivos problemas para entender el JSF, pero sí tuve más de uno para integrar el Facelets, desarrollar componentes en Facelets y usar el Richfaces. Una vez configurado un proyecto ya lo tuve para los demás. La ventaja de JSF2 es que Facelets es el motor de plantillas por defecto de JSF, aunque no lo he probado, yo entiendo que ya no es necesario configurarlo. Aparte d eque simplifica la creación de controles con respecto a JSF 1. Por otro lado no uso lazy en JSF, no da más que problemas, ya que las operaciones lazy presentan el problema de que cuando se accede a un sistema de persistencia es posible que cuando se intenta resolver el lazy la sesión se haya cerrado. A mi modo de ver el lazy es demasiado peligroso cuando de lo que se trata es de separar el acceso a datos de la vista. El ciclo de vida de las peticiones en JSF2 soporta atajos, para aquellos casos en los que no es necesario pasar por todo el ciclo de la petición (creo que se pensó para AJAX, sobre todo). Y que conste que no pretendo convencer, simplemente lo conozco mucho más que otros entornos, y doy mi opinión. De hecho, antes de JSF venía de usar Freemarker, que por su sintaxis me facilitó muchísimo el paso a JSF (Freemarker proporcionaba algo parecido al EL, con una sintaxis similar). Espero que esto pueda arrojar un puntito a favor de JSF, aunque es cierto que aún tiene que mejorar en velocidad, sobre todo. Pero no se puede tener todo.
RE: tomcat jboss ...		18/06/2010 12:20
coutemeier	La gracia de las sesiones... el último anónimo soy yo...
RE: tomcat jboss ...		18/06/2010 12:42
greeneyed	Simplemente añadir que ahora mismo la razón primordial para querer usar EJB de sesión sería el acceso remoto que proporciona el contenedor sin que tu tengas que montarte nada de RMI ni similares, o la integración con colas de mensajes de los EJB de mensajería. Eso o si se quiere entrar a tener un control de acceso muy refinado por componente en vez de funcionalidad. Para todo lo demás Master... digo... los servlets y sus amigos valen :). Lo EJB de entidad no hay que mencionarlos por que a los difuntos hay que dejarlos descansar no vaya a ser que se levanten, que están bien donde están ;). Y de JSF y similares no digo ná, que ya lo dicen los que lo usan más y no hace falta hurgar en la herida. El GlassFish personalmente no me mata mucho, está demasiado volcado al modelo empresarial y area de sistemas, y con el futuro incierto dentro de Oracle... en fin. No creo que sea mala elección, pero para empezar y usar "simplemente" servlets con el Resin o el Jetty vas que te matas. S!
RE: tomcat jboss ...		18/06/2010 12:46
izaera	Uff, compresion ZIP me suena a "no uso memoria pero uso CPU". Pero bueno esta claro que si hay que guardar el estado hay que guardar el estado, no se puede hacer magia. En cuanto a centrismo en el servidor a mi tambien me gusta mas y lo veo mas facil de desarrollar, pero tambien tiene mas problemas de escalabilidad y de alta disponibilidad si engordas mucho la sesion. Como siempre es una cuestion de contexto. Lo malo de JSF es que engorda la sesion y si no quieres, te ves obligado a mandar el estado de la UI en un campo hidden, lo cual permite alta disponibilidad pero es dudosamente eficiente. Otra opcion es serializar la sesion y replicarla entre servidores balanceados, pero tampoco es muy buena opcion, yo creo. Sobre las etiquetas JSTL al final se integran con JSF en facelets como en JSF. Un poco mejor, pero no mucho mejor. Mi queja es que hay dos momentos de evaluacion de etiquetas: al construir la vista y luego al renderizarla. Asi, por ejemplo, no siempre funciona meter c:ifs dentro de un dataTable por ejemplo o no puedes hacer un ui:include dentro de un control JSF. En general, analizando cada problema se puede encontrar una solucion, pero es complejo y requiere de mucha experiencia. Incluso en tomahawk estan haciendo falsos controles JSF para solucionar estos problemas que no son controles visuales en si, sino un poco, digamos, ñapas que simulan los c:if y los ui:include.  Y lo de lazy no me he explicado, no me referia a JPA, me referia a que las expresiones EL internamente crean un arbol de evalucion bastante complejo (uso de memoria y CPU) y que cada vez que se evaluan (y se evaluan muchisimas veces en cada renderizacion de pagina) tienen un coste muy alto de CPU. Ejemplo: si tu haces c:set var=pepito value=${x.y.z} y luego usas la variable ${pepito} en un control de JSF, cada vez que el control quiera acceder a pepito, el EL tiene que resolver que es x, luego llamar a getY dentro de x, luego a getX dentro de lo que devuelve, y finalmente pasarle el valor a JSF. Estaria bien que hubiese un modo de resolver la expresion al hacer el c:set y que no se evaluase mas. Aunque esto es cosa mas de EL que de JSF. En fin, lo de siempre, que no esta ni mal ni bien, tiene sus cosas buenas y sus malas. A mi personalmente me esta decepcionando un poco, pero quizas porque esperaba que fuese mas de lo que al final ha resultado ser para mi. No desaconsejo totalmente su uso, pero desde luego ya no lo aconsejo tanto como antes ;-).
RE: tomcat jboss ...		18/06/2010 17:59
coutemeier	Sí, siempre que se habla de compresión es a costa de CPU. Ahí es donde entra en juego el viejo equilibrio entre cpu-memoria-coste. De cualquier forma, tampoco es que tengas que comprimir 1Gb de información, así que, a priori, tampoco es un coste tan grande.  JSF engorda la sesión, sí, y volvemos al tema del punto anterior: cpu-memoria-coste. Pero este engordamiento no es gratuito en el sentido de que se hace de una forma para proporcionar un control sobre una serie de aspectos que sea más o menos sencillo de acceder. Personalmente no me gusta que el estado viaje al cliente en un campo oculto. En cuanto a la evaluación EL a eso me refería yo con lo de # y $, y las adaptaciones que se han hecho para usar los tags propios de JSP en JSF. Pero no es realmente una integración, sino una adaptación, ya que los jstl:core se resuelven en el contenedor del JSP, y JSP tiene conceptos como el Page scope que no existen en JSF. Por ejemplo, el c:forEach, este problema está documentado en la especificación de JSF. Resumiendo, puedes usar las etiquetas, pero tienes que entender cuál es el contexto en el que se van a resolver. No niego que las uso, pero en muy contadas ocasiones. En cuanto al sistema de resolución de EL básicamente han optado por una estructura de tipo Map. Y curiosamente, los List, o los propios Map, no funcionan muy bien, porque un #{lista.size} o #{lista.size()} no resuelven correctamente, ya que por la especificación se espera que exista un método lista.getSize(). Pero eso se resuelve fácilmente con una implementación de un Resolver para que resuelva las propiedades de un List o de un Map. A mí ni me impresiona ni me decepciona, simplemente hace lo que necesito; cuando necesito más lo extiendo (si soy capaz), y si no a otra cosa mariposa. Yo sí lo aconsejo, porque no estoy limitado por CPU ni por memoria (al menos no de momento). Más adelante ya veremos. Y sobre el Glassfish, yo creo que sí tiene futuro, aunque distinto al que inicialmente se había previsto. Probablemente, acabaremos viendo una versión OpenGlassFish (como le pasó al OpenJDK), que será la base y contendrá lo mejor (y quizá también lo peor) de GlassFish y del servidor de Oracle. Tiempo al tiempo. Y espero que además, la licencia del GlassFish permita hacer un fork para continuar con el desarrollo del GlassFish llamémoslo tradicional, el que conocemos hoy en día, para no tener que cambiar al de Oracle, que sinceramente, como emrpesa y orientación de sus productos, cada día me decepciona más. Un saludo, da gusto tener intercambio de opiniones sobre el tema.
RE: tomcat jboss ...		18/06/2010 18:14
izaera	Leyendo tu post, quiza sea eso lo que mas me decepciona de JSF: que estaba llamado a ser el estandar de desarrollo de aplicaciones web y al final hay que ser ingeniero espacial para usarlo. Ya se que estoy exagerando, pero ponte tu a contarle las sutilezas del uso de tags ui:include y c:if a un novato. O que las expresiones EL se componen en una pasada pero se evaluan en un momento u otro segun donde las estes poniendo en la pagina y quien las evalua. Lo fliparia y no creo que lo llegase a entender hasta darse varias veces de cabezazos con ello. No puedo dejar de imaginarme el tipico equipo de desarrollo de la megaconsultora chupiguay lleno de primerizos programando en JSF sin haberse leido ni un folleto sobre el tema, y me recorre un escalofrío la espalda del que me cuesta recuperarme :-D. Seria interesante saber, si marioko anda por ahi, porque se paso a ZK despues de Icefaces. Seguro que tambien tenia un punto de vista interesante sobre el asunto. Marioko, ¿andas por ahi? ¡Manifiestate! Ah, y a mi tambien me mola hablar de estos temas "filosoficos". Ya lo habréis notado ;-).
RE: tomcat jboss ...		18/06/2010 20:45
greeneyed	Al igual que la compresión o no es un tema CPU/memoria, hay otro tema que hay que equilibrar y es el de la funcionalidad-abstracción vs comprensión-facilidad de uso. Sun suele(solía) pecar en algunos casos (especialmente en Java EE) de hacer especificaciones pensando en mega-corporaciones para casos de uso complejísimos, olvidándose de los casos sencillos y la gente "común", y luego salen estas cosas hiper-flexibles, extensibles, mega-especificadas que para hacer una cosa sencilla son un dolor de cabeza. Pero bueno, sus cosas buenas tienen... supongo ;). Nosotros en el equilibrio optamos por separar limpiamente las capas y tendemos a la simplicidad para que cada una sea más sencilla de entender, con el consiguiente coste en esfuerzo extra. Tiene sus pros y sus contras, como todo, pero a nosotros nos sirve y eso es lo importante: encontrar algo que te sirva para tu equipo y tus tipos de proyecto.
RE: RE: tomcat jboss ...		21/06/2010 11:50
coutemeier	Como greeneyed yo también creo que Sun ha hecho un gran esfuerzo pensando siempre en una arquitectura para proyectos excesivamente complejos. Eso no quiere decir que siempre se deba aplicar siempre esa arquitectura, sino que si la conoces y sabes aplicar en su momento lo que más conviene a tu problema, tendrás menos problemas que si lo haces a tu manera. También opino como greeneyed que al final como se trata de construir algo en lo que puede colaborar mucha gente y que se puede desmadrar fácilmente, cuanto más separadas estén las distintas capas entre sí mejor. Por ejemplo, yo soy un anti Spring, y reconozco que está muy bien, y que posee sus virtudes, pero cuando me hablan de usar Spring, y me dan cincuenta mil razones por las cuales debería usarlo, por poner un ejemplo, siempre pregunto lo mismo, ¿en qué lo quieres utilizar? JSF fue una reacción de Sun a una necesidad. No creo que sea tan mala, pero creo que es importante conocer sus limitaciones antes de decidirse a usarla. Y creo que el EL es bastante útil (es mejor hablar de EL unificado más que de EL) y muy potente, pero que se diseñó en el contexto JSF, y ahí es donde realmente tiene sentido, por lo que intentar aplicarle conceptos de JSP sólo puede llevar a confusión. JSF no es JSP. Creo que el gran error de Sun fue crear esa adaptación de las librerías JSTL con una mezcla de JSP y JSF. Desde mi punto de vista, deberían haberlas diseñado de nuevo bajo el modelo JSF, pero con el cuento de la reusabilidad (reusar los componentes de JSP) le han hecho mucho daño a JSF sin que las causas se le puedan atribuir a JSF. Pero el problema de esta confusión es que Sun no se distingue por ser muy claro con JSF. En su momento en otro post, había comentado que para diseñar mi primer control JSF había encontrado como tres o cuatro modelos de ejemplos, de los cuales sólo uno me funciono. Había mucha información, pero la información de calidad en este tema brillaba por su ausencia. Por otro lado, seguro que podría prescindir de JSF en muchos de mis proyectos (ya os comenté que empecé con el Freemarker, gran motor de plantillas), seguro que añadiéndole un frontend decente ya contaría con la mayoría de opciones que necesito hoy en día. Pero por comodidad (el plugin de JBoss es impresionante), uso JSF. Por eso y porque realmente es más que suficiente para lo que necesito. De hecho, mientras que otros apuestan por Spring para hacer cualquier proyecto yo procuro buscar un compromiso entre la complejidad de un proyecto y las tecnologías a aportar. Un apunte, la parte visual la diseño con Richfaces (por la ventaja que tiene la integración AJAX, sobre todo), así que tengo una interface muy completa. Decía un anuncio de la tele que la potencia sin control no sirve de nada, y el dicho popular que no puedes matar moscas a cañonazos. En esto pasa lo mismo. Lo mejor es conocer y decidir, y lo que a veces vale para uno, no es tan adecuado para otro con el mismo problema.
RE: tomcat jboss ...		29/06/2010 04:46
anonymous	Gracias de responder tan ampliamente y ahondar en el tema de JSF, tambien lo que trabajado aunque no tan avanzado, como todo cosas buenas o malas.

Comparación entre Tomcat6 , Jboss y Geronimo

Tomado de:
Comparación entre Servidores EJB - Enlace en Ingles

Three open source Java application servers compared

By Jonathan Campbell, JavaWorld.com, 12/11/07

Open source Java EE application servers like JBoss, Tomcat, and Apache Geronimo easily stand up to their commercial counterparts, and actually lead the market in innovation. All open source Java EE application servers are not created equal, however. In this article, Jonathan Campbell compares JBoss 4.2, Geronimo 2, and Tomcat 6 based on features, deployment, and performance.

Java Enterprise Edition (Java EE) application servers are the Web-enabled standard when it comes to application development for the enterprise. While there are commercial options, studies have shown that open source technology has become a familiar, if not essential, part of the corporate IT infrastructure. JBoss 4.2, Geronimo 2, and Tomcat 6 are three widely used open source Java EE servers. Of the three, JBoss and Tomcat hold the majority share of the market, although neither one is fully Java EE compliant. The fully Java EE compliant Geronimo, meanwhile, is quickly gaining momentum. If you want to compete in the Java EE job market, you should be familiar with all three of these open source servers and understand how they differ.
In this article I compare the three leading open source Java application servers based on features, deployment, and performance. I explain why the various features found in each app server matter, and also offer some insight into where each server might fit into your enterprise development architecture. My discussion includes commentary from Chantal Yang of Red Hat and Jeff Genender of the Apache Software Foundation.

Java enterprise features comparison

Table 1 offers a snapshot view of how JBoss 4.2, Tomcat 6, and Geronimo 2 compare in their delivery of Java EE features. Note that features marked partial are not completely supported by the server, requiring you to install additional packages. If a feature is marked available you must install a third-party package to use it.
All three servers have been tested on Linux, Solaris, Microsoft Windows, and Mac OS X. JBoss has also been tested on HP-UX and AIX, and Tomcat on AIX. You'll find more information about each of these features, and why they matter, following the table.

Table 1. Java EE feature comparison

Feature	JBoss 4.2	Geronimo 2	Tomcat 6
Java EE 5 compliance	Partial	Yes	No
EJB 3.0 capable	Yes	Yes	Available
JSP 2.1 and Servlet 2.5 capable	Yes	Yes	Yes
JavaServer Faces 1.2 support	Yes	Yes	Available
Custom plug-in support	Yes	Yes	No
Business-rules engine support	Available	Available	Available
Hibernate 3.x support	Yes	Available	Available
JBoss Seam support	Yes	Yes	Available
Clustering support	Yes	Yes	Partial
Eclipse IDE connector support	Yes	Yes	Yes

Geronimo 2 is the clear choice if your Java application needs are particularly extensive or if you just want to leverage total Java EE 5 compliance. Although JBoss 4.2 is not completely compatible with Sun's Java EE 5 standard, the JBoss 4.2 team is responsible for many of the cutting-edge technologies used by all of the servers and added to the standard Java EE 5 capabilities. Tomcat 6 by itself is a lightweight solution. It does not come with all the JEE features and additional packages found in JBoss and Geronimo, but also doesn't require much memory and runs fast even on smaller servers.
Now, let's look at why these features matter.

Java EE 5 compliance

Java EE compliance is an important issue if your enterprise Java applications must be fully compatible with Sun's Java EE 5 server features. Geronimo 2 is the only one of the three servers that is fully Java EE 5 compliant. JBoss 4.2 supports most Java EE 5 features, and Red Hat will soon release JBoss 5, which will be fully compliant with Java EE 5. Tomcat is a JSP/servlet container that supports only basic Java application server features.

EJB 3 (Enterprise JavaBeans) capable

Enterprise JavaBeans (EJB) is a Java component architecture for application development on Java EE servers. It allows you to package functionality into reusable components. Earlier versions of EJB are considered to be difficult for development, even though it was intended to be a development advantage. The new EJB 3 is supposed to solve the difficulties associated with earlier versions and offer some new functionality. Both JBoss 4.2 and Geronimo 2 support EJB 3. Tomcat 6 by itself does not offer EJB 3 compatibility, but the Apache OpenEJB project can be embedded in Tomcat for EJB 3 support. According to Jeff Genender of the Apache Software Foundation, Tomcat can also run an embeddable version of the JBoss EJB 3 container.

JSP 2.1 and Servlet 2.5 capable

JSP/servlet features are the most basic capabilities for any Java server. JSP 2.1 and Servlet 2.5 are the new Java EE 5 versions of JSP/servlet capabilities. JBoss 4.2, Geronimo 2, and Tomcat 6 all support these new JSP/servlet versions.

JSF 1.2 support

JavaServer Faces is a Java EE application-development architecture that makes development of Web-based user interfaces easier. Instead of a request-driven MVC (model-view-controller) architecture, JSF uses a component-based approach. JSF 1.2, the current version, is supported by JBoss 4.2 and Geronimo 2. JSF 1.2 runs on Tomcat 6 but problems have been reported.

Custom plug-in support

Plug-in support refers to an architecture for incorporating new functions and features into the server. JBoss calls its plug-in development features MBeans (managed beans), and Geronimo has similar functionality, called GBeans. These custom beans provide a set of interfaces for developing and managing custom resources that can in turn be reused as plug-in components.
Geronimo takes plug-ins a step further, according to Jeff Genender:

With Geronimo, you can pick and choose from a plethora of components to build an application-server stack that fits your needs. For example if you wanted to install the Liferay portal, or Apache Directory server, you would add the URL in the management console and install the plug-in over the Net. The plug-in management system retrieves all of the dependencies that are needed and installs those as well.

Geronimo also has custom assemblies, which Jeff summarized as

[t]he ability to make an application as light or heavy as you want it. You can use the full Java EE 5 stack which includes all the components, or you can use Little G, which is just Geronimo with a Web container, or Micro G [...] which is just the Geronimo kernel and a perfect base for SOA and ESB solutions. You can add and remove components, providing only the ones you want to make use of. If you don't need EJB, you can simply remove the component from the console.

Chantal Yang of Red Hat says that JBoss 4 offers the advantage of an application server built "from the ground up using a micro-kernel architecture." According to Yang, this enables JBoss to "plug in a variety of components to create a custom application server footprint."
Yang also stated that JBoss 5 and its micro-container will greatly improve on the plug-in support of MBeans. According to Yang, no other application server has "such an evolved POJO-based micro-container at its heart."

Business-rules engine support

Most every application is built around some set of business rules, also called business logic. A business-rules engine component can make business-logic programming much easier to manage. In most programming, the if/then basic logic is all you have to work with. A business rules engine lets you implement much more intelligent logic with ease. JBoss 4.2, Geronimo 2, and Tomcat 6 support Drools, a popular, standards-compliant, and powerful business-rules engine. Although Geronimo is a fully Java EE 5 certified server that can run Drools, JBoss has provided Drools support for three years as of this writing, making JBoss/Drools a stronger business-rules solution. JBoss has recently rebranded Drools, naming it JBoss Rules. The Drools project itself started in 2001.

Hibernate 3.x support

Hibernate provides object-relational mapping (ORM) services for the Java language. Its easy-to-use framework lets you map an object-oriented model into a traditional relational database, which is a powerful advancement for Java development. Put simply, Hibernate manages persistence by allowing you to store POJOs in an SQL database of virtually any type. The SQL data access is then transparent to your application, making application data and object management much easier.
Hibernate is an open source package, originally developed by a team led by Gavin King of JBoss. It now runs on many Java EE servers, and works with J2SE as well. JBoss 4.2, Geronimo 2, and Tomcat 6 all support Hibernate 3.

JBoss Seam support

JBoss Seam is a powerful application framework that unifies a number of Java and Web technologies such as asynchronous JavaScript and XML (Ajax), JSF, EJB 3, Java Portlets, and business-process management (BPM).
Seam is a JBoss project, so JBoss 4.2 naturally supports it, as does Geronimo 2. According to the makers of Seam, they have ensured that Seam applications can run on Tomcat using the JBoss embeddable EJB 3 container.

Clustering support

Clustering is the term for running several parallel servers, all of which provide the same services, yielding what's often called "high availability": because more clients can be supported by your cluster of servers, if one servers in the cluster dies, the other servers will still support the clients. In the case of Java EE servers, the Java applications are still accessible even if one server in the cluster dies. Clustering provides scalability for enterprise Java applications, improves performance, and eliminates a single point of failure.
JBoss 4.2, Geronimo 2, and Tomcat 6 all support clustering in some way. According to Chantal Yang, JBoss uses a "high-performance and reliable clustering layer through buddy replication and fine-grained replication." On Geronimo 2, a patch made to correct clustering issues was released recently, so there may still be some testing to be done with Geronimo on this point. If you are interested in using Geronimo with clustering, consult the Apache Software Foundation.

Eclipse IDE support

Eclipse is arguably the most popular IDE for Java development, so integrating it with your Java EE server is one way to foster good development. JBoss, Geronimo, and Tomcat all support Eclipse integration. JBoss has its own version of Eclipse, called Red Hat Developer Studio, which is in beta at the time of this writing.

Installation and deployment

Installation notes
Tomcat 6 and JBoss 4.x are packaged in a tar file using GNU's tar command. Solaris, Mac OS X, and other Unix systems with a non-GNU tar command will not be able to expand the GNU tar file. Solution: simply get the GNU Tar program. Geronimo has downloads specific for non-GNU Unix-type systems, so you won't encounter this problem with Geronimo installs.

Installing all three of the Java servers under test is extremely easy. Aside from expanding the downloaded zip or tar package, all you need to do is set the JAVA_HOME environment variable to point to your Java 1.5 installation. You must set this environment variable before running the startup or shutdown scripts to start and stop these servers. Note that with Linux/Unix systems you might need to issue a chmod command to give execute permissions to the scripts.

Deployment

Geronimo 2 really shines when it comes to general configuration and deployment. I found it a breeze to configure and deploy a Java application through its Web console (see Figure 1 below). As Jeff Genender explains

The Geronimo console includes a lot of different wizards to help make the configuration of the application server as simple as possible. Geronimo includes wizards that allow you to test database connection pools, security realms, etc. [...] Instead of having to edit XML configuration, or stopping and restarting a server, you can walk through an easy to use wizard [... ]The database connection pool wizard will even download most drivers right off the Internet for you, so you do not have to find the proper driver for your database.

The Geronimo console also allows you to configure most features of its embedded Tomcat 6 container, without ever needing to touch an XML configuration file.

Figure 1. Geronino Web console (click for larger image)

 Boss 4.2 also has a nice-looking management console (see Figure 2), but it doesn't provide near the feature set of Geronimo. It primarily gives you JBoss status and monitoring information, and it lacks deployment features. To deploy an application you simply copy it to the default /deploy directory, after which it is automatically and quickly deployed. Optionally, you can set your own custom deployment directory by specifying it in the jboss-service.xml configuration file.

Figure 2. JBoss Web console

Tomcat 6 is quick and slim, true to form for a lightweight application server. It provides a nice Web console with the basic features that you need (see Figure 3). You can start/stop and deploy/undeploy WAR applications from the Web-based Tomcat manager. It also provides most of the status and monitoring information you would want. It has a good basic authentication system for the Web console too: you simply specify users/passwords in an XML file within one of the Tomcat server directories.

Figure 3. Tomcat Web console

Performance benchmarks

Along with reliability, performance is perhaps the most important feature for an application server. To benchmarks the servers, I did a simple test with a JSP page and a compiled servlet to see how many user application sessions the servers would handle and how fast they would connect users. Real-world Java applications are large. My test JSP and servlet were small, serving only to test the basic scalability, reliability, and speed of these servers.
Using my dual-core 64-bit CPU server with 4 GB of RAM, I was able to get all three Java servers to run up to 1.2 million concurrent sessions. That doesn't mean simultaneous connections, but it means maintaining concurrent unique user sessions that browser clients connect to. I could surely have gotten more then 1.2 million if I had more memory.
Figures 4 and 5 show the benchmark results.

Figure 4. Starting massive quantities of JSP sessions

Figure 5. Massive hits on a servlet checking the sessions

The code used for gathering these benchmarks was a few hundred lines long. For accuracy, I used the same configuration for each server test. With real-world Java EE applications, each session would maintain much more data then my test, so you wouldn't get the massive numbers I did unless you ran a mid-range server with eight processors and lots and lots of RAM.
JBoss 4.2 did not do quite as well as Geronimo 2 because Geronimo is newer and uses more up-to-date internals. Tomcat 6 did the best of all because it is a lightweight server specifically designed for JSP/servlet services, which is what I benchmarked. Tomcat takes 3 seconds to start up compared to about 20 seconds for JBoss or Geronimo.
If these servers run out of memory, they are inclined to crash. I once had a Java: null pointer exception with JBoss 4.2 on trying to shut it down, even though it hadn't run out of memory. Geronimo and Tomcat both seem to stall badly when they run out of memory, and I had difficulty just shutting them down at that point.

In conclusion

I have installed and deployed Java applications on both commercial Java application servers (such as Sun's Java Application Server and BEA WebLogic) and on open source alternatives. In my experience commercial application servers have more bugs than the open source servers compared in this article, and they are more difficult to install. Deployment can also be an issue -- at least with the recent version of Sun's Java Application Server.
Bottom line: JBoss, Geronimo, and Tomcat are reliable, fast, and definitely able to handle the traffic on large-scale enterprise applications. Furthermore, many of the high-demand Java server technologies presented in the features comparison originate from the open source world, not the commercial one.
In this article I've compared three popular open source JEE application servers based on features, deployment, and performance. The features comparison should help you determine which of these open source options best suits the needs of your application environment, and the performance benchmarks should help you round out your consideration.

About the author

Jonathan Campbell holds more than 15 IT certifications and works as a project manager. He has been developing software for various flavors of Unix since the late 1980s and for Windows since the mid 1990s. He also has expertise in network engineering and integration of Unix, Linux, and Windows platforms. He has worked for various corporations and the United States government.

 Tomado de:

Comparacion entre Tomcat6, Jboss, Geronimo y Glassfish

Four open source Java application servers compared

Posted by kalali on December 11, 2007 at 1:11 PM PST I was looking at feeds that my email client fetched during the day and I find am interesting one which lead me to an article written by Jonathan Campbell. Article can be found at http://www.javaworld.com/javaworld/jw-12-2007/jw-12-appservers.html Jonathan compared 3 different application server/ servlet container by thier support of Java EE 5 and some other factors. article explained about each feature that he compared application servers based on it. Jonathan did not included GlassFish in his review of "open source Java application servers" and only included 3 application servers/ Servlet containers including Tomcat, Jboss and Geronimo. :-), So I thought I should include some facts here in order to make the comparison fair to all parties. Including Glassfish into Jonathan matrix will give us the following table: *Notice* Feature JBoss 4.2 Geronimo 2 Tomcat 6 GlassFish 2 Java EE 5 compliance Partial Yes No Yes EJB 3.0 capable Yes Yes Available Yes JSP 2.1 and 2.5 capable Yes Yes Yes Yes JavaServer Faces 1.2 support Yes Yes Available Yes Custom plug-in support Yes Yes No ? Business-rules engine support Available Available Available Available Hibernate 3.x support Yes Available Available Yes, based on below description JBoss Seam support Yes Yes Available Yes Clustering support Yes Yes Partial Yes Eclipse IDE connector support Yes Yes Yes Yes Following descriptions further explain some of what Glassfish can provides in relation of the above table GlassFish fully support Java EE 5 with all its related JSRs like JSP 2.1 (JSR 245), Servlet 2.5(154), EJB 3.0(JSR 245), etc. GlassFish support clustering and cluster management out of the box, a cluster can be configured from both CLI and Administration console. GlassFish administration console allows you to configure your load balancer :-), for example you can configure a Sun Java Web Server which works as load balancer to add or add/ remove an instance from its list of servers, either manually or automatically if a new node joined the cluster or removed from the cluster GlassFish allows you to manage resources for entire cluster at once instead of applying them for each instance, for example you can deploy a web application into a cluster of 10 instances instead of deploying it seperately for each instance. GlassFish has a very wide array documentation both from Sun Microsystems (for free) and from GlassFish community. GlassFish installation is as easy as executing 2 commands. Deploying applications into GlassFish or even an entire cluster of glassfish instances is just 2 clicks away. Quality of GlassFish components is out of any question, Metro is well known for supporting new WS-* standards, EJB support uses Toplink Essentials, MQ server is Sun open sourced MQ, etc. GlassFish has very good interoperability with some other open source projects like, OpenESB and OpenSSO which allows you to have what you need to kick start your J2EE application without looking at any additional configuration. Certainly performance is something which everyone should have in mind before considering other feaures, take a look at http://www.spec.org/jAppServer2004/results/res2007q3/jAppServer2004-2007... and http://weblogs.java.net/blog/sdo/archive/2007/07/sjsas_91_glassf.html to find out more about how much capable GlassFish is. GlassFish has connectors for both Eclipse and Netbeans, although other mentioned servers have a connector in Netbeans and Eclipse. Seam support is available from GlassFish 1 upward. Business rule engine support is available from OpenESB project integration. About hibernate support, I cannot understand whether Jonathan means to use Hibernate as a persistence provider or plainly as an ORM, by the way both of this ?features? are available for GlassFish users. GlassFish has an Update center, which allows you to update your application server from a remote repository. GlassFish runs on all mentioned platforms, from Windows to AIX (Glasdfish 2 update 1 runs on AIX) and there is no restriction for you to run it on your platform of choice. Mentioned items are in relation to what orginal article tried to compare. GlassFish can be used by a ROR developer by its integration with first class ROR IDE (Netbeans 6), It can serve you VOIP and SIP requirement by means of sailfin,etc. Any user with any kind of requirement will find GlassFish a suitable application server. Although Jonathan did not mentioned GlassFish directly, but he gives his opinion by writing:In my experience commercial application servers have more bugs than the open source servers compared in this article, and they are more difficult to install. Deployment can also be an issue -- at least with the recent version of Sun's Java Application Server. The article could be more complete if Jonathan included GlassFish in his comparsion chart and at then end he could write that GlassFish has problematic deployment procedure An statement which looks odd to me is: In my experience commercial application servers have more bugs than the open source servers compared in this article, and they are more difficult to install., Althogh it will be a complex procedure to setup a Cluser of Websphere (as a commercial application servers ) using websphere XD, Object Grid, and other available packages that faciliate enterprise scale deployment of Websphere, but WebSphere has a decent performance and reliability which is very hard to deny. Notice: Some parts of this table taken from Jonathan Campbell article published by javaworld and is available at http://www.javaworld.com/javaworld/jw-12-2007/jw-12-appservers.html

No usar mapeo para servlets en JBoss y Mejorar Rendimiento JBoss

Tomado de:

No usar mapeo para servlets en JBoss

   Si no desea mapear cada servlet en web.xml del JBoss y desea llamarlos directamente incluyendo el paquete y el nombre del Servlet, entonces agregue lo siguiente en el archivo web.xml de la aplicacion.

.......
    <servlet>
        <servlet-name>invoker</servlet-name>
        <servlet-class>
          org.apache.catalina.servlets.InvokerServlet
        </servlet-class>
        <init-param>
            <param-name>debug</param-name>
            <param-value>0</param-value>
        </init-param>
        <load-on-startup>2</load-on-startup>
   </servlet>
 
   <servlet-mapping>
        <servlet-name>invoker</servlet-name>
        <url-pattern>/servlet/*</url-pattern>
   </servlet-mapping>
...... 

Mejorar rendimiento Jboss
Tomado de:
Tunning Jboss

Al final encontré en un foro que se trata de o bien modificar el fichero de configuración de JBoss ..\deploy\jbossweb.sar.context.xml añadiendo las propiedades reloadable="false" privileged="true"
También existe la posibilidad de crearte un context.xml en la aplicación que vayas a desplegar y así no tocas el de configuración del JBoss. De porque este cambio no lo sé ya que son mis primeros inicios en JBoss y he encontrado esto en un foro en internet.

Ahora que en el nuevo lugar de trabajo lidiamos a diario con servidores de aplicación JBoss, veamos algunos trucos para optimizar su funcionamiento.
El más importante de todos y en el que hicieron mucho hicapié es en el hot deploy. Para entornos de producción no se recomienda tenerlo activado, aunque si no queremos desprendernos de esta utilidad, siempre podemos prolongar su tiempo de chequeo. Veamos como hacerlo:
Editando el archivo de configuración jboss-service.xml ubicado en el directorio conf de nuestra configuración, tenemos que modificar:
<!-- A flag to disable the scans -->
<attribute name="ScanEnabled">true</attribute>
Cambiando a false ala variable, los despliegues en caliente se deshabilitarán.
Si por el contrario, decidimos ampliar los tiempos de búsqueda para nuevos despliegues, editaremos la siguiente entrada:
<!-- Frequency in milliseconds to rescan the URLs for changes -->
<attribute name="ScanPeriod">5000</attribute>
Podríamos ponerlo cada hora (3600000), no olvidemos que estos tiempos se miden en milisegundos.

JBoss es un servidor de aplicaciones que se ejecuta sobre la JVM, así que deberemos afinar y mejorar todo lo posible el rendimiento de esta, para que las aplicaciones que despleguemos sobre JBoss se ejecuten con la máxima eficiencia. Si esto lo sumamos a un buen diseño de las aplicaciones y una arquitectura adecuada (sin sobredimensionarla), obtendremos un resultado óptimo (tened en cuenta que siempre falla uno de los 3).
Es fundamental aplicar estas buenas prácticas no solo a JBoss, sino a servidores que trabajan sobre la JVM.
1.-Xms y Xmx
Asignar el mismo valor a cada uno de estos parámetros optimiza el trabajo dentro de la memoria, porque es donde se reserva la memoria que se va a usar, estando toda seguida y no espaciada por toda la memoria, cosa que dilataría la recuperación de información.
2.- GC
Este posiblemente sea uno de los aspectos más importantes a la hora de hacer más eficiente nuestro servidor de aplicaciones.
Lo que haremos será usar el sistema de recolección distribuido.
-Dsun.rmi.dgc.client.gcInterval=1800000
-Dsun.rmi.dgc.server.gcInterval=1800000
Por defecto el tiempo de acción es muy reducido, cada minuto, por lo que normalmente todos suelen establecerlo a 3600000 (una hora), en entornos de producción. En mi opinión esto no mejora mucho el rendimiento porque es dilatar demasiado esta acción, por ello debemos hacer que se ejecute ajustándolo a nuestras necesidades, el tiempo que mejor resultado me ha ofrecido es de 30 minutos.
No olvidemos que esta acción, penaliza mucho mientras se está ejecutando, porque está organizando gran parte de la memoria.
3.- Ejecución paralela
Podemos hacer que se ejecuten varios hilos del GC, consiguiendo que la cantidad de elementos organizados y eliminados sea mayor. -XX:+ UseParallelGC
Esto ejecutará tantos hilos como procesadores tenga nuestra máquina, quizás queramos que solo se encarguen 2 procesadores de esta tarea, así que podemos establecer el número máximo de hilos con el parámetro: -XX:ParallelGCThreads=2
4.- 70%
La memoria Heap no debe superar el 70% de la memoria física, para evitar errores de paginación y que la recolección de basura sea más eficiente.

 

Instalación JBoss 5 en CEntOS 5.4

Tomado de:


Instalacion de Jboss en Centos

Luego de instalar Java en un servidor CEntOS 5.4 me di a la tarea de instalar JBoss. Descargue la versión más actual de JBoss desde www.jboss.org, en este momento 5.1.0.GA. Como root hice las siguientes operaciones en orden para una instalación exitosa
Descomprimi JBoss

unzip jboss-5.1.0.GA

La moví a /usr/local, en donde supuestamente debe quedar la instalacion (lo digo porque los scripts estan direccionados a esa carpeta)

mv jboss-5.1.0.GA /usr/local/

Hice de /usr/local la carpeta actual

cd /usr/local

Renombre la carpeta de su nombre original a jboss (la forma linux de renombrar es mover hacia la misma carpeta actual con otro nombre)

mv jboss-5.1.0.GA jboss

Cree el grupo jboss

groupadd jboss

Cree un usuario y lo incorpore al grupo jboss

useradd -d /usr/local/jboss -g jboss jboss

Cambie el usuario de la carpeta recursivamente a jboss

chown jboss:jboss -R /usr/local/jboss

Copie un script que viene dentro de la distribucion hacia la inicializacion del servidor, desde esta carpeta uno puede iniciar como servicio las aplicaciones

cp /usr/local/jboss/bin/jboss_init_redhat.sh /etc/init.d/jboss

El archivo lo modifique y le incluí la linea

JBOSS_HOST=0.0.0.0

Finalmente inclui un enlace simbolico al inicio, con esto se iniciará el serivio cuando reinicie la máquina (obviamente debe ser modificado si posees un inicio grafico a rc5.d)

ln -s /etc/init.d/jboss /etc/rc3.d/S96jboss

/usr/local/jboss/bin/run.sh    <====== Arrancar el Jboss

Con todo esto aplicado en orden tienes un servidor JBoss funcionando en CEntOS, no lo he probado en alguna otra version de Linux, pero debería sufrir ligeras modificaciones.
Como nota aparte, si es qu tienes un firewall funcionando recuerda dar el permiso al puerto correcto

JBoss

De Atiwiki, la enciclopedia libre.

JBoss es un servidor de aplicaciones J2EE de código abierto implementado en Java puro. Al estar basado en Java, JBoss puede ser utilizado en cualquier sistema operativo que lo soporte. Los principales desarrolladores trabajan para una empresa de servicios, JBoss Inc., adquirida por Red Hat en Abril del 2006, fundada por Marc Fleury, el creador de la primera versión de JBoss. El proyecto está apoyado por una red mundial de colaboradores. Los ingresos de la empresa están basados en un modelo de negocio de servicios. JBoss implementa todo el paquete de servicios de J2EE (EJB, JMS, JTS/JTA, Servlets/JSP, JNDI, etc.) y también ofrece características tales como los clustering, JMX, Web Services y la integración IIOP, y la principal característica que desde que JBoss esta licenciado bajo la LGPL, puede libremente usarse sin costo alguno en cualquier aplicación comercial o ser redistribuirlo.

Instalaciòn y Configuración de JBoss

---

• Primero que todo debemos tener instalado y configurado JDK 1.3 o una versión mayor.
• Descargar una versión de JBoss, dicha descarga puede realizarse desde: www.jboss.org

(Cabe destacar que vamos a encontrar los archivos tanto en formato tanto .zip como tar.gz dependiendo si lo queremos para los sistemas operativos Windows o Linux).

• Una vez descargado el archivo .zip en el caso de Windows, debe descomprimirlo y colocarlo en el dirtectorio de nuestra preferencia.
• Por ejemplo si se tratara de la version se pudiese colocar en la siguiente ruta. (C:\jboss-4.0.0)
• Para correr dicho servidor de aplicaciones es necesario pararnos en el directorio (C:\jboss-4.0.0\bin) y ejecutar el archivo (run.bat), el cual levantara el servidor y atendera peticiones por el puerto por defecto el cual es el puerto 8080.
• Las aplicaciones que han de estan montadas en mencionado servidor deben ser colocadas en el siguiente directorio (C:\jboss-4.0.0\server\default\deploy).
• Una vez instalado JBoss, es creada la siguiente estructura de Directorio:

• bin: Contienes los scripts necesarios para abrir y cerrar el servidor de aplicación, como y
• client: Contine todos los archivos o archivos de biblioteca (.jar) necesarios para la parte del cliente que quiera comunicarse con el servidor JBoss.
• docs: Muestra las configuraciones de los archivos (Configuración de BD, etc).
• dtd: Para varios XML, que usados en JBoss
• lib: Archivos .jar cargadois al momento de correr el servidor y compartidos por toda la configuración de JBoss.
• server: Conyiene varias configuraciones de JBoss. Cada configuración debe estar en un diferente sub-directorio, el nombre del sub-directorio represneta el nombre de cada configuración. Por defecto JBoss contiene 3 configuraciones: minimal, default y all.
• server/all: Incluye la configuración completa de JBoss, levantando todos los servicios tales como clustering y IIOP.
• server/minimal: Solamente incluye lña configuración minimal levantando sólo los servicios muy básicos. Esta configuración no puede ser usada por los EJB.
• server/default: Esta configuración es usada por defcto.
• server/default/conf:
• server/default/db: Aqui van los archivos de configuración referntes a las BD.
• server/default/deploy: Este es el directorio donde deben ser colocadas todas aquellas aplicaciones que se quieran ser ejecutadas o levanatadas por el servidor, como por ejemplo EJB,EAR,WAR e inclusive servicios.
• server/default/lib: Aqui van los JARs caragados al momento de levnatar el servidor al momento de levnatar una configuración particular.
• server/default/log: Es un log de transacciones referentes a los servicios brindados y ejecutados por JBoss.
• server/default/tmp: Archivos temporales de JBoss.

INSTALACION ALTERNA DE JBOSS 5 EN CENTOS 5.4


a) instalar el JDK, tanto 1,5 y 1,6 son adecuados. I did the easiest way Hice la manera más fácil
yum install java-1.6.0*
check the installed JDK with the command java -version . comprobar el JDK instalado con el comando java -version . The output should look like (I'm running the server in a virtual machine): La salida debe ser similar (estoy corriendo el servidor en una máquina virtual):
java version “1.6.0″ java version "1.6.0"
OpenJDK Runtime Environment (build 1.6.0-b09) Entorno de ejecución OpenJDK (compilación 1.6.0-b09)
OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode) OpenJDK 64-Bit servidor de máquina virtual (compilación 1.6.0-b09, modo mixto)
b) install JBoss . b) instalación de JBoss.
There are 2 options. Hay 2 opciones. Installation with a binary package or compile yourself out of the source package. Instalación con un paquete de binarios o compilarlo uno mismo fuera del paquete fuente. Since I don't need some special settings, … I'll it install via the binary package. Dado que no necesita algunas configuraciones especiales, ... voy a instalar a través del paquete binario.
There are different versions of JBoss available: Existen diferentes versiones de JBoss disponibles:
JBoss Enterprise Application Platform – for highly transactional Java EE applications JBoss Enterprise Application Platform - altamente transaccional para aplicaciones Java EE
JBoss Enterprise Web Platform – for mid-sized, light and rich Java applications JBoss Enterprise Web de la plataforma - de tamaño mediano, ricas aplicaciones Java y la luz
JBoss Enterprise Web Server – for simple Java workloads that only require enterprise Apache Tomcat. JBoss Enterprise Web Server - para cargas de trabajo Java simple que sólo requieren de la empresa Apache Tomcat.
We need the Spring-functionality, therefore I use the second one, the Enterprise-Web-Platform-Edition. Necesitamos la primavera de funcionalidad, por lo tanto yo uso el segundo, el Enterprise-Web-Plataforma-Edition. Currently released version is 5.1, version 6.0 isn't finally released yet. Actualmente se lanzó la versión 5.1, la versión 6.0 no es finalmente liberado todavía.
Download and extract Descargue y extraiga

mkdir /srv
cd /srv

wget http://sourceforge.net/projects/jboss/files/JBoss/JBoss-5.1.0.GA/jboss-5.1.0.GA.zip 

jar -xf jboss-5.1.0.GA.zip

set environment variable JBOSS_HOME establecer la variable de entorno JBOSS_HOME

vi ~/.bashrc

add the following lines añadir las siguientes líneas
export JBOSS_HOME=/srv/jboss-5.1.0.GA exportación JBOSS_HOME = / srv/jboss-5.1.0.GA
export PATH=$PATH:$JBOSS_HOME/bin Export PATH = $ PATH: $ JBOSS_HOME / bin

and “source” it y "fuente" que

source ~/.bashrc
 
Now JBoss is ready to run, but there's one important note !!!! Ahora JBoss está lista para funcionar, pero hay una nota importante!!
By default JBoss listens only to localhost, keep this in mind, and provide the startup with the “-b 0.0.0.0″ if you want your installation be accessible from anywhere Por defecto JBoss escucha sólo a localhost, tenga esto en cuenta, y proporcionar el inicio con la opción "-b 0.0.0.0" si desea que su instalación sea accesible desde cualquier lugar
…startup ... De inicio
chmod +x $JBOSS_HOME/bin/*.sh
$JBOSS_HOME/bin/run.sh -b 0.0.0.0
…and test, point a browser to ... Y la prueba, punto un navegador para
http://:8080 http://:8080
create user jboss, under which jboss should be started crear jboss usuario, en virtud del cual se debe iniciar jboss
adduser jboss
chown -Rf jboss.jboss /srv/jboss-5.1.0.GA
and copy the init-script for starting/stopping jboss y copiar el init-script para iniciar / detener jboss
cd /srv/jboss-5.1.0.GA/bin
cp jboss_init_redhat.sh /etc/init.d/jboss
chmod +x /etc/init.d/jboss
vi /etc/init.d/jboss

adjust the parameters: ajustar los parámetros:
JBOSS_HOME,JAVAPTH, JBOSS_CONF and JBOSS_HOST, like => JBOSS_HOME, JAVAPTH, JBOSS_CONF y JBOSS_HOST, como =>
JBOSS_HOME=${JBOSS_HOME:-”/srv/jboss-5.1.0.GA”} JBOSS_HOME = $ (JBOSS_HOME: - "/ srv/jboss-5.1.0.GA")
JBOSS_USER=${JBOSS_USER:-”jboss”} JBOSS_USER = $ (JBOSS_USER: - "jboss")
JAVAPTH=${JAVAPTH:-”/usr/bin”} JAVAPTH = $ (JAVAPTH: - "/ usr / bin")
JBOSS_CONF=${JBOSS_CONF:-”default”} JBOSS_CONF = $ (JBOSS_CONF: - "por defecto")
JBOSS_HOST=”0.0.0.0″ JBOSS_HOST = "0.0.0.0"
JBOSS_BIND_ADDR=${JBOSS_HOST:+”-b $JBOSS_HOST”} JBOSS_BIND_ADDR = $ (JBOSS_HOST: + "-b $ JBOSS_HOST")

..done, ready to use JBoss…..but keep in mind, this was just the initial setup…..the real work isn't done yet…..configuration and adjust it to your needs will start right now .. Hecho, listo para usar JBoss ... .. pero tenga en cuenta, esto fue sólo la configuración inicial ... .. el verdadero trabajo no está hecho todavía ... .. de configuración y ajuste a sus necesidades comenzará ahora

Crear un Servicio JBOSS.

CHKCONFIG es una herramienta que permite a los administradores activar y desactivar servicios en los diferentes niveles de ejecucion.
En primera instancia solamente actuara bajo aquellos servicios que esten en su lista de trabajo.
Verifica con chkconfig --list que servicios estan siendo administrados con chkconfig
Es logico suponer que el script que deseas ejecutar por medio de chkconfig no esta considerado como un servicio puesto que recien fue creado.
man chkconfig indica que tu script debe tener un par de lineas
# chkconfig: 345 20 80
# description: Saves and restores system entropy pool for \
# higher quality random number generation.
La primera indicara los niveles en los que arrancara el servicio y la prioridad que tendra al ejecutarse. Y la segunda podra contener una descripcion de las bondades de tu script
Luego agregas tu script para que sea considerado como un servicio

chkconfig --add jboss

y Finalmente si le indicas que se levante

chkconfig --level 345 jboss on

Sitios Web para crear Botones

Crear Botones As Button Generator

The Free Web Stuff

My cool button 

Glassy Buttons