I am looking for the semp-rpc-soltr-jaxb-bindings.xsd file which should be used while generating the java object for SEMP request.
The solace version used is 7.2.1.
xjc -p SolaceSempRequest semp-rpc-soltr.xsd -b semp-rpc-soltr-jaxb-bindings.xsd
SolOS 7.1.1 does not have a JAXB bindings file.
This is a new feature only for Solace physical appliances running SolOS 7.2 onwards.
Solace Virtual Message routers also do not currently have a JAXB bindings file, but will be included in the next release.
Related
I work in a lab and use a number of Windows VMs to run analysis software. I manage these VMs and am being asked to fix the log4j vulnerability. However, while I have some experience in research computing, I'm really lost as to exactly what I need to do.
I know I need to update to log4j 2.16.0. For next steps, I received instructions from our IT to "make sure that both of the patched API and Core jars are listed in your application’s classpath, which can be done from the command line or by using a manifest file." Unfortunately I don't know what that means.
What are the exact steps I should take to fix the log4j vulnerability on a Windows machine (Windows Server 2019 Datacentre)?
Java applications typically use JAR files that ar zip files with classes. The Log4J.jar file has to be updated. Java applications load these classes at startup, by loading all jar files and classfiles that are specified in the classpath. From the command line that may look like this
Java -cp log4j.jar;myapp.jar my.app.HelloWorld
Its enough to replace the jar file with a new version and restart the application. How the startup looks like for you and where the jar files are located can wildly vary and is impossible to guess without more information
R Greg Stacey
https://github.com/lunasec-io/lunasec/releases/
Apex One indicates a ramsomware
I like to prototype a JEE environment with Wildfly 10.1 and Hazelcast 3.8. Until now I only have experience with ancient JBoss 4.2.3.GA.
I already found existing resource adapter implementation based on older hazelcast 3.6 under https://github.com/hazelcast/hazelcast-ra. Unfortunately I couldn't deploy it as-is on Wildfly 10.1 since IronJacamar complained about missing equals/hashCode methods (which isn't true since they are explictly overwritten in the source code. deploying a self-built snapshot of git master had the same issue).
I ended up with migrating the ra.xml configuration code to proper javax.resource.spi annotations (#Connector, #ConfigProperty, #ConnectionDefinition) and adding javax.resource.Referenceable interface implementation (don't know whether this is necessary). The step to hazelcast 3.8 was much easier - just adding missing interface methods to HazelcastConnectionImpl.
I still struggle with deployment/configuration, so here are my questions:
How should the deployment structure for an JCA adapter look like? I tested the following approaches:
All-in-one: RAR file containing all of cache-api-1.0.0.jar, hazelcast-3.8.jar, hazelcast-client-3.8.jar, my-hazelcast-ra-impl.jar and deployment descriptors.
By-Library: Added new modules javax.cache.api (cache-api-1.0.0.jar) and com.hazelcast.hazelcast (hazelcast-3.8.jar, hazelcast-client-3.8.jar) to ${WILDFLY_HOME}/modules/ and declared appropriate module dependencies in jboss-deployment-structure.xml. RAR file contains my-hazelcast-ra-impl.jar, hazelcast.xml and deployment descriptors.
By-Adapter: Added a new module my.hazelcast.ra (cache-api-1.0.0.jar, my-hazelcast-ra-impl.jar) to ${WILDFLY_HOME}/modules/ and declared appropriate module dependency in jboss-deployment-structure.xml. RAR file contains hazelcast-3.8.jar, hazelcast-client-3.8.jar, hazelcast.xml and deployment descriptors.
Where is the proper place to deploy a hazelcast.xml configuration file into Wildfly 10.1? It seems that I need to pack it next to ResourceAdapterImpl class (my-hazelcast-ra-impl.jar) so that the class loader finds it and prefers it over hazelcast-default.xml. It contains only global configuration options like group/network. No cache definitions since caches should be configured/created on-demand via CDI.
Is there something like a conf folder where I can deploy hazelcast.xml file separate from binary RAR contents? It would be nice if it could be hot-deployed (for prototyping) but that is not mandatory.
Should it be placed somehow inside subsystem configurations within standalone.xml? I found similar cache-container configurations for infinispan subsystem but don't know how to adapt this to hazelcast (since it's not an own subsystem).
In Wildfly Management webinterface I can find the deployed RAR under Depoyments and in the JNDI view, but it is not listed under Configuration -> Subsystems -> Resource Adapters. I can create a new entry there but don't find any advantage. What is the meaning of this configuration option?
Thank you in advance
I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.
I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.
Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?
The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.
Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).
This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.
I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).
/John
You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail.
In order to do that do the following:
Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
Restart the HTTP service. The higher version - the one you created - will now be used
I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.
Using Mule IDE version 3.2.3 to invoke JAX-WS web service. In the "Import WSDL" dialogue after entering the WSDL URL and package name the JAX-WS client generation fails with error message
Error generating from WSDL: Thrown by JAXB : A class/interface with same name is already in use. Use a class customization to resolve this conflict.
How do I specify jaxb customization in Mule IDE?
What you are covering with the black colour is key to resolve this issue. Are you sure you are not using a reserved class, or a package name already taken?
Just try with org.example.helloWorld and let us know if it still fails.
I'm developing a web application using JSF 2.0, NetBeans 6.9.1, GlassFish Server 3.1, mojarra 2.0.3, and JasperReports 3.7.6. Included in my project library is the jar file "xerces-2.8.0.jar". This file was imported as part of the JasperReports jar file library. Whenever I try to deploy, run, or debug my project through NetBeans, I receive this error:
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory.
After any change in my project my build fails, and I receive the above error, when I try to deploy, run, or debug it. I have to restart the server and run/debug a second time. I've searched the internet and cannot find a solution to this problem. I've looked at the jar file in question, and and DTDDVFactoryImpl does indeed extend from DTDDVFactory - I don't know why I'm receiving this error. While I can eventually get my project running, it would be much nicer if I wasn't receiving this error.
Can anyone please tell me how I can fix this? Do I need to remove this file from my project library? Do I need to update this file with a newer version/older version?
If you provide your own xerces.jar, you have to do that through the Endorsed Standards Override Mechanism (java -Djava.endorsed.dirs=/path/to/xerces.jar), you are not allowed to just add it on the classpath (and will sooner or later run into trouble if you do). Let me explain.
JAXP is the Java API for XML Processing. The creation of JAXP objects (like parsers, XSLT transfomers, DOM Documents) is done through the factory/factory-method pattern so you can plugin a new JAXP implementation (it has to be newer than the one provided in your JRE). Xerces provides (part of) a JAXP implementation and contains endorsed standards (an endorsed standard is a Java API defined through a standards process other than the Java Community Process, see the Endorsed Standards Override Mechanism). You'll run in all kinds of troubles if you don't use the ESOM.
I got this error when using Selenium with Glassfish. I got around it by copying XML jars (xerces-*, xalan-*, xml-apis*, serialize*) from selenium/libs/ to $AS_HOME/lib/endorsed (for Glassfish 2) or to $AS_HOME/glassfish/lib/endorsed for Glassfish 4.