Rafnu,
Thanks a lot for your feedback. A lot of what I am talking about below is addressed in Broadleaf 4.0, which is yet unreleased. The plan is for this to be in RC1 by early next week. To address your points:
Had they been built using @RestController rather than jersey/jax-rs
This is the new default for Broadleaf 4.0 and has been completed:
https://github.com/BroadleafCommerce/Br ... /pull/1221.
Broadleaf works well with Spring Boot (and spring 4)
Broadleaf 4.0 targets Spring 4.1. You are right that it is somewhat "old wine in new bottles"; we have a way to go with a lot of our design patterns to take advantage of the newer ways of doing things in Spring 4. One of the next major items for refactoring is to reduce/eliminate our need for a customized XML merging process. However, even though in Broadleaf we might not use all the latest and greatest, by the nature of targeting Spring 4 the idea is that people that are using Broadleaf can take advantage of those new features.
For Spring Boot specifically, this is again another refactoring process that we simply have not had time for. I would love to drill into the trouble that you had and see how we can address those individually and make that process easier. I can also see a tutorial for how to start with Spring Boot and add Broadleaf, or even refactor our public DemoSite to be a Spring Boot based project. Unfortunately, we have limited resources (still a small company) and limited time to solve all of these refactoring problems. We would love to support community efforts here.
Cloud
We can definitely improve in this area. This year we are going to be focusing on documentation, various strategies for production deploys is one of the areas. Getting the site and admin to deploy on the same instance specifically is lower on the priority list.
API Doc - I rolled out Swagger for the existing endpoints.
I would love to see what you have done here; writing some sort of blog or tutorial on how to use Swagger with the Broadleaf endpoints has been on my backlog for a while.
I found this was due to the fact that wrappers don't have getters.
I didn't realize this could manifest itself in this way. We have an issue open at
https://github.com/BroadleafCommerce/Br ... issues/651, it would be great to have a pull request that solves that.
Custom wrappers - I wrote some custom wrappers by extending existing wrappers
applicationContext-entity.xml is a specialized applicationContext; you need to put wrapper overrides in a different applicationContext. This is not well documented at this point.
but this had cascading effect which resulted into many changes in endpoint.java file
Not sure what you mean by this, can you elaborate?
4.) Endpoints are not logical
I agree with you, can you open an issue at
https://github.com/BroadleafCommerce/Br ... rce/issues?
Registered User Checkout - Using rest api, if an existing user (but not logged in)
This is a great point, not sure how to solve it. It would be awesome if you could open an issue at
https://github.com/BroadleafCommerce/Br ... rce/issues with a potential solution, or even just present that problem.
I was writing Tax module for Vertex and not able to get soap response integrated inside calculateTaxForOrder() implementation of TaxProvider
Not sure what you mean by this, need more information.