精华内容
下载资源
问答
  • Context

    千次阅读 2018-07-20 09:25:20
    Context在Java中的出现是如此频繁,但其中文翻译“上下文”又是如此诡异拗口,因此导致很多人不是很了解Context的具体含义是指什么,所以很有必要来深究一下这词的含义。先来举几个JAVA中用到Context的例子  (1)...

    Context在Java中的出现是如此频繁,但其中文翻译“上下文”又是如此诡异拗口,因此导致很多人不是很了解Context的具体含义是指什么,所以很有必要来深究一下这词的含义。先来举几个JAVA中用到Context的例子 

    (1)JNDI的一个类javax.naming.InitialContext,它读取JNDI的一些配置信息,并内含对象和其在JNDI中的注册名称的映射信息。请看下面的代码

    InitialContext ic=new InitialContext();
    RMIAdaptor server=(RMIAdaptor)ic.lookup("jmx/invoker/RMIAdaptor");

    这是一段JBoss中获取MBean的远程调用类的代码。在这里面通过InitialContext中JNDI注册的名称“jmx/invoker/RMIAdaptor”来获得RMIAdaptor对象。这和JAVA集合中的MAP有点象,有一个String的key,key对映着它的对象。

    (2)再来看看下面Spring中最常见的几句代码。ApplicationContext 是内含configuration.xml配置文件的信息,使得可以通过getBean用名称得到相应的注册对象。

    ApplicationContext ctx= new FileSystemXmlApplicationContext("configuration.xml");
    Object obj= ctx.getBean("Object_Name");

    从上面的代码,我很能体会到Context所代表的意义:公用信息、环境、容器....。所以我觉得Context翻译成上下文并不直观,按照语言使用的环境,翻译成“环境”、“容器”可能更好。 把Context翻译成“上下文”只是不直观罢了,不过也没大错。我们来看看中文的“上下文”是什么意思。我们常说听话传话不能“断章取义”,而要联系它的“上下文”来看。比如,小丽对王老五说“我爱你”,光看这句还以为在说情话呢。但一看上下文--“虽然我爱你,但你太穷了,我们还是分手吧”,味道就完全变了。从这里来看“上下文”也有“环境”的意思,就是语言的环境。

     PS:

     上下文其实是一个抽象的概念。我们常见的上下文有Servlet中的pageContext,访问JNDI时候用的Context。写过这些代码的人可能比较容易理解,其实他们真正的作用就是承上启下。比如说pageContext他的上层是WEB容器,下层是你写的那个Servlet类,pageContext作为中间的通道让Servlet 和Web容器进行交互。再比如访问JNDI的Context,他的上层是JNDI服务器(可能是远程的),下层是你的应用程序,他的作用也是建立一个通道让你能访问JNDI服务器,同时也让JNDI服务器接受你的请求,同样起到交互作用。

    展开全文
  • Context相信所有的Android开发人员基本上每天都在接触,因为它太常见了。但是这并不代表Context没有什么东西好讲的,实际上Context有太多小的细节并不被大家所关注,那么今天我们就来学习一下那些你所不知道的细节。...

    转载请注明出处:http://blog.csdn.net/guolin_blog/article/details/47028975


    前几篇文章,我也是费劲心思写了一个ListView系列的三部曲,虽然在内容上可以说是绝对的精华,但是很多朋友都表示看不懂。好吧,这个系列不仅是把大家给难倒了,也确实是把我给难倒了,之前为了写瀑布流ListView的Demo就写了大半个月的时间。那么本篇文章我们就讲点轻松的东西,不去分析那么复杂的源码了,而是来谈一谈大家都熟知的Context。


    Context相信所有的Android开发人员基本上每天都在接触,因为它太常见了。但是这并不代表Context没有什么东西好讲的,实际上Context有太多小的细节并不被大家所关注,那么今天我们就来学习一下那些你所不知道的细节。


    Context类型


    我们知道,Android应用都是使用Java语言来编写的,那么大家可以思考一下,一个Android程序和一个Java程序,他们最大的区别在哪里?划分界限又是什么呢?其实简单点分析,Android程序不像Java程序一样,随便创建一个类,写个main()方法就能跑了,而是要有一个完整的Android工程环境,在这个环境下,我们有像Activity、Service、BroadcastReceiver等系统组件,而这些组件并不是像一个普通的Java对象new一下就能创建实例的了,而是要有它们各自的上下文环境,也就是我们这里讨论的Context。可以这样讲,Context是维持Android程序中各组件能够正常工作的一个核心功能类。


    下面我们来看一下Context的继承结构:


    Context的继承结构还是稍微有点复杂的,可以看到,直系子类有两个,一个是ContextWrapper,一个是ContextImpl。那么从名字上就可以看出,ContextWrapper是上下文功能的封装类,而ContextImpl则是上下文功能的实现类。而ContextWrapper又有三个直接的子类,ContextThemeWrapper、Service和Application。其中,ContextThemeWrapper是一个带主题的封装类,而它有一个直接子类就是Activity。


    那么在这里我们至少看到了几个所比较熟悉的面孔,Activity、Service、还有Application。由此,其实我们就已经可以得出结论了,Context一共有三种类型,分别是Application、Activity和Service。这三个类虽然分别各种承担着不同的作用,但它们都属于Context的一种,而它们具体Context的功能则是由ContextImpl类去实现的。


    那么Context到底可以实现哪些功能呢?这个就实在是太多了,弹出Toast、启动Activity、启动Service、发送广播、操作数据库等等等等都需要用到Context。由于Context的具体能力是由ContextImpl类去实现的,因此在绝大多数场景下,Activity、Service和Application这三种类型的Context都是可以通用的。不过有几种场景比较特殊,比如启动Activity,还有弹出Dialog。出于安全原因的考虑,Android是不允许Activity或Dialog凭空出现的,一个Activity的启动必须要建立在另一个Activity的基础之上,也就是以此形成的返回栈。而Dialog则必须在一个Activity上面弹出(除非是System Alert类型的Dialog),因此在这种场景下,我们只能使用Activity类型的Context,否则将会出错。


    Context数量


    那么一个应用程序中到底有多少个Context呢?其实根据上面的Context类型我们就已经可以得出答案了。Context一共有Application、Activity和Service三种类型,因此一个应用程序中Context数量的计算公式就可以这样写:

    Context数量 = Activity数量 + Service数量 + 1

    上面的1代表着Application的数量,因为一个应用程序中可以有多个Activity和多个Service,但是只能有一个Application。


    Application Context的设计


    基本上每一个应用程序都会有一个自己的Application,并让它继承自系统的Application类,然后在自己的Application类中去封装一些通用的操作。其实这并不是Google所推荐的一种做法,因为这样我们只是把Application当成了一个通用工具类来使用的,而实际上使用一个简单的单例类也可以实现同样的功能。但是根据我的观察,有太多的项目都是这样使用Application的。当然这种做法也并没有什么副作用,只是说明还是有不少人对于Application理解的还有些欠缺。那么这里我们先来对Application的设计进行分析,讲一些大家所不知道的细节,然后再看一下平时使用Application的问题。


    首先新建一个MyApplication并让它继承自Application,然后在AndroidManifest.xml文件中对MyApplication进行指定,如下所示:

    <application
        android:name=".MyApplication"
        android:allowBackup="true"
        android:icon="@drawable/ic_launcher"
        android:label="@string/app_name"
        android:theme="@style/AppTheme" >
        ......
    </application>
    指定完成后,当我们的程序启动时Android系统就会创建一个MyApplication的实例,如果这里不指定的话就会默认创建一个Application的实例。


    前面提到过,现在很多的Application都是被当作通用工具类来使用的,那么既然作为一个通用工具类,我们要怎样才能获取到它的实例呢?如下所示:

    public class MainActivity extends Activity {
    	
    	@Override
    	protected void onCreate(Bundle savedInstanceState) {
    		super.onCreate(savedInstanceState);
    		setContentView(R.layout.activity_main);
    		MyApplication myApp = (MyApplication) getApplication();
    		Log.d("TAG", "getApplication is " + myApp);
    	}
    	
    }

    可以看到,代码很简单,只需要调用getApplication()方法就能拿到我们自定义的Application的实例了,打印结果如下所示:



    那么除了getApplication()方法,其实还有一个getApplicationContext()方法,这两个方法看上去好像有点关联,那么它们的区别是什么呢?我们将代码修改一下:

    public class MainActivity extends Activity {
    	
    	@Override
    	protected void onCreate(Bundle savedInstanceState) {
    		super.onCreate(savedInstanceState);
    		setContentView(R.layout.activity_main);
    		MyApplication myApp = (MyApplication) getApplication();
    		Log.d("TAG", "getApplication is " + myApp);
    		Context appContext = getApplicationContext();
    		Log.d("TAG", "getApplicationContext is " + appContext);
    	}
    	
    }

    同样,我们把getApplicationContext()的结果打印了出来,现在重新运行代码,结果如下图所示:




    咦?好像打印出的结果是一样的呀,连后面的内存地址都是相同的,看来它们是同一个对象。其实这个结果也很好理解,因为前面已经说过了,Application本身就是一个Context,所以这里获取getApplicationContext()得到的结果就是MyApplication本身的实例。


    那么有的朋友可能就会问了,既然这两个方法得到的结果都是相同的,那么Android为什么要提供两个功能重复的方法呢?实际上这两个方法在作用域上有比较大的区别。getApplication()方法的语义性非常强,一看就知道是用来获取Application实例的,但是这个方法只有在Activity和Service中才能调用的到。那么也许在绝大多数情况下我们都是在Activity或者Service中使用Application的,但是如果在一些其它的场景,比如BroadcastReceiver中也想获得Application的实例,这时就可以借助getApplicationContext()方法了,如下所示:

    public class MyReceiver extends BroadcastReceiver {
    
    	@Override
    	public void onReceive(Context context, Intent intent) {
    		MyApplication myApp = (MyApplication) context.getApplicationContext();
    		Log.d("TAG", "myApp is " + myApp);
    	}
    
    }

    也就是说,getApplicationContext()方法的作用域会更广一些,任何一个Context的实例,只要调用getApplicationContext()方法都可以拿到我们的Application对象。

    那么更加细心的朋友会发现,除了这两个方法之外,其实还有一个getBaseContext()方法,这个baseContext又是什么东西呢?我们还是通过打印的方式来验证一下:




    哦?这次得到的是不同的对象了,getBaseContext()方法得到的是一个ContextImpl对象。这个ContextImpl是不是感觉有点似曾相识?回去看一下Context的继承结构图吧,ContextImpl正是上下文功能的实现类。也就是说像Application、Activity这样的类其实并不会去具体实现Context的功能,而仅仅是做了一层接口封装而已,Context的具体功能都是由ContextImpl类去完成的。那么这样的设计到底是怎么实现的呢?我们还是来看一下源码吧。因为Application、Activity、Service都是直接或间接继承自ContextWrapper的,我们就直接看ContextWrapper的源码,如下所示:

    /**
     * Proxying implementation of Context that simply delegates all of its calls to
     * another Context.  Can be subclassed to modify behavior without changing
     * the original Context.
     */
    public class ContextWrapper extends Context {
        Context mBase;
        
        /**
         * Set the base context for this ContextWrapper.  All calls will then be
         * delegated to the base context.  Throws
         * IllegalStateException if a base context has already been set.
         * 
         * @param base The new base context for this wrapper.
         */
        protected void attachBaseContext(Context base) {
            if (mBase != null) {
                throw new IllegalStateException("Base context already set");
            }
            mBase = base;
        }
    
        /**
         * @return the base context as set by the constructor or setBaseContext
         */
        public Context getBaseContext() {
            return mBase;
        }
    
        @Override
        public AssetManager getAssets() {
            return mBase.getAssets();
        }
    
        @Override
        public Resources getResources() {
            return mBase.getResources();
        }
    
        @Override
        public ContentResolver getContentResolver() {
            return mBase.getContentResolver();
        }
    
        @Override
        public Looper getMainLooper() {
            return mBase.getMainLooper();
        }
        
        @Override
        public Context getApplicationContext() {
            return mBase.getApplicationContext();
        }
    
        @Override
        public String getPackageName() {
            return mBase.getPackageName();
        }
    
        @Override
        public void startActivity(Intent intent) {
            mBase.startActivity(intent);
        }
        
        @Override
        public void sendBroadcast(Intent intent) {
            mBase.sendBroadcast(intent);
        }
    
        @Override
        public Intent registerReceiver(
            BroadcastReceiver receiver, IntentFilter filter) {
            return mBase.registerReceiver(receiver, filter);
        }
    
        @Override
        public void unregisterReceiver(BroadcastReceiver receiver) {
            mBase.unregisterReceiver(receiver);
        }
    
        @Override
        public ComponentName startService(Intent service) {
            return mBase.startService(service);
        }
    
        @Override
        public boolean stopService(Intent name) {
            return mBase.stopService(name);
        }
    
        @Override
        public boolean bindService(Intent service, ServiceConnection conn,
                int flags) {
            return mBase.bindService(service, conn, flags);
        }
    
        @Override
        public void unbindService(ServiceConnection conn) {
            mBase.unbindService(conn);
        }
    
        @Override
        public Object getSystemService(String name) {
            return mBase.getSystemService(name);
        }
    
        ......
    }

    由于ContextWrapper中的方法还是非常多的,我就进行了一些筛选,只贴出来了部分方法。那么上面的这些方法相信大家都是非常熟悉的,getResources()、getPackageName()、getSystemService()等等都是我们经常要用到的方法。那么所有这些方法的实现又是什么样的呢?其实所有ContextWrapper中方法的实现都非常统一,就是调用了mBase对象中对应当前方法名的方法。


    那么这个mBase对象又是什么呢?我们来看第16行的attachBaseContext()方法,这个方法中传入了一个base参数,并把这个参数赋值给了mBase对象。而attachBaseContext()方法其实是由系统来调用的,它会把ContextImpl对象作为参数传递到attachBaseContext()方法当中,从而赋值给mBase对象,之后ContextWrapper中的所有方法其实都是通过这种委托的机制交由ContextImpl去具体实现的,所以说ContextImpl是上下文功能的实现类是非常准确的。


    那么另外再看一下我们刚刚打印的getBaseContext()方法,在第26行。这个方法只有一行代码,就是返回了mBase对象而已,而mBase对象其实就是ContextImpl对象,因此刚才的打印结果也得到了印证。


    使用Application的问题


    虽说Application的用法确实非常简单,但是我们平时的开发工作当中也着实存在着不少Application误用的场景,那么今天就来看一看有哪些比较容易犯错的地方是我们应该注意的。


    Application是Context的其中一种类型,那么是否就意味着,只要是Application的实例,就能随时使用Context的各种方法呢?我们来做个实验试一下就知道了:

    public class MyApplication extends Application {
    	
    	public MyApplication() {
    		String packageName = getPackageName();
    		Log.d("TAG", "package name is " + packageName);
    	}
    	
    }

    这是一个非常简单的自定义Application,我们在MyApplication的构造方法当中获取了当前应用程序的包名,并打印出来。获取包名使用了getPackageName()方法,这个方法就是由Context提供的。那么上面的代码能正常运行吗?跑一下就知道了,你将会看到如下所示的结果:




    应用程序一启动就立刻崩溃了,报的是一个空指针异常。看起来好像挺简单的一段代码,怎么就会成空指针了呢?但是如果你尝试把代码改成下面的写法,就会发现一切正常了:

    public class MyApplication extends Application {
    	
    	@Override
    	public void onCreate() {
    		super.onCreate();
    		String packageName = getPackageName();
    		Log.d("TAG", "package name is " + packageName);
    	}
    	
    }

    运行结果如下所示:




    在构造方法中调用Context的方法就会崩溃,在onCreate()方法中调用Context的方法就一切正常,那么这两个方法之间到底发生了什么事情呢?我们重新回顾一下ContextWrapper类的源码,ContextWrapper中有一个attachBaseContext()方法,这个方法会将传入的一个Context参数赋值给mBase对象,之后mBase对象就有值了。而我们又知道,所有Context的方法都是调用这个mBase对象的同名方法,那么也就是说如果在mBase对象还没赋值的情况下就去调用Context中的任何一个方法时,就会出现空指针异常,上面的代码就是这种情况。Application中方法的执行顺序如下图所示:




    Application中在onCreate()方法里去初始化各种全局的变量数据是一种比较推荐的做法,但是如果你想把初始化的时间点提前到极致,也可以去重写attachBaseContext()方法,如下所示:

    public class MyApplication extends Application {
    	
    	@Override
    	protected void attachBaseContext(Context base) {
    		// 在这里调用Context的方法会崩溃
    		super.attachBaseContext(base);
    		// 在这里可以正常调用Context的方法
    	}
    	
    }

    以上是我们平时在使用Application时需要注意的一个点,下面再来介绍另外一种非常普遍的Application误用情况。


    其实Android官方并不太推荐我们使用自定义的Application,基本上只有需要做一些全局初始化的时候可能才需要用到自定义Application,官方文档描述如下:


    但是就我的观察而言,现在自定义Application的使用情况基本上可以达到100%了,也就是我们平时自己写测试demo的时候可能不会使用,正式的项目几乎全部都会使用自定义Application。可是使用归使用,有不少项目对自定义Application的用法并不到位,正如官方文档中所表述的一样,多数项目只是把自定义Application当成了一个通用工具类,而这个功能并不需要借助Application来实现,使用单例可能是一种更加标准的方式。


    不过自定义Application也并没有什么副作用,它和单例模式二选一都可以实现同样的功能,但是我见过有一些项目,会把自定义Application和单例模式混合到一起使用,这就让人大跌眼镜了。一个非常典型的例子如下所示:

    public class MyApplication extends Application {
    	
    	private static MyApplication app;
    	
    	public static MyApplication getInstance() {
    		if (app == null) {
    			app = new MyApplication();
    		}
    		return app;
    	}
    	
    }

    就像单例模式一样,这里提供了一个getInstance()方法,用于获取MyApplication的实例,有了这个实例之后,就可以调用MyApplication中的各种工具方法了。


    但是这种写法对吗?这种写法是大错特错!因为我们知道Application是属于系统组件,系统组件的实例是要由系统来去创建的,如果这里我们自己去new一个MyApplication的实例,它就只是一个普通的Java对象而已,而不具备任何Context的能力。有很多人向我反馈使用 LitePal 时发生了空指针错误其实都是由于这个原因,因为你提供给LitePal的只是一个普通的Java对象,它无法通过这个对象来进行Context操作。


    那么如果真的想要提供一个获取MyApplication实例的方法,比较标准的写法又是什么样的呢?其实这里我们只需谨记一点,Application全局只有一个,它本身就已经是单例了,无需再用单例模式去为它做多重实例保护了,代码如下所示:

    public class MyApplication extends Application {
    	
    	private static MyApplication app;
    	
    	public static MyApplication getInstance() {
    		return app;
    	}
    	
    	@Override
    	public void onCreate() {
    		super.onCreate();
    		app = this;
    	}
    	
    }

    getInstance()方法可以照常提供,但是里面不要做任何逻辑判断,直接返回app对象就可以了,而app对象又是什么呢?在onCreate()方法中我们将app对象赋值成this,this就是当前Application的实例,那么app也就是当前Application的实例了。


    好了,关于Context的介绍就到这里吧,内容还是比较简单易懂的,希望大家通过这篇文章可以理解Context更多的细节,并且不要去犯使用Context时的一些低级错误。


    关注我的技术公众号,每天都有优质技术文章推送。关注我的娱乐公众号,工作、学习累了的时候放松一下自己。

    微信扫一扫下方二维码即可关注:

            

    展开全文
  • context:component-scan使用说明

    万次阅读 多人点赞 2013-11-14 12:43:12
    在xml配置了这个标签后,spring可以自动去扫描base-pack下面或者子包下面的java文件,如果扫描到有@Component @Controller@Service等这些注解的类,则把这些类注册为bean 注意:如果配置了那么标签就可以不用再xml中...

       在xml配置了这个标签后,spring可以自动去扫描base-pack下面或者子包下面的java文件,如果扫描到有@Component @Controller@Service等这些注解的类,则把这些类注册为bean

    注意:如果配置了<context:component-scan>那么<context:annotation-config/>标签就可以不用再xml中配置了,因为前者包含了后者。另外<context:component-scan>还提供了两个子标签

    1.        <context:include-filter>

    2.       <context:exclude-filter>

    在说明这两个子标签前,先说一下<context:component-scan>有一个use-default-filters属性,该属性默认为true,这就意味着会扫描指定包下的全部的标有@Component的类,并注册成bean.也就是@Component的子注解@Service,@Reposity。所以如果仅仅是在配置文件中这么写

    <context:component-scan base-package="tv.huan.weisp.web"/>

     Use-default-filter此时为true那么会对base-package包或者子包下的所有的进行java类进行扫描,并把匹配的java类注册成bean。

     

     可以发现这种扫描的粒度有点太大,如果你只想扫描指定包下面的Controller,该怎么办?此时子标签<context:incluce-filter>就起到了勇武之地。如下所示

    <context:component-scan base-package="tv.huan.weisp.web .controller">  

    <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/>   

    </context:component-scan>  

    这样就会只扫描base-package指定下的有@Controller下的java类,并注册成bean

    但是因为use-dafault-filter在上面并没有指定,默认就为true,所以当把上面的配置改成如下所示的时候,就会产生与你期望相悖的结果(注意base-package包值得变化)

    <context:component-scan base-package="tv.huan.weisp.web">  

    <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/>   

    </context:component-scan>  

    此时,spring不仅扫描了@Controller,还扫描了指定包所在的子包service包下注解@Service的java类

    此时指定的include-filter没有起到作用,只要把use-default-filter设置成false就可以了。这样就可以避免在base-packeage配置多个包名这种不是很优雅的方法来解决这个问题了。

    另外在我参与的项目中可以发现在base-package指定的包中有的子包是不含有注解了,所以不用扫描,此时可以指定<context:exclude-filter>来进行过滤,说明此包不需要被扫描。综合以上说明

    Use-dafault-filters=”false”的情况下:<context:exclude-filter>指定的不扫描,<context:include-filter>指定的扫描

     

    展开全文
  • 严重: Context initialization failedorg.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.context.annotation.internalAsyncAnnotationProcessor' ...

    严重: Context initialization failed
    org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.context.annotation.internalAsyncAnnotationProcessor' defined in org.springframework.scheduling.annotation.ProxyAsyncConfiguration: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.scheduling.annotation.AsyncAnnotationBeanPostProcessor]: Factory method 'asyncAdvisor' threw exception; nested exception is java.lang.IllegalArgumentException: @EnableAsync annotation metadata was not injected
    at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:599)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)

    at 。。。。。。。

        解决方法:在springmvc.xml配置文件中 将<context:component-scan base-package="*"/>

    改为自己的项目类文件所在的路径 如:<context:component-scan base-package="com.srpingmvc.*">

    --------------------以下进行解释---------------------------------------

    下面我们来看一下springmvc.xml文件,了解一下为何这样改

    <?xml version="1.0" encoding="UTF-8"?>
    <beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"

    xsi:schemaLocation="http://www.springframework.org/schema/beans

                                http://www.springframework.org/schema/beans/spring-beans.xsd

                   http://www.springframework.org/schema/context

                                http://www.springframework.org/schema/context/spring-context-4.3.xsd">

     

    <!--  配置 @Controller @Service-->
    <context:component-scan
    base-package="com.springmvc.*"></context:component-scan>
    <!-- 视图解析器  逻辑视图,物理视图-->
    <bean class= "org.springframework.web.servlet.view.InternalResourceViewResolver">
    <property name="prefix" value="/"></property>
    <property name="suffix" value= ".jsp"></property>
    </bean>

     

    </beans>

    配置文件中base-package="com.srpingmvc.*" 是指com.springmvc文件夹下的所有文件都会被扫描,扫描的目的在于

    将带有特定注解的类如@Controller @component #repository等等,作为Bean注册进Spring容器。

    以下为转载自: http://blog.csdn.net/zzjjiandan/article/details/22922847

    Spring配置文件是用于指导Spring工厂进行Bean生产、依赖关系注入(装配)及Bean实例分发的"图纸"。

    Java EE程序员必须学会并灵活应用这份"图纸"准确地表达自己的"生产意图"。

    Spring配置文件是一个或多个标准的XML文档,applicationContext.xml是Spring的默认配置文件,

    当容器启动时找不到指定的配置文档时,将会尝试加载这个默认的配置文件。

    下面列举的是一份比较完整的配置文件模板,文档中各XML标签节点的基本用途也给出了详细的解释,

    这些XML标签节点在后续的知识点中均会用到,熟练掌握了这些XML节点及属性的用途后,

    为我们动手编写配置文件打下坚实的基础。

     

     

    展开全文
  • idea配置application context(web项目的默认访问路径)

    万次阅读 多人点赞 2017-11-11 23:05:25
    idea的application context eclipse大家应该都用过,eclipse访问项目的路径一般是localhost:8080/projectName, 当把IDE换成idea以后,访问路径一般情况下就变成了localhost:8080,路径没有了后面的项目名。...
  • Context是什么

    万次阅读 多人点赞 2018-03-12 22:40:17
    1.Context是什么 相信很多人多会问Context到底是什么? 我们可以理解为“上下文”:它贯穿整个应用; 也可以理解成“运行环境”:它提供了一个应用运行所需要的信息,资源,系统服务等; 同样可以理解成“场景”...
  • 揭秘Context(上下文)

    万次阅读 多人点赞 2019-03-08 00:03:13
    本文主要记述,Context到底是什么、如何理解Context、一个APP可以有几个ContextContext能干啥、Context的作用域、获取Context、全局获取Context技巧。 思考: Java:万物皆对象。Flutter:万物皆组件。 俗语:”没...
  • django中context_processors的理解

    万次阅读 2018-10-14 14:38:49
    'django.contrib.messages.context_processors.messages'] 若想添加,可直接从django.template.context_processors导入常用函数: 'context_processors': [ 'django.template.context_processors.debug', 'django....
  • Android Context 上下文 你必须知道的一切

    万次阅读 多人点赞 2015-01-05 09:21:59
    转载请标明出处:http://blog.csdn.net/lmj623565791/article/details/40481055,本文出自:【张鸿洋的博客】本文大多数内容翻译自:...1、Context概念其实一直想写一篇关于Context的文章,但是又怕技
  • Context详解

    千次阅读 2016-05-30 17:15:52
    原文为了更好的使用Context,翻译了一篇介绍Context的文章,原文链接:Context, What Context?什么是ContextContext可能是Android应用中最经常使用的对象成员,但是也可能是最被错误使用的对象成员.Context对象在Android...
  • React context/contextTypes

    千次阅读 2017-07-13 11:28:32
    本博客主要讲述一下,在开发工程总遇到的关于contextTypes/context的一些知识点。 通过context传递属性的方式可以大量减少 通过显式的通过 props 逐层传递属性的方式。这样可以减少组件之间的直接依赖关系。
  • Context也就是上下文对象,是Android较为常用的类,但是对于Context,很多人都停留在会用的阶段,这个系列会带大家从源码角度来分析Context,从而更加深入的理解它。
  • Persistence Context

    千次阅读 2018-03-29 16:30:02
    Persistence context是由一组受托管的实体对象实例所构成的集合。它受entity manager 的管理。Entity manager追踪persistence context中所有对象的修改和更新情况,并根据指定的flush模式(本章稍后会做讨论)将这些...
  • React 中 ContextcontextType的使用

    千次阅读 2019-06-24 19:31:38
    React 中 Context 的使用 context Context 提供了一种方式,能够让数据在组件树中传递时不必一级一级的手动传递 一般情况下,数据在组件中,要一级一级的传递,单向数据流,比如Parent组件中的theme值,需要在Item...
  • 解析Android中的Context

    万次阅读 2020-07-09 17:18:06
    理解上下文 Context Context 也就是上下文对象,是 Android 常用的类,但是对于 Context ,很多人都停留在会用的阶段,本文将带领大家从源码的角度来分析 Context ,从而更加深入地理解它。本文基于Android8.1.0...
  • context deadline exceeded

    千次阅读 2020-07-13 15:53:58
    context deadline exceeded 第一种 context.WithTimeout 客户端 服务端 问题总结 客户端用的上下文是context.WithTimeout 超时时间小于服务端的返回时间,造成 context deadline exceeded 第二种 context....
  • Android Context初探

    千次阅读 2020-02-24 21:53:30
    作为一个Android新手,每次看到使用Context作为参数时,都有点焦虑,有时候传this就可以,有时候又不行,不知道为什么可以,为什么又不可以,根本原因还是对Context是一知半解,偏偏很多地方用到Context作为参数,...
  • Java进阶(十)java tomcat中context配置

    万次阅读 2015-08-03 21:46:00
    Tomcat中Context的配置 问题: javatomcat中docBase属性是什么意思? 元素的属性: path:指定访问该Web应用的URL入口。 docBase:指定Web应用的文件路径,可以给定绝对路径,也可以给定相对于appBase属性的相对路径,...
  • Android中Context详解 ---- 你所不知道的Context

    万次阅读 多人点赞 2012-03-01 21:17:12
         前言:本文是我读《Android内核剖析》第7章 后形成的读书笔记 ,在此向欲了解Android框架的书籍推荐... 大家好, 今天给大家介绍下我们在应用开发中最熟悉而陌生的朋友-----Context类 ,说它熟悉,是应
  • 今天在开发项目的时候遇到了请求不通API的问题,最开始以为是server.servlet.context-path配置导致的问题,最终发现是由于AWS端口未开放/监听导致的connection refuse。虽然如此,仍然想记录一下server.servlet....
  • 我们分为四篇文章详细介绍Context, 这是第三篇 Android深入理解Context–Application中Context的创建过程 Android深入理解Context–Activity中Context的创建过程 Android深入理解Context–Service中Context的...
  • 此文章转自... Spring 中在使用注解(Annotation)会涉及到< context:annotation-config> 和 < context:component-scan>配置,下面就对这两个配置进行诠释。 1.conte...
  • OgnlContext对象

    千次阅读 2017-03-10 20:37:26
    OgnlContext对象 Ognl的API类和方法 OgnlContext类【本质是一个Map】 OgnlContext context = new OgnlContext(); context.put("user", user); context.put("address", address); context.setRoot(address) ...
  • 严重: Context initialization failed org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace ...
  • 从网上找了些关于Context 的资料,整理如下   I. Context 上下文,位于framework package的android.content.Context中,类似Win32中的Handle句柄。    SDK中对其说明如下:Interface to global information ...
  • 作为一个Android开发者,我们在Android开发中经常会使用到Context这个类。它在加载资源、启动Activity、获取系统服务、创建View等活动中都需要参与。 但Context到底是什么,我就很少去关注了…那么我们该如何理解去...
  • Context以及ContextWrapper

    千次阅读 2018-03-02 17:15:06
    在Android应用开发中,Context是一个非常重要的类,它是一个抽象类,是关于一个应用环境的描述的接口,Context的实例在应用程序被启动时由Android系统提供。 由于Context是一个抽象类,所以Android系统为我们提供了...
  • 上一篇文章我们学习了Context关联类和Application Context的创建过程,这一篇我们接着来学习Activity和Service的Context创建过程。需要注意的是,本篇的知识点会和深入理解四大组件系列的部分文章的知识点相重合。
  • gin使用context

    千次阅读 2018-11-01 16:53:42
    gin使用context.PostForm(“key”)无法获取到值 原因: ​ 有些场景使用context.BindJSON(&amp;stru)函数虽然可以帮前台传入的json转换成struct结构,但是有些字段是不需要的(虽然理论上应该使用VO接收对象,但是...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 402,168
精华内容 160,867
关键字:

context