[JBoss JIRA] Created: (JBRULES-2707) Split up drools-guvnor into drools-guvnor-gwtclient and drools-guvnor(-server)
by Geoffrey De Smet (JIRA)
Split up drools-guvnor into drools-guvnor-gwtclient and drools-guvnor(-server)
------------------------------------------------------------------------------
Key: JBRULES-2707
URL: https://jira.jboss.org/browse/JBRULES-2707
Project: Drools
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 5.1.1.FINAL
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Fix For: 5.2.0.M1
All classes/resources under the client/public package go to drools-guvnor-gwtclient.
The drools-guvnor-gwtclient pom.xml
- is of type war
- has only the gwt dependencies
All classes under the server package go to drools-guvnor(-server)
The drools-guvnor(-server) pom.xml
- is of type war
- has a dependency on drools-guvnor-gwtclient (= war overlay!)
- has dependencies on drools-core, drools-compiler (so on jdt too), ...
What do we do with drools-ide-common and drools-factconstraints? Split them up to, or simply move the client package code into drools-guvnor?
Where will the drools-ide-common and drools-factconstraints GWT modules be reused, besides in Guvnor?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (JBMETA-329) Using ejb-jar.xml for @Singleton bean
by Benoit Heinrich (JIRA)
Using ejb-jar.xml for @Singleton bean
-------------------------------------
Key: JBMETA-329
URL: https://issues.jboss.org/browse/JBMETA-329
Project: JBoss Metadata
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBoss AS 6.0.0.Final
Reporter: Benoit Heinrich
Hi all,
After talking on the forum about a problem with @Singleton and the use of ejb-jar.xml I've been instructed to open a bug report.
An example project is available on the jboss forum post, and can be used to reproduce the problem here.
Here is the stacktrace thrown by jboss when deploying the attached sample project:
{code}
12:48:35,699 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Real: name=vfs:///opt/src/jboss-6.0.0.Final/server/default/deploy/02-startup.ear state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error during deploy: org.jboss.metadata.ejb.jboss.JBossEnterpriseBeanMetaData.StartupBean
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:185) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1603) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.GA]
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.GA]
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0.Final]
at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.2.2]
at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:57) [:0.2.2]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.2.2]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:95) [:0.2.2]
at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.2.2]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_22]
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0_22]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0_22]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0_22]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) [:1.6.0_22]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) [:1.6.0_22]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_22]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_22]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_22]
Caused by: java.lang.RuntimeException: Could not resolve @EJB reference: [EJB Reference: beanInterface 'com.example.services.version.VersionManager', beanName 'null', mappedName 'null', lookupName 'null', owning unit 'ComponentDeploymentContext(a)10824652{org.jboss.metadata.ejb.jboss.JBossEnterpriseBeanMetaData.StartupBean}'] for environment entry: env/ejb/VersionManager in unit ComponentDeploymentContext(a)10824652{org.jboss.metadata.ejb.jboss.JBossEnterpriseBeanMetaData.StartupBean}
at org.jboss.ejb3.jndi.deployers.resource.provider.AnnotatedEJBRefResourceProvider.provide(AnnotatedEJBRefResourceProvider.java:99) [:0.1.7]
at org.jboss.ejb3.jndi.deployers.resource.provider.AnnotatedEJBRefResourceProvider.provide(AnnotatedEJBRefResourceProvider.java:50) [:0.1.7]
at org.jboss.switchboard.mc.JndiEnvironmentProcessor.process(JndiEnvironmentProcessor.java:68) [:1.0.0-alpha-15]
at org.jboss.switchboard.mc.deployer.AbstractSwitchBoardDeployer.process(AbstractSwitchBoardDeployer.java:119) [:1.0.0-alpha-15]
at org.jboss.switchboard.mc.deployer.EJBEnvironmentSwitchBoardDeployer.internalDeploy(EJBEnvironmentSwitchBoardDeployer.java:87) [:1.0.0-alpha-15]
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.GA]
... 39 more
{code}
I hope it won't be too hard to fix it.
Cheers,
/Benoit
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (JGRP-1288) FD_SOCK ignores port_range when opening server sockets
by Manuel Dominguez Sarmiento (JIRA)
FD_SOCK ignores port_range when opening server sockets
------------------------------------------------------
Key: JGRP-1288
URL: https://issues.jboss.org/browse/JGRP-1288
Project: JGroups
Issue Type: Bug
Affects Versions: 2.12
Reporter: Manuel Dominguez Sarmiento
Assignee: Bela Ban
Priority: Minor
FD_SOCK.startServerSocket() calls Util.createServerSocket(), which does not take into account a port_range. The docs for FD_SOCK state that port_range applies both for client and server socket ports. The configured value should be used instead of incrementing the port number until a free port can be bound to.
Also, the port number keeps incrementing - there's no check for MAX_PORT i.e. 65535 which could mean this could loop forever, unless an IOException is thrown before because of an invalid port number, but I don't know whether this is specified anywhere.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[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
13 years, 4 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
13 years, 4 months