xjc errors out when using scd in binding customization - plugins

When customizing a binding using scd, non-Sun jaxb plugins are not recognized
For example, this does NOT work:
<jaxb:bindings
scd="/~fpml:TradeHeader">
<ext:interfaces>
example.TradeHeaderDelegateInterface
</ext:interfaces>
</jaxb:bindings>
However, this works:
<jaxb:bindings
schemaLocation="../schemas/fpml-5-1/fpml-doc-5-1.xsd"
node="/xsd:schema//xsd:complexType[#name='TradeHeader']">
<ext:interfaces>
example.TradeHeaderDelegateInterface
</ext:interfaces>
</jaxb:bindings>
and, this works:
<jaxb:bindings
scd="/~fpml:CommodityMarketDisruption//fpml:marketDisruptionEvent">
<jaxb:property name="marketDisruptionEvent"/>
</jaxb:bindings>
which makes me think that scd and third party plugins don't get along:
The error I get is:
[ERROR] Error while parsing schema(s).Location [ file:/C:/projects/domain-fpml-5-1/src/main/resources/xjb/fpml-5-1.xjb{40,19}].
org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'ext:interfaces'.
My .xjb file does declare the namespace for the "ext" prefix, so that's not the issue.
Has anyone worked with xjc plugins (e.g. the jaxb commons ones like Copyable etc.) and gotten it to work with scd based customization?
My xjc version is: 2.2.2 and I'm using the maven-jaxb2-plugin (version 0.8.0) plugin to generate bindings.
Thanks for any help,
aravind

maven-jaxb22-plugin:jar:0.8.1:runtime, com.sun.xml.bind:jaxb-impl:jar:2.2.5-b10:runtime, com.sun.xml.bind:jaxb-xjc:jar:2.2.5-b10:runtime] still exhibit this issue.
From looking at the xjc source code (some time ago) this is NOT an easy fix, because the customizations are not "imported" into the target xsd and the processing occurs in the context of the matched component.
This is the case with the Schema parser where by the schema is "imported" into the bindings context so all the namespaces are valid.
I have reverted all customizations back to schema style. I remember this had painful implications when trying to do both wsdl and xsd in the same bindings file.

Related

ClassCastException with ECIConnectionFactory running in Liberty

The problem - I am receiving the following message:
java.lang.ClassCastException: com.ibm.connector2.cics.ECIConnectionFactory incompatible with com.ibm.connector2.cics.ECIConnectionFactory
I am receiving it when trying to make the following statement:
eisDci = (ECIConnectionFactory)ctx.lookup(eisn);
The 'eisDci' has been defined previously:
private static ECIConnectionFactory eisDci = null;
And the 'eisn' is the String with the name of the conection like 'eis/DCIXxxxECI'
These connection is defined in the Server.xml:
<connectionFactory id="DCIXxxxECI" jndiName="eis/DCIXxxxECI">
<properties.cicseci ServerName="XXXX" TPNName="xx" connectionUrl="url" portNumber="2006"/>
</connectionFactory>
I understand that this is warning me that the cast is not possible. What I don't know is what I'm doing wrong. That must be comparing one version of the ECIConnectionFactory class with a different version of ECIConnectionFactory.
The server I'm working with is a Liberty, I'm going crazy, I can't figure out why Eclipse is comparing two different versions.
Similar problems I have searched for:
ClassCastException when casting to the same class
Waxwing's answer seems good, but I don't have access to make those changes, This connection is carried out by an external library.
First Thank you for your answer Ben Cox, in Liberty's server.xml (for LOCAL) I have declared the library:
<fileset caseSensitive="false" dir="C:\CICSECI"/>
And in the Liberty Runtime/Shared/resources I have cicseci.rar which I have declared in the server.xml as a resourceAdapter:
<resourceAdapter autoStart="true" id="cicseci" location="${shared.resource.dir}/cicseci.rar">
<classloader apiTypeVisibility="spec, ibm-api, api, third-party"/>
</resourceAdapter>
I have checked the rest of the libraries that I am importing into the project, and so far I have not seen that I have the repeated library.
I think the issue here has to do with classloading between your resource adapter and your application. This is something we more commonly see with DataSources but the results are the same.
The problem is that the same jar is being loaded by two different classloaders. One classloader for the resource adapter, and another classloader for your application. The solution is to use a commonLibraryRef
<library id=cicseci>
<file name="${shared.resource.dir}/cicseci.rar"/>
</library>
<resourceAdapter autoStart="true" id="cicseciRA">
<classloader commonLibraryRef="cicseci"/>
</resourceAdapter>
<connectionFactory id="DCIXxxxECI" jndiName="eis/DCIXxxxECI">
<properties.cicseci ServerName="XXXX" TPNName="xx" connectionUrl="url" portNumber="2006"/>
</connectionFactory>
<!-- Location of app that is trying to cast ECIConnectionFactory -->
<application location="${shared.resource.dir}/cicseci.rar">
<classloader commonLibraryRef="cicseci"/>
</application>
In this configuration, the cicseci.rar will only be loaded once.
ClassCastException can happen when the same class is loaded by two different class loaders, making what otherwise looks like the same class incompatible.
The mechanism that you should be using to avoid this involves configuring the application's class loader with a classProviderRef to the resourceAdapter, which is documented here. For example,
<application location=...>
<classloader classProviderRef="cicseci"/>
</application>
Already resolved
I import global libraries from different directories of my computer, in two of them the libraries were repeated with different versions, the obsolete versions were renamed, but it doesn't matter, the system recognized them as .jar and loaded them, producing the conflict.
I deleted the leftover libraries and it started working.
You have helped me a lot, and for that, Thank you.

