RECUPERACIÓN DEL INTEGRATED WEBLOGIC SERVER EN JDVELOPER 11

JDeveloper 11gR2 - Integrado Weblogic servidor Password Reset Hola a todos. Después de meses de trabajo con ADF Essentials, que necesitaba para iniciar sesión en la aplicación de la consola del servidor integrado Weblogic que viene con JDeveloper 11.1.2.3 (Weblogic servidor 10.3.5) y luego me di cuenta que se me ha olvidado la contraseña del usuario weblogic ... Así que me puse a buscar y encontré dos soluciones:

Solución 1: Elimine la carpeta de dominio predeterminado creado por el servidor Weblogic Integrado.
Solución 2: Generar una nueva contraseña para el usuario weblogic.

¿Cuál es la diferencia entre una solución de 1 y 2?

En la solución 1, perderá cualquier configuración que usted ha hecho a su servidor weblogic integrado, esto incluye: fuentes de datos, configuración de seguridad, etc.

En solución 2, perderá sólo configuraciones de seguridad que ha realizado. Por ejemplo, si ha creado más usuarios o grupos, o configurar el acceso a un servicio LDAP externo, pero se mantendrá todo lo demás. Tengo que decir que esta solución es más difícil que la solución 1.

Si usted no ha hecho ninguna configuración en el servidor Weblogic integrado, te sugiero que vayas con una solución de 1. Antes de continuar con las soluciones, primero tenemos que encontrar el directorio de sistema de IDE. Con el fin de hacer eso, JDeveloper abierta, vaya al menú Ayuda y seleccione la opción Acerca de. Una ventana emergente aparece, seleccione la ficha Propiedades y desplácese hacia abajo hasta que encuentre alguna de estas: ide.pref.dir o ide.system.dir o ide.user.dir

En un entorno Linux, puede encontrar algo como esto:

En un entorno de ventanas, puede encontrar algo como esto:

En realidad, el directorio que estamos buscando es la ide.system.dir por lo que permite anótelo para que podamos utilizarlo más tarde:

Linux (mi caso, la suya puede ser diferente)
SYS_DIR = / home / aalopez / .jdeveloper / system.11.1.2.3.39.62.76.1

De Windows (mi caso, la suya puede ser diferente)
SYS_DIR = C: \ Users \ CVDESA \ AppData \ Roaming \ JDeveloper \ system11.1.2.3.39.62.76.1

Hacer servidor Weblogic seguro se apaga antes de continuar.

Solución 1: Extracción de la carpeta DefaultDomain.
La primera y más fácil solución es quitar la carpeta siguiente (DefaultDomain):
SYS_DIR / DefaultDomain

La carpeta obtendrá re-creado para usted la próxima vez que inicie el servidor Weblogic. El problema es que usted perderá cualquier configuración que pueda haber hecho que incluye: usuarios, contraseñas, fuentes de datos, etc. Todo eso. Una vez que se quita la carpeta, JDeveloper abierta ir al menú Ejecutar, y seleccione la opción Start Server Instancia (IntegratedWeblogicServer). Una ventana emergente aparece pidiéndole que establezca las credenciales de usuario weblogic. ¡Eso es!

Solución 2: Cambiar la contraseña de usuario weblogic Por favor, siga los pasos a seguir con el fin restablecer la contraseña en un sistema Linux (Ubuntu 12.1), también se presentan los pasos para el sistema de Windows:

