大家好，感謝邀請，今天來為大家分享一下下面不屬于spring注解的是的問題，以及和spring配置文件的名稱可以自定義的一些困惑，大家要是還不太明白的話，也沒有關系，因為接下來將為大家分享，希望可以幫助到大家，解決大家的問題，下面就開始吧！
為什么spring的事務@transaction注解只對public方法有效
理論上而言，不public，也可以用aop實現transactional的功能，但我感覺只針對public是考慮外部調用，而且也只能從外部調用。加在interface上這個沒意義吧。
springboot常用注解有哪些
springboot常用的注解有如下幾個：
1、SpringBootApplication；
2、Repository；
3、Service；
4、RestController；
5、ResponseBody；
6、Component等
spring有什么缺點嗎
明明一個很輕量級的框架，卻給人感覺大而全，這就是它的缺點。Spring的核心概念是啥，最主要的，IoC和AOP，這兩個核心服務的對象是啥，就是那堆beans，Spring我們可以理解為就是存放這些bean的容器，它最核心的就干這些事。IoC干嘛的，就是為了讓開發者關注的重心放在如何使用這些bean。不管bean怎么來，只要@Autowired就給我老老實實出現，讓我調接口就好，不需要每次用之前都要手動構建，盡量減少手動實例化bean的次數。SpringBoot以前，主要在beans.xml中注冊bean，SpringBoot的話只要在Configuration中定義一個@Bean方法即可，就為了做好這件事，Spring弄了多少東西，BeanDefinition，BeanFactory，FactoryBean，然后Bean的生命周期接口好幾個，Aware接口又好幾個，等等，然后是AOP，AOP是很好的特性，在Spring中其主要目的就是以一種非浸入的方式對bean進行擴展，看到沒，又是bean。為了對bean支持，Spring弄了一套AspctJ的子集，既有Java原生的接口代理，又有更加靈活的Cglib，光是AOP的概念就不少，更不要說實現的原理。簡單的大e家都可以說出一二三四五，但深入細節誰有把握？所以，Spring就是圍繞著bean展開的，它主要就是作為bean的容器，在這個基礎上，有了SpringMVC，有了JPA，有了Cloud，有了DataFlow，以及其他模塊。但這些模塊的本質，不全是Spring，比如JPA，核心還是Hibernate，Cloud，核心是另外一套微服務框架。Spring就好比膠水，通過bean把這些模塊粘在一起。實踐過程中，反復的提醒自己，不要用Spring玩花，讓它老老實實的做bean的容器就好了。我這么說，不看源碼，你會覺得Spring重嗎？可就這么些個東西，Spring弄出了多少名堂。隨便找個地方打斷點，調用就不下二十來層，在現在這種強調輕量化服務的大環境下，不被吐槽才怪。當然，我認為也不能全怪Spring。Java這門語言動態性本來就是它的弱項，Spring能把Java包裝的像個動態化的語言已經蠻拼了。Spring背的最大的鍋，我認為就是J2EE，就憑那套在當時有一定價值但放現在已經淘汰的標準，沒有Spring，Java的企業級市場未必有今天。不過話說回來，從學習企業級Java開發的角度看，Spring的代碼依然是教科書般的代碼。面向對象封裝，編程原則，設計模式，都是具有很高的參考價值。如果你才開始，我建議先沉住氣，老老實實的敲代碼，看文檔，不管最后還在不在Java圈，將來一定會收獲不小。有時候，你不復雜一些，又怎么能體會到簡單的價值呢？
java中注解方式是否是侵入
謝邀，作為一個Java軟件工程師對這個問題有自己的見解。
先搞清楚侵入性的概念當你的代碼引入了一個組件,導致其它代碼或者設計,要做相應的更改以適應新組件.這樣的情況我們就認為這個新組件具有侵入性。顯然，如果設計的代碼對原有代碼邏輯有代碼侵入的話，是一個糟糕的設計方式。什么是侵入性？個人認為就是一旦你這段添加的代碼出現異常對原本的代碼會有極大影響，那你這段代碼侵入性就太明顯了。
而注解對代碼是否有侵入性呢？要知道注解是從老版jdk就有的一個語法特性，目前廣泛運用在各大框架中間件的開發中，比如我們最常用的spring框架，編程時service和autoware等注解幾乎是必用的。如果說注解式編程對代碼有過度侵入性，我想甲骨文公司也不會去創造注解這種東西。顯然，注解本身并不會對代碼造成侵入，反而他的設計是為了解耦合，通過代理等方式將需要引入的組件添加到原邏輯中。
但是注解一定不會侵入嗎？答案是否定的，注解本身其實不用糾結會不會侵入，而是對注解使用過程中的開發者，是否會寫出侵入性極強的代碼。用注解完全可以寫出侵入式的代碼，比如在寫spring的aop時，后置處理的代碼有bug，那必然會導致原邏輯不能正常進行，這就是一種侵入，而且還影響很大。
宇文哥習慣性總結:注解是一件利器，用的好代碼可以低耦合，用的不好，就會造成侵入性極強，沒有最好的技術只有更好的編碼者。
關注@極客宇文氏一名熱心有料的Java軟件工程師。spring使用注解時報錯，該怎么辦
解決方案：
1、在這需要說明的是，由于后臺從始至終沒有報任何的錯誤，故我的文章里不會有出錯的貼圖，有人就會說了，為什么不把自己的配置文件貼給大家看呢，我認為沒有必要，因為接下來我會給大家講解排錯方法，并且貼上已經訪問成功的完整代碼貼圖。其實剛開始一遇見這樣的錯誤，自己也排查了一邊沒有任何的發現，于是就網上百度各種搜索，其中也搜到一些結果，按照提示操作一通都沒有成功。這里我總結一下網上各種帖子的解決方案：
1、大量文章都是千篇一律的說處理器映射器和處理器適配器以及視圖解析器沒有配置好，于是教你怎么去配置處理器映射器，這里我總結一個處理器映射器和適配器以及視圖解析器的配置
1.1、非注解的處理器映射器和適配器配置，注意：在這里處理器映射器的配置必須和處理器適配器的配置是成對的，還有必須在配置文件里聲明注入你的controller，并且這個controller必須實現Controller接口。非注解的配置訪問是根據聲明注入的beanname來進行映射處理的，必須有name,而且name的值必須有根符號（“/”）。
1.2、注解的處理器映射器和適配器配置。注解的controller類必須使用@Controller進行注解，類中的方法使用@RequestMapping("")進行注解。注解的配置方式還有一種，即<mvc:annotation-driven/>注解驅動配置，這樣更方便，實際項目也是這樣使用的。
1.3、視圖解析器的配置。
至此，springmvc的controller需要的處理器映射器和處理器適配器以及視圖解析器的配置已經完成，當然實際要運行的時候還必須要有Controller包掃描，不然你的程序在實例化完sqlSessionFactory后會一直卡在那里，不做任何操作，頁面也不會有任何的反映。
2、這網上的第二種解決方法說的最多的就是我上面說的Controller的包掃描沒有加或者包掃描的配置是錯誤的，這如果說其他配置都OK的話，如果沒有加包掃描，那么他不回報任何的錯誤，但是會輸出日志，創建SqlSessionFactory的日志是有的，不會什么信息都沒有。有的人將Controller的包掃描加成這樣
<context:component-scanbase-package="com.springmvc.ssm.controller.*"/>也是什么都沒有的。正確的包掃描是這樣的：
3、當然也有說jar包沒有，這也有可能是有的，沒有jar包報404很正常的。這里要說的是如果出現404，你的判斷是jar包沒有，那你就得去你的項目發布路徑下的WEB-INF下的lib文件夾去找jar包，而不是你的eclipse里看有沒有。更需要注意的是，有人在tomcat運行設置過發布路徑，那就必須在你設置的發布路徑下找，我的設置為tomcat的安裝目錄下的webapps下了。
4、其實忘了一個最多的說法，那就是說你的請求地址是錯誤的，這個只能說自己認真排查，一般人在出現404的時候第一反應就是請求地址的核對，所以這個我也不說了。但是在這里我強調一個現象，就是你的請求地址是正確的，但是你的目錄里沒有Controller里的方法返回的頁面，這樣也會出現404,但是這個404和之前的404是不一樣的。比如我在我的testController的items映射的方法里返回的itemsLists,實際我的jsp下的JSP文件沒有一個itemsLists.jsp，那么頁面的錯誤就會是這樣的：
5、還有一種解決辦法說web.xml配置DispatcherServlet的時候servlet的映射關系<url-pattern>配置不正確，應該將<url-pattern>/*</url-pattern>改為<url-pattern>/*</url-pattern>，去掉根號后面的星號，當然如果確實這樣寫了，那這也是一種解決辦法。
private方法的事務生效嗎
spring注解事務是不支持private方法的，這是設計時注定的，為了跟jdk的代理保持一致。
文章到此結束，如果本次分享的下面不屬于spring注解的是和spring配置文件的名稱可以自定義的問題解決了您的問題，那么我們由衷的感到高興！
