一直使用SVN进行版本控制，环境是：

win2003+myeclipse6+svn1.46

部署到tomcat5.5和weblogic8.1

问题描述：

eclipse开发过程经常进行自动编译和发布，这导致/web-inf/目录下相关文件夹对应的.svn文件夹被连同删除，导致同步时出现：svn' containing working copy admin area is missing提示。

解决办法：

浏览SVN仓库目录结构，把工程目录下对应的/web-inf/目录下相关文件全部或部分删除（这里我仅仅删除classes目录），刷新。再进行同步工作，OK。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

最近丢失了几个老旧的java源文件，大概有1M多那么大，

编译后class文件有600k，

结果使用jad反编译回来到到一半就出错了，

提示如下：

反编译得到的.jad文件只有754k，只编译了一半。

我找了几款反编译软件，同样出现无法反编译的情况。请问还有其他软件可以反编译大class文件吗？

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

Refactoring书上有一段关于注释的解释，可以看出作者对注释的态度，并不是"如果你要加注释，就说明这部分代码需要重构"

Don't worry, we aren't saying that people shouldn't write comments. In our olfactory analogy,
comments aren't a bad smell; indeed they are a sweet smell. The reason we mention comments
here is that comments often are used as a deodorant. It's surprising how often you look at thickly
commented code and notice that the comments are there because the code is bad.

Comments lead us to bad code that has all the rotten whiffs we've discussed in the rest of this
chapter. Our first action is to remove the bad smells by refactoring. When we're finished, we often
find that the comments are superfluous.

If you need a comment to explain what a block of code does, try Extract Method. If the method
is already extracted but you still need a comment to explain what it does, use Rename Method.
If you need to state some rules about the required state of the system, use Introduce
Assertion.

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

以下是有趣的文章：

fangang：如何在spring框架中解决多数据源的问题

stephen：spring 多数据源解决方案

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

Posted on January 23rd, 2007 by Mark Fisher in Spring, 2.0, Data Access.

Spring 2.0.1 introduced an AbstractRoutingDataSource. I believe that it deserves attention, since (based on frequent questions from clients) I have a hunch that there are quite a few 'home-grown' solutions to this problem floating around. That combined with the fact that it is trivial to implement yet easy to overlook, and now I have several reasons to dust off my corner of the Interface21 team blog.

The general idea is that a routing DataSource acts as an intermediary - while the 'real' DataSource can be determined dynamically at runtime based upon a lookup key. One potential use-case is for ensuring transaction-specific isolation levels which are not supported by standard JTA. For that, Spring provides an implementation: IsolationLevelDataSourceRouter. Consult its JavaDoc for a detailed description including configuration examples. Another interesting use-case is determination of the DataSource based on some attribute of the current user's context. What follows is a rather contrived example to demonstrate this idea.

First, I created a Catalog that extends Spring 2.0's SimpleJdbcDaoSupport. That base class only requires an instance of any implementation of javax.sql.DataSource, and then it creates a SimpleJdbcTemplate for you. Since it extends JdbcDaoSupport, the JdbcTemplate is also available. However, the "simple" version provides many nice Java 5 conveniences. You can read more detail about that in this blog by Ben Hale.

Anyways, here's the code for my Catalog:

java 代码

 

1. package blog.datasource;  
2.   
3. import java.sql.ResultSet;  
4. import java.sql.SQLException;  
5. import java.util.List;  
6.   
7. import org.springframework.jdbc.core.simple.ParameterizedRowMapper;  
8. import org.springframework.jdbc.core.simple.SimpleJdbcDaoSupport;  
9.   
10. public class Catalog extends SimpleJdbcDaoSupport {  
11.          
12.    public List<Item> getItems() {  
13.       String query = "select name, price from item";  
14.       return getSimpleJdbcTemplate().query(query, new ParameterizedRowMapper<Item>() {  
15.             public Item mapRow(ResultSet rs, int row) throws SQLException {  
16.                String name = rs.getString(1);  
17.                double price = rs.getDouble(2);  
18.                return new Item(name, price);  
19.             }  
20.       });  
21.    }  
22. }  

As you can see, the Catalog simply returns a list of Item objects. The Item just contains name and price properties:

java 代码

 

1. package blog.datasource;  
2.   
3. public class Item {  
4.   
5.    private String name;  
6.    private double price;  
7.          
8.    public Item(String name, double price) {  
9.       this.name = name;  
10.       this.price = price;  
11.    }  
12.   
13.    public String getName() {  
14.       return name;  
15.    }  
16.   
17.    public double getPrice() {  
18.       return price;  
19.    }  
20.   
21.    public String toString() {  
22.       return name + " (" + price + ")";  
23.    }  
24.   
25. }  