Linux
Ir a esta ruta: SYS_DIR / DefaultDomain / bin, donde SYS_DIR es el camino que hemos definido anteriormente. Ejecute el setDomainEnvironment.sh Ir a esta ruta: SYS_DIR / DefaultDomain / seguridad Cambie el nombre del archivo DefaultAuthenticatorInit.ldift a algo como oldDefaultAuthenticatorInit.ldift Exportar el archivo weblogic.jar a la ruta de clases, para que podamos crear una nueva contraseña para el usuario weblogic (en mi caso, el directorio de instalación de JDeveloper es / home / aalopez / Oracle): export CLASSPATH = $ CLASSPATH: /home/aalopez/Oracle/Middleware/wlserver_10.3/server/lib/weblogic.jar Ejecute el siguiente comando para crear la nueva contraseña. Observe que el comando tiene un punto al final, esto es necesario para que se cree la nueva contraseña en el directorio actual. Cambie NEW_PASSSWORD para la nueva contraseña del usuario weblogic: java weblogic.security.utils.AdminAccount weblogic new_password. Ir a esta ruta: SYS_DIR / DefaultDomain / servidores / DefaultServer Cambie el nombre del directorio de datos a algo como data_old Ir a esta ruta: SYS_DIR / DefaultDomain / servidores / DefaultServer / seguridad Cambie el nombre del archivo boot.properties a algo como oldboot.properties Crear un nuevo archivo boot.properties en el mismo directorio. Esto es necesario si se quiere autoconectarse al iniciar el servidor Weblogic desde dentro de JDeveloper. El contenido del archivo debe ser algo como lo siguiente (cambiar new_password la contraseña que ha definido en los pasos anteriores): nombre de usuario = weblogic password = new_password Es hora de probar nuestros cambios. Ir a esta ruta: SYS_DIR / DefaultDomain / bin Ejecute el archivo startWeblogic.sh y verifique que el servidor Weblogic inicia sin excepciones. Abra un navegador y escriba la siguiente dirección URL (el puerto puede ser diferente para usted): http: // localhost: 7101 / console La aplicación de consola del servidor Weblogic debe mostrar y se puede iniciar sesión con sus credenciales nuevas. Cuando esté listo para detener el servidor Weblogic, ir a esta ruta: SYS_DIR / DefaultDomain / bin Ejecute el archivo stopWeblogic.sh con el fin de detener el servidor.

Hay un paso extra que vamos a cubrir después comprobamos los pasos de Windows:

Ventanas
Ir a esta ruta: SYS_DIR \ DefaultDomain \ bin, donde SYS_DIR es el camino que hemos definido anteriormente. Ejecute el setDomainEnvironment.cmd Ir a esta ruta: SYS_DIR \ DefaultDomain \ security Cambie el nombre del archivo DefaultAuthenticatorInit.ldift a algo como oldDefaultAuthenticatorInit.ldift Ejecute el siguiente comando para crear la nueva contraseña. Observe que el comando tiene un punto al final, esto es necesario para que se cree la nueva contraseña en el directorio actual. Cambie NEW_PASSSWORD para la nueva contraseña del usuario weblogic: java weblogic.security.utils.AdminAccount weblogic new_password. Ir a esta ruta: SYS_DIR \ DefaultDomain \ servers \ DefaultServer Cambie el nombre del directorio de datos a algo como data_old Ir a esta ruta: SYS_DIR \ DefaultDomain \ servers \ DefaultServer \ security Cambie el nombre del archivo boot.properties a algo como oldboot.properties Crear un nuevo archivo boot.properties en el mismo directorio. Esto es necesario si se quiere autoconectarse al iniciar el servidor Weblogic desde dentro de JDeveloper. El contenido del archivo debe ser algo como lo siguiente (cambiar new_password la contraseña que ha definido en los pasos anteriores): nombre de usuario = weblogic password = new_password Es hora de probar nuestros cambios. Ir a esta ruta: SYS_DIR \ DefaultDomain \ bin Ejecute el archivo startWeblogic.cmd y verifique que el servidor Weblogic inicia sin excepciones. Abra un navegador y escriba la siguiente dirección URL (el puerto puede ser diferente para usted): http: // localhost: 7101 / console La aplicación de consola del servidor Weblogic debe mostrar y se puede iniciar sesión con sus credenciales nuevas. Cuando esté listo para detener el servidor Weblogic, ir a esta ruta: SYS_DIR \ DefaultDomain \ bin Ejecute el archivo stopWeblogic.cmd con el fin de detener el servidor.

