Following the Arun Gupta's Java EE 6 Hands-on Lab using Netbeans 7.0.1 and Glassfish 3.1.1, I found the following error, which prevented me from deploy the app: Error creating managed object for class org.jboss.weld.servlet.WeldListener.
I just restarted Glassfish, did a Clean and Build and the problem was gone :P
The Lab is a very good way to know several new cool Java EE 6 features.
jueves, 22 de diciembre de 2011
miércoles, 28 de septiembre de 2011
"Oracle Web Services Inspection Language Configuration Assistant" failed ("Could not get DeploymentManager" deploying WSIL App)
Installing the 10.1.3.5 Oracle Application Server patch on an 10.1.3.1 installation, I got the following error in the "Configuration Assistants" step:
The log windows didn't have any useful information so I took a look at the full installActions* log. This log didn't have also the concrete error but showed the complete Ant command being executed:
The command being spawned is: '/ESB/ant/bin/ant -buildfile /ESB/webservices/lib/wsil-install.xml -logfile /ESB/cfgtoollogs/wsil.txt -DHOST=ESBDB -DOPMNPORT="6003" -DADMIN_USER=oc4jadmin -DOPMNINSTANCE=home -Denv.JAVA_HOME=/ESB/jdk -Denv.ANT_HOME=/ESB/ant -Denv.ORACLE_HOME=/ESB *Protected value, not to be logged*'
Luckily, this command had its own log file: /ESB/cfgtoollogs/wsil.txt.
This log had the following information:
[echo] Deploying WSIL App with JSSO disabled
[java] Failed at "Could not get DeploymentManager".
[java] This is typically the result of an invalid deployer URI format being supplied, the target server not being in a started state or incorrect authentication details being supplied.
[java] More information is available by enabling logging -- please see the Oracle Containers for J2EE Configuration and Administration Guide for details.
Watching other post (and other) I found this error occurs when there are errors in the arguments supplied in the deployment URL (OC4J instance, password, etc.). I looked the Ant script and found the OC4J instance being used to deploy the WSIL app was 'home', but I don't have an O4CJ instance called 'home'. My OC4J admin instance is called 'admin'.
I hardcoded the name of my real OC4J intance in the ANT buildfile, retried the action and the installation finished OK.
Configuration assistant "Oracle Web Services Inspection Language Configuration Assistant" failed
Buildfile: /ESB/webservices/lib/wsil-install.xml
Buildfile: /ESB/webservices/lib/wsil-install.xml
The log windows didn't have any useful information so I took a look at the full installActions* log. This log didn't have also the concrete error but showed the complete Ant command being executed:
Luckily, this command had its own log file: /ESB/cfgtoollogs/wsil.txt.
This log had the following information:
[echo] Deploying WSIL App with JSSO disabled
[java] Failed at "Could not get DeploymentManager".
[java] This is typically the result of an invalid deployer URI format being supplied, the target server not being in a started state or incorrect authentication details being supplied.
[java] More information is available by enabling logging -- please see the Oracle Containers for J2EE Configuration and Administration Guide for details.
Watching other post (and other) I found this error occurs when there are errors in the arguments supplied in the deployment URL (OC4J instance, password, etc.). I looked the Ant script and found the OC4J instance being used to deploy the WSIL app was 'home', but I don't have an O4CJ instance called 'home'. My OC4J admin instance is called 'admin'.
I hardcoded the name of my real OC4J intance in the ANT buildfile, retried the action and the installation finished OK.
martes, 6 de septiembre de 2011
Configuración alternativa del Softphone (teléfono VoIP) de Une en Windows 7 (64 bits)
Hace poco estaba fuera de Colombia e intenté usar el Softphone de UNE en Windows 7 64bits para hacer llamadas "locales" en Medellín, pero no me fue posible. El software que ellos distribuyen es una versión preconfigurada de SJphone de SJ Labs. También descargué directamente la última versión de dicha página pero tampoco me fue posible. No recuerdo exáctamente el error y no guardé un pantallazo; creo que era "No active network interface". Intenté iniciarlo con compatibilidad a Windows XP, pero tampoco. He visto el softphone funcionando en otros sistemas Windows 7, pero en mi máquina no lo logré (depronto los otros eran 32 bits y la incompatibilidad es solo con 64 bits).
Afortunadamente me recomendaron otro programa bastante bueno y grátis para uso personal, llamado X-Lite.
Para configurarlo debes disponer solo de tu número telefónico de VoIP y tu contraseña. Suponiendo que te asignaron el número 1234567, la configuración sería la siguiente:
User ID: 1234567
Domain: une.net.co
Password:
Authorization name: toip1234567
Proxy SIP: epmvoip1.une.net.co
Y listo.
Como yo estaba en un lugar con un límite muy bajo de cuota de navegación (usando un móden móvil), modifiqué los codecs disponibles para dejar solo unos de menor calidad, pero de menor consumo de ancho de banda. Si el ancho de banda esto no es una limitante, esto no es necesario ya que la calidad es muy buena con los predefinidos.
Antes:
Después:
Ver también Configuración del Softphone (teléfono VoIP) de Une en iPad (o iPhone).
Afortunadamente me recomendaron otro programa bastante bueno y grátis para uso personal, llamado X-Lite.
Para configurarlo debes disponer solo de tu número telefónico de VoIP y tu contraseña. Suponiendo que te asignaron el número 1234567, la configuración sería la siguiente:
User ID: 1234567
Domain: une.net.co
Password:
Authorization name: toip1234567
Proxy SIP: epmvoip1.une.net.co
Y listo.
Como yo estaba en un lugar con un límite muy bajo de cuota de navegación (usando un móden móvil), modifiqué los codecs disponibles para dejar solo unos de menor calidad, pero de menor consumo de ancho de banda. Si el ancho de banda esto no es una limitante, esto no es necesario ya que la calidad es muy buena con los predefinidos.
Antes:
Después:
Ver también Configuración del Softphone (teléfono VoIP) de Une en iPad (o iPhone).
miércoles, 31 de agosto de 2011
"package javax.xml.bind.annotation does not exist" using CXF's DynamicClientFactory in OC4J 10.1.3.x
I'm using CXF 2.4.2 and DynamicClientFactory in OC4J 10.1.3.4 (and 10.1.3.5).
When DynamicClientFactory tries to compile the dinamycally generated Java sources, the following errors occur:
There was a reported bug (CXF-2549) which gives a solution for Weblogic. I didn't find a good similar solution for OC4J to send a patch.
I found the necessary compilation libraries are the JAXB ones. What I did, before calling createClient, was to set a new URLClassLoader which include the JAXB jars:
The compilation is now succesful.
DynamicClientFactory internally creates another URLClassLoader which includes the newly generated classes and set it as the current thread's Context Class Loader; for this reason, when working with DynamicClientFactory in a multithreaded environment, there are some gotchas relating the ClassLoaders, but I thing this is material for another post.
EDIT: I found a better way to initialize the JAXB jars URL's array:
In my case, it printed somethig like:
:-)
When DynamicClientFactory tries to compile the dinamycally generated Java sources, the following errors occur:
INFO: Created classes: XXX, YYY, ...
C:\..\org.apache.cxf.endpoint.dynamic.DynamicClientFactory@12f767-1314800629516-src\...\XXX.java:4: package javax.xml.bind.annotation does not exist
import javax.xml.bind.annotation.XmlAccessType;
^
C:\..\org.apache.cxf.endpoint.dynamic.DynamicClientFactory@12f767-1314800629516-src\...\YYY.java:4: package javax.xml.bind.annotation does not exist
import javax.xml.bind.annotation.XmlAccessType;
^
I dug into the DynamicClientFactory code and found that setupClasspath, the method which sets the Classpath for the javac compilation iterates between the supplied ClassLoader (or the Context ClassLoader if none is supplied) and the SystemClassLoader extrating the ClassPath paths for each one; this extraction is done only if the ClassLoader in turn is an instance of URLClassLoader. In OC4J, the ClassLoaders are usually instances of oracle.classloader.PolicyClassLoader (which is not an instance of URLClassLoader). For this reason, the Classpath for the compilation is not correctly set.C:\..\org.apache.cxf.endpoint.dynamic.DynamicClientFactory@12f767-1314800629516-src\...\XXX.java:4: package javax.xml.bind.annotation does not exist
import javax.xml.bind.annotation.XmlAccessType;
^
C:\..\org.apache.cxf.endpoint.dynamic.DynamicClientFactory@12f767-1314800629516-src\...\YYY.java:4: package javax.xml.bind.annotation does not exist
import javax.xml.bind.annotation.XmlAccessType;
^
There was a reported bug (CXF-2549) which gives a solution for Weblogic. I didn't find a good similar solution for OC4J to send a patch.
I found the necessary compilation libraries are the JAXB ones. What I did, before calling createClient, was to set a new URLClassLoader which include the JAXB jars:
URL[] jaxbUrls = null;
jaxbUrls = new URL[]{
new URL("file:/C:/.../jaxb-api-2.2.1.jar"),
new URL("file:/C:/.../jaxb-impl-2.2.1.1.jar"),
new URL("file:/C:/.../jaxb-xjc-2.2.1.1.jar")
};
jaxbUrls = new URL[]{
new URL("file:/C:/.../jaxb-api-2.2.1.jar"),
new URL("file:/C:/.../jaxb-impl-2.2.1.1.jar"),
new URL("file:/C:/.../jaxb-xjc-2.2.1.1.jar")
};
ClassLoader currentCL = Thread.currentThread().getContextClassLoader();
URLClassLoader urlCL = new URLClassLoader(jaxbUrls, currentCL);
client = dcf.createClient(xxx, yyy, urlCL, zzz);
The compilation is now succesful.
DynamicClientFactory internally creates another URLClassLoader which includes the newly generated classes and set it as the current thread's Context Class Loader; for this reason, when working with DynamicClientFactory in a multithreaded environment, there are some gotchas relating the ClassLoaders, but I thing this is material for another post.
EDIT: I found a better way to initialize the JAXB jars URL's array:
import oracle.classloader.PolicyClassLoader;
import oracle.classloader.SharedCodeSource;
import oracle.classloader.SharedCodeSource;
Class someJaxbClazz = Class.forName("javax.xml.bind.annotation.XmlAccessType");
PolicyClassLoader jaxbClazzClassLoader = (PolicyClassLoader)someJaxbClazz.getClassLoader();
SharedCodeSource[] sharedCodeSources = jaxbClazzClassLoader.getCodeSources(false);
for(SharedCodeSource sharedCodeSource : sharedCodeSources) {
URL location = sharedCodeSource.getLocation();
if(location.toString().toLowerCase().contains("jaxb")) {
System.out.println("JAXB jar URL found->" + location);
}
}
PolicyClassLoader jaxbClazzClassLoader = (PolicyClassLoader)someJaxbClazz.getClassLoader();
SharedCodeSource[] sharedCodeSources = jaxbClazzClassLoader.getCodeSources(false);
for(SharedCodeSource sharedCodeSource : sharedCodeSources) {
URL location = sharedCodeSource.getLocation();
if(location.toString().toLowerCase().contains("jaxb")) {
System.out.println("JAXB jar URL found->" + location);
}
}
In my case, it printed somethig like:
JAXB jar URL found->file:/C:/.../cxf/2.4.2/jaxb-api-2.2.1.jar
JAXB jar URL found->file:/C:/.../cxf/2.4.2/jaxb-impl-2.2.1.1.jar
JAXB jar URL found->file:/C:/.../cxf/2.4.2/jaxb-xjc-2.2.1.1.jar
JAXB jar URL found->file:/C:/.../cxf/2.4.2/jaxb-impl-2.2.1.1.jar
JAXB jar URL found->file:/C:/.../cxf/2.4.2/jaxb-xjc-2.2.1.1.jar
:-)
martes, 30 de agosto de 2011
"compiler was unable to honor this globalBindings customization" using CXF's DynamicClientFactory
I'm using CXF 2.4.2 and DynamicClientFactory. To simplify the runtime classes manipulation I wanted to make sure the generated Java clases didn´t contain JAXBElement attributes; so I created the famous generateElementProperty globalBindings JAXB binding file.
I used the createClient method that receives the binding list to feed DynamicClientFactory with my file, but I received the following JAXB error: compiler was unable to honor this globalBindings customization. It is attached to a wrong place, or its inconsistent with other bindings.
I found this error may occur if you use more than one binding file with globalBindings declarations. I dug into the DynamicClientFactory code and found that by default, CXF use one binding file with globalBindings declarations: /org/apache/cxf/endpoint/dynamic/simple-binding.xjb in the addSchemas method. Thus, besides my binding file, there was another file internally used by CXF. Luckily, the binding file included by CXF have the generateElementProperty declaration that I was trying to configure with my binding file.
I checked the runtime generated classes and indeed (modifying the DynamicClientFactory class to not delete the source files) they did'n include the JAXBElement attributes when they would normally do.
It was no necesary to include my extra binding file.
This is a fragment of the stack trace:
Update (2013/08/14): I tried the same codebase with CXF 2.6.1, but started having issues with JAXBElement attributes appearing in the generated Java classes. I dug again into the DynamicClientFactory code and found in SVN revision 1232564 ([CXF-4037] Allow dynamic client to use already parsed and processed schemas like the tooling does), the code section that included the default binding file (simple-binding.xjb) was removed. It haven't been included in posterior commits (last trunk revision now for DynamicClientFactory is 1502354).
This is one version of the DynamicClientFactory.java's removed code section:
if (simpleBindingEnabled) {
String id = "/org/apache/cxf/endpoint/dynamic/simple-binding.xjb";
LOG.fine("Loading the JAXB 2.1 simple binding for client.");
try {
Document doc = StaxUtils.read(getClass().getResourceAsStream(id));
compiler.parseSchema(id, doc.getDocumentElement());
} catch (XMLStreamException e) {
LOG.log(Level.WARNING, "Could not parse simple-binding.xsd", e);
}
}
Due to the fact my code is not expecting JAXBElement attributes in the generated classes, I'm including the binding (again) by myself.
My binding:
<bindings version="2.1"
xmlns="http://java.sun.com/xml/ns/jaxb"
xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc">
<bindings>
<globalBindings>
<xjc:generateElementProperty>false</xjc:generateElementProperty>
</globalBindings>
</bindings>
</bindings>
<jaxb:bindings
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" jaxb:version="2.0"
xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc" jaxb:extensionBindingPrefixes="xjc">
<jaxb:globalBindings generateElementProperty="false">
<xjc:simple />
</jaxb:globalBindings>
</jaxb:bindings>
I used the createClient method that receives the binding list to feed DynamicClientFactory with my file, but I received the following JAXB error: compiler was unable to honor this globalBindings customization. It is attached to a wrong place, or its inconsistent with other bindings.
I found this error may occur if you use more than one binding file with globalBindings declarations. I dug into the DynamicClientFactory code and found that by default, CXF use one binding file with globalBindings declarations: /org/apache/cxf/endpoint/dynamic/simple-binding.xjb in the addSchemas method. Thus, besides my binding file, there was another file internally used by CXF. Luckily, the binding file included by CXF have the generateElementProperty declaration that I was trying to configure with my binding file.
I checked the runtime generated classes and indeed (modifying the DynamicClientFactory class to not delete the source files) they did'n include the JAXBElement attributes when they would normally do.
It was no necesary to include my extra binding file.
This is a fragment of the stack trace:
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy25.error(Unknown Source)
at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.error(SchemaCompilerImpl.java:286)
at com.sun.tools.xjc.util.ErrorReceiverFilter.error(ErrorReceiverFilter.java:77)
at com.sun.tools.xjc.util.ErrorReceiverFilter.error(ErrorReceiverFilter.java:77)
at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:82)
at com.sun.tools.xjc.reader.xmlschema.ErrorReporter.error(ErrorReporter.java:79)
at com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.check(UnusedCustomizationChecker.java:144)
at com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.check(UnusedCustomizationChecker.java:122)
at com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.schema(UnusedCustomizationChecker.java:199)
at com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.run(UnusedCustomizationChecker.java:95)
at com.sun.tools.xjc.reader.xmlschema.BGMBuilder._build(BGMBuilder.java:187)
at com.sun.tools.xjc.reader.xmlschema.BGMBuilder.build(BGMBuilder.java:116)
at com.sun.tools.xjc.ModelLoader.annotateXMLSchema(ModelLoader.java:415)
at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:245)
... 32 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at org.apache.cxf.common.util.ReflectionInvokationHandler.invoke(ReflectionInvokationHandler.java:52)
... 46 more
Caused by: java.lang.RuntimeException:
at $Proxy25.error(Unknown Source)
at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.error(SchemaCompilerImpl.java:286)
at com.sun.tools.xjc.util.ErrorReceiverFilter.error(ErrorReceiverFilter.java:77)
at com.sun.tools.xjc.util.ErrorReceiverFilter.error(ErrorReceiverFilter.java:77)
at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:82)
at com.sun.tools.xjc.reader.xmlschema.ErrorReporter.error(ErrorReporter.java:79)
at com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.check(UnusedCustomizationChecker.java:144)
at com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.check(UnusedCustomizationChecker.java:122)
at com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.schema(UnusedCustomizationChecker.java:199)
at com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.run(UnusedCustomizationChecker.java:95)
at com.sun.tools.xjc.reader.xmlschema.BGMBuilder._build(BGMBuilder.java:187)
at com.sun.tools.xjc.reader.xmlschema.BGMBuilder.build(BGMBuilder.java:116)
at com.sun.tools.xjc.ModelLoader.annotateXMLSchema(ModelLoader.java:415)
at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:245)
... 32 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at org.apache.cxf.common.util.ReflectionInvokationHandler.invoke(ReflectionInvokationHandler.java:52)
... 46 more
Caused by: java.lang.RuntimeException:
Error compiling schema from WSDL at {http://xxx?wsdl}: compiler was unable to honor this globalBindings customization. It is attached to a wrong place, or its inconsistent with other bindings.
at org.apache.cxf.endpoint.dynamic.DynamicClientFactory$InnerErrorListener.error(DynamicClientFactory.java:582)
... 51 more
Caused by: com.sun.istack.SAXParseException2: compiler was unable to honor this globalBindings customization. It is attached to a wrong place, or its inconsistent with other bindings.
... 42 more
at org.apache.cxf.endpoint.dynamic.DynamicClientFactory$InnerErrorListener.error(DynamicClientFactory.java:582)
... 51 more
Caused by: com.sun.istack.SAXParseException2: compiler was unable to honor this globalBindings customization. It is attached to a wrong place, or its inconsistent with other bindings.
... 42 more
Update (2013/08/14): I tried the same codebase with CXF 2.6.1, but started having issues with JAXBElement attributes appearing in the generated Java classes. I dug again into the DynamicClientFactory code and found in SVN revision 1232564 ([CXF-4037] Allow dynamic client to use already parsed and processed schemas like the tooling does), the code section that included the default binding file (simple-binding.xjb) was removed. It haven't been included in posterior commits (last trunk revision now for DynamicClientFactory is 1502354).
This is one version of the DynamicClientFactory.java's removed code section:
if (simpleBindingEnabled) {
String id = "/org/apache/cxf/endpoint/dynamic/simple-binding.xjb";
LOG.fine("Loading the JAXB 2.1 simple binding for client.");
try {
Document doc = StaxUtils.read(getClass().getResourceAsStream(id));
compiler.parseSchema(id, doc.getDocumentElement());
} catch (XMLStreamException e) {
LOG.log(Level.WARNING, "Could not parse simple-binding.xsd", e);
}
}
Due to the fact my code is not expecting JAXBElement attributes in the generated classes, I'm including the binding (again) by myself.
My binding:
<bindings version="2.1"
xmlns="http://java.sun.com/xml/ns/jaxb"
xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc">
<bindings>
<globalBindings>
<xjc:generateElementProperty>false</xjc:generateElementProperty>
</globalBindings>
</bindings>
</bindings>
The CXF's equivalent binding:
<jaxb:bindings
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" jaxb:version="2.0"
xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc" jaxb:extensionBindingPrefixes="xjc">
<jaxb:globalBindings generateElementProperty="false">
<xjc:simple />
</jaxb:globalBindings>
</jaxb:bindings>
domingo, 31 de julio de 2011
"Could not locate the launcher comand" running JDeveloper, Weblogic installers
My actual client has strong security restrictions in their employee's corporate laptops. Although I received the authorization to install JDeveloper 11g and Weblogic in one of them's laptop, the installers keep showing the "Could not locate the launcher comand" error.
I did't want to check security issues, so what I did was "extract" the exe installer contens and run the internal installer.jar jar file (double click on windows or java -jar installer.jar). The installation ran without problems.
If there's no a good compression utility at hand, you can use the “-Djava.io.tmpdir=C:\xxx" flag to obtain the exe internal files (the installer extract the files at this location and you can copy them while the error message is active; after you click the Ok button, the installer will erase them).
If you have Administrator privileges, just use Run As Administrator.
I did't want to check security issues, so what I did was "extract" the exe installer contens and run the internal installer.jar jar file (double click on windows or java -jar installer.jar). The installation ran without problems.
If there's no a good compression utility at hand, you can use the “-Djava.io.tmpdir=C:\xxx" flag to obtain the exe internal files (the installer extract the files at this location and you can copy them while the error message is active; after you click the Ok button, the installer will erase them).
If you have Administrator privileges, just use Run As Administrator.
domingo, 17 de julio de 2011
VERR_GENERAL_FAILURE importing Oracle SOA Pre-built VM
I downloaded and tried to import the pre-built VM for SOA on VirtualBox (in my 64bits Win 7 laptop), and I found this error: Could not create the clone medium (VERR_GENERAL_FAILURE).
After googling and finding nothing useful, I cheked the MD5 sum of the downloaded files. One was incorrect. I downloaded it again and the VM worked without problems.
I never before bothered cheking the MD5 sums, but I guess I'll do it from now.
After googling and finding nothing useful, I cheked the MD5 sum of the downloaded files. One was incorrect. I downloaded it again and the VM worked without problems.
I never before bothered cheking the MD5 sums, but I guess I'll do it from now.
Suscribirse a:
Entradas (Atom)