<commit_before>/*
 * Copyright 2002-2007 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.springframework.beans.factory.aspectj;

import java.io.ObjectStreamException;
import java.io.Serializable;

import org.springframework.beans.factory.annotation.AnnotationBeanWiringInfoResolver;
import org.springframework.beans.factory.annotation.Configurable;

/**
 * Concrete aspect that uses the {@link Configurable }
 * annotation to identify which classes need autowiring.
 *
 * <p>The bean name to look up will be taken from the
 * <code>&#64;Configurable</code> annotation if specified, otherwise the
 * default bean name to look up will be the FQN of the class being configured.
 * 
 * <h2>Implementation details:</h2> 
 *
 * <p>This aspect advises object creation for <code>&#64;Configurable</code>
 * class instances. There are two cases that needs to be handled:
 *
 * <ol>
 *   <li>Normal object creation via the '<code>new</code>' operator: this is
 *       taken care of by advising <code>initialization()</code> join points.</li>
 *   <li>Object creation through deserialization: since no constructor is
 *       invoked during deserialization, the aspect needs to advise a method that a
 *       deserialization mechanism is going to invoke. Ideally, we should not
 *       require user classes to implement any specific method. This implies that
 *       we need to <i>introduce</i> the chosen method. We should also handle the cases
 *       where the chosen method is already implemented in classes (in which case,
 *       the users implementation for that method should take precedence over the 
 *       introduced implementation). There are a few choices for the chosen method:
 *       <ul>
 *       <li>readObject(ObjectOutputStream): Java requires that the method must be
 *           <code>private</p>. Since aspects cannot introduce a private member, 
 *           while preserving its name, this option is ruled out.</li>
 * 		 <li>readResolve(): Java doesn't pose any restriction on access specifier. 
 *           Problem solved! There is one (minor) limitation of this approach in 
 *           that if a user class already has this method, that method must be 
 *           <code>public</code>. However, this shouldn't be a big burden, since
 *           use cases that need classes to implement readResolve() (custom enums, 
 *           for example) are unlikely to be marked as &#64;Configurable</li>, and
 *           in any case asking to make that method <code>public</code> should not
 *           pose any undue burden. 
 *       </ul>
 *       The minor collaboration needed by user classes (the implementation of
 *       <code>readResolve()</code>, if any, must be <code>public</code>) can be
 *       lifted as well if we were to use experimental feature in AspectJ - the
 *       <code>hasmethod()</code> PCD.
 * </ol>
 *
 * @author <NAME>
 * @author <NAME>
 * @author <NAME>
 * @since 2.0<commit_msg>Corrected grammar and layout issues in Javadoc.<commit_after>/*
 * Copyright 2002-2007 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.springframework.beans.factory.aspectj;

import java.io.ObjectStreamException;
import java.io.Serializable;

import org.springframework.beans.factory.annotation.AnnotationBeanWiringInfoResolver;
import org.springframework.beans.factory.annotation.Configurable;

/**
 * Concrete aspect that uses the {@link Configurable }
 * annotation to identify which classes need autowiring.
 *
 * <p>The bean name to look up will be taken from the
 * <code>&#64;Configurable</code> annotation if specified, otherwise the
 * default bean name to look up will be the FQN of the class being configured.
 * 
 * <h2>Implementation details:</h2> 
 *
 * <p>This aspect advises object creation for <code>&#64;Configurable</code>
 * class instances. There are two cases that needs to be handled:
 *
 * <ol>
 *   <li>Normal object creation via the '<code>new</code>' operator: this is
 *       taken care of by advising <code>initialization()</code> join points.</li>
 *   <li>Object creation through deserialization: since no constructor is
 *       invoked during deserialization, the aspect needs to advise a method that a
 *       deserialization mechanism is going to invoke. Ideally, we should not
 *       require user classes to implement any specific method. This implies that
 *       we need to <i>introduce</i> the chosen method. We should also handle the cases
 *       where the chosen method is already implemented in classes (in which case,
 *       the user's implementation for that method should take precedence over the 
 *       introduced implementation). There are a few choices for the chosen method:
 *       <ul>
 *       <li>readObject(ObjectOutputStream): Java requires that the method must be
 *           <code>private</p>. Since aspects cannot introduce a private member, 
 *           while preserving its name, this option is ruled out.</li>
 * 		 <li>readResolve(): Java doesn't pose any restriction on an access specifier. 
 *           Problem solved! There is one (minor) limitation of this approach in 
 *           that if a user class already has this method, that method must be 
 *           <code>public</code>. However, this shouldn't be a big burden, since
 *           use cases that need classes to implement readResolve() (custom enums, 
 *           for example) are unlikely to be marked as &#64;Configurable, and
 *           in any case asking to make that method <code>public</code> should not
 *           pose any undue burden.</li>
 *       </ul>
 *       The minor collaboration needed by user classes (i.e., that the 
 *       implementation of <code>readResolve()</code>, if any, must be 
 *       <code>public</code>) can be lifted as well if we were to use an 
 *       experimental feature in AspectJ - the <code>hasmethod()</code> PCD.</li>
 * </ol>
 *
 * @author <NAME>
 * @author <NAME>
 * @author <NAME>
 * @since 2.0
{'fraction_non_alphanumeric': 0.08398354376507305, 'fraction_numerical': 0.006242020144701376, 'mean_word_length': 3.311926605504587, 'pattern_counts': {'":': 0, '<': 84, '<?xml version=': 0, '>': 84, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4674196', 'n_tokens_mistral': 1832, 'n_tokens_neox': 1766, 'n_words': 839}