Is there a tool or maven plugin to generate a xsd-file for a JSR-303 annotation-based bean? I use SpringMVC for my REST services and validate the beans using JSR-303. Now i want to generate for based on the beans xsd files.
I assume you re asking about generating XML configuration files. The xsd files are schema files the configuration files have to adhere to. For JSR 303 the schema file can be found at http://www.jboss.org/xml/ns/javax/validation/mapping/validation-mapping-1.0.xsd.
From what do you want to create the xml configuration from? From already annotated entities (annotations are the default configuration source which can be overridden by xml)? Or do you want to create xml configuration files from scratch? For the former, I don't think that there are any tools which generate Bean Validation xml configuration files from annotated entities. For the latter, some IDEs (for example Idea) have some basic support for Bean Validation and its xml configuration.
Is this answering your question?
Related
I am a new user of Spring framework. I am facing some confusion in understanding the difference between core spring framework and spring boot. As far as I understand, Spring boot is a framework which performs the initial setup automatically (like Setting up Maven dependencies and downloading the jar files) and comes with an embedded Tomcat server which makes it ready to deploy in just one click., Whereas, Spring MVC requires manual setup. All the tutorials that I watched for core spring show bean configuration using bean factory which configures the beans using a .XML file. In Spring boot, this bean configuration file is absent. My question is, what is the use of this bean configuration file? I did not find any legitimate use of this file in making a REST service with spring. I didn't see any use of the Application Context, Bean Factory in creating web application. Can someone point out how can bean factory be used in Spring web apps? Is there any fundamental difference between core spring and spring boot other than the additional components?
The Spring application context is essentially the "pool" of beans (service objects, which include controllers, converters, data-access objects, and so on) and related information that define an application; I recommend the reference introduction. In theory, you can get complicated with the context setup and have hierarchical organization and such, but in most real-world cases you just have a single plain context.
Inside this context you need to install all of the beans that provide the logic for your application. There are several possible ways to do this, but the two main ways are by providing XML files with have directives like bean (define an individual bean) or component-scan (automatically search for classes with certain annotations, including #Controller) and by using Java classes annotated with #Configuration, which can use annotations and #Bean methods.
The XML style is generally older, and newer applications mostly use Java configuration, but both provide entries that are collected into the context, and you can use both simultaneously. However, in any application, you have to provide some way of getting the registration started, and you will typically have one "root" XML file or configuration class that then imports other XML files and/or configuration classes. In a legacy web.xml-based application, you specify this in your servlet configuration file.
Spring Boot is, as you said, essentially a collection of ready-to-go configuration classes along with a mechanism for automatically detecting configurations and activating them. Even this requires a configuration root, though! This is the #EnableAutoConfiguration instruction, frequently used through its composite #SpringBootApplication. The application context and configuration mechanisms work normally once Boot finds them and pulls them in. Spring knows where to get started because you give it an explicit instruction to build a context starting with that entry point, usually with SpringApplication.run(MyApplication.class, args).
The embedded-server configuration just happens to be a particular set of configuration that is really useful and comes with one of the Boot starter packages. There's nothing there that you couldn't do in a non-Boot application.
I am developing an application that runs on Spring Boot configured via XML. For modularity, I didn't want to use #ImportResource as it requires me to go into the source code when in XML configuration I can just configure the XML files to change dependencies.
The problem is that I'm using Spring Boot to run my Spring MVC Controllers (#Controller) and for me to make use of the dependencies I configured in my XML files, I need to declare #ImportResource, which I don't want to use.
Is there any workaround to not use #ImportResource while still using XML config files to inject the dependencies in my Spring MVC Controllers?
If you are using spring boot and you are ok with mentioning the config location in application properties, you can do this in application.properties
config:
location: file:///config.xml
And the you can use this property in your #ImportResource
#ImportResource("${config.location}")
This way you can avoid changes to the source code, while still using xml configuration.
My question is the following:
Is it possible to ignore XML configuration for HibernateValidator, i.e. exclude validation.xml parsing in a SpringBoot application?
I do not have the need for a validation.xml in my application, but I see that when the application starts up, it tries to parse this file.
I found this in the Hibernate Validator documentation (https://docs.jboss.org/hibernate/validator/4.1/reference/en-US/html/validator-xmlconfiguration.html):
It is even possible to ignore the XML configuration completely via Configuration.ignoreXmlConfiguration().
What I see is, that in the LocalValidatorFactoryBean.afterPropertiesSet() method, the configuration is created for the validator. This bean has a method called postProcessConfiguration(Configuration configuration), which is called before the validatorFactory is built from the configuration.
It seemed an ideal place to call the ignoreXmlConfiguration() method, what the documentation suggested.
I tried to extend this LocalValidatorFactoryBean, so that I can implement this call in the above mentioned method. Then I tried to load this bean via java configuration class.
Unfortunately some bootstrapping mechanism already uses the Spring provided bean, before it finds mine, the two beans run at the same time. I saw the message saying that XML configuration is ignored the with the bean I created, however, this solution did not help, because the Spring provided bean is not substituted with mine.
I also tried to find if there is any application property that I can use, or exclude some autoconfiguration, but no luck.
Any ideas? :)
UPDATE:
I tried excluding the HibernateJPAAutoConfiguration, it didn't help.
If you dont need hibernate validator then remove all dependency related to hibernate validator from pom.xml file.
you can also try #EnableAutoConfiguration(excludes=) annotation adding on your Application class to exclude default validation configuration.
like #SpringBootApplication(exclude = {HibernateJpaAutoConfiguration.class,DataSourceAutoConfiguration.class} })
I am using Hibernate 4.3.6.Final with JPA and Spring 4.0.6.RELEASE in my project with Java Configuration.
I have two jar files. module1.jar and module2.jar. module1.jar has some entities
and module2 has some entities. I can't use the module1.jar entity in module2.jar without using
persistent.xml and
<jar-file>module1.jar</jar-file>
Is it necessary to have persistent.xml as I am using
entityManagerFactoryBean.setPackagesToScan("com.mydomain") to scan all the entities from all jar files.
No, it is not necessary to use the persistence.xml if you are configuring Spring's entityManagerFactoryBean with setPackagesToScan().
From New Features and Enhancements in Spring 3.1:
3.1.12 JPA EntityManagerFactory bootstrapping without persistence.xml
In standard JPA, persistence units get defined through META-INF/persistence.xml files in specific jar files which will in turn get searched for #Entity classes. In many cases, persistence.xml does not contain more than a unit name and relies on defaults and/or external setup for all other concerns (such as the DataSource to use, etc). For that reason, Spring 3.1 provides an alternative: LocalContainerEntityManagerFactoryBean accepts a 'packagesToScan' property, specifying base packages to scan for #Entity classes. This is analogous to AnnotationSessionFactoryBean's property of the same name for native Hibernate setup, and also to Spring's component-scan feature for regular Spring beans. Effectively, this allows for XML-free JPA setup at the mere expense of specifying a base package for entity scanning: a particularly fine match for Spring applications which rely on component scanning for Spring beans as well, possibly even bootstrapped using a code-based Servlet 3.0 initializer.
I am building a sort of validation framework for a GWT project.
The point is to reuse the same validation code for both client and server side.
I found that jsr-303 Bean Validation is supported by both GWT(here) and Spring(here).
As my model object are generated and I cannot annotate them properly, I would like to use xml-based configuration for jsr-303 Bean Validation. However, I don't see a way of doing it with gwt-validation.
Is there a way I configure the gwt-validation using xml instead of annotations?
It looks like there's no way of doing this yet.