Una vez que haya cambiado y puesto a prueba la nueva contraseña para el usuario weblogic, es hora de actualizar la información de JDeveloper. Abra JDeveloper e ir a la paleta de recursos, si no lo encuentra, vaya al menú Ver y selecciona la opción Paleta de recursos:

Allí, seleccione la categoría Application Server y el IntegratedWebLogicServer. Haga clic derecho y seleccione la opción Propiedades. Una nueva ventana emergente aparece, seleccione la ficha Autenticación:

No se puede establecer la nueva contraseña de usuario weblogic que acaba de definir pasos anteriores. Aplicar cambios y eso es todo!

Leer más

EDITANDO PROPIEDADES Y ELEMENTOS DE LOG4J MIENTRAS LA APLICACIÓN SE EJECUTA

De tarea, pasar la info. http://www.avajava.com/tutorials/lessons/how-do-i-change-my-log4j-settings-while-my-web-application-is-running.html

Leer más

ADMINISTRACION DE MEMORIA EN JAVA

Leer más

GENERAL JAVA BEST PRACTICES

Leer más

PATRONES DE DISEÑO - MVC

Modelo-Vista-Controlador (Model-View-Controller MVC)

1. EJEMPLO YII

Yii implementa el diseño de patron modelo-vista controlador (model-view-controller MVC) el cual es adoptado ampliamente en la programación Web. MVC tiene por objeto separar la lógica del negocio de las consideraciones de la interfaz de usuario para que los desarrolladores puedan modificar cada parte más fácilmente sin afectar a la otra. En MVC el modelo representa la información (los datos) y las reglas del negocio; la vista contiene elementos de la interfaz de usuario como textos, formularios de entrada; y el controlador administra la comunicación entre la vista y el modelo.

Más alla del MVC, Yii tambien introduce un front-controller llamado aplicación el cual representa el contexto de ejecución del procesamiento del pedido. La aplicación resuelve el pedido del usuario y la dispara al controlador apropiado para tratamiento futuro.

El siguiente diagrama muestra la estructura estática de una aplicación Yii"

Estructura estática de aplicación Yii

1. Un flujo de tareas típico 

El siguiente diagrama muestra un típico flujo de tareas de una aplicación Yii cuando resuelve un pedido de usuario:

Un típico flujo de tareas de una aplicación Yii

1. Un usuario realiza un pedido con la siguiente URL http://www.example.com/index.php?r=post/show&id=1 y el servidor Web se encarga de la solicitud mediante la ejecución del script de arranque en index.php.
2. El script de entrada crea una instancia de applicación y la ejecuta.
3. La aplicación obtiene la información detallada del pedido del usuario del componente de aplicaciónrequest.
4. El controlador determina le controlador y la acción pedido con ayuda del componente de aplicación llamado urlManager. Para este ejemplo el controlador es post que refiere a la clase PostController y la acción es show que su significado es determinado por el controlador.
5. La aplicación crea una instancia del controlador pedido para resolver el pedido del usuario. El controlador determina que la acción show refiere al nombre de método actionShow en la clase controlador. Entonces crea y ejecuta los filtros asociados con esta acción (ejemplo: control de acceso, benchmarking). La acción es ejecutado si los filtros lo permiten.
6. La acción lee el modelo Post cuyo ID es 1 de la base de datos.
7. La acción realiza la vista llamada show con el modelo Post
8. La vista lee y muestra los atributos del modelo Post.
9. La vista ejecuta algunos widgets.
10. El resultado realizado es embebido en un esquema (layout).
11. La acción completa la vista realizada y se la muestra al usuario.

----------------------------------------------------------------------------------------------------------------------

MVC está muerto, es hora de seguir adelante.

Conrad Irwin - Junio ​​2012

MVC es una idea fenomenal. Usted tiene modelos, que son agradables pedacitos independientes de Estado, vistas que son buenos pedacitos independientes de la interfaz de usuario y los controladores que son buenos pedacitos independientes de ...

