[JBoss JIRA] (CDI-492) Give ownership of servlet specific part to servlet specification
by Antoine Sabot-Durand (JIRA)
Antoine Sabot-Durand created CDI-492:
----------------------------------------
Summary: Give ownership of servlet specific part to servlet specification
Key: CDI-492
URL: https://issues.jboss.org/browse/CDI-492
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Java EE integration
Reporter: Antoine Sabot-Durand
[Section 3.8 of the spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_...] places some requirements on CDI implementations when running with Servlet. To better suit user desires for modularity these requirements are better met by moving them to the Servlet spec. Specifically,
{quote}
A servlet container must provide the following built-in beans, all of which have qualifier @Default:
* a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the HttpServletRequest
* a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the HttpSession,
* a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the ServletContext,
These beans are passivation capable dependencies, as defined in Passivation capable dependencies.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
Important improvements for product development in CDI 2.0
by Thomas Andraschko
Hi,
we have a big product with many subproducts/projects and customizations for
some customers.
CDI and JSF is really doing a great job here but i found 2 really annoying
issues which could be improved:
- CDI-224: Allow decoration on classes, not only on interfaces
We created many interfaces the last months for our beans just to get
decoration working
This is really annoying as this interfaces are just overhead and actually
senseless for us.
- CDI-407: Specify @Named @Alternatives
Currently its not defined what should happen if a alternative has a
@Named and is activated via beans.xml in the current app:
@Named public class A
@Named @Alternative public class B extends A
or even something like:
@Named public class A
@Specializes public class B extends A
@Named @Alternative public class B2 extends B
IMO B and B2 should also be available via EL "a".
This are really important issues for standard cases.
It would be great to see it in CDI 2.0.
Best regards,
Thomas
9 years, 5 months
Next meeting proposed agenda
by Antoine Sabot-Durand
Hi All,
Sorry for the 2 previous meeting I had to cancel for personal issue and Devoxx. I propose we adopt the following agenda for the next meeting (wednesday 18:00 CET / 17:00 GMT)
- Java SE support (I’ll try to provide a doc before the meeting)
- Asynchronous event scenarios
- Feedback on AtInject initiative.
If you want to add something else, please let me know.
Regards
Antoine
9 years, 5 months
Destroying beans from an interceptor
by arjan tijms
Hi,
I wonder if it would be allowed according to the CDI spec to destroy a
bean instance from within an interceptor.
To test this (on Weld) I used the following code:
@Interceptor
@DestroyOnError
@Priority(APPLICATION)
public class DestroyOnErrorInterceptor implements Serializable {
private static final long serialVersionUID = 1L;
@AroundInvoke
public Object tryInvoke(InvocationContext ctx) throws Exception {
try {
return ctx.proceed();
} catch (Exception e) {
destroy(ctx.getMethod().getDeclaringClass());
throw e;
}
}
private <T> void destroy(Class<T> clazz) {
Instance<T> instance = CDI.current().select(clazz);
instance.destroy(instance.get());
}
}
When I use this interceptor on a SessionScoped bean:
@SessionScoped
public class TestBean implements Serializable {
private static final long serialVersionUID = 1L;
@DestroyOnError
public void test() {
throw new IllegalStateException();
}
}
And then inject said bean in say a Servlet and call the test() method,
destruction of the bean happens partially, but as soon as Weld tried
to invocate a preDestroy method, it goes through the bean proxy again,
detects that "the" interceptor handler is already active, promptly
skips its attempt to call a preDestroy method and then to add insult
to injury tries to call a "proceed" method which is always null and
thus throws a NPE.
(this happens in
org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke)
I tried some alternative methods to destroy the bean such as:
Bean<T> bean = resolve(beanManager, beanClass);
AlterableContext context = (AlterableContext)
beanManager.getContext(bean.getScope());
context.destroy(bean);
with resolve being:
public static <T> Bean<T> resolve(BeanManager beanManager, Class<T> beanClass) {
Set<Bean<?>> beans = beanManager.getBeans(beanClass);
for (Bean<?> bean : beans) {
if (bean.getBeanClass() == beanClass) {
return (Bean<T>)
beanManager.resolve(Collections.<Bean<?>>singleton(bean));
}
}
return (Bean<T>) beanManager.resolve(beans);
}
But this resulted in the same problem.
Any idea?
Kind regards,
Arjan Tijms
9 years, 5 months
Canceling meeting
by Antoine Sabot-Durand
Hi guys,
I'm having meeting with other spec leads at Devoxx during our time slot so won't be available for today's meeting. We'll catch up next week
Antoine Sabot-Durand
9 years, 5 months
Funny exception in generating rest endoint
by Antonio Goncalves
During the HoL one guy had this problem (on windows) generating REST
endpoints. The generated code is ok, and everything works fine, but here is
the stack trace
---------- Forwarded message ----------
From: Ilya Masharov <ilya.masharov(a)gmail.com>
Date: 2014-11-11 10:30 GMT+01:00
Subject: Forge stacktrace
To: antonio.goncalves(a)gmail.com
11:29:22,655 SEVERE
[org.jboss.forge.addon.ui.impl.controller.AbstractCommandController]
(AeshProcess: 45) Error while notifying listeners:
java.lang.ClassCastException: java.util.ArrayList cannot be cast to
org.jboss.forge.addon.resource.FileResource
at
org.jboss.forge.addon.projects.Projects.getSelectedProject(Projects.java:37)
at
org.jboss.forge.addon.projects.ui.ProjectBuildStatusListener.postCommandExecuted(ProjectBuildStatusListener.java:41)
at sun.reflect.GeneratedMethodAccessor135.invoke(Unknown Source) [:1.8.0_05]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.8.0_05]
at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_05]
at
org.jboss.forge.furnace.proxy.ClassLoaderInterceptor$1.call(ClassLoaderInterceptor.java:87)
[furnace-proxy-2.10.1.Final.jar:2.10.1.Final]
at
org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:42)
[furnace-api-2.10.1.Final.jar:2.10.1.Final]
at
org.jboss.forge.furnace.proxy.ClassLoaderInterceptor.invoke(ClassLoaderInterceptor.java:103)
[furnace-proxy-2.10.1.Final.jar:2.10.1.Final]
at
org.jboss.forge.addon.projects.ui.ProjectBuildStatusListener_$$_javassist_55c47aad-8fa7-4e5a-86e8-9fc7e27f9cef.postCommandExecuted(ProjectBuildStatusListener_$$_javassist_55c47aad-8fa7-4e5a-86e8-9fc7e27f9cef.java)
at
org.jboss.forge.addon.ui.impl.controller.AbstractCommandController.firePostCommandExecuted(AbstractCommandController.java:144)
[ui-impl-2.10.1.Final.jar:2.10.1.Final]
at
org.jboss.forge.addon.ui.impl.controller.SingleCommandControllerImpl.execute(SingleCommandControllerImpl.java:89)
[ui-impl-2.10.1.Final.jar:2.10.1.Final]
at
org.jboss.forge.addon.shell.aesh.CommandAdapter.execute(CommandAdapter.java:74)
[shell-impl-2.10.1.Final.jar:2.10.1.Final]
at
org.jboss.aesh.console.AeshConsoleImpl$AeshConsoleCallbackImpl.execute(AeshConsoleImpl.java:325)
[aesh-0.56.1.jar:0.56.1]
at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:40)
[aesh-0.56.1.jar:0.56.1]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[rt.jar:1.8.0_05]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[rt.jar:1.8.0_05]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
--
--
Antonio Goncalves (antonio.goncalves(a)gmail.com)
Software architect
Web site : www.antoniogoncalves.org
Blog: agoncal.wordpress.com
Feed: feeds2.feedburner.com/AntonioGoncalves
Paris JUG leader : www.parisjug.org
LinkedIn: www.linkedin.com/in/agoncal
9 years, 5 months
[JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.sys... ]
arjan tijms commented on CDI-10:
--------------------------------
{quote}If an Extension hacker really needs such a hardcore hack, then he might as well take the direct route:{quote}
Given an unknown proxy, how do you know the scope, type and qualifiers?
I think the original request is stall valid, for instance for those case where you need to take action based on a bean's class (it's class name may be a key into some map for instance) but all you got is the proxy.
The workaround seems a bit circular, but maybe I misunderstood. If you want to find out the original bean type of a proxy, you need the type to obtain a Bean instance via which you can obtain the original type. But if I had the type already, I wouldn't need to obtain a Bean instance in the first place.
See also http://stackoverflow.com/questions/14511433/original-class-name-of-a-prox...
> Add ability to access a bean instance from a proxy
> --------------------------------------------------
>
> Key: CDI-10
> URL: https://issues.jboss.org/browse/CDI-10
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Stuart Douglas
>
> There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method.
> Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required.
> This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
JSF 2.3 and specifying alternatives for build-in producers
by arjan tijms
Hi,
For JSF 2.3 we're currently working on providing build-in producers
for various JSF artefacts.We're basically using the approach that I
outlined here: http://jdevelopment.nl/dynamic-cdi-producers
I noticed CDI is using a similar approach for its build-in producers,
e.g. the one for HttpServletRequest (in Weld:
org.jboss.weld.bean.builtin.ee.HttpServletRequestBean).
Now we're currently putting these producers in an API package, to give
the user a chance to override them, but I noticed CDI is not doing
this. All producers are in implementation packages.
After some experimentation I couldn't really succeed in providing an
alternative producer for the CDI produced HttpServletRequest. I tried
the obvious things, like an @Produces method in a bean annotated with
@Alternative but that didn't work. Registered the bean as alternative
in beans.xml, tried the uhm alternative @Priority method, tried
different priority ranges, etc but my own producer was never called.
Am I missing something very obvious, or is it not trivial to provide
an alternative for build-in producers?
Kind regards,
Arjan Tijms
9 years, 5 months
Cancelling today's meeting
by Antoine Sabot-Durand
Hi guys,
I have to drive my son to the hospital, he just had a bike accident. Nothing too serious but he definitely needs stitches.
Antoine
9 years, 5 months
