Re: [Discuss]Make omega and alpha decouple with spring-boot
Ok, I’ll keep the old aspect processor way. And OmegaContextAware annotation have not used in pack, I think we should delete this unused code. > On Jan 17, 2019, at 9:54 PM, Willem Jiang wrote: > > I prefer to keep the Aspect annotation processor in the old way and OK > for for put Omega components initial code together. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Thu, Jan 17, 2019 at 5:36 PM zhaojun wrote: >> >> I’ll try to refactor the code in my local repo today. >> Please feel free if you have any advice. >> >> -- >> Zhao Jun >> Apache Sharding-Sphere & ServiceComb >> >> >>> On Jan 15, 2019, at 11:37 AM, zhaojun wrote: >>> >>> Hi, Willem >>> >>> Thanks for the comment. >>> >>> 1. Current implement we use @EnableAspectJAutoProxy to create proxy bean, >>> please see TransactionAspectConfig. >>> it will auto-config AnontaionAwareAspectJAutoProxyCreator, this is the >>> AspectJ implementation for AbstractAutoProxyCreator. >>> If we exetend AbstractAutoProxyCreator directly, we can control the >>> annotation and proxy creator more flexible. >>> We can complete annotation parse within proxy creator instead of defining >>> another BeanPostProcessor to parse it. >>> In one word, we can make currently implement more better. >>> >>> 2. Yes, we can find a way to aggregate this code together, and provider a >>> api interface for spring-boot. >>> >>> >>> -- >>> Zhao Jun >>> Apache Sharding-Sphere & ServiceComb >>> On Jan 15, 2019, at 9:47 AM, Willem Jiang wrote: Here are some of my comments for the design: 1. I don't think we need to use the internal AOP API (AbstractAutoProxyCreator), current AOP solution is much straightforward, we don't need to bind to the internal API unless we want to create the proxy ourselves. 2. In ServiceComb starter, we have the configure to setup beans of Omega to use, I think we just need to find a way to reuse this code in none Spring Boot application. 3. +1 to create the Transaction Engine in the Omega Core. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Mon, Jan 14, 2019 at 7:38 PM zhaojun wrote: > > I have made omega design for this issue[1], please feel free to give me > some advice. > > > [1] > https://cwiki.apache.org/confluence/display/SERVICECOMB/refactor+design+of+service-comb+pack+omega > > > -- > Zhao Jun > Apache Sharding-Sphere & ServiceComb > >> On Jan 14, 2019, at 5:27 PM, zhaojun wrote: >> >> I have created SCB-1113[1] to track this issue. >> >> [1] https://issues.apache.org/jira/browse/SCB-1113 >> >> -- >> Zhao Jun >> Apache Sharding-Sphere & ServiceComb >> >>> On Jan 14, 2019, at 5:21 PM, zhaojun wrote: >>> >>> OK, let me create a JIRA, and try to refactor it >>> >>> -- >>> Zhao Jun >>> Apache Sharding-Sphere & ServiceComb >>> >>> On Jan 14, 2019, at 4:50 PM, Willem Jiang wrote: Yeah, we just need to think about starting the Omega context by wiring the components through Spring API, then wrap it with Spring Boot Starter API. In this way we could support to inject the Omega context not only to the Spring Boot Application but also Spring Application. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Mon, Jan 14, 2019 at 3:09 PM zhaojun wrote: > > Hi, all > > I think we should provide api way to bootstrap omega and alpha. > Now our code was tightly coupled with spring-boot, it is not possible > for integrated with other middleware. > We should provide Omega.init(), Alpha.init() api, spring-boot was > just one implementation for Pack. > > Any thought? > > -- > Zhao Jun > Apache Sharding-Sphere & ServiceComb > >>> >> > >>> >>
Re: [Discuss]Business exception cannot be rollbacked in ShardingSphere with saga transaction.
I think it could be be resolved in ShardingSphere and catch the business exception and mark the cached result "ROLLBACK_ONLY". Anyway, this should be done before submitting to the saga actor. tsubasaotl 于2019年1月16日周三 下午8:06写道： > Hi, everyone. > > > In ShardingSphere, SQL and their execution result will be cached in saga > transaction manager. > When users call `commit` or `rollback` method, the cached SQL will > generate `SagaDefinition` > and submit it to the saga actuator. > > > Saga actuator do `Transaction` first and get execution result from cached. > When the result is successful, the actuator will directly judge that the > Transaction is successful > and execute the next Transaction. > When the result not found in cached or the result is failed, the actuator > will do retry or compensation > according to configuration. > > > But there is a problem that saga actuator cannot rollback when business > exception happened. > The situation will happen in following workflow. > > >---multiple times--- > begin transaction --> | execute SQL --> cached result | --> throw business > exception --> call rollback >-- > | > > | > > | > but all SQL success, saga actuator don't run compensation <-- get result > from cache <-- saga actuator > > > All SQL is executed successfully, but the business program throws an > exception. So the actuator will judge > transaction is successful, and not to do compensation, which makes users > confused. > > > On this issue, I would like to ask for advice, should resolved in Saga > actuator or ShardingSphere? > And how to resolve better? > > > -- > Yi Yang (Sion) > Apache ShardingSphere contributor
Re: [discuss] change mechanism of java chassis POJO consumer paramters mapping
java8 support present interface method parameter name
need to add compile argument, not debug option
在 2019年1月17日星期四，Willem Jiang 写道：
> Java compile will remove the parameters name by default. We faced the
> same problem in CXF simple frontend.
> The solution could be enable the debug option in the compiler or add
> annotation to the parameters.
>
> If we decide to setting the option on the compiler, we should not only
> throw exception in the runtime, but also document it.
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Thu, Jan 17, 2019 at 5:23 PM wjm wjm wrote:
> >
> > Scenes：
> > 1.producer is springMVC dev mode
> > class QueryWrapper {
> > int x;
> > int y;
> > }
> > void method(QueryWrapper querys, int p2);
> >
> > will produce swagger operation, have 3 parameters: x, y, p2
> >
> > 2.consumer is POJO dev mode, declare a interface:
> > interface TestIntf {
> > void method(int x, int y, int p2);
> > }
> > until now, everything is ok.
> >
> > 3.producer upgrade
> > class QueryWrapper {
> > int x;
> > int y;
> > int z;
> > }
> > will produce swagger operation, have 4 parameters: x,y,z,p2
> >
> > in this time, old POJO consumers will have problems:
> > assign x to x, y to y, p2 to z
> > that's because we map parameters by their index
> >
> > to resolve the problem:
> > we need to map parameters by their name
> > this require customers change their compile argument in pom.xml to
> allow
> > interface present method parameter name
> > if did not add compile argument, SDK can throw exception, and print how
> > to add the compile argument.
> >
> > any idea?
>
Re: [discuss] change mechanism of java chassis POJO consumer paramters mapping
Java compile will remove the parameters name by default. We faced the
same problem in CXF simple frontend.
The solution could be enable the debug option in the compiler or add
annotation to the parameters.
If we decide to setting the option on the compiler, we should not only
throw exception in the runtime, but also document it.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Thu, Jan 17, 2019 at 5:23 PM wjm wjm wrote:
>
> Scenes：
> 1.producer is springMVC dev mode
> class QueryWrapper {
> int x;
> int y;
> }
> void method(QueryWrapper querys, int p2);
>
> will produce swagger operation, have 3 parameters: x, y, p2
>
> 2.consumer is POJO dev mode, declare a interface:
> interface TestIntf {
> void method(int x, int y, int p2);
> }
> until now, everything is ok.
>
> 3.producer upgrade
> class QueryWrapper {
> int x;
> int y;
> int z;
> }
> will produce swagger operation, have 4 parameters: x,y,z,p2
>
> in this time, old POJO consumers will have problems:
> assign x to x, y to y, p2 to z
> that's because we map parameters by their index
>
> to resolve the problem:
> we need to map parameters by their name
> this require customers change their compile argument in pom.xml to allow
> interface present method parameter name
> if did not add compile argument, SDK can throw exception, and print how
> to add the compile argument.
>
> any idea?
Re: [Discuss]Make omega and alpha decouple with spring-boot
I prefer to keep the Aspect annotation processor in the old way and OK for for put Omega components initial code together. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Thu, Jan 17, 2019 at 5:36 PM zhaojun wrote: > > I’ll try to refactor the code in my local repo today. > Please feel free if you have any advice. > > -- > Zhao Jun > Apache Sharding-Sphere & ServiceComb > > > > On Jan 15, 2019, at 11:37 AM, zhaojun wrote: > > > > Hi, Willem > > > > Thanks for the comment. > > > > 1. Current implement we use @EnableAspectJAutoProxy to create proxy bean, > > please see TransactionAspectConfig. > >it will auto-config AnontaionAwareAspectJAutoProxyCreator, this is the > > AspectJ implementation for AbstractAutoProxyCreator. > >If we exetend AbstractAutoProxyCreator directly, we can control the > > annotation and proxy creator more flexible. > >We can complete annotation parse within proxy creator instead of > > defining another BeanPostProcessor to parse it. > >In one word, we can make currently implement more better. > > > > 2. Yes, we can find a way to aggregate this code together, and provider a > > api interface for spring-boot. > > > > > > -- > > Zhao Jun > > Apache Sharding-Sphere & ServiceComb > > > >> On Jan 15, 2019, at 9:47 AM, Willem Jiang wrote: > >> > >> Here are some of my comments for the design: > >> 1. I don't think we need to use the internal AOP API > >> (AbstractAutoProxyCreator), current AOP solution is much > >> straightforward, we don't need to bind to the internal API unless we > >> want to create the proxy ourselves. > >> 2. In ServiceComb starter, we have the configure to setup beans of > >> Omega to use, I think we just need to find a way to reuse this code in > >> none Spring Boot application. > >> 3. +1 to create the Transaction Engine in the Omega Core. > >> > >> Willem Jiang > >> > >> Twitter: willemjiang > >> Weibo: 姜宁willem > >> > >> On Mon, Jan 14, 2019 at 7:38 PM zhaojun wrote: > >>> > >>> I have made omega design for this issue[1], please feel free to give me > >>> some advice. > >>> > >>> > >>> [1] > >>> https://cwiki.apache.org/confluence/display/SERVICECOMB/refactor+design+of+service-comb+pack+omega > >>> > >>> > >>> -- > >>> Zhao Jun > >>> Apache Sharding-Sphere & ServiceComb > >>> > On Jan 14, 2019, at 5:27 PM, zhaojun wrote: > > I have created SCB-1113[1] to track this issue. > > [1] https://issues.apache.org/jira/browse/SCB-1113 > > -- > Zhao Jun > Apache Sharding-Sphere & ServiceComb > > > On Jan 14, 2019, at 5:21 PM, zhaojun wrote: > > > > OK, let me create a JIRA, and try to refactor it > > > > -- > > Zhao Jun > > Apache Sharding-Sphere & ServiceComb > > > > > >> On Jan 14, 2019, at 4:50 PM, Willem Jiang > >> wrote: > >> > >> Yeah, we just need to think about starting the Omega context by wiring > >> the components through Spring API, then wrap it with Spring Boot > >> Starter API. > >> In this way we could support to inject the Omega context not only to > >> the Spring Boot Application but also Spring Application. > >> > >> Willem Jiang > >> > >> Twitter: willemjiang > >> Weibo: 姜宁willem > >> > >> On Mon, Jan 14, 2019 at 3:09 PM zhaojun wrote: > >>> > >>> Hi, all > >>> > >>> I think we should provide api way to bootstrap omega and alpha. > >>> Now our code was tightly coupled with spring-boot, it is not possible > >>> for integrated with other middleware. > >>> We should provide Omega.init(), Alpha.init() api, spring-boot was > >>> just one implementation for Pack. > >>> > >>> Any thought? > >>> > >>> -- > >>> Zhao Jun > >>> Apache Sharding-Sphere & ServiceComb > >>> > > > > >>> > > >
Re: [Discuss]Make omega and alpha decouple with spring-boot
I’ll try to refactor the code in my local repo today. Please feel free if you have any advice. -- Zhao Jun Apache Sharding-Sphere & ServiceComb > On Jan 15, 2019, at 11:37 AM, zhaojun wrote: > > Hi, Willem > > Thanks for the comment. > > 1. Current implement we use @EnableAspectJAutoProxy to create proxy bean, > please see TransactionAspectConfig. >it will auto-config AnontaionAwareAspectJAutoProxyCreator, this is the > AspectJ implementation for AbstractAutoProxyCreator. >If we exetend AbstractAutoProxyCreator directly, we can control the > annotation and proxy creator more flexible. >We can complete annotation parse within proxy creator instead of defining > another BeanPostProcessor to parse it. >In one word, we can make currently implement more better. > > 2. Yes, we can find a way to aggregate this code together, and provider a api > interface for spring-boot. > > > -- > Zhao Jun > Apache Sharding-Sphere & ServiceComb > >> On Jan 15, 2019, at 9:47 AM, Willem Jiang wrote: >> >> Here are some of my comments for the design: >> 1. I don't think we need to use the internal AOP API >> (AbstractAutoProxyCreator), current AOP solution is much >> straightforward, we don't need to bind to the internal API unless we >> want to create the proxy ourselves. >> 2. In ServiceComb starter, we have the configure to setup beans of >> Omega to use, I think we just need to find a way to reuse this code in >> none Spring Boot application. >> 3. +1 to create the Transaction Engine in the Omega Core. >> >> Willem Jiang >> >> Twitter: willemjiang >> Weibo: 姜宁willem >> >> On Mon, Jan 14, 2019 at 7:38 PM zhaojun wrote: >>> >>> I have made omega design for this issue[1], please feel free to give me >>> some advice. >>> >>> >>> [1] >>> https://cwiki.apache.org/confluence/display/SERVICECOMB/refactor+design+of+service-comb+pack+omega >>> >>> >>> -- >>> Zhao Jun >>> Apache Sharding-Sphere & ServiceComb >>> On Jan 14, 2019, at 5:27 PM, zhaojun wrote: I have created SCB-1113[1] to track this issue. [1] https://issues.apache.org/jira/browse/SCB-1113 -- Zhao Jun Apache Sharding-Sphere & ServiceComb > On Jan 14, 2019, at 5:21 PM, zhaojun wrote: > > OK, let me create a JIRA, and try to refactor it > > -- > Zhao Jun > Apache Sharding-Sphere & ServiceComb > > >> On Jan 14, 2019, at 4:50 PM, Willem Jiang wrote: >> >> Yeah, we just need to think about starting the Omega context by wiring >> the components through Spring API, then wrap it with Spring Boot >> Starter API. >> In this way we could support to inject the Omega context not only to >> the Spring Boot Application but also Spring Application. >> >> Willem Jiang >> >> Twitter: willemjiang >> Weibo: 姜宁willem >> >> On Mon, Jan 14, 2019 at 3:09 PM zhaojun wrote: >>> >>> Hi, all >>> >>> I think we should provide api way to bootstrap omega and alpha. >>> Now our code was tightly coupled with spring-boot, it is not possible >>> for integrated with other middleware. >>> We should provide Omega.init(), Alpha.init() api, spring-boot was just >>> one implementation for Pack. >>> >>> Any thought? >>> >>> -- >>> Zhao Jun >>> Apache Sharding-Sphere & ServiceComb >>> > >>> >
[discuss] change mechanism of java chassis POJO consumer paramters mapping
Scenes：
1.producer is springMVC dev mode
class QueryWrapper {
int x;
int y;
}
void method(QueryWrapper querys, int p2);
will produce swagger operation, have 3 parameters: x, y, p2
2.consumer is POJO dev mode, declare a interface:
interface TestIntf {
void method(int x, int y, int p2);
}
until now, everything is ok.
3.producer upgrade
class QueryWrapper {
int x;
int y;
int z;
}
will produce swagger operation, have 4 parameters: x,y,z,p2
in this time, old POJO consumers will have problems:
assign x to x, y to y, p2 to z
that's because we map parameters by their index
to resolve the problem:
we need to map parameters by their name
this require customers change their compile argument in pom.xml to allow
interface present method parameter name
if did not add compile argument, SDK can throw exception, and print how
to add the compile argument.
any idea?