¿Qué?

Ciertamente no soy la primera persona en darse cuenta de esto, pero el problema con MVC como se da es que usted termina el relleno demasiado código en los controladores, porque usted no sabe dónde más ponerlo.

Para solucionar este problema que he estado usando un nuevo patrón:MOVER . M odelos, O peraciones, V iews y E respiraderos.

Visión de conjunto

Voy a definir los detalles en un minuto, pero este diagrama muestra la estructura básica de una aplicación de MOVE.

• Modelos encapsular todo lo que su aplicación sabe.
• Operaciones encapsular todo lo que hace la aplicación.
• Vistas mediar entre la aplicación y el usuario.
• Los eventos se utilizan para unir todos estos componentes de manera segura.

Con el fin de evitar el código espagueti, también vale la pena señalar que hay recomendaciones para lo que se permiten los objetos de cada tipo de hacer. He representado a estos como flechas en el diagrama. Por ejemplo, las vistas se les permite escuchar a los eventos emitidos por los modelos, y las operaciones se les permite cambiar los modelos, pero los modelos no deben hacer referencia a puntos de vista o las operaciones.

Modelos

El modelo arquetípico es un objeto de "usuario". Tiene por lo menos una dirección de correo electrónico, y probablemente también un nombre y un número de teléfono.

En los modelos de aplicación de MOVE sólo envolver conocimiento. Esto significa que, además de los captadores y definidores, pueden contener funciones que le permiten comprobar "es la contraseña del usuario?", Pero que no contienen funciones que permiten guardarlos en una base de datos o subirlos a una API externa . Ese sería el empleo de una operación.

Operaciones

Una operación común para las aplicaciones está registrando un usuario pulg Es realmente dos sub-operaciones compuestas juntos: primero obtener la dirección de correo electrónico y la contraseña del usuario, segundo cargar el modelo "usuario" de la base de datos y comprobar si la contraseña coincide.

Las operaciones son los que hacen el mundo de MOVE. Ellos son responsables de hacer cambios a sus modelos, para mostrar los puntos de vista correctos en el momento adecuado, y para responder a los eventos provocados por las interacciones del usuario. En una aplicación bien factorizada, cada sub-operación se puede ejecutar de forma independiente de su matriz; por lo que en los hechos diagrama de flujo hacia arriba, y los cambios son empujados hacia abajo.

Lo que es interesante sobre el uso de las operaciones de esta manera es que toda la aplicación en sí puede ser tratada como una operación que se inicia cuando se inicia el programa. Se genera tantos sub-operaciones, ya que necesita, donde se ejecuta cada sub-operación concurrente existente en paralelo, y se sale del programa cuando todos están completos.

Vistas

La pantalla de inicio de sesión es una vista en la que se encarga de mostrar un par de cuadros de texto para el usuario. Cuando el usuario hace clic en el botón "login" la vista producirá un evento de "loginAttempt", que contiene el nombre de usuario y una contraseña que el usuario escribió.

Todo lo que el usuario puede ver o interactuar con debe ser alimentado por una vista. Ellos no sólo muestran el estado de la aplicación de una forma comprensible, pero también simplifican el flujo de las interacciones del usuario entrantes en eventos significativos. Es importante destacar que vistas no cambian modelos directamente, simplemente se emiten eventos a las operaciones, y esperar a que los cambios al escuchar a los eventos emitidos por los modelos.

Eventos

El evento "loginAttempt" se emite por la vista cuando el usuario hace clic identificarte. Además, cuando la operación de inicio de sesión se completa, el modelo de "currentUser" emitirá un evento para notificar a la aplicación que ha cambiado.

Escuchando en eventos es lo que da de MOVE (y MVC) la inversión de control que usted necesita para permitir que los modelos para actualizar vistas sin los modelos de ser directamente conscientes de que las opiniones están poniendo al día. Esta es una poderosa técnica de abstracción, permitiendo que los componentes que se acoplan entre sí sin interferir entre sí.

