Hi Harshan,
Correct, I had a offline discussion with Sameera on this. But there are
some cases inside the business logic it requires axis2 context hierarchy
which only can access from admin service and cannot access from OSGI
Service level. In that case we cannot use this pattern in all the time.
Hi Godwin,
IMO keeping the business logic separate from the services will be more
appropriate. So that you can change the business logic later without
breaking the service contract.
Thanks,
Lakshitha Harshan
Software Engineer
Mobile: *+94724423048*
Email: hars...@wso2.com
Blog :
+1 for the option no : 03. Admin services are web services and those need
to got to a separate layer. In that layer no business logic is required.
Roshan Deniyage
Associate Technical Lead
WSO2, Inc: http://wso2.com
Mobile: +94 777636406
Twitter: *https://twitter.com/roshku
#3 is the answer, but need to verify carefully this works (with Prabath and
(Sameera or Kishanthan))
If this works, this is a common pattern we can used at other places.
On Fri, Nov 14, 2014 at 9:53 AM, Roshan Deniyage rosh...@wso2.com wrote:
+1 for the option no : 03. Admin services are web
Copying Prabath, Sameera and Kishantha.
On Fri, Nov 14, 2014 at 10:07 AM, Srinath Perera srin...@wso2.com wrote:
#3 is the answer, but need to verify carefully this works (with Prabath
and (Sameera or Kishanthan))
If this works, this is a common pattern we can used at other places.
On Fri,
Hi Godwin,
We tried the approach sometime back, but had to drop this coz of some
complexities.
* Some admin services needs to access the axis2 context hierarchy e.g.
MessageContext, properties set in Handlers etc. So you cannot put all
business logic to a OSGi Service.
* Admin services can
Hi All,
Thanks for the feedback, I think I described it wrongly, I didn't mentioned
3 options to do this, I mentioned 3 steps to overcome the issue. Sorry for
my bad.
@Sameera : As you have mentioned we'll be have issues when admin services
use axis2 context hierarchy e.g. MessageContext,
