On Mon, Mar 18, 2013 at 1:38 PM, Isuru Perera <[email protected]> wrote:
> Hi Sagara, > > The first question I had was whether we use Spring within Carbon. If yes, > then I was thinking whether we can use Spring APIs. > > On Mon, Mar 18, 2013 at 1:04 PM, Sagara Gunathunga <[email protected]>wrote: > >> >> >> On Mon, Mar 18, 2013 at 11:27 AM, Isuru Perera <[email protected]> wrote: >> >>> Hi all, >>> >>> I have a question regarding $subject. >>> >>> Is it already used inside core? Will we be able to use Spring Bean >>> inside back-end services? >>> >>> I have used Spring Framework for many years and there are so many ways >>> we can use it. We can also save a lot of time writing code. >>> >> >> I'm '*strongly -1*' to use Spring within Carbon framework. >> >> Other than time saving do you have any strong use case to use Spring >> within Carbon ? >> > > There is no strong use case as of now. > > >> >> If you read AS related support-dev mails during last month you can find >> tons of reason not to use Spring within Carbon. Any way I will list of main >> reasons below. >> > > AFAIU, AS related issues were mainly due to exposing classpath to the > webapps. Now a solution is provided to have different isolated environments > to webapps. In this scenario, webapps were not exposed to existing Spring > libraries right? Please correct me if I'm wrong. > If you use 'Tomcat' environment you will get Tomcat Jars only but if you use "Carbon" environment all Carbon level dependencies are visible to web apps. What we are promoting on AS is to use "Carbon" environment so that web app writers can leverage Carbon feature within web apps such as throttling, caching , user management, registry access. If Carbon component start to use Spring those web apps deployed on "Carbon" environment also can see Spring dependencies that it the main issue here. > > >> 1.) In AS 5.0.0 we provided Spring jars within Carbon framework so that >> users don't need to package them with their web apps but finally this leads >> to a disaster on AS 5.0.0. AFAIK there are more than 10 Spring versions >> used by people and you can't mix Jars from different Spring versions in a >> single classpath. If we provide a Spring version within a framework level, >> users can't use any other Spring version with their web application they >> have to use what ever the Spring version provided by us. This kind of >> restrictions are no where acceptable for AS, we can't ask people to >> re-write their application to use our AS. >> >> 2. ) We have received lot of issue on AS 5.0.0/5.0.1/5.0.2 just because >> we provided Spring Jars on classpath. If we groining to use Spring within >> Carbon components this will end up getting tons of blocking issues. Say you >> use Spring 3.2.0 within a Carbon component and a user upload web >> application with Spring 2.5.0 this will result into having mix of Jars file >> on Application classpath and no one can imagine the result. Please note >> that Spring F/W it self doesn't not recommend to mix different version >> within a single application. >> >> 3.) If you go through other application servers ( also cloud offering >> like GAE, Openshift ) most of them does not use Spring within their >> framework level nor do not ship a Spring Jars with the servers because it >> just break the ability to use multiple version of Spring F/W . AS try to >> make an exception on AS 5.0.0 by shipping Spring with server and had to pay >> great cost . In fact two weeks ago Amila and myself discussed to remove >> Spring completely from Carbon but we have small dependency on Axis2 and >> Synpase so we can't remove it completely. What we need to understand here >> is if we want to provide 1st class Spring experience to users you should >> not ship or use Spring your server framework. >> >> 4.) I'm a big fan of Spring F/W and it's ideal to write end user >> applications but I haven't seen non of the enterprise level F/W like Carbon >> use it for internal operations. In fact loading and maintaining Spring >> ApplicationContext is costly and should not do it in a F/W level. >> >> 5.) Spring configuration file loading and NamespaceHandler mechanism are >> not best fit with OSGI we may need to bring project like Spring-DM also to >> get rid of those issues. So we end up loading lot of Spring dependencies >> within Carbon . AFAIK C5 philosophy is make Carbon very thin and we are >> removing Axis2 also so we should not bring 3rd party F/W like Spring unless >> we have great amount of usages. >> >> 6.) In Spring JDBC Template you just need to provide JDBC query only and >> F/W provide connection handling and Exception handling features for us >> other than that I don't aware with any other advantages. But the known fact >> is Spring JDBC Template is relatively slower than pure JDBC. When we write >> F/W we need to focus on performance than time saving. In fact once you get >> into work with pure JDBC for sometime you can achieve same level of >> efficiency. >> >> > I agree with all your points. I'm +1 on removing Spring dependency in > Carbon Framework. My question is whether we can have something similar to > JDBC Template within Carbon framework. > If you can write a abstraction layer using pure JDBC say CarbonJDBCTemplate so that other can use this abstraction layer instead of pure JDBC that can be a useful feature and definitely +1 :) Thanks ! > > I prefer if there are Spring like APIs for common use cases within Carbon > framework so that developers can use to develop components. Right now I > couldn't find any documentation on these kind of scenarios apart from > opening different components and seeing how the code has written. This is > also not easy due to large code base. > > Thanks ! >> >> >> >>> For example, Can we use Spring JDBC [1]? >>> >>> Spring Framework is released under Apache License [2] and therefore I >>> think there will be no problems with license. >>> >>> [1] >>> http://static.springsource.org/spring/docs/current/spring-framework-reference/htmlsingle/#jdbc >>> [2] http://www.springsource.org/spring-framework >>> -- >>> Isuru Perera >>> Senior Software Engineer | WSO2, Inc. | http://wso2.com/ >>> Lean . Enterprise . Middleware >>> >>> Twitter: http://twitter.com/chrishantha | LinkedIn: >>> http://lk.linkedin.com/in/chrishantha/ >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> Sagara Gunathunga >> >> Technical Lead; WSO2, Inc.; http://wso2.com >> V.P Apache Web Services ; http://ws.apache.org/ >> Blog ; http://ssagara.blogspot.com >> > > > > -- > Isuru Perera > Senior Software Engineer | WSO2, Inc. | http://wso2.com/ > Lean . Enterprise . Middleware > > Twitter: http://twitter.com/chrishantha | LinkedIn: > http://lk.linkedin.com/in/chrishantha/ > -- Sagara Gunathunga Technical Lead; WSO2, Inc.; http://wso2.com V.P Apache Web Services ; http://ws.apache.org/ Blog ; http://ssagara.blogspot.com
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
