[JBoss JIRA] Moved: (JBAS-8870) Injecting SessionContext and WebServiceContext failing with Weld1.1 Final in JBoss 6
by Ales Justin (JIRA)
[ https://issues.jboss.org/browse/JBAS-8870?page=com.atlassian.jira.plugin.... ]
Ales Justin moved WELD-854 to JBAS-8870:
----------------------------------------
Project: JBoss Application Server (was: Weld)
Key: JBAS-8870 (was: WELD-854)
Issue Type: Task (was: Bug)
Affects Version/s: 6.0.0.Final
(was: 1.1.0.Final)
Component/s: EJB3
(was: Weld SPI)
Security: Public
Steps to Reproduce: (was: Interceptor Binding
@Inherited
@InterceptorBinding
@Target({TYPE})
@Retention(RUNTIME)
public @interface Obfuscator {
}
Interceptor
@Interceptor @Obfuscator
public class ObfuscatorImpl {
@Resource
SessionContext sessionContext;
@Resource
WebServiceContext webServiceContext;
@AroundInvoke
public Object intercept(InvocationContext ctx) throws Exception {
System.out.println("GetRollback? " + sessionContext.getRollbackOnly());
System.out.println("!!!!!!!!!!!!!Interception!!!!!!!!!!!!!!!");
return "I don't like what you said.";
}
}
Bean
@Stateless
@Obfuscator
public class MyBean implements MyBeanLocal {
@Override
public String repeat(String s) {
return s;
}
}
beans.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
<interceptors>
<class>sf.jra.interceptor.implementation.ObfuscatorImpl</class>
</interceptors>
</beans>
Abbreviated Stack Trace
> >
> > Caused by: java.lang.RuntimeException: Error looking up java:comp/env/sf.jra.interceptor.implementation.ObfuscatorImpl/sessionContext in JNDI
> >
> > at org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:51) [:20101031-0118]
> >
> > at org.jboss.weld.util.Beans.injectEEFields(Beans.java:795) [:6.0.0.Final]
> >
> > at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1$1.proceed(ManagedBean.java:181) [:6.0.0.Final]
> >
> > at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:54) [:6.0.0.Final]
> >
> > at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1.work(ManagedBean.java:176) [:6.0.0.Final]
> >
> > at org.jboss.weld.bean.ManagedBean$FixInjectionPoint.run(ManagedBean.java:142) [:6.0.0.Final]
> >
> > at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.inject(ManagedBean.java:170) [:6.0.0.Final]
> >
> > at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:339) [:6.0.0.Final]
> >
> > at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:67) [:6.0.0.Final]
> >
> > at org.jboss.weld.integration.ejb.interceptor.Jsr299BindingsInterceptor.addInterceptorInstance(Jsr299BindingsInterceptor.java:107) [:6.0.0.Final]
> >
> > at org.jboss.weld.integration.ejb.interceptor.Jsr299BindingsInterceptor.init(Jsr299BindingsInterceptor.java:82) [:6.0.0.Final]
> >
> > at org.jboss.weld.integration.ejb.interceptor.Jsr299BindingsInterceptor.doPostConstruct(Jsr299BindingsInterceptor.java:68) [:6.0.0.Final]
> >
> > ... 90 more
> >
> > Caused by: javax.naming.NameNotFoundException: sf.jra.interceptor.implementation.ObfuscatorImpl not bound
> >
> > at org.jnp.server.NamingServer.getBinding(NamingServer.java:771) [:5.0.5.Final]
> >
> > at org.jnp.server.NamingServer.getBinding(NamingServer.java:779) [:5.0.5.Final]
> >
> > at org.jnp.server.NamingServer.getObject(NamingServer.java:785) [:5.0.5.Final]
> >
> > at org.jnp.server.NamingServer.lookup(NamingServer.java:396) [:5.0.5.Final]
> >
> > at org.jnp.server.NamingServer.lookup(NamingServer.java:399) [:5.0.5.Final]
> >
> > at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728) [:5.0.5.Final]
> >
> > at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:835) [:5.0.5.Final]
> >
> > at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:688) [:5.0.5.Final]
> >
> > at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_19]
> >
> > at org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:47) [:20101031-0118]
> >
> > ... 101 more
> >
> >
)
> Injecting SessionContext and WebServiceContext failing with Weld1.1 Final in JBoss 6
> ------------------------------------------------------------------------------------
>
> Key: JBAS-8870
> URL: https://issues.jboss.org/browse/JBAS-8870
> Project: JBoss Application Server
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: EJB3
> Affects Versions: 6.0.0.Final
> Environment: JBoss AS6
> Reporter: Joel Tosi
> Assignee: Marius Bogoevici
>
> A customer development team at is using Weld 1.1 on JBoss 6 and is encountering the following issue. hey are looking to apply an interceptor to their EJB's to do special exception handling based upon on how the EJB was invoked (RMI or SOAP). Other than the interceptor, they want no reference to exception handling code in the EJB.
>
> They are an EAP customer and using EAP5.1 with @Interceptors(class), they could create an interceptor where they could inject the SessionContext and WebServiceContext simply using @Resource without additional parameters.
>
> Trying to do the same thing in JBoss 6 using interceptor bindings, it appears that this does not function the same way. From the stack trace and the code available on line, it appears it is trying to inject the resource as if the interceptor is completely independent of the EJB. Is that as expected or is it an issue? They are seeing an error on the jndi lookup that is caused from the interceptor implementation not being bound.
>
> Ideally they would like to reuse this interceptor on all of their services, regardless of whether the EJB's are invoked via RMI or SOAP, POJO JAX-WS services, or POJO JAX-RS services. The expectation is for the injection to fail gracefully (just return null or some façade / proxy) if the SessionContext or WebServiceContext is not relevant for the given invocation. In the short term, in the context of EJB's shouldn't this function the same as @Interceptors?
>
> Sample code from the customer is in steps to reproduce along with the stack trace. This looks like a bug - if its not please help me understand the design choices here.
> Best,
> Joel
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (JGRP-1289) TCP: multicasting should be restricted to current members
by Bela Ban (JIRA)
TCP: multicasting should be restricted to current members
---------------------------------------------------------
Key: JGRP-1289
URL: https://issues.jboss.org/browse/JGRP-1289
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.12
In TP.down(), when TCP is used as transport, BasicTCP.sendMulticast() calls sendToAllPhysicalAddresses(). This method grabs all physical addresses from the cache and sends the message to each of them in turn.
However, this is problematic in the following case:
- {A,B,C}
- C is stopped (CTRL-Z)
- After some time, A installs view {A,B}
- This marks C in the cache as 'removed', but the list of physical addresses is still {A,B,C}, so when we multicast to the group, we send to A, B *and* C !
- The send to C will block at some point (as C is stopped), therefore the sending thread will block !
- Even if we use send queues in TCP, after some time, the send queue of C will fill up and the addition to the queue will block
SOLUTION: send a group multicast only to elements in the cache which are not marked as 'removable'.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (JBAS-8868) Incorrect setter picked up for resource injection
by jaikiran pai (JIRA)
Incorrect setter picked up for resource injection
-------------------------------------------------
Key: JBAS-8868
URL: https://issues.jboss.org/browse/JBAS-8868
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Integration
Affects Versions: 6.0.0.Final
Reporter: jaikiran pai
Assignee: jaikiran pai
If a resource injection target contains the following piece of code:
{code}
@Stateless
public class BugResourceBean implements BugResourceLocal {
@EJB
private CreateLocal create;
public String create() {
return "ok";
}
}
{code}
during injection, instead of injecting into the field, jboss-injection tries to incorrectly inject in the method leading to an exception:
{code}
Caused by: java.lang.IllegalArgumentException: failed to set value Proxy to jboss.j2ee:ear=alexandria-ear-0.3.4-SNAPSHOT.ear,jar=alexandria-ejb-0.3.4-SNAPSHOT.jar,name=CreateBean,service=EJB3 implementing [interface com.unifiedpost.alexandria.ejb.CreateLocal] with setter public java.lang.String com.unifiedpost.alexandria.rest.resource.service.BugResourceBean.create()
at org.jboss.injection.injector.util.MethodInjectionPoint.set(MethodInjectionPoint.java:66) [:1.0.0-alpha-6]
at org.jboss.injection.injector.EEInjector.inject(EEInjector.java:159) [:1.0.0-alpha-6]
at org.jboss.injection.injector.EEInjector.inject(EEInjector.java:134) [:1.0.0-alpha-6]
at org.jboss.injection.injector.EEInjector.inject(EEInjector.java:82) [:1.0.0-alpha-6]
{code}
Please see the referenced forum thread for the complete details.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (JBRULES-2892) Not Clause in Guided Decision Table
by Brad Davis (JIRA)
Not Clause in Guided Decision Table
-----------------------------------
Key: JBRULES-2892
URL: https://issues.jboss.org/browse/JBRULES-2892
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-guvnor
Affects Versions: 5.1.0.FINAL
Reporter: Brad Davis
Assignee: Mark Proctor
We have had many situations where a not clause needs to be entered within a Guided Decision Table. This functionality seems to be missing. We are trying to produce a rule similar to the following in DSL.
WHEN
not Patient(gender="M")
THEN
...
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (JBRULES-2890) Enumerated Values Via Query
by Brad Davis (JIRA)
Enumerated Values Via Query
---------------------------
Key: JBRULES-2890
URL: https://issues.jboss.org/browse/JBRULES-2890
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-guvnor
Affects Versions: 5.1.1.FINAL
Reporter: Brad Davis
Assignee: Mark Proctor
Priority: Optional
When creating the Rules Fact Model, it would be helpful to be able to define a query and datasource to enumerate possible values for a given field. An example of the usefulness would be for ICD Codes for healthcare. By annotating a fact model field with Datasource and Query information, we could provide auto-complete / enumeration for a given field in the UI.
public class ICD9Code {
@org.jboss.brms.ui.validators.DatabaseEnumerator(
datasource="ExampleDS",
query={"select field from some table where field like '{value}%"')
private String code;
...
}
As the user starts to type in the BRL UI, we could then perform a query on the underlying datasource to autocomplete the annotated field. For large datasets, this would decrease the entry time significantly for the business users, while also ensuring that users are adhering to known business values.
This would also be useful for zip codes, states, etc.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months