I'm trying to execute a small spring application in my eclipse ide.I have downloaded the spring-framework-4.1 zip file. I want xml schema to put it in my spring.xml file.where can i get the schema from the downloaded zip file?
thanks.
Usually the xsd schemas come in one of the packaged within the jar files, for example within org.springframework.beans.factory.xml there are the spring-beans-X.X.xsd files, try to search the entire zip looking for the files that ends with .xsd.
Sometimes the xsd files are contained within the config packages for example.
org.springframework.data.jpa.repository.config
I should recomment to use STS it can be create the namespace configuration on behalf you, just clicking in the namespace tab and add what you required.
Or you can download from here, but again I should recommend use maven to download dependencies.
Related
I am using liferay 6.2 & built a maven portlet and working fine, I want to use its tables to store data for another portlet so that I need its services in this portlet.
But we can't access it externally so i find a way something like: required-deployment-contexts=Portlet-Project1 inside liferay-plugin-package.properties, then found its works for Ant only.
I was also finding the xxx-portlet-service.jar but didn't able to, so that i could manually put it in other portlet's lib folder i.e inside tomcat-webapps-xxxportlet-WEB-INF.
Just want to find how to use xxxLocalService.util in other in maven portlet
The best approach you can implement is a plugin to manage all the interaction with the DB.
First of all you must create a Service with a maven project and include it into your pom.xml in each portlet that you need. Then you can invoke its methods whenever you want because each portlet will store the dependencies.
Create Service Plugin into jar file
Rebuild with mvn clean liferay:build-service
Custom your own methods to manage the iteraction with the DB (LocalServiceUtilImpl and rebuild).
Include this plugin into pom.xml portlets
Rebuild your portlet.
The JAR will be placed in your .m2 folder, then each time that you rebuild your Service Plugin will be updated.
If i understood your question correctly, You need to create service builder project using maven and then you can add as dependency in other project wherever you need access to use xxxLocalServicutil class.
You can follow below link to create maven service builder project.
http://www.liferay-guru.com/how-to-use-liferay-servicebuilder-archetype/
As you mentioned in your question.
was also finding the xxx-portlet-service.jar but didn't able to, so
that i could manually put it in other portlet's lib folder
To answer this, manually putting .jar file in lib directory will not help when you are working with maven project
Does anybody knows if we can store the properties file under different folders on github and then spring-boot config server can read those files?
for example if my repository for properties file is:
https://github.com/chetankokil/configfiles
Can i have as many folder as i want under config-files repository and then these folders will have properties files under it? Can it be done?
I would suggest to take a look at Spring Could Config module. Spring ecosystem has your use case covered and it's better to follow proven footsteps rather than creating your custom solution.
You can create various directories in Github and provide bootstrap.properties file in your project. A sample bootstrap file is shown below
spring.cloud.config.uri=<your config server url>
spring.application.name=<your folder name in github>
spring.cloud.config.label=<github project branch name>
spring.output.ansi.enabled=ALWAYS
spring.profiles.active=<active profile in spring>
I have created a flow under a subfolder in src/main/app in mule. So now I have a global folder under src/main/app and I have created a flow in the global folder.
When I do a maven build and run the project I am getting the errores config for app not found.
Is there ny work around for this problem,
Note : config.resources gets automatically updated with all .xml file with corresponding sub folders when I do a maven build.
I tried to put a flow in a subfolder under apps like you did but by doubt where confirmed.
When Mule is preparing the zip is not scanning and including the subfolders of /app in the main app folder on deploy but under classes, this causes the error that conf file cannot be found.
At this point if you really want to have flows in subfolder you have only one option:
Move your shared resources flow in src/main/resources/ for example under a folder flows
Add a spring include to your test.xml flow in this way
<spring:import resource="flows/shared-resources.xml"/>
This will include the other flow in your test flow and it will be virtually the same than having them listed in the mule-deploy.properties
Note that if your common flow contains logic that could potentially be reused on multiple mule apps you can also put it in a separate mule app that you can package as jar and include as a dependency.
Just google create mule commons libraries if you want to know more, I wrote a blog post about it but link it here will look like self promotion.
Hope this helps
In my project I use Maven to package a web application to a WAR which is later deployed to Jetty using a custom Maven plugin on CentOS. The custom plugin is used by every project that deployes to a production environment. There is now a requirement that all static content (like web site text, properties) is packed outside of the WAR so that it can be changed in production without requiring a new release cycle. I am unsure how to achieve this externalization.
The Jetty server has the directory structure described in Jetty quick start guide. Currently, the web application already offers some .properties files which can be altered externally, and these reside in the resources/ directory. These files are moved here by the custom Maven plugin. The WAR resides in the webapp/ folder. One option for my problem is to use <packagingExcludes> of maven-war-plugin to not include e.g. *.xhtml and *.properties in the WAR. Later, I can use the custom Maven plugin to move excluded files to resources/ directory. But, I have a feeling this is not the correct way to externalize static content... Shouldn't xhtml files live in webapp/ folder while the only the properties file live in resources/ folder?
I have also researched the option of deploying the WAR as exploded, but I am unsure of the implications of such. Clearly, the changes in the exploded WAR files will be overwritten in the next deploy, but the idea is to do static changes both in development and production. Also, I am not sure how to achieve WAR "explosion", is it something that Jetty does for your WAR if configured in jetty.xml or do I have to extract the WAR before deploying?
Lastly, how do people serve static content in Jetty which can be altered in production? Do both the WAR and static files live side by side
The Jetty resources folder should not be used for application files. A J2EE web application (war) should be self-contained -- and in Jetty, reside only on the /webapps folder -- and its only binding to the container (Jetty servlet engine) is via the web.xml deployment descriptor.
Since property files may be read from the classpath and the Jetty resources folder is part of the system classpath, a property file there could be read by the web application class loader. Note that there are other ways to read property files as well and the Jetty resources folder should not be used for application properties. Also, the application may not be portable as other application servers have different forms of webapp classloader isolation.
If the below architecture approach does not work for you, then your only approach would be to expand (explode the war) in the /webapps folder and hope for the best when files are edited.
Tackling this from a different angle,
- if your web application depends on .properties and .xhtml files in order to function properly, then these files are probably not 'content'. The fact that there is a business process that requires them to to be updated ad hoc does not make them content.
- 'content' is something like text, images, and videos that is added, edited and removed by an administrative user. The application does not depend on it for correct execution, it merely reads and passes it on the browser.
Suggestions:
I would suggest that you deploy your application every time there is a change to the .xhtml or .properties files change. If the editors of these files are power business users, you might think of a git push-pull tool for them and a continuous build hook, so that when they make changes and push them to the git repository, the application gets tagged with a newer version and gets built and deployed. If there is a problem (tag not closed in xhtml), then it would be easy to roll back to the last tag.
Alternately, if the changes are minor (such as text descriptions), then modify the application to read them from an arbitrary external file (outside the webapp) -- a location that is provided to the webapp on startup. You can then package a 'default' version of the file in the webapp, but the code would attempt to look in the specified external location first.
I discovered that you can add HTML tags to properties and later use <h:outputFormat> to fetch these properties with parameters. Also, you can do pretty neat stuff with property files as described in MessageFormat API.
My solution was to keep the .xhtml files inside the WAR, but use simple HTML snippets properties from the default resource bundle which is based on a .properties file. These properties were included in the .xhtml using <h:outputFormat>and <h:outputText>. This allows the user to add simple styling like bold and underline to the snippets.
The properties file are copied to the Jetty resource folder using the custom Maven plugin, so I have kept the .properties files in the WAR. For some reason the Jetty resource folder has precedence over the packed .properties files, so this works out fine. Also, as Akber pointed out, I will have the default versions of the properties available if for some reason the WAR was moved to some other application server where the resource folder is not available.
Of course, with this approach the code can break if malformed HTML is placed inside the snippet properties, as pointed out by Akber, but it works for our application as it is very small. I may never have done this if this was a much larger application, but then I might have gone for a database based solution for adding static text (like Joomla/Drupal/Wordpress).
When running the packaged app like "java -jar my-app-0.0.1-SNAPSHOT-jar-with-dependencies.jar", I get the following error:
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 47 in
XML document from URL [jar:file:/.../cxf/javafirst/target/my-app-0.0.1-SNAPSHOT-jar-with-dependencies.jar!/application-context.xml]
is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 47;
columnNumber: 61; cvc-complex-type.3.2.2: Attribute 'sendServerVersion'
is not allowed to appear in element 'httpj:engine'.
This is due to an outdated http-jetty.xsd schema published at apache.org. And that is NOT my problem. My problem is that this does not happen in cases like:
maven jetty:run
or
maven exec:java
where the service runs directly against the unpacked binary directories and obviously finds the updated and correct http-jetty.xsd schema file.
I want to do basically one thing:
put the webservice into one jar including dependencies. That should also include all XML schema files because, obviously, it is not a good idea to make a web service dependent on outside resources.
What's the best way to do that using maven?
My possibly naive solution would be to copy the XML schema files manually into the resources directory and tell CXF to resolve them in the jar file. Therefore I have two more specific questions:
1.) Is it possible to let maven find the XML schema files and copy them into appropriate places?
2.) What's the recommended way to make CXF look up the schema files in the jar file?
3.) Is there any better, best-practice solution to that problem?
My maven configuration regarding the maven assembly plugin is the direct combination of the last two sections at http://maven.apache.org/plugins/maven-assembly-plugin/usage.html.
Spring has a very good mechanism to resolve the schema files that it requires - it typically does not download it from the web at all, instead using locally available files within jar files to get the schema and validate the xml, for eg. consider the context custom namespace schema in Spring, if you look at the META-INF/spring.schemas file in spring-context.jar file, you will see an entry along these lines:
http\://www.springframework.org/schema/context/spring-context-3.1.xsd=org/springframework/context/config/spring-context-3.1.xsd
basically what it is saying is to resolve the spring-context-3.1.xsd files from the classpath org.springframework.context.config.spring-context-3.1.xsd file
This applies for any third party library also, which in your case is http-jetty.xsd.
I think what I would recommend is to simply create a spring.schemas file in your jar file in META-INF/ folder, put an entry for the full path to the schema and replace it with a classpath version of http-jetty.xsd.