Type Error while downloading 'http://google-web-toolkit.googlecode.com/svn/tags/2.7.0/distro-source/core/src/gwt-module.dtd'

I try to compile my widgetset in Vaadin 7.7.26 but I get an error :
Unable to find 'AppDefaultWidgetset.gwt.xml' on your classpath
but the name is correct and the file is there.
Opening the .gwt.xml file I see the following error :
Description Resource Path Location Type
Error while downloading 'http://google-web-toolkit.googlecode.com/svn/tags/1.7.0/distro-source/core/src/gwt-module.dtd' to C:\Users\axioma28\.lemminx\cache\http\google-web-toolkit.googlecode.com\svn\tags\2.7.0\distro-source\core\src\gwt-module.dtd. AppDefaultWidgetset.gwt.xml /pax-ui-vaadin-client/src/main/resources line 6 Language Servers
Update the wigetset does nothing.
Tks
The error about downloading the dtd shouldn't be related to the compilation problem. The dtd is used by the IDE to provide better validation and content suggestions when editing the file, but it shouldn't have any direct impact on compilation.
I'm thus strongly suspecting that the problem is about where the file is located in combination with how the compiler is launched. Since you don't provide any information on those aspects, I cannot even speculate on what to look for
Your AppDefaultWidgetset.gwt.xml should by default be located in src\main\resources\whatever\your\package\name\is\ and your widgetset configuration should similarly have e.g. in #VaadinServletConfiguration annotation for your Servlet something like widgetset = "whatever.your.package.name.is.AppDefaultWidgetset" -- is this where your file is and how you refer to it, and if not, does changing it to be like this help?
(And if you have custom client-side classes, those should be in src\main\java\whatever\your\package\name\is\client\ for them to be found.)
Also, if you want to use newer Vaadin 7 versions than 7.7.17, make sure you have extended support for Vaadin 7.
Edit: alternative options where the widgetset might be configured:
annotation on your UI class:
#Widgetset("whatever.your.package.name.is.AppDefaultWidgetset")
web.xml:
<init-param>
<description>Application widgetset</description>
<param-name>widgetset</param-name>
<param-value>whatever.your.package.name.is.AppDefaultWidgetset</param-value>
</init-param>

GWT module xml source element to specify single class

