I have a CDI bean, and a interceptor is added to one method of this bean.
If this bean doesn't have a default constructor(I use the Constructor Injection).
At runtime, I get the exception
java.lang.Class.newInstance0(Class.java:357)
java.lang.Class.newInstance(Class.java:325)
org.apache.webbeans.proxy.javassist.JavassistFactory.createProxy(JavassistFactory.java:79)
org.apache.webbeans.proxy.ProxyFactory.createProxy(ProxyFactory.java:241)
org.apache.webbeans.proxy.ProxyFactory.createDependentScopedBeanProxy(ProxyFactory.java:412)
org.apache.webbeans.component.AbstractInjectionTargetBean.createDefaultInstance(AbstractInjectionTargetBean.java:140)
org.apache.webbeans.component.AbstractInjectionTargetBean.createInstance(AbstractInjectionTargetBean.java:116)
org.apache.webbeans.component.AbstractOwbBean.createNewInstance(AbstractOwbBean.java:233)
org.apache.webbeans.portable.creation.AbstractProducer.produce(AbstractProducer.java:77)
org.apache.webbeans.component.InjectionTargetWrapper.produce(InjectionTargetWrapper.java:136)
If I add a default constructor in this bean, or remove the interceptor, it will be OK.
In fact, I can use the field injection to handle this question.
But I want to know: if I add a default constructor, that means this bean has two constructors -- one is non-parametric, the other with #Injected parameters. In this case (with interceptor), will The container create the instance twice?
Edit: I use Tomee1.5, and WebShpere8.5 is same as Tomee1.5
and it seems that GlassFish3.1.2 does not have this issue.
Edit: i found an answer in Tomee User Forum that is
The CDI container will invoke the #Inject annotated ct for your bean but will use the default ct for creating the proxies.
So, I think that means if you want to use constructor injection, u also need a default constructor for being proxyable.
Edit:
According to http://docs.jboss.org/weld/reference/latest/en-US/html/injection.html#d0e1443
unless a bean has the default scope #Dependent, the container must indirect all injected references to the bean through a proxy object.
According to //openejb.979440.n4.nabble.com/RequestScoped-CDI-constructor-td4661541.html
The CDI container will invoke the #Inject annotated constructor for your bean but will use the default constructor for creating the proxies. Therefor The default constructor is needed for all 'NormalScoped' (#RequestScoped #SessionScoped #ApplicationScoped #ConversationScoped) beans because they will always get proxied.
If a bean uses interceptor, according to the error message, OpenWebBean uses Proxy to deal with interceptor, so the intercepted classes must have the default construct. But Weld uses subclasses for interceptors and decorators. https://issues.jboss.org/browse/WELD-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel The subclassing solution is superior to proxification, since it avoids dealing with a number of issues such as: intercepted classes without a no-arg constructor and field access on proxified instances.
So, if I use Tomee and Websphere, it needs a default ct, but GlassFish doesn't.
Thanks brandizzi, It is my first question here. Thank you for your help.
And it seems I can not answer my own question and post more than two links
without 10 reputation, so I edited here.
As documented in the CDI specification, a CDI bean that has a bound interceptor must be proxyable, as defined in unproxyable bean types, which states in addition that proxyble beans are classes which have a non-private constructor with no parameters.
Related
the full sentence taken from the EJB3.2 specifications:
When interacting with a reference to the no-interface view, the client
must not make any assumptions regarding the internal implementation of
the reference, such as any instance-specific state that may be
present in the reference
I'm actually trying to understand what that actually mean and I was wondering if someone could kindly provide some examples.
EDIT:
The Above sentence is take from Section 3.4.4 Session Bean’s No-Interface View, maybe this info is helpful
When generating a no-interface view proxy, the EJB container must create a subclass of the EJB class and override all public methods to provide proxying behavior (like security, transactions).
You can get a reference to the bean with (eg. for passing it to another ejb):
NoInterfaceBean bean = ejbContext.getBusinessObject(NoInterfaceBean.class);
This returns a reference with a class-type that is the same as the bean class itself (normally if the EJB has a business interface it would return the interface class), but it is not a reference to an instance of NoInterfaceBean (but to that proxy class with the same name). Think of it as a reference to a pimped version of your bean, about which you
must not make any assumptions regarding the internal implementation
It's basically the same with "normal" EJB's. You know that there is some magic around your bean instance, but since you get the interface as class-type it's already clear that every class implementing the interface can have a different internal implementation.
So the specification emphasizes this difference at that point. Even if it looks like a reference to your concrete class it is none (as they say in the next paragraph of the specification JSR-000345 Enterprise JavaBeansTM 3.2 Final Release:
Although the reference object is type-compatible with the
corresponding bean class type, there is no prescribed relationship
between the internal implementation of the reference and the
implementation of the bean instance.
I am using camel apns component in order to push send notifications but I did not find any timeout setter for both reading and connection.
As I have seen:
There is this class , ApnsConnection, and it includes that parameters. But ApnsServiceFactory uses ApnsBuilder class as default. In its getService() method, setting of these two timeouts is not implemented.
So the question is, am I missing something or are the timeout settings really missing?
Thanks
The timeout settings are missing but that doesn't mean you can't do this, looking in the source code for ApnsServiceFactory you can see a protected method called configureServiceBuilder(ApnsServiceBuilder serviceBuilder) which is used in the testing of the class (which gives a good example usage) and means you can add extra configuration to the builder.
Subclass the ApnsServiceFactory and override configureServiceBuilder. In the body of that override add your withConnectionTimeout() and withReadTimeout() to the passed in serviceBuilder and return it.
We are using JSF 1.2 and WAS 6.1 in our application.
I am from servlet background and understand instance variable of a servlet class are not thread safe because instance variable are shared among all requests AND each request creates a new thread and gets served using doGet or doPost or any other handler.
How is above scenario handled in JSF 1.2?
We are using ChangeAddress managed bean with the following entry in faces-config.xml. Does Faces Servlet create new instances of ChangeAddressBean for each request?
<managed-bean>
<managed-bean-name>ChangeAddress</managed-bean-name>
<managed-bean-class>com.ChangeAddressBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
If the answer to point 2 is yes then how are final static variable used for all requests? Do final static variables remain common for all requests? Value of
anAddressFinder is populated in a static block but value may differ for different type of users based on some condition. Does that mean value of anAddressFinder once populated for first request/user will remain same for all subsequent requests/users?
public class ChangeAddressBean{
int flatNumber;
final static AddressFinder anAddressFinder;
.
.
.
}
Yes. 2. The value of "anAddressFinder" is bound the the class definition, not a particular class instance. You're assumption is correct. This is not the approach you should use. Based on the name alone, "AddressFinder" sounds very much like it should be a singleton service. Let Spring manage and inject this dependency in your ManagedBean. Fetch the needed data in an init() post-construct method or similar. In general, avoid static members in this context. They make testing more difficult, and it your case are not thread-safe.
I've been trying to find some info on difference between instantiating form fields through static method and the new keyword. Can somebody tell me what are the practical implications, limitations, between new MyFormField and MyFormField::create() esp. with regards to SilverStripe
Using the create factory method would check for overloads (set via Object::useCustomClass()) and return an instance of the custom class in that case.
This method first for strong class overloads (singletons & DB
interaction), then custom class overloads. If an overload is found, an
instance of this is returned rather than the original class. To
overload a class, use Object::useCustomClass()
So using the create method rather than instantiating the Object yourself would provide a possibility to overload the used Class without altering the code.
see
http://api.silverstripe.org/3.1/class-Object.html#_useCustomClass
http://api.silverstripe.org/3.1/class-Object.html#_create
I want to perform custom logic in an IdempotentConsumer. I've extended the class and implemented the logic. How can I add this to my route?
Do I have to make my own Definition class? Do I add it as a Processor? How do I get the parameters passed to the constructor?
Well, custom consumer/producer could be little overkill. I think for some kind of custom logic is enough to do it trough processor or custom bean.
1.Bean
Look at bean binding you can use simple language to pass arguments to your method. It will looks like this:
.bean(OrderService.class, "doSomething(${body}, true)")
.to("bean:orderService?method=doSomething(null, true)")
2.Processor
You have to realize your classes should be stateless because of concurrent matter of camel framework. Your constructor should be empty and your variables final otherwise whole bunch of magic could happen. Everything you want to pass to your logic component/processor should be passed via Exchange object. You can store your variables in getin() or getOut() messages as headers or body or Exchange properties and pass it to next endpoint. The exchange will change dynamically as it flows trough you camel routes. It should be your one and only one mutable object.