I'm creating a Instances instance using weka. When I define attributes, I get the following exception: "The constructor Attribute(String, boolean) is undefined". The following is the code I have tried:
...
Attribute dtzg = new Attribute("att1Name", 0);
Attribute pDea = new weka.core.Attribute("att2Name", true);
...
My pom weka dependency is the following:
<!-- https://mvnrepository.com/artifact/nz.ac.waikato.cms.weka/weka-stable -->
<dependency>
<groupId>nz.ac.waikato.cms.weka</groupId>
<artifactId>weka-stable</artifactId>
<version>3.8.0</version>
</dependency>
I would expect that I would be able to use the constructor "Attribute(java.lang.String attributeName, boolean createStringAttribute)" because it is listed as constructor in the javadoc here
I discovered that the documentation I was referring to is about the "develop" version of weka, while I imported in my pom the "stable" version of weka. So, if I exchange the dependency above with the following, the compiler does not complain:
<!-- https://mvnrepository.com/artifact/nz.ac.waikato.cms.weka/weka-dev -->
<dependency>
<groupId>nz.ac.waikato.cms.weka</groupId>
<artifactId>weka-dev</artifactId>
<version>3.9.3</version>
</dependency>
However, I'm curious about the difference between the two versions. I'll ask a question about it, if I'll have time.
Related
I'm using:
Quarkus 1.6.1.Final
Vertx 3.9.1 (provided by quarkus-vertx dependency, see pom.xml below)
And I can't get the clusered Eventbus working. I've followed the instructions listed here:
https://vertx.io/docs/vertx-hazelcast/java/
I've also enabled clustering in Quarkus:
quarkus.vertx.cluster.clustered=true
quarkus.vertx.cluster.port=8081
quarkus.vertx.prefer-native-transport=true
quarkus.http.port=8080
And here is my pom.xml:
<dependencies>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-resteasy</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-resteasy-mutiny</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-vertx</artifactId>
</dependency>
<dependency>
<groupId>io.vertx</groupId>
<artifactId>vertx-hazelcast</artifactId>
<version>3.9.2</version>
<exclusions>
<exclusion>
<groupId>io.vertx</groupId>
<artifactId>vertx-core</artifactId>
</exclusion>
<!-- <exclusion>-->
<!-- <groupId>com.hazelcast</groupId>-->
<!-- <artifactId>hazelcast</artifactId>-->
<!-- </exclusion>-->
</exclusions>
</dependency>
<!-- <dependency>-->
<!-- <groupId>com.hazelcast</groupId>-->
<!-- <artifactId>hazelcast-all</artifactId>-->
<!-- <version>3.9</version>-->
<!-- </dependency>-->
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-transport-native-epoll</artifactId>
<classifier>linux-x86_64</classifier>
</dependency>
</dependencies>
And the error I get is the following:
Caused by: java.lang.ClassNotFoundException: com.hazelcast.core.MembershipListener
As you can see in my pom.xml, I've also added the dependency hazelcast-all:3.9 and excluded the hazelcast dependency from vertx-hazelcast:3.9.2, then this error disappears but another comes up:
Caused by: com.hazelcast.config.InvalidConfigurationException: cvc-complex-type.2.4.a: Invalid content was found starting with element '{"http://www.hazelcast.com/schema/config":memcache-protocol}'. One of '{"http://www.hazelcast.com/schema/config":public-address, "http://www.hazelcast.com/schema/config":reuse-address, "http://www.hazelcast.com/schema/config":outbound-ports, "http://www.hazelcast.com/schema/config":join, "http://www.hazelcast.com/schema/config":interfaces, "http://www.hazelcast.com/schema/config":ssl, "http://www.hazelcast.com/schema/config":socket-interceptor, "http://www.hazelcast.com/schema/config":symmetric-encryption, "http://www.hazelcast.com/schema/config":member-address-provider}' is expected.
Am I doing something wrong or forgetting something, or is this simply a bug in Quarkus or in Vertx ?
Thx in advance for any help.
I think the most probable reason of your issue is that you are using the quarkus-universe-bom which enforces a version of Hazelcast (we have an Hazelcast extension there) which is not compatible with vertx-hazelcast.
Check your dependency tree with mvn dependency:tree and make sure the Hazelcast artifacts are of the version required by vertx-hazelcast.
Another option would be to simply use the quarkus-bom which does not enforce an Hazelcast version and let vertx-hazelcast drag the dependency by itself.
It seems like a bug in Quarkus and this issue is related to:
https://github.com/quarkusio/quarkus/issues/10889
Bringing this from its winter sleep...
I am looking to use quarkus 2 + vert.x 4 and use either the shared data vert.x api or vert.x cluster manager in order to achieve an in-process, distributed cache (as opposed to an external dist. cache cluster)
What's unclear to me, also by looking at the git issue described above (thats still open), is if I can count on these APIs working for me at this time with the versions I mentioned.
Any comments will be great!
Thanks in advance...
[UPDATE]: looks like the clustered cache works with no issues using the shared data API along with quarkus, vertx, hazlecast & mutiny bindings for vertx (all with latest versions).
all I needed to do is set quarkus.vertx.cluster.clustered=true in quarkus properties file, use vertx.sharedData().getClusterWideMap implementation for the distrubuted cache and add gradle/maven 'io.vertx:vertx-hazelcast:4.3.1' support.
in general, thats all it took for a small poc code.
thanks
After trying to deploy war file on Weblogic 12.2.1.3.0 for past few days i keep getting this errors:
Unable to access the selected application.
VALIDATION PROBLEMS WERE FOUND /domains/hnb_frtest/weblogic.utils.classloaders.GenericClassLoader#14809eda finder: weblogic.utils.classloaders.CodeGenClassFinder#494ac240 annotation: /WEB-INF/lib/tomcat-embed-jasper-9.0.12.jar!/META-INF/web-fragment.xml:18:3:18:3: problem: cvc-enumeration-valid: string value '4.0' is not a valid enumeration value for web-app-versionType in namespace http://xmlns.jcp.org/xml/ns/javaee
VALIDATION PROBLEMS WERE FOUND /domains/hnb_frtest/weblogic.utils.classloaders.GenericClassLoader#14809eda finder: weblogic.utils.classloaders.CodeGenClassFinder#494ac240 annotation: /WEB-INF/lib/tomcat-embed-jasper-9.0.12.jar!/META-INF/web-fragment.xml:18:3:18:3: problem: cvc-enumeration-valid: string value '4.0' is not a valid enumeration value for web-app-versionType in namespace http://xmlns.jcp.org/xml/ns/javaee
VALIDATION PROBLEMS WERE FOUND /domains/hnb_frtest/weblogic.utils.classloaders.GenericClassLoader#14809eda finder: weblogic.utils.classloaders.CodeGenClassFinder#494ac240 annotation: /WEB-INF/lib/tomcat-embed-jasper-9.0.12.jar!/META-INF/web-fragment.xml:18:3:18:3: problem: cvc-enumeration-valid: string value '4.0' is not a valid enumeration value for web-app-versionType in namespace http://xmlns.jcp.org/xml/ns/javaee
Unable to access the selected application.
VALIDATION PROBLEMS WERE FOUND /domains/hnb_frtest/weblogic.utils.classloaders.GenericClassLoader#7e1a4876 finder: weblogic.utils.classloaders.CodeGenClassFinder#37fb545a annotation: /WEB-INF/lib/tomcat-embed-websocket-9.0.12.jar!/META-INF/web-fragment.xml:18:3:18:3: problem: cvc-enumeration-valid: string value '4.0' is not a valid enumeration value for web-app-versionType in namespace http://xmlns.jcp.org/xml/ns/javaee
VALIDATION PROBLEMS WERE FOUND /domains/hnb_frtest/weblogic.utils.classloaders.GenericClassLoader#7e1a4876 finder: weblogic.utils.classloaders.CodeGenClassFinder#37fb545a annotation: /WEB-INF/lib/tomcat-embed-websocket-9.0.12.jar!/META-INF/web-fragment.xml:18:3:18:3: problem: cvc-enumeration-valid: string value '4.0' is not a valid enumeration value for web-app-versionType in namespace http://xmlns.jcp.org/xml/ns/javaee
VALIDATION PROBLEMS WERE FOUND /domains/hnb_frtest/weblogic.utils.classloaders.GenericClassLoader#7e1a4876 finder: weblogic.utils.classloaders.CodeGenClassFinder#37fb545a annotation: /WEB-INF/lib/tomcat-embed-websocket-9.0.12.jar!/META-INF/web-fragment.xml:18:3:18:3: problem: cvc-enumeration-valid: string value '4.0' is not a valid enumeration value for web-app-versionType in namespace http://xmlns.jcp.org/xml/ns/javaee
Has anyone encountered this error and if so what is the way to fix it?
P.S. I've read one answer about creating web.xml file and changing web-app versions but I've also tried that and it didn't work.
you may insert this in pom.xml:
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion>
</exclusions>
you have exclusion all libraries of Tomcat because Tomcat is for execute your aplication in Local but in weblogic Tomcat dont may stay.
Try this. Work for me:
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
I am playing with some Spring Boot code to convert a java class to a Json schema and am getting strange behavior just by addin the dependency to the POM file as in
<dependency>
<groupId>com.fasterxml.jackson.module</groupId>
<artifactId>jackson-module-jsonSchema</artifactId>
<version>2.9.4</version>
</dependency>
the error I am getting is:
The Bean Validation API is on the classpath but no implementation could be found
Action:
Add an implementation, such as Hibernate Validator, to the classpath
Any suggestion on reading on this or resolving.
Thanks.
Yes this comes because the artifact mentioned by you depends on:
<dependency>
<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
<version>1.1.0.Final</version>
</dependency>
But this is only the validation API, a real validator that can do the 'real' work has to be added.
It would be interesting to see your pom.xml because many Spring Boot Starters already come with a validation implementation, e.g.:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
…comes with…
<dependency>
<groupId>org.hibernate.validator</groupId>
<artifactId>hibernate-validator-parent</artifactId>
</dependency>
By the way, the behavior described by you is also documented in this Spring Boot issue.
It will be fixed with this pull request which mandates a validation implementation only if a validation action is really performed (#Validated).
According to Camel documentation, I create JaxbDataFormat (example code in documentation uses non-existing constructor, though?)
#Override
public void configure() throws Exception {
JaxbDataFormat jaxbDataFormat = new JaxbDataFormat();
jaxbDataFormat.setContextPath("somepackage");
I have pom-dependency
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-jaxb</artifactId>
<version>2.18.3</version>
</dependency>
Doesn't work : "ConvertBody... because of Data format 'jaxb' could not be created."
Could somebody please give an example code how jaxb conversions are supposed to work with Camel. I have Camel in Action 2ed, but the example there uses XML-definde route. Procedure seems simple enough with XML - but I'm not very enthusiastic about using xml as programming language ;)
Using java 8.
............
Exception in thread "CamelMainRunController" java.lang.RuntimeException: org.apache.camel.FailedToCreateRouteException: Failed to create route route2 at: >>> Marshal[org.apache.camel.model.dataformat.JaxbDataFormat#57d7f108] <<< in route: Route(route2)[[From[activemq:gateway.queue]] -> [OnException... because of Data format 'jaxb' could not be created. Ensure that the data format is valid and the associated Camel component is present on the classpath
at org.apache.camel.spring.boot.CamelSpringBootApplicationController.run(CamelSpringBootApplicationController.java:74)
at org.apache.camel.spring.boot.CamelMainRunController$DaemonTask.run(CamelMainRunController.java:42)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.camel.FailedToCreateRouteException: Failed to create route route2 at: >>> Marshal[org.apache.camel.model.dataformat.JaxbDataFormat#57d7f108] <<< in route: Route(route2)[[From[activemq:gateway.queue]] -> [OnException... because of Data format 'jaxb' could not be created. Ensure that the data format is valid and the associated Camel component is present on the classpath
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:1071)
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:196)
at org.apache.camel.impl.DefaultCamelContext.startRoute(DefaultCamelContext.java:984)
at org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:3401)
at org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3132)
at org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:183)
at org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2961)
at org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2957)
at org.apache.camel.impl.DefaultCamelContext.doWithDefinedClassLoader(DefaultCamelContext.java:2980)
at org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:2957)
at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:2924)
at org.apache.camel.main.Main.doStart(Main.java:129)
at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
at org.apache.camel.main.MainSupport.run(MainSupport.java:138)
at org.apache.camel.spring.boot.CamelSpringBootApplicationController.run(CamelSpringBootApplicationController.java:69)
... 2 more
Caused by: java.lang.IllegalArgumentException: Data format 'jaxb' could not be created. Ensure that the data format is valid and the associated Camel component is present on the classpath
at org.apache.camel.model.DataFormatDefinition.getDataFormat(DataFormatDefinition.java:107)
at org.apache.camel.model.DataFormatDefinition.getDataFormat(DataFormatDefinition.java:88)
at org.apache.camel.model.MarshalDefinition.createProcessor(MarshalDefinition.java:177)
at org.apache.camel.model.ProcessorDefinition.makeProcessorImpl(ProcessorDefinition.java:545)
at org.apache.camel.model.ProcessorDefinition.makeProcessor(ProcessorDefinition.java:506)
at org.apache.camel.model.ProcessorDefinition.addRoutes(ProcessorDefinition.java:222)
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:1068)
... 17 more
add to pom
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-jaxb-starter</artifactId>
<version>2.23.1</version>
</dependency>
and update project
I work in a project that uses Log4J. One of the requirement is to create a separate log file for each thread; this itself was a odd issue, somewhat sorted by creating a new FileAppender on the fly and attaching it to the Logger instance.
Logger logger = Logger.getLogger(<thread dependent string>);
FileAppender appender = new FileAppender();
appender.setFile(fileName);
appender.setLayout(new PatternLayout(lp.getPattern()));
appender.setName(<thread dependent string>);
appender.setThreshold(Level.DEBUG);
appender.activateOptions();
logger.addAppender(appender);
Everything went fine until we realised that another library we use - Spring Framework v3.0.0 (which use Commons Logging) - does not play ball with the technique above – the Spring logging data is “seen” only by Appenders initialised from the log4.configuration file but not by the runtime created Appenders.
So, back to square one.
After some investigation, I found out that the new and improved LogBack has an appender - SiftingAppender – which does exactly what we need i.e. thread level logging on independent files.
At the moment, moving to LogBack is not an option, so, being stuck with Log4J, how can I achieve SiftingAppender-like functionality and keep Spring happy as well ?
Note: Spring is only used for JdbcTemplate functionality, no IOC; in order to “hook” Spring’s Commons Logging to Log4J I added this line in the log4j.properties file:
log4j.logger.org.springframework=DEBUG
as instructed here.
In Log4j2, we can now use RoutingAppender:
The RoutingAppender evaluates LogEvents and then routes them to a subordinate Appender. The target Appender may be an appender previously configured and may be referenced by its name or the Appender can be dynamically created as needed.
From their FAQ:
How do I dynamically write to separate log files?
Look at the RoutingAppender. You can define multiple routes in the configuration, and put values in the ThreadContext map that determine which log file subsequent events in this thread get logged to.
LogBack is accessed via the slf4j api. There is an adapter library called jcl-over-sjf4j which exposes the commons logging interface but makes all the logging to the slf4j API, which goes directly to the implementation - LogBack. If you are using maven, here are the dependencies:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.5.8</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.5.8</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>0.9.18</version>
</dependency>
(and add the commons-logging to the exclusion list, see here)
I struggled for a while to find SiftingAppender-like functionality in log4j (we couldn't switch to logback because of some dependencies), and ended up with a programmatic solution that works pretty well, using an MDC and appending loggers at runtime:
// this can be any thread-specific string
String processID = request.getProcessID();
Logger logger = Logger.getRootLogger();
// append a new file logger if no logger exists for this tag
if(logger.getAppender(processID) == null){
try{
String pattern = "%d{yy/MM/dd HH:mm:ss} %p %c{2}: %m%n";
String logfile = "log/"+processID+".log";
FileAppender fileAppender = new FileAppender(
new PatternLayout(pattern), logfile, true);
fileAppender.setName(processID);
// add a filter so we can ignore any logs from other threads
fileAppender.addFilter(new ProcessIDFilter(processID));
logger.addAppender(fileAppender);
}catch(Exception e){
throw new RuntimeException(e);
}
}
// tag all child threads with this process-id so we can separate out log output
MDC.put("process-id", processID);
//whatever you want to do in the thread
LOG.info("This message will only end up in "+processID+".log!");
MDC.remove("process-id");
The filter appended above just checks for a specific process id:
public class RunIdFilter extends Filter {
private final String runId;
public RunIdFilter(String runId) {
this.runId = runId;
}
#Override
public int decide(LoggingEvent event) {
Object mdc = event.getMDC("run-id");
if (runId.equals(mdc)) {
return Filter.ACCEPT;
}
return Filter.DENY;
}
}
Hope this helps a bit.
I like to include all of the slf4j facades/re-routers/whateveryoucallthem. Also note the "provided" hack, which keeps dependencies from pulling in commons logging; previously I was using a fake empty commons logging library called version-99.0-does-not-exist.
Also see http://blog.springsource.com/2009/12/04/logging-dependencies-in-spring/
<dependencies>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<!-- use provided scope on real JCL instead -->
<!-- <version>99.0-does-not-exist</version> -->
<version>1.1.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging-api</artifactId>
<!-- use provided scope on real JCL instead -->
<!-- <version>99.0-does-not-exist</version> -->
<version>1.1</version>
<scope>provided</scope>
</dependency>
<!-- the slf4j commons-logging replacement -->
<!-- if any package is using jakarta commons logging this will -->
<!-- re-route it through slf4j. -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>${version.slf4j}</version>
</dependency>
<!-- the slf4j log4j replacement. -->
<!-- if any package is using log4j this will re-route -->
<!-- it through slf4j. -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>${version.slf4j}</version>
</dependency>
<!-- the slf4j java.util.logging replacement. -->
<!-- if any package is using java.util.logging this will re-route -->
<!-- it through slf4j. -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
<version>${version.slf4j}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${version.slf4j}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>${version.logback}</version>
</dependency>
</dependencies>
<properties>
<version.logback>0.9.15</version.logback>
<version.slf4j>1.5.8</version.slf4j>
</properties>
have you looked at log4j.NDC and MDC? This at least allows you to tag thread specific data to your logging. Not exactly what you're asking, but might be useful. There's a discussion here.