Still getting in my raw project (established only for #Pattern exercises in #Entity without any Spring framework and servlets):
Exception in thread "main" javax.validation.NoProviderFoundException: Unable to create a Configuration, because no Bean Validation provider could be found ...
I've decided to try it with Jakarta libraries and found in hibernate operate manual point 1.1.3. "Running with a security manager" such an additional, suggested configuration lines to put in the java policy file
vide: https://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#section-getting-started-security-manager
but before I will begin configuration tests with my $JAVA_HOME/lib/security/default.policy file I would like to gather information: how to refer to libraries that I would like to authorize in this file for the appropriate accesses?
Should I give this direct path to the jar files or point only to the fully-qualified class name? and what is the correct syntax in default.policy?
I don't know what you think you are doing, but the error clearly says that there is no bean validation implementation available on the class-/module-path. The reason why it can't find the provider depends on your project. Maybe you didn't specify it as dependency? Anyway, if you need further help, you will have to post more information about your project and runtime setup.
Related
We had recently moved to building projects using Maven. Earlier, all the JARs were added in libs folder and added to classpath. While moving to the Maven build, I missed to add a dependency to the 'sqlite-jdbc'. This library is required to read data from a local .db3 file.
As the 'org.sqlite.JBDC' class was loaded by calling the code Class.forName("org.sqlite.JDBC"), there was no compilation error and I deployed the WAR file and servlet failed in the server. I was thinking of a way to find the issue at the compilation time itself to avoid any such mistakes in the future. Can I simply call the JDBC.PREFIX to load the JDBC, so that, If I forget to add the dependency to the pom.xml file, I can find the issue at the compile time, itself?
Is there was difference between Class.forName("org.sqlite.JDBC") vs JDBC.PREFIX to load JDBC class?
No need for Class.forName
There is no generally no need to call Class.forName.
Such calls were used in the early years. Modern Java was changed so that JDBC drivers are automatically loaded and registered with the JVM via the Java Service Provider Interface (SPI) facility.
If you are using books or tutorials advising Class.forName, you may want to obtain more up-to-date learning materials.
DataSource
Furthermore, in Servlet work you generally should not be explicitly accessing the JDBC driver.
Setting the database server address, username, and password would require hard-coding text. When the deployment sysadmins change the IP address, or rotate passwords, your code breaks. You would then have to modify your source code, re-compile, and re-deploy.
Instead, you should externalize such configuration details.
For SQLite, see Using DataSource to connect to SQLite with (Xerial) sqlite-jdbc driver.
JNDI
You can externalize database configuration by using the the DataSource interface. After obtaining a DataSource object at runtime, make database connections by calling its getConnection method. That DataSource object holds the database server address, username, password, and all other settings needed to make a connection to the database.
Obtain a DataSource object at runtime by using JNDI. Your Servlet container may act as the naming/directory server to provide the DataSource object, if your sysadmin so configures it. Or the DataSource can be obtained via JNDI from an external server such as an LDAP server.
Again, the beauty of using DataSource and JNDI is that you as the Servlet programmer need not be involved, or even informed, when the deployment details change.
JDBC driver location
For Servlet work, you generally do not bundle the JDBC driver with your app.
Instead, the JDBC driver goes into a folder managed by your Servlet container. Study the documentation for your particular Servlet container. For Apache Tomcat, see this Answer.
In development, your IDE may need access to the JDBC driver to compile. If so, in your Maven POM, mark the dependency with a <scope>provided</scope> element. This tag tells Maven to omit that dependency from the final build because the dependency will already be present (provided) at runtime.
If you insist on bundling your JDBC driver within the WAR file of your web app, then see the important Comment by Mark Rotteveel.
This topic has been addressed many times on Stack Overflow. Search to learn more.
As the title mentioned, I have a A component required a bean of type [SomeBean] error and I would like to know which component requires [SomeBean]. Is there a way to get more information on which bean requires the missing one?
Also, why do I get this error message? I am pretty sure that sometime missing beans generate a clearer message stating what beans require the missing ones.
Why I am asking:
I am trying to make a spring application that is similar to another (working) one, and use many similar beans. But I have trouble following the bean dependencies. So I removed one bean of the working application and run it in order to know where and how this component is used.
=> So, in general, I am looking for good ways to track bean dependencies in complex contexts.
Some time my IDE (intellij ultimate 2019) gives me some information, but here it doesn't. Maybe because the dependencies span a few packages, many being outside the application code, and use AutoConfiguration. Don't know...
If I use the spring diagram, it generates something that is not really readable (too meany beans). And the diagram is more a list of found beans structured by where there are provided, not the bean dependency diagram: my application list the beans it provides, and the autoConfig list the beans it provides. But It doesn't tell what bean of the autoConf is using which bean that my app provides. Or maybe I just don't understand how it works.
The default log configuration echoes messages to the console as they are written. By default, ERROR-level, WARN-level, and INFO-level messages are logged. You can also enable a “debug” mode by starting your application with a --debug flag.
So, indeed, you should enable that debug mode to see a more detailed log information about your error, which seems to be a missing required bean dependency.
See some more detailed info about in Spring Loggin
I wasn't able to find the solution and I found more people stuck in the same problem so I will post it here.
By default a JAX-WS server (at least for WebLogic) will not validate the message received with its associated schema.
This can lead to a lot of problems since any invalid value (wrong xsd:dateTime format, letters on a number field, etc) will result in a null value in the Java object, including mandatory fields.
What I need to do is a simple validation that should be provided by the server.
import com.sun.xml.internal.ws.developer.SchemaValidation;
#Stateless
#WebService(portName="ValidatedService")
#SchemaValidation
public class ValidatedService {
public void operation(#WebParam(name="request") ValidatedRequest request) {
/* do stuff */
}
}
For some reason when I was trying to use the provided schema validation I was getting the following exception:
Caused By: javax.xml.ws.WebServiceException: Annotation #com.sun.xml.internal.ws.developer.SchemaValidation(handler=class com.sun.xml.internal.ws.server.DraconianValidationErrorHandler) is not recognizable, atleast one constructor of class com.sun.xml.internal.ws.developer.SchemaValidationFeature should be marked with #FeatureConstructor
I do not wish to implement any custom validator. The server should provided this type of service with simple and straightforward configuration.
The problem was: I was using the wrong package for #SchemaValidation.
The correct class that worked for me is com.sun.xml.ws.developer.SchemaValidation, which is provided in the file mw_home\modules\glassfish.jaxws.rt_1.3.0.0_2-1-5.jar (using WLS 10.3.6).
In the previous code segment I was referencing the wrong package: com.sun.xml.internal... but using the one provided by WebLogic worked instantly.
If you are using Maven and using the bundled JAR as dependency you might not have this library in the classpath, which led me to the problem. You need to add it to your classpath via dependency (provided scope only) and reference the correct package for that class name in your JAX-WS WebService class (an abstract class won't do it).
More information in the Enabling Schema Validation on the Server page.
This schema validation is enough for me at the moment since I do not need any custom behavior.
In my case: Maven project with many modules. I got the next error when was trying to deploy application into tomcat:
failed to parse runtime descriptor: javax.xml.ws.WebServiceException: Annotation #com.sun.xml.ws.developer.SchemaValidation(handler=class com.sun.xml.ws.server.DraconianValidationErrorHandler) is not recognizable, at least one constructor of class com.sun.xml.ws.developer.SchemaValidationFeature should be marked with #FeatureConstructor
I resolved problem by don't including jaxws-rt.jar in WEB-INF/lib.
It appears that this library already exists in the tomcat/lib folder.
Just tuned up pom.xml, setted provided scope for this dependency entry.
Now all works fine.
I am attempting to get a WAR file to run inside of a Karaf OSGi container. The application runs correctly in stand-alone Jetty 6.1.26, but when the application is run inside of Karaf, I get the following exception and the Karaf instance freezes:
WARN org.hibernate.ejb.packaging.InputStreamZippedJarVisitor - Unable to find
file (ignored): bundle://125.0:240/ java.lang.NullPointerException: in is null
Note that the application is not relying on Hibernate in a separate OSGi bundle; it includes the hibernate jars in WEB-INF/lib.
I have examined the information on this post: Equinox (OSGi) and JPA/Hibernate - Finding Entities. However, the application is using JPA, rather than using Hibernate directly. The application's configuration is much like the 2nd option found in this post: Difference between configuring data source in persistence.xml and in spring configuration files. As such, I don't have a handle on a Hibernate SessionFactory that allows me to set the annotatedClasses property.
Any ideas on how to get past the exception?
I worked in parallel with the author and I'll post our solution here for anyone that runs into this in the future.
The exception is thrown because Hibernate tries to unzip it's jar to look for the persistence classes. As other posts mention, OSGi does not allow Hibernate to act like a classloader, so this fails. The solution was specifying all of the classes that it needed to load by hand and then telling it not to try to load anything else.
We used a persistence.xml file and an orm.xml file (we used default names so we didn't have to specify either in our applicationContext.xml).
Our persistence.xml file simply pointed to the orm.xml using the <mapping-file> tag. It also included the <exclude-unlisted-classes/> tag to keep hibernate from trying to load additional classes.
Our orm.xml file used <entity class="path.to.my.class" metadata-complete="false"/> to call out every entity class that we needed to load. The metadata-complete part tells hibernate to use the annotations found in the class to complete the configuration.
I am trying to get schema validation working for a JAX-WS Web Service deployed on Weblogic 10.3.3.
According to the documentation, this should be as simple as adding the annotation
"#SchemaValidation" to the endpoint class. However when I try this the following exception is thrown when the application is deployed:
Caused by: javax.xml.ws.WebServiceException:
Annotation#com.sun.xml.internal.ws.developer.SchemaValidation
(handler=class com.sun.xml.internal.ws.server.DraconianValidationErrorHandler)
is not recognizable,
atleast one constructor of class com.sun.xml.internal.ws.developer.SchemaValidationFeature
should be marked with #FeatureConstructor
at com.sun.xml.ws.binding.WebServiceFeatureList.getWebServiceFeatureBean(WebServiceFeatureList.java:169)
at com.sun.xml.ws.binding.WebServiceFeatureList.parseAnnotations(WebServiceFeatureList.java:141)
The error message is complaining that "com.sun.xml.internal.ws.developer.SchemaValidationFeature" does not have a constructor annotated with #FeatureConstructor. When I look at that class, it sure seems to have one:
#com.sun.xml.internal.ws.api.FeatureConstructor(value={"handler"})
public SchemaValidationFeature(java.lang.Class arg0);
I have googled around but cannot find any reference to this more than this fellow unfortunate soul who did not get any answers. It would be great if someone could point me in the right direction because at this moment I am stuck.
SchemaValidation annotation is working, but make sure you're importing correct class.
com.sun.xml.ws.developer.SchemaValidation
instead of
com.sun.xml.internal.ws.developer.SchemaValidation
The second class is bundled with JDK by default. The first one (used by weblogic) comes from glassfish.jaxws.rt_XXX.jar, so you may need to add this jar to your classpath explicitly.
I have faced the same problem recently.
To overcome this, I added the tag
<validation-request>true</validation-request>
to the file weblogic-webservices.xml
This enabled SOAP request validation on the app-server.
XML Structure of weblogic-webservices.xml
Note : I have not been able to use the #SchemaValidation tag successfully, but the above way - works as expected.