I'm trying to validate something using the GWT BeanValidation but these two lines are giving me some trouble:
Validator validator=Validation.buildDefaultValidatorFactory().getValidator();
Set<ConstraintViolation<Contact>> violations = validator.validate(contact, Default.class);
The thing is, I have imported the corresponding classes:
import javax.validation.ConstraintViolation;
import javax.validation.Validation;
import javax.validation.Validator;
import javax.validation.groups.Default;
But still, the Validator, Validation, ConstraingViolation and Default references in the code are underlined in red and the error they show is:
javax.validation.Validator can not be found in source packages. Check the inheritance chain from your module; it may not be inheriting a required module or a module may not be adding its source path entries properly.
I have checked that the necessary lib validation-api-1.0.0.GA.jar is in the classpath and everything seems normal.
Anyone happens to know what could be the problem?
thanks!!
I see only two possibilities
Check the size of jar file , either in your local maven repository which your build path is pointing to or check that in your eclipse by browsing its source code to double check its there :)
Have you inherited this is any awt module using ? Can you check its syntax or if it is really required?
Do you have validator-implementation in your classpath? AFAIK, javax.validation is only the API (interfaces), you'll need an actual validator-implementation to use it. See for example Hibernate Validator.
Related
Maybe I am misunderstanding Maven's dependency principles but this is my question:
I have a little Java program that requires these imports
import javax.xml.transform.OutputKeys;
import javax.xml.transform.Source;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.stream.StreamResult;
import javax.xml.transform.stream.StreamSource;
import java.io.StringReader;
import java.io.StringWriter;
Now instead of importing these at the top of the code, I would just go
into the POM file of my Maven project and add the dependencies.
But on https://mvnrepository.com/ how do I find the correct imports?
Is there another way besides looking on that site?
Thank you.
Now instead of importing these at the top of the code, I would just go into the POM file of my Maven project and add the dependencies.
No. You are conflating two different things:
Managing dependencies (downloading and placing libraries within your project)
Using dependencies (calling the library’s classes and methods from within your code)
Managing dependencies
To use a library, you need to obtain a physical copy, a file, usually a .jar file. You can manually download a copy. Or you can use Maven or Gradle to download a copy on your behalf. The Maven or Gradle approach is generally recommended over the manual approach.
Once downloaded, you need to place the file where it can be found within your project. Again, you can do this manually, or you can use Maven or Gradle to make the file available to your project. Again, the Maven or Gradle approach is generally recommended over the manual approach.
Using dependencies
After having obtained and placed a copy of the library, you are ready to access its classes and methods.
👉 The catch is that the authors of that library may have named some of their classes and methods coincidentally with the same name as found in another library.
Imagine you want to use a class named Source, but two of your libraries have such a class:
javax.xml.transform.Source
com.example.awesome.Source
If you write in your code:
Source s = new Source() ;
… how does the compiler know which of the two classes you meant? 👈
To resolve the mystery, you either:
Write a fully-qualified class name.javax.xml.transform.Source s = new javax.xml.transform.Source() ;
Write an import statement.import javax.xml.transform.Source ;
The second approach, writing an import statement, usually makes for less typing and easier reading than the first approach of using fully-qualified names.
The word import is a bit of a misnomer, and was used for legacy historical reasons. Its use here does not involve any moving of anything anywhere. A better name would have been namespace, as in, specifying a defined domain of known names.
When reading this:
import javax.xml.transform.Source ;
… think this:
namespace javax.xml.transform.Source ;
… meaning: “Any use below of the word “Source” can be assumed to mean the Source class from the library whose package is javax.xml.transform”
In its effort to find the class of that package you named, the Java Virtual Machine at runtime automatically looks through all the libraries you obtained and placed.
There is something called java standard library - this means that a lot of things are automatically avaibable to you and you don't have to add anything to pom file.
Maven is used for adding external libraries that are not included and shipped with your java.
Easiest way to find out if you need to add anything to pom file is to use good IDE (for example Intellij) that provides support for maven. It should mark any libraries that are missing - then add those to your pom file.
And you still need import everything you need to use for each *.java file.
You can also search Maven library by full class name by fc operator at search.maven.org
eg.
fc:javax.xml.transform.stream.StreamResult
https://search.maven.org/search?q=fc:javax.xml.transform.stream.StreamResult
Of course one class can be found in many library...
I'm started working on an already existing project. In this project there is some JSON-parsing happening with the following exception being thrown by several methods:
JSONException.class
While I was unit-testing these parsers I couldn't import the right org.json.JSONException library.
The maven library used in the codebase was (package org.json.JSONException):
org.json:json:20160810
And the one that was importing in my tests was (package org.json.JSONException):
com.vaadin.external.google:android-json:0.0.20131108.vaadin1
I think the problem lies in both libraries share the same package names. When the test is execute the JSONException is thrown but the test still fails because its probably the other library. Anybody knows why this problem is happening and how to solve it?
Thanks in advance!
I believe you need to updated your pom.xml file and in the dependency section you can exclude a 3rd party dependency from a declared dependency. I guess in your case there is a dependency to json and vaadin, you'll find vaadin is also pulling the different version of json.
You can try removing one of them. As suggested here:
https://github.com/spring-cloud/spring-cloud-deployer-kubernetes/issues/142
I am newbie at Java EE and I have a simple problem.
I created a project using Maven plugin's default directory structure and I want to annotate a class as #Loggable, but I get a
Loggable cannot be resolved to a type
error. Any annotation I want to use can't be resolved to a type. What's the problem? I suspect that it has to do with dependency or build path issues but I can seem to get it working.
You will have a list of dependencies in the pom.xml file of your maven project. Make sure the jar that has Loggable is listed as a dependency.
Read here how to do it.
Your import java.lang.annotation.*; will not help as Loggable is not in that namespace.
Maybe you should write this Annotation on your own. Read this to learn more.
You have to import annotation classes just like anything else. Use an IDE such as Eclipse; it will handle and many similar tasks for you automatically.
I am importing a Jar file "com.ibm.mq.jar" into my workspace(Eclipse IDE).
While importing, a screen came where I could see all the classes in the Jar file.
After I imported it into the work space, I was able to import the package and following statement didn't give any error.
import com.ibm.mq.*;
But, in code I am not able to use any of the classes which were there in the package.
Like, "MQC" is a class in the package, but in code it doesn't reflect("MQC cannot be resolved as a type" error comes if I try to use it).
This jar file actually contains Websphere MQ API classes.
Can anyone advise, what am I missing.
If you're using MQ 7, check its documentation here. There was some stuff going on about deprecation of com.ibm.mq.mqc and, depending on the version you use, that class was replaced by com.ibm.mq.constants.MQConstants. Like this one, there are other cases.
In fact com.ibm.mq only contains the exception MQException, so you won't find any classes there. I suggest you check the version you're using and dig a little deeper into the docs, as a first step.
I am using a 3rd party annotation processor for generating meta-data code (.java files) from the annotated classes in my project.
I have successfully configured the processor through Eclipse (Properties -> Java Compiler -> Annotation Processing) and the code generation works fine (code is automatically created and generated). Also, Eclipse successfully auto-completes the generated classes and their fields, without any errors. Let's say that I have a class "some.package.Foo" and that the generated meta-data class is "some.package.Foo_". By the help of auto-completion, I can get the following code in the Eclipse editor, without any errors:
import some.package.Foo_;
...
public class Test {
void test() {
Foo_.someField = null; // try to access a field from the generated class Foo_
}
}
However, as soon as I actually build the project (or just save the file since Build automatically is enabled), I get the error which tells that "some.package.Foo_" cannot be resolved.
It seems like Eclipse is generating and compiling the some.package.Foo_ at the same time, or more likely.
I found two temporary solutions (which are practically hindering the use of the annotation processor in the first place):
Before each build of that generated classes, right click on every generated file go to Properties and uncheck the "Derived" tick. After that, I do the cleanup of the project and the imports are fine - there are no more errors. However, if I do the cleanup one more time, the errors again show up, because the generation of the files causes the "Derived" tick to be checked again (automatically). So this is really annoying and time-consuming.
I also uncheck the "Derived" tick
from all those files, and this time
I uncheck the "Derived" tick from
the source folder and packages which
contain those files. Then I disable
the annotation processor, and then
do the cleanup. There are no more
import errors, even if I do another
cleanup, but there is no benefit of
using the annotation processor,
because if I was to change something
which would update the model, I need
to turn the annotation processor
back on, and repeat this tedious
procedure to turn it off, after it
has generated the new version of
those files.
Is this a bug in Eclipse? If yes, is there a better workaround or quick-fix than the two I have stated above? If not, what should I try to solve the problem?
I also tried rearranging the order of the libraries on the build path and it doesn't help.
I assume that you are generating sources in the last processor round. This is not recommended way and leads exactly to the problem that you had.
Explanation is here: http://code.google.com/p/acris/wiki/CodeGenerationPlatform_Pitfall_Rounds
So the my advise is to generate sources in regular processing rounds and final round should be used just for notification that processing is over or something like that.
Hopefully this helps you.
I have a similar problem, and the only thing I've found is that it's the imports specifically that don't work, but the references in the class itself do work. The workaround I've used is to use the FQCN in all cases where the generated class is needed (except when the generated class is in the same package, since then the import is obviously not needed).
So to use your example, I'd do:
public class Test {
void test() {
some.package.Foo_.someField = null; // try to access a field from the generated class Foo_
}
}
My only guess then is that the eclipse compiler is processing the imports before doing the annotation processing, which imho must be a bug in eclipse.
I know this question is over a year old, so I'd be interested to know if you've found any other way to fix it.
We were experiencing a similar problem and apparently just solved it, so thought of sharing it at SO, in case it helps someone.
We are using:
Eclipse Indigo (Build id: 20120216-1857)
m2e Connector for maven
openJPA for static metamodel class generation
Our problem:
Say, we have a package named com.abc.xyz and an entity class in there named OurEntity. When we build the projects (JPA, EJB, EAR etc. all together with an mvn clean at the beginning) the metamodel classes get generated. And also get appropriately packaged within the PU jar. But when we try to import the generated metamodel class com.abc.xyz.OurEntity_, Eclipse cannot resolve it. OP apparently got past this point:-). Maven build failed, saying it could not resolve that class. Not much help from google except for a few bug reports such as this one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=350378
That bug report said importing the whole package as opposed to the single class helped. So, tried that, but with no benefit. It also said (and so did David Heitzman) that using the fully qualified class name worked for them. That did not work either.
The solution:
Added the PU jar to Eclipse build path for the project that needed to use the metamodel classes. All of a sudden all the red underlines went away (not a surprise). But the fear was there might be two PUs in the same ear. But maven automagically took care of that.
As this rather old question got some attention without pointing to the very probable eclipse bug the OP was specifically asking for, I'd like to complement the above answers with a pointer to the eclipse bug tracker:
Cannot resolve import for generated class IF processing annotations with parameters referencing constants
The workarounds include
doing a wildcard import of the package defining the generated classes (i.e. import some.package.*;)
using the fully qualified name of your generated class, i.e. referring to some.package.Foo in your code and not using an import
switch to a newer Eclipse. This specific eclipse bug is resolved with Eclipse version 4.4 (aka Luna).