¿Por qué ahora?

No quiero que se me malinterprete como dando a entender que MVC es malo; que realmente ha sido una manera increíblemente exitosa para estructurar grandes aplicaciones para las últimas décadas. Desde que se inventó, sin embargo, las nuevas técnicas de programación se han vuelto populares. Sin cierres (o bloques anónimos) de enlace de eventos puede ser muy tedioso; y sin deferrables (también conocidos como deferreds o promesas) la idea de tratar las operaciones individuales como objetos en sí mismos, no tiene mucho sentido.

Para reiterar: MVC es impresionante, pero está diseñado con décadas de antigüedad tecnologías. MOVE es simplemente una actualización para hacer un mejor uso de las nuevas herramientas que tenemos.

Leer más

PATRONES DE DISEÑO - SINGLETON

Muchos problemas de rendimiento y de escalabilidad suceden cuando se utilizan las conexiones a las bases de datos. Hay que tener en cuenta que las conexiones son un recurso que consume memoria y tiempo de procesador, por lo que sólo se deben crear las conexiones necesarias y estas deben cerrarse tan pronto como se a posible.

Una buena práctica es que todas las clases accedan a los recursos de la base de datos usando siempre una única conexión sin importar el número de instancias que estas clases generen al ser ejecutadas en una aplicación.

El patrón Singleton (instancia única) es el más sencillos, conocidos y utilizados. Está diseñado para restringir la creación de objetos pertenecientes a una clase o el valor de un tipo a un único objeto, asegurando de que sólo exista una única instancia de la clase sin importar el número de veces que se intente crear y proporcionando un punto de acceso global.

Se podría suponer que utilizando miembros estáticos obtendríamos el mismo resultado, pero no es así, ya que en este caso la responsabilidad de tener una única instancia recae en el cliente de la clase.

El patrón Singleton hace que la clase sea responsable de su única instancia y se implementa creando en nuestra clase un método para la creación de la instancia del objeto sólo si todavía no existe alguna. Para asegurar que la clase no puede ser instanciada nuevamente se regula el alcance del constructor (con atributos como protegido o privado).

Resumiendo, el patrón Singleton, provee una única instancia global ya que:

• La propia clase es responsable de crear la única instancia.
• Permite el acceso global a dicha instancia mediante un método de clase.
• Declara el constructor de clase como privado para que no sea instanciable directamente.

El diseño clásico de un es el siguiente:

Analizando la clase se puede observar el uso de los modificadores "private" y "static" en el constructor que hacen que no se pueda crear la clase de forma directa, sino a través del método public GetInstance() que devuelve la instancia creada.

A continuación voy a mostrar un ejemplo en c# en el que tendremos dos clases, que al crearse se guardan la fecha y hora de creación:

• "Instancia1", en la que no se utiliza el patrón Singleton

• "Instancia2" en la que implementaremos el patrón Singleton.

Para utilizar esta clase se deberá invocar mediante el método "GetInstance()".

Aquí les dejo el pantallazo del programa en el que se utilizan ambas clases, es muy básico con la opción "a" se crea una instancia de la clase que no tiene implementado el patrón Singleton y con la opción "b" se crea la instancia con el patrón implementado y estas instancias se guardan en una lista para mostrarlas.

Como se puede observar cada vez que se crea una instancia sin el patrón Singleton obtenemos una fecha y hora diferente, es decir, son instancias diferentes que se crean en cada llamada. En cambio, utilizando el patrón Singleton obtenemos la misma fecha y hora, ya que se crea una sola instancia de acceso global.



                    

Leer más

EXCEPCIONES - MEJORES PRÁCTICAS

Mejores prácticas para el manejo de excepciones

Amigos, hemos estado utilizando el manejo de excepciones en nuestro código para casi todas las aplicaciones estándar de la industria. Enfoque habitual es crear algunas clases de excepciones personalizadas que se extienden de la base Excepción clase. En este post, voy a sugerir otro enfoque que pudiera hacerle más sentido.