I have a GWT application (FooGwtApp) and a library module (FooLib) used as a dependency in FooGwtApp. The package structure of FooLib looks like this:
packageFoo.ImportantClass
packageFoo.UnimportantClass
packageBar.OtherClass
I want ImportantClass (and only ImportantClass) to be compiled to JS by the GWT compiler. Moving ImportantClass to another package is not an option.
I created ImportantClass.gwt.xml within packageFoo with the following content:
<module>
<inherits name="com.google.gwt.user.User"/>
<source path="" includes="**/ImportantClass*"/>
</module>
Next I put an inherited reference to the ImportantClass module definition in FooGwtApp.gwt.xml (this seems to work: the IDE recognizes it, and is able to parse the reference to ImportantClass.gwt.xml).
Now If I put references to ImportantClass into FooGwtApp's client code, the GWT compiler fails, because it does not find ImportantClass on the source path:
No source code is available for type packageFoo.ImportantClass; did you forget to inherit a required module?
I likely messed up sommething in the source path / includes attribute in ImportantClass.gwt.xml - either defining the current package as root package with path="" is not a valid notation or something's wrong with the includes attribute. Or both. Or neither.
Can you give me a clue about where it all went wrong?
It turns out the problem was not in ImportantClass.gwt.xml, but in other Maven related stuff:
ImportantClass.gwt.xml should be placed under src/main/resources/packageFoo, not src/main/java/packageFoo, otherwise it won't be packaged into the binary jar.
GWT compiler compiles from Java source to Javascript source. This means we don't just need ImportantClass.class in FooLib.jar, but also its source. Best solution for this is to use maven-source-plugin in FooLib's pom.xml and also to import the FooLib dependency into FooGwtApp with sources classifier.
On the latter topic, see the following SO answers:
Maven: Distribute source code with with jar-with-dependencies
How to properly include Java sources in Maven?
After fixing the above problems, the source path declaration present in the question works.

Class not found for UIMA pear fle

I am new in UIMA. I am working with pear files for annotation purposes from PubMed xml file. I have already installed Julie Lab medline reader UIMA collection reader file and Lingpipe gazeteer as analysis engine. I have run CPE generator and tried to get proper annotated words, but I failed to do that. The following error occurred:
The class de.julielab.jules.reader.reader.MedlineReader could not be found
Descripotor file=file/C:/apache-uima/examples/descriptor/collection reader/julie-medline-reader 1.7/desc/Medlinereaderdesciptor.xml
causedBy: org.apache.uima.ResourceInitializationException:The class de.julielab.jules.reader.reader.MedlineReader could not be found
caused by: Java.lang.classNotFound exception
de.julielab.jules.reader.reader.MedlineReader
It would be a great help to me to give me a solution to this error.
Have a look in the MedlineReader CollectionReader descriptor in your PEAR at
C:/apache-uima/examples/descriptor/collection reader/julie-medline-reader 1.7/desc/Medlinereaderdesciptor.xml
and look at the typesystem imports:
<typeSystemDescription>
<imports>
<import location="julie-document-meta-pubmed-types.xml"/>
<import location="julie-document-structure-types.xml"/>
</imports>
</typeSystemDescription>
make sure that these files exists. Try to hardcode the full path (something like C:/....) and see if that fixes the problem.
PS: beware that you have spaces in your paths, better use underscores
C:/apache-uima/examples/descriptor/collection_reader/julie-medline-reader_1.7/desc/Medlinereaderdesciptor.xml

Defining modules in GWT with non-default source directories

Let's say that I want to define a module "Pair" in com.mycompany.common such that the source is located in com.mycompany.common (and not com.mycompany.common.client). How would I do this? Alternatively, let's say that I have the flexibility of defining the module "Pair" in com.mycompany instead while still having the source in com.mycompany.common.
Thanks to a quick search on google, I found the answer myself. One can add a source path tag to the module xml file to define the source directory instead of leaving it to the default "client." For example, Pair.gwt.xml would look something like this:
<module>
...
<source path="."/>
...
</module>
... if we wanted the gwt.xml file to be in the same directory as the source.
But when compiling this module, we get a "Non-canonical source package: ./" warning. Is this ok to ignore?