`
文章列表
最近正在研究ZooKeeper源码,有这个意向的小伙伴吗?来一起探讨和研究 现在想寻求能挤出时间、经常研究源码的小伙伴,终极目标能够改造ZooKeeper: 利用空余时间研究源码,平时一起交流探讨,分工合作源码研究任务。
本人博客已搬往开源中国,地址   http://my.oschina.net/pingpangkuangmo/blog    
有时为了保证一些操作要么都成功,要么都失败,这就需要事务来保证。 传统的jdbc事务如下: @Test public void testAdd(){ Connection con=null; try { con=DriverManager.getConnection(url , username , password ) con.setAutoCommit(false); //操作一 PreparedStatement ps = con.prepareStatement("insert in ...
有了上一篇文章的原理分析,这一篇文章主要结合原理来进行使用。 shiro.ini配置为: [main] #realm dataSource=com.mchange.v2.c3p0.ComboPooledDataSource dataSource.driverClass=com.mysql.jdbc.Driver dataSource.jdbcUrl=jdbc:mysql://localhost:3306/shiro dataSource.user=XXXXXX dataSource.password=XXXXX jdbcRealm=org.apache.sh ...
Realm在验证用户身份的时候,要进行密码匹配。最简单的情况就是明文直接匹配,然后就是加密匹配,这里的匹配工作则就是交给CredentialsMatcher来完成的。先看下它的接口方法: public interface CredentialsMatcher { boolean doCredentialsMatch(AuthenticationToken token, AuthenticationInfo info); } 根据用户名获取AuthenticationInfo ,然后就需要将用户提交的AuthenticationToken和AuthenticationInfo ...
首先还是Realm的接口设计图: 这里只来说明SimpleAccountRealm和JdbcRealm的实现。 首先是SimpleAccountRealm不用关心数据的具体来源,只提供了与上层的交互,即实现了AuthenticatingRealm遗留的AuthenticationInfo doGetAuthenticationInfo和AuthorizingRealm遗留的AuthorizationInfo doGetAuthorizationInfo。 如下: protected final Map<String, SimpleAccount> users; //usern ...
前两篇文章主要说的是认证过程,这一篇来分析下授权的过程。还是开涛大神的案例(http://jinnianshilongnian.iteye.com/blog/2020017),如下: public class ShiroTest { @Test public void testHelloworld() { init(); Subject subject=login("zhang","123"); Assert.assertTrue(subject.hasRole("role1")); As ...
继续上一篇文章的案例,第一次使用SecurityUtils.getSubject()来获取Subject时 public static Subject getSubject() { Subject subject = ThreadContext.getSubject(); if (subject == null) { subject = (new Subject.Builder()).buildSubject(); Threa ...
最近闲来无事,准备读个框架源码,经别人推荐shiro,那就准备读读其中的设计。开涛大神已经有了跟我学Shiro系列,那我就跟着这个系列入门然后再深入源代码,所以我的侧重点就是源码分析。 话不多说,上开涛大神的入门案 ...
看了多方资料,整理下单例设计模式,有不少值得相互探究的地方,你就会发现就这一个小小的单例模式竟然映射出N多知识。我在这里把问题综述出来,一起相互探讨。 单例涉及到的相关文章如下:                 反射、枚举与单例                 序列化与单例                 类加载器与单例 本文则主要是讲多线程与单例。 单例模式首先分为懒汉式和饿汉式。所谓饿汉式即一开始就创建出单例对象,懒汉式则为当需要使用的时候才会去创建出单例对象。 先看下饿汉式: public final class Singleton { private static fin ...
当使用不同的类加载器时,也会使单例失效,如下: 单例为: public final class Singleton{ private static final Singleton instance=new Singleton(); private Singleton(){ System.out.println("执行构造函数"); System.out.println("类加载器="+this.getClass().getClassLoader()); } public stat ...
当单例模式的类实现了系列化Serializable接口,也可以通过反序列化来使它不再单例。 我们的单例类: public final class Singleton implements Serializable{ private static final long serialVersionUID = 1735776740157142434L; private static final Singleton instance=new Singleton(); private Singleton(){} public static Singleton ge ...
通常我们所使用的单例模式,我们都可以使用反射使它不再单例,如下饿汉式的单例模式: public final class Singleton { private static final Singleton instance=new Singleton(); private Singleton(){} public static Singleton getInstance(){ return instance; } } 测试案例如下: Singleton singleton1=Singleton.getInstance(); Singlet ...
有时候为了传承某个类的一些功能,我们可以采用继承该类来获取功能,并可以通过覆写某些方法来进行功能加强。然而若想对一批类的功能进行加强,如果仍采用继承,不仅在代码上重复,并且不利于扩展。如下所示: public interface Component { public void fun(); } public class ConcreteAComponent implements Component{ @Override public void fun() { System.out.println("ConcreteAComponent" ...
本文章内容是看完《HeadFirst设计模式》书籍的工厂模式后为了加深印象而写。其实有的时候,某些博客并不是仅仅为了分享,更主要的是写给自己,主要是为了自己在写的过程去更加深刻去体会,光看看别人所说的,感觉挺有道理的,却没有转化成自己的东西,就更不会在实际的工作中去使用设计模式了。 言归正传,工厂模式分成3种,简单工厂模式、工厂方法模式、抽象工厂模式。这些模式都是通过接口和抽象进行解耦。 简单工厂模式:(为了偷懒,我也不会独自去想一个实际的场景,将那本书所用场景复述下来,纯手打) 订购一个披萨现状如下: public Pizza orderPizza(String type){ P ...
Global site tag (gtag.js) - Google Analytics