Now, in order to demonstrate multiple DataSources, I created an enum for different Customer types (representing "levels" of membership I guess), and I created three different databases - so that each type of customer would get a distinct item list (I did mention that this would be a contrived example didn't I?). The important thing is that each of the databases are equivalent in terms of the schema. That way the Catalog's query will work against any of them - just returning different results. In this case, it's just the "item" table with 2 columns: name and price. And… here is the enum:

java 代码

 

1. public enum CustomerType {  
2.    BRONZE,  
3.    SILVER,  
4.    GOLD  
5. }  

It's time to create some bean definitions. Since I have 3 datasources where everything is the same except for the port number, I created a parent bean so that the shared properties can be inherited. Then, I added the 3 bean definitions to represent the per-CustomerType DataSources:

 

xml 代码

 

1. <bean id="parentDataSource"  
2.          class="org.springframework.jdbc.datasource.DriverManagerDataSource"  
3.          abstract="true">  
4.    <property name="driverClassName" value="org.hsqldb.jdbcDriver"/>  
5.    <property name="username" value="sa"/>  
6. </bean>  
7.                  
8. <bean id="goldDataSource" parent="parentDataSource">  
9.    <property name="url" value="jdbc:hsqldb:hsql://localhost:${db.port.gold}/blog"/>  
10. </bean>  
11.   
12. <bean id="silverDataSource" parent="parentDataSource">  
13.    <property name="url" value="jdbc:hsqldb:hsql://localhost:${db.port.silver}/blog"/>  
14. </bean>  
15.   
16. <bean id="bronzeDataSource" parent="parentDataSource">  
17.    <property name="url" value="jdbc:hsqldb:hsql://localhost:${db.port.bronze}/blog"/>  
18. </bean>  
19.   
20. <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">  
21.    <property name="location" value="classpath:/blog/datasource/db.properties"/>  
22. </bean>  

Notice that I added a PropertyPlaceholderConfigurer so that I could externalize the port numbers in a "db.properties" file, like so:

java 代码

 

1. db.port.gold=9001  
2. db.port.silver=9002  
3. db.port.bronze=9003  

Now things start to get interesting. I need to supply the "routing" DataSource to my Catalog so that it can dynamically get connections from the 3 different databases at runtime based on the current customer's type. As I mentioned, the AbstractRoutingDataSource can be rather simple to implement. Here is my implementation:

java 代码

 

1. package blog.datasource;  
2.   
3. import org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource;  
4.   
5. public class CustomerRoutingDataSource extends AbstractRoutingDataSource {  
6.   
7.    @Override  
8.    protected Object determineCurrentLookupKey() {  
9.       return CustomerContextHolder.getCustomerType();  
10.    }  
11. }  

…and the CustomerContextHolder simply provides access to a thread-bound CustomerType. In reality, the 'context' would likely hold more information about the customer. Also note that if you are using Acegi, then you could retrieve some information from the userDetails. For this example, it's just the customer "type":

java 代码

 

1. public class CustomerContextHolder {  
2.   
3.    private static final ThreadLocal<CustomerType> contextHolder =  
4.             new ThreadLocal<CustomerType>();  
5.          
6.    public static void setCustomerType(CustomerType customerType) {  
7.       Assert.notNull(customerType, "customerType cannot be null");  
8.       contextHolder.set(customerType);  
9.    }  
10.   
11.    public static CustomerType getCustomerType() {  
12.       return (CustomerType) contextHolder.get();  
13.    }  
14.   
15.    public static void clearCustomerType() {  
16.       contextHolder.remove();  
17.    }  
18. }  

Finally, I just need to configure the catalog and routing DataSource beans. As you can see, the "real" DataSource references are provided in a Map. If you provide Strings, they can be resolved as JNDI names (or any custom resolution strategy can be provided - see the JavaDoc). Also, I've simply set the 'bronzeDataSource' as the default:

 

xml 代码

 

1. <bean id="catalog" class="blog.datasource.Catalog">  
2.    <property name="dataSource" ref="dataSource"/>  
3. </bean>  
4.   
5. <bean id="dataSource" class="blog.datasource.CustomerRoutingDataSource">  
6.    <property name="targetDataSources">  
7.       <map key-type="blog.datasource.CustomerType">  
8.          <entry key="GOLD" value-ref="goldDataSource"/>  
9.          <entry key="SILVER" value-ref="silverDataSource"/>  
10.       </map>  
11.    </property>  
12.    <property name="defaultTargetDataSource" ref="bronzeDataSource"/>  
13. </bean>  

Of course I'd like to see this working, so I've created a simple test (extending one of Spring's integration test support classes). I added 3 items to the "gold" database, 2 items to the "silver" database, and only 1 item to the "bronze" database. This is the test:

java 代码

 

1. public class CatalogTests extends AbstractDependencyInjectionSpringContextTests {  
2.   
3.    private Catalog catalog;  
4.   
5.    public void setCatalog(Catalog catalog) {  
6.       this.catalog = catalog;  
7.    }  
8.   
9.    public void testDataSourceRouting() {  
10.       CustomerContextHolder.setCustomerType(CustomerType.GOLD);  
11.       List<Item> goldItems = catalog.getItems();  
12.       assertEquals(3, goldItems.size());  
13.       System.out.println("gold items: " + goldItems);  
14.   
15.       CustomerContextHolder.setCustomerType(CustomerType.SILVER);  
16.       List<Item> silverItems = catalog.getItems();  
17.       assertEquals(2, silverItems.size());  
18.       System.out.println("silver items: " + silverItems);  
19.          
20.       CustomerContextHolder.clearCustomerType();  
21.       List<Item> bronzeItems = catalog.getItems();  
22.       assertEquals(1, bronzeItems.size());  
23.       System.out.println("bronze items: " + bronzeItems);                
24.    }  
25.   
26.    protected String[] getConfigLocations() {  
27.       return new String[] {"/blog/datasource/beans.xml"};  
28.    }     
29. }  

…and rather than simply taking a screenshot of the green bar, you'll notice I've provided some console output - the results!:

java 代码

 

1. gold items: [gold item #1 (250.0), gold item #2 (325.45), gold item #3 (55.6)]  
2. silver items: [silver item #1 (25.0), silver item #2 (15.3)]  
3. bronze items: [bronze item #1 (23.75)]  

As you can see, the configuration is simple. Better still, the data-access code is not concerned with looking up different DataSources. For more information, consult the JavaDoc for AbstractRoutingDataSource.

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

Johannes Ernst's Blog

This week, I attended a very interesting presentation by Dan Pritchett and Randy Shoup, both senior technologists at eBay, on eBay's architecture. Some of it was as I would have expected, other things were, shall we say, counter-intuitive. Here is a random collection of notes, with some special exclamation marks:

• 212 million registered users, 1 billion photos
• 1 billion page views a day, 105 million listings, 2 petabytes of data, 3 billion API calls a month
• something like a factor of 35 in page views, e-mails sent, bandwidth from June 1999 to Q3/2006.
• 99.94% availability, measured as "all parts of site functional to everybody" vs. at least one part of a site not functional to some users somewhere
• 15,000 application servers, all J2EE. About 100 groups of functionality aka "apps". Notion of a "pool": "all the machines that deal with selling"... Well over 200 databases.
• Everything is planned with the question "what if load increases by 10x". Scaling only horizontal, not vertical: many parallel boxes.
• leverages MSXML framework for presentation layer (even in Java)
• Oracle databases, WebSphere Java (still 1.3.1)
• split databases by primary access path, modulo on a key
• every database has at least 3 on-line databases. Distributed over 8 data centers
• some database copies run 15 min behind, 4 hours behind
• no stored procedures. some very simple triggers.
• move cpu-intensive work moved out of the database layer to applications applications layer: referential integrity, joins, sorting done in the application layer! Reasoning: app servers are cheap, databases are the bottleneck.
• no client-side transactions. no distributed transactions
• J2EE: use servlets, JDBC, connection pools (with rewrite). Not much else.
• no state information in application tier. transient state maintained in cookie or scratch database
• app servers do not talk to each other -- strict layering of architecture
• Search, in 2002: 9 hours to update the index running on largest Sun box available -- not keeping up
• Average item on site changes its search data 5 times before it is sold (e.g. price), so real-time search results are extremely important.
• "Voyager": real-time feeder infrastructure built by eBay.. Uses reliable multicast from primary database to search nodes, in-memory search index, horizontal segmentation, N slices, load-balances over M instances, cache queries

There were way more questions by the packed audience of architects and other techies than there was time. Absolutely worth everybody's time.

Dan put the slides on his blog: eBaySDForum2006-11-29.pdf.

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

要处理2个数据库之间事务：

JOTM Transactions In Spring And Hibernate

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

Introduction

A bit of back story:

I had to tie in web services to a hibernate-based backend for the upcoming release of FireBright's SaaS on Demand platform. The problem: Doing it in such a way that:

• doesn't tie me down to a particular platform.
• Offers me maximum flexibility in terms of features
• Doesn't bog down performance.

Web services are quite interesting beasts. Not something to be taken lightly, if you consider the implementation that Axis2 provides. That being said, there is another way, privided by the friendly folks at XFire (which, incidentally, is where I found out about FishEye^?). But, there seems to be a bit of a disconnect.. I've got objects persisted by Hibernate, and those same objects need to be rendered as XML Data, and with over 50 entity types and relationships, I really don't want to have to write populators for everything.

Again, introduce XFire. Why? Because it makes this stuff simple. WSDL Generation, auto-typing using aegis or JAXB (PERFECT!), and it even uses jws annotations, so it limits the amount of implementation specific code in my own code. So how this is done.

http://wiki.firebright.com/bin/view/Main/SpringHibernateXFire

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师