I am following the "web service from pojo"[1] bottom-up guide in axis2 documentations, but the wsdl that is generated is not good.
Specifically, the xsd schema that is embedded in the wsdl is not good and I want to customize it. I want to allow cyclic references, in a similar fashion to what jaxb lets you do with XMLID and XMLREFID.
Any ideas?
Thanks
[1] -> http://ws.apache.org/axis2/1_5_1/pojoguide.html
If you use the Netbeans plugin for AXIS2 (tutorial here) you can specify to edit the WSDL, otherwise I can't help, sorry. Maybe you could look at the options available for the ant task?
I do find AXIS2 overly painful compared to other web service frameworks, and the documentation leaves a lot to be desired.
Related
I'd like to get some business apps up and running quickly with the use of JHipster, which seems like a solid approach; assuming it is allowed. Is the commercial use of a generated JHipster application allowed and if so, what are the proper steps to take in in order to not infringe upon any terms and conditions of open source?
I apologize if this has been asked previously.
I really just need to know how I can go about using an instance of a generated application for something other than an open-source project.
Sincerely,
Art
There are many closed source applications originally generated by JHipster. The generated project is fully yours.
I remember seeing the palette in Spring Tool Suite (long time back) to design the Spring Integration work flow which I cannot find in Spring Tool Suite 4.x. Can someone tell me if it is available as a separate add-on or how do I enable it?
Thanks.
See the answer to this question and associated comments.
It is not currently available in STS 4.x, although, as stated by Martin Lippert there, the 3.9.x tooling can still be installed.
Bear in mind that it was limited to a single XML configuration file and many modern Spring Integration applications use Spring Boot auto-configuration and the Java DSL which cannot be rendered by the graph; Spring Integration now provides a runtime graph that can be rendered by a number of tools and works with any configuration technology.
We have been looking closely at SPAs using Breezejs for providing the data context between the client and the server. The features look great on the client, but we want to use the Repository pattern on the server and get good separation of concerns without having to inherit from EFContextProvider which would cause problems with IoC and possibly unit testing/mocking. We have been following John Papa's Code Camper sample on Pluralsight which initially set out using a Respository/UoW pattern without Breeze which then led us to look at the Hot Towel template which does include Breeze.
Does anyone know how Breeze can be abstracted to a Repository which keeps the DbContext cleanly (if using Entity Framework) encapsulated. Also, what happens if you are not using Entity Framework and prefer to use another ORM such as nHibernate.
Thanks for posting here as I am sure others will ask this :)
If you don't use EF then you won;t get the automatic metadata creation that Breeze provides. You can certainly abstract the EF context into a Repo however, and still get the benefits.
The Breeze/Knockout ASP.NET SPA template shows the repository broken out. I believe there is a sample for the UoW somewhere - tho it escapes me where. I have asked the Breeze folks to point to an answer for that.
If you use nHibernate there is no automatic metadata - however that is a great feature request I could see for Breeze.
I try find some simple security plugin from Grails.
And first of all, i want ask you: what plugin you can recommend?
I not need super powerful plugin. Its must be simply and for small application.
Thanks.
I recommend Spring Security. It is easy to configure, and very flexible. It can handle everything from simple login, to annotated access controls on methods, to various complicated login schemes.
It does have a fairly complicated API, but there is plenty of documentation, and you can be sure others are using it.
If you just want simple login, it is really easy to set up.
More info here.
Per #robbbert suggestion, here is an alternative -- the Shiro plugin. I cannot speak to its reliability/community/expandibility.
We use Apache Shiro which is very simple to use and set up. It works by convention and supports both authentication and authorization.
I'm starting work on a new website (sort of an e-commerce product comparison thing) and I'm trying to choose what technologies to build it on. I've ruled out PHP and I don't think I want to use Python or Ruby. I really like Java and Hibernate so I started looking into Java-based web technologies.
My problem is that all of the documentation and examples I've read can't seem to stop repeating the words "enterprise" and "web applications." I'm afraid of ending up with giant XML configuration files and business-oriented components while losing the ability to actually design the website. From what I've read of JSF, I like the idea of reusable components, but I still want the ability to customize individual pages. So my question is, are JSF/Seam/Spring well-suited for non-enterprise development? If not, what Java technologies are?
I have just started looking into JSF/Seam so please forgive me if this is an uninformed quesiton. Thanks in advance. :)
No problem. The JSF/Seam stack gives you all the customization you want, and it has very few XML files. In fact, it uses a lot of annotations to define entities and components, so you don't have to worry about writing tou much XML (it is one of the reason why Seam was invented).
JSF's standard components are rendered as simple HTML tags, while if you want to go AJAX and use Richfaces it will be a little harder to customize it, but nothing dramatic. I can assure you that for the view part, you can write whatever you want in your webpages.
Here's a nice reference of how the JSF tags are rendered.
For the model and DB part, the JPA framework gives you the ability to work with simple Java Objects, and sometimes using it in an "enterprise" context with legacy schema is even more difficult, so don't worry.
For a simple website you may safely skip the EJB part, this will help you writing a more cleaner project structure. You can package all your website in a simple .WAR file.
As for the "enterprise" word, I think it is more related to the fact that the Java EE framework gives you the feature you may need in an enterprise context, (i.e. EJBs), but you can avoid them.
They don't bite.