Secciones de este mensaje:

• Nuestro nuevo enfoque
• Ventajas

Nuestro nuevo enfoque

Probablemente algunos de nosotros ya utilizan este mecanismo. Si usted es uno de ellos, entonces por favor revise este post y sugerir las mejoras. De lo contrario, aprender sobre este mecanismo y sus comentarios.

Nuestro nuevo enfoque utiliza las clases internas estáticas para cada nuevo escenario excepcional .Tradicionalmente, creamos una clase DBException extendiendo la clase Exception. Ahora, cada vez que nos vemos atrapados en una situación en la que es necesario que excepción lanzada, solemos crear una instancia de esta clase, poner un poco de información en forma de mensaje, y echarlo.

Ahora, vamos a considerar que hay situaciones siguientes que hemos identificado en el que tenemos que tirar DBException:

1. Error de ejecución del SQL
2. No existen datos en la que esperamos al menos una fila
3. Existen múltiples filas en la que esperamos fila único single
4. Error parámetros no válido

y pueden existir muchos más de tales casos.

Diferentes con nuestro enfoque tradicional, y mucho, prueba nuestro nuevo enfoque, es decir crear las clases internas estáticas.

Vamos a empezar con la clase BaseException que se crea como abstracto y será el tratamiento super clase de todas las clases de excepción.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

// Make this class abstract so that developers are forced to create // suitable exception types only public abstract class BaseException extends Exception{     //Each exception message will be hold here     private String message;     public BaseException(String msg)     {         this.message = msg;     }     //Message can be retrieved using this accessor method     public String getMessage() {         return message;     } }

No es el momento de crear nuevas clases internas de excepción. Deje que golpeó el teclado.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

public class DBExeption {     //SQL execution error     public static class BadExecution extends BaseException     {         private static final long serialVersionUID = 3555714415375055302L;         public BadExecution(String msg) {             super(msg);         }     }     //No data exist where we expect at least one row     public static class NoData extends BaseException     {         private static final long serialVersionUID = 8777415230393628334L;         public NoData(String msg) {             super(msg);         }     }     //Multiple rows exist where we expect only single row     public static class MoreData extends BaseException     {         private static final long serialVersionUID = -3987707665150073980L;         public MoreData(String msg) {             super(msg);         }     }     //Invalid parameters error     public static class InvalidParam extends BaseException     {         private static final long serialVersionUID = 4235225697094262603L;         public InvalidParam(String msg) {             super(msg);         }     } }

Aquí, creamos una clase interna para cada escenario posible error identificado en el arranque. No puede haber muchos más extra. Depende de ti sólo para identificar y agregar más clases.

Veamos cómo estas clases parecen en archivos de registro.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public class TestExceptions {     public static void main(String[] args)     {         try         {             throw new DBExeption.NoData("No row found for id : x");         }         catch(Exception e)         {             e.printStackTrace();         }     } } Output: com.exception.DBExeption$NoData: No row found for id : x at com.test.TestExceptions.main(TestExceptions.java:7)

Como se puede ver el mensaje de registro de seguimiento de pila de excepción, si se ha vuelto más informativo.

Ventajas del uso de clases internas

1. Ventaja más importante es que si usted desarrollador ha escrito un texto de mensaje dudoso, entonces también se puede observar claramente que lo que era realmente malo.
2. Usted puede utilizar la instancia de comparación en diferentes situaciones en el que maneje diferentes escenarios excepcionales.
3. No es necesario enviar una sola excepción para un gran conjunto de condiciones excepcionales.
4. Es fácil de escribir casos de prueba de unidad para casos negativos donde se sabe la clase exacta excepción, debe esperar.
5. La tala es más significativo e informativo.

Espero que este post ha sido algunos informativa para usted. Si usted tiene algunas sugerencias, por favor escríbame.

Leer más