April 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3630) JMSTransportSupport is not portable across different JMS providers.

by Darran Lofthouse (JIRA)

JMSTransportSupport is not portable across different JMS providers. ------------------------------------------------------------------- Key: JBAS-3630 URL: http://jira.jboss.com/jira/browse/JBAS-3630 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: JBossAS-4.0.4.GA Reporter: Darran Lofthouse Assigned To: Thomas Diesler Fix For: JBossAS-4.0.6.CR1 JMSTransportSupport is not portable across different JMS providers, the queue name is retrieved using the following code: - String fromName = null; Destination destination = message.getJMSDestination(); if (destination instanceof Queue) fromName = "queue/" + ((Queue)destination).getQueueName(); if (destination instanceof Topic) fromName = "topic/" + ((Topic)destination).getTopicName(); For JBossMQ this is fine and it results in a name that matches the JNDI name of the queue, for WebSphereMQ this returns the name of the queue as configured on WebSphere not the JNDI name the queue is bound to in JBoss. The Javadoc for Queue describes the getQueueName as not being suitable for portable clients: - http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Queue.html A more portable solution could be to lookup a variable in the ENC that contains the name of the web service, this could either be provided by the user deploying the MDB or the web service deployer could bind a value to the ENC of the message driven bean as the web service is deployed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-7953) Incorrect parsing of jboss-service.xml

by Pavel Macik (JIRA)

Incorrect parsing of jboss-service.xml -------------------------------------- Key: JBAS-7953 URL: https://jira.jboss.org/jira/browse/JBAS-7953 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: System service Affects Versions: JBossAS-5.1.0.GA Reporter: Pavel Macik Assignee: Dimitris Andreadis n the server/<config>/conf/jboss-service.xml file there is mbean's attributes configured as following: <server> <mbean ... name="jboss:service=Naming" ...> ... <attribute name="BindAddress"> <value-factory bean="ServiceBindingManager" method="getStringBinding"> <parameter>jboss:service=Naming</parameter> <parameter>Port</parameter> <parameter><null/></parameter> </value-factory> </attribute> ... </mbean> ... </server> This exact configuration is fine. But while I change element formatting as follows, the </null> parameter parsing fails. ... <attribute name="BindAddress"> <value-factory bean="ServiceBindingManager" method="getStringBinding"> <parameter>jboss:service=Naming</parameter> <parameter>Port</parameter> <parameter> <null/> </parameter> </value-factory> </attribute> ... It seems the parser that parses this file doesn't ignore white-spaces around the <null/> element and the mbean behaves in different way. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBBUILD-550) Setting up test configs

by Paul Gier (JIRA)

Setting up test configs ----------------------- Key: JBBUILD-550 URL: https://jira.jboss.org/jira/browse/JBBUILD-550 Project: JBoss Build System Issue Type: Task Components: Sonatype Reporter: Paul Gier >From Max's email: When we run hibernate testsuite we today configure every run by having a <profile> section. Each profile setup its own dependencies (i.e. jars for the classpath) and properties used in interpolation of files like hibernate.properties. This works pretty well and even works good with IDE's since you can just do: mvn -Pdb2 test then maven will generate the right hibernate.properties and run the tests. Then in your IDE (eclipse, netbeans, intellij, whatever) can just use the generated hibernate.properties file and pickup the jars. Nice and simple. The downsides of this are: A) To test a custom config you have to edit the pom.xml which becomes tedious when that file is under svn and thus becomes dirty even though you haven't really changed anything in here. B) There is not a clean way of having downstream adopters use our testsuite to run the testsuite. A could be solved in a couple of ways: 1) create a "custom" profile which will pick up settings from lets say "custom.properties" to get the connection information. But then we would be missing the jar dependencies. 2) Another way would by being able to have profiles stored external to the pom.xml. Steve mentioned profiles.xml being discussed at some point to allow for this. 3) create a separate project per testsetup, but then we bump into other issues: - surefire not being able to run tests based of tests in a jar. Not even when explicitly naming the class. - Having a test subclass per config is also not scalable since it would just be tons and tons of boilerplate code with zero differences in plus without the easy "build project + dependencies" this becomes hard to maintain. - And finally when it is a separate project it becomes cumbersome to run this easily from an IDE (the test class is in separate location, and so is the hibernate.properties) - No way of overriding hibernate.properties since additional classpath entries are *appended* not *prepended* to the classpath when running tests. B) could also be solved with the profiles.xml option or separate project - but have similar issues as described above. I hope that put some more light on the issues ? Let me know if it makes sense/nonsense. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-6589) Client pom describing runtime and compile time dependencies for the profile service

by Pete Muir (JIRA)

Client pom describing runtime and compile time dependencies for the profile service ----------------------------------------------------------------------------------- Key: JBAS-6589 URL: https://jira.jboss.org/jira/browse/JBAS-6589 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: ProfileService Reporter: Pete Muir Assignee: Emanuel Muckenhuber -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-6697) provide API in DeploymentManager for specifying which dir the file should be deployed to (e.g. to deploy to farm dir, rather than deploy dir)

by Ian Springer (JIRA)

provide API in DeploymentManager for specifying which dir the file should be deployed to (e.g. to deploy to farm dir, rather than deploy dir) --------------------------------------------------------------------------------------------------------------------------------------------- Key: JBAS-6697 URL: https://jira.jboss.org/jira/browse/JBAS-6697 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: ProfileService Reporter: Ian Springer Assignee: Emanuel Muckenhuber -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

4
10
0 / 0

[JBoss JIRA] Created: (JBAS-6680) Extract Profile Service into its own project

by Jesper Pedersen (JIRA)

Extract Profile Service into its own project -------------------------------------------- Key: JBAS-6680 URL: https://jira.jboss.org/jira/browse/JBAS-6680 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: ProfileService Reporter: Jesper Pedersen Assignee: Scott M Stark Fix For: JBossAS-6.0.0.Alpha1 Extract the profiler service out of the application server repository into its own project. That way other projects can depend on it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-6070) Need an overview of the profile service in the 5.0 docs

by Scott M Stark (JIRA)

Need an overview of the profile service in the 5.0 docs ------------------------------------------------------- Key: JBAS-6070 URL: https://jira.jboss.org/jira/browse/JBAS-6070 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Docs/Administration and Configuration Guide, Docs/Clustering Guide, Docs/Installation and Getting Started Guide Reporter: Scott M Stark Assignee: Scott M Stark Fix For: JBossAS-5.0.0.GA There is no mention of the profile service as an abstraction over the 4.x and earlier file system structure in the current guides. It needs to be emphasized that the file system based server profiles will be changing and that edits via the profile service management view will obsolete the original file system deployment content. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

4
8
0 / 0

[JBoss JIRA] Created: (JBAS-5990) ProfileService Repository

by Scott M Stark (JIRA)

ProfileService Repository ------------------------- Key: JBAS-5990 URL: https://jira.jboss.org/jira/browse/JBAS-5990 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: ProfileService Reporter: Scott M Stark Assignee: Scott M Stark Fix For: JBossAS-5.1.0.CR1 We need to make the profile service repository a proper external spi that can be used during bootstrap, offline operation, ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

3
8
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1797) JBm queue conflict in a cluster environment.

by Marek Baluch (JIRA)

JBm queue conflict in a cluster environment. -------------------------------------------- Key: JBMESSAGING-1797 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1797 Project: JBoss Messaging Issue Type: Bug Components: JMS Clustering Affects Versions: 1.4.6.GA Reporter: Marek Baluch Priority: Critical First server starts no problem, but during the second server startup I see the following exception in log: 2010-04-02 10:05:09,668 ERROR [org.jboss.messaging.util.ExceptionUtil] (main) Queue[null, name=B] startService java.lang.IllegalStateException: Channel id map for node 2 already contains binding for queue 5 at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.addBindingInMemory(MessagingPostOffice.java:2543) at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.internalAddBinding(MessagingPostOffice.java:1980) at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.addBinding(MessagingPostOffice.java:470) at org.jboss.jms.server.destination.QueueService.startService(QueueService.java:126) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:322) at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:189) at $Proxy38.start(Unknown Source) at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42) at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37) at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.system.ServiceController.doChange(ServiceController.java:688) at org.jboss.system.ServiceController.start(ServiceController.java:460) at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163) at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99) at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46) at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171) at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179) at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782) at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702) at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117) at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70) at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53) at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:403) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540) at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:308) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java: at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461) at org.jboss.Main.boot(Main.java:221) at org.jboss.Main$1.run(Main.java:556) at java.lang.Thread.run(Thread.java:619) All jBPM queues have their "Clustered" attribute set to "true" and ServerPeerID's are different. Each instance in the cluster uses it's own database schema. Dependencies on "PostOffice" service are defined for each queue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-7046) Support CDI injection into managed Servlet objects

by Pete Muir (JIRA)

Support CDI injection into managed Servlet objects -------------------------------------------------- Key: JBAS-7046 URL: https://jira.jboss.org/jira/browse/JBAS-7046 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Pete Muir Fix For: JBossAS-5.2.0.Beta1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

6
17
0 / 0

[JBoss JIRA] Created: (JBWEB-143) ThreadName in AccessLogValve

by Vijayanandraj Amaladoss (JIRA)

ThreadName in AccessLogValve ----------------------------- Key: JBWEB-143 URL: https://jira.jboss.org/jira/browse/JBWEB-143 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Affects Versions: JBossWeb-2.0.0.GA Environment: Jboss 4.2 GA EAP / Any operating system Reporter: Vijayanandraj Amaladoss Assignee: Remy Maucherat Writing the thread name in the access log using "%I" pattern is not supported in Jboss web 2.0 GA. This is implemented in Jboss web 2.1.2 GA. Please refer to thread http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236960' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-5745) ServerMBean.InShutdown flag won't turn on when the shutdown hook is called directly

by Takayoshi Kimura (JIRA)

ServerMBean.InShutdown flag won't turn on when the shutdown hook is called directly ----------------------------------------------------------------------------------- Key: JBAS-5745 URL: http://jira.jboss.com/jira/browse/JBAS-5745 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: System service Affects Versions: JBossAS-5.0.0.CR1, JBossAS-5.0.0.Beta4, JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA, JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-5.0.0.Beta1, JBossAS-4.0.5.GA, JBossAS-4.0.4.GA Reporter: Takayoshi Kimura Assigned To: Dimitris Andreadis The ServerMBean.InShutdown flag is only turned on when the shutdown() operation is called. There is another shutdown path, a shutdown hook called by signals including Ctrl+c. This flag is needed to update in the shutdownHook.shutdown() method to reflect the sever status. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-6588) Move to HASingletonProfileActivator

by Brian Stansberry (JIRA)

Move to HASingletonProfileActivator ----------------------------------- Key: JBAS-6588 URL: https://jira.jboss.org/jira/browse/JBAS-6588 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.Alpha1 When the profile service moves to XML-based configuration, switch deploy-hasingleton to a subprofile that gets created at bootstrap but not activated. Differs from 5.1 impl which creates the subprofile when HASingletonProfileManager is deployed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-6355) ServiceBindingManager docs

by Brian Stansberry (JIRA)

ServiceBindingManager docs -------------------------- Key: JBAS-6355 URL: https://jira.jboss.org/jira/browse/JBAS-6355 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Docs/Administration and Configuration Guide Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-5.0.1.CR1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

3
10
0 / 0

[JBoss JIRA] Created: (JBAS-7709) Review beans that bind in JNDI to add a dependency on Naming

by Brian Stansberry (JIRA)

Review beans that bind in JNDI to add a dependency on Naming ------------------------------------------------------------ Key: JBAS-7709 URL: https://jira.jboss.org/jira/browse/JBAS-7709 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.M3 There are a number of services/beans that bind things in JNDI that just assume a naming server is available. This assumption is only valid because historically the local Naming server has been deployed in a "deployment phase" prior to when those services are deployed. A proper dependency should be declared to make server startup more robust. The MC name of the bean to depend on is "LocalNamingBean" but IMHO we should give it a different name or an alias. Perhaps just "LocalJNDI". "JNDI" sounds tempting but some I think the name should make clear that no remote capability exists. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-5554) Cross-cluster dependencies

by Brian Stansberry (JIRA)

Cross-cluster dependencies -------------------------- Key: JBAS-5554 URL: http://jira.jboss.com/jira/browse/JBAS-5554 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering, Deployers Reporter: Brian Stansberry Assigned To: Brian Stansberry Service B on node 2 depends on Service A on node 1. Per Scott, "Dependencies on components that are marked as @Clustered needs a cluster aware dependency implementation. Custom dependencies are supported by the mc, but the component deployers generating the component metadata have to generate the correct dependency implementation." This also ties in with the coordinated deployment issue in JBAS-5553, as we wouldn't want Service B deployment to fail on node 2 just because it happened to deploy before Service A on node 1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-5550) Clustered deployments using the ProfileService

by Brian Stansberry (JIRA)

Clustered deployments using the ProfileService ---------------------------------------------- Key: JBAS-5550 URL: http://jira.jboss.com/jira/browse/JBAS-5550 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering, ProfileService Reporter: Brian Stansberry Assigned To: Brian Stansberry Container task for work on bringing clustered deployments to the full ProfileService. Some of the subtasks will be for AS 5.0.0; others for later. See the forum reference as well as an earlier discussion at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=63437 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-5553) Coordinated cluster-wide deployment into the runtime

by Brian Stansberry (JIRA)

Coordinated cluster-wide deployment into the runtime ---------------------------------------------------- Key: JBAS-5553 URL: http://jira.jboss.com/jira/browse/JBAS-5553 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering, ProfileService Reporter: Brian Stansberry Assigned To: Brian Stansberry Once deployment repository content is synchronized across a cluster, need to add the ability to do staged deployments of updated content into the runtime. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-5555) Rationalize clustering metadata

by Brian Stansberry (JIRA)

Rationalize clustering metadata ------------------------------- Key: JBAS-5555 URL: http://jira.jboss.com/jira/browse/JBAS-5555 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering, Deployers Reporter: Brian Stansberry Assigned To: Brian Stansberry Clustering metadata is scattered in different metadata objects. Need to rationalize, particularly to support adding clustering aspects to non-JEE beans. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-5551) Provide cluster topology info to the DeploymentManager impl

by Brian Stansberry (JIRA)

Provide cluster topology info to the DeploymentManager impl ----------------------------------------------------------- Key: JBAS-5551 URL: http://jira.jboss.com/jira/browse/JBAS-5551 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering, ProfileService Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.CR1 DeploymentManager operations create a list of DeploymentTargets. Currently this list only includes the local node. Need to integrate cluster topology information so it can include one DeploymentTarget per node in the cluster (at least if the relevant DeploymentPhase is APPLICATION_CLUSTERED.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
6
0 / 0

[JBoss JIRA] Created: (JBAS-6933) Review HA design to inlcude Mobicents more easily

by jean deruelle (JIRA)

Review HA design to inlcude Mobicents more easily ------------------------------------------------- Key: JBAS-6933 URL: https://jira.jboss.org/jira/browse/JBAS-6933 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-5.1.0.CR1 Reporter: jean deruelle Assignee: Brian Stansberry Priority: Minor Change the clustering design to allow for extensibility without so much protected methods as per the JBoss Fourm thread http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4231472#4231472 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

3
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1728) Create a JTA profile for use in unit tests

by Carlo de Wolf (JIRA)

Create a JTA profile for use in unit tests ------------------------------------------ Key: EJBTHREE-1728 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1728 Project: EJB 3.0 Issue Type: Feature Request Reporter: Carlo de Wolf Assignee: Carlo de Wolf -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1232) A failing commit must not throw a RuntimeException

by Carlo de Wolf (JIRA)

A failing commit must not throw a RuntimeException -------------------------------------------------- Key: EJBTHREE-1232 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1232 Project: EJB 3.0 Issue Type: Bug Reporter: Carlo de Wolf Assigned To: Carlo de Wolf Fix For: AS 5.0.0.CR1 java.lang.RuntimeException: javax.transaction.RollbackException: [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] Can't commit because the transaction is in aborted state at org.jboss.aspects.tx.TxPolicy.handleEndTransactionException(TxPolicy.java:198) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
11
0 / 0

[JBoss JIRA] Created: (JBAS-5102) Crossreferencing EJBs using comp-names does not work

by Christian Nolte (JIRA)

Crossreferencing EJBs using comp-names does not work ---------------------------------------------------- Key: JBAS-5102 URL: http://jira.jboss.com/jira/browse/JBAS-5102 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-4.2.2.GA Reporter: Christian Nolte Assigned To: Carlo de Wolf I have two stateless session beans which are referencing each other like that: @Stateless public class SessionBeanA implements SessionBeanALocal { @EJB private SessionBeanB sessionB; } and @Stateless public class SessionBeanB implement SessionBeanBLocal { @EJB private SessionBeanA sessionA; } When deploying the application on JBoss AS I get --- MBeans waiting for other MBeans --- ObjectName: jboss.j2ee:jar=test.jar,name=SessionBeanA,service=EJB3 State: NOTYETINSTALLED I Depend On: jboss.j2ee:jar=test.jar,name=SessionBeanB,service=EJB3 persistence.units:jar=test.jar,unitName=test.jar Depends On Me: jboss.j2ee:jar=test.jar,name=SessionBeanB,service=EJB3 ObjectName: jboss.j2ee:jar=test.jar,name=SessionBeanB,service=EJB3 State: NOTYETINSTALLED I Depend On: jboss.j2ee:jar=test.jar,name=SessionBeanA,service=EJB3 Depends On Me: jboss.j2ee:jar=test.jar,name=SessionBeanA,service=EJB3 and the deployment fails. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-7651) Revisit profiles that come pre-configured with AS

by Stan Silvert (JIRA)

Revisit profiles that come pre-configured with AS ------------------------------------------------- Key: JBAS-7651 URL: https://jira.jboss.org/jira/browse/JBAS-7651 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: ProfileService Affects Versions: JBossAS-6.0.0.M1 Reporter: Stan Silvert Assignee: Scott M Stark Priority: Blocker Fix For: JBossAS-6.0.0.M3 We need to revisit the profiles that come pre-configured with AS. The goal is to provide a robust set of profiles that cover the needs of most users out of the box. Right now we have: minimal - total bare bones default - what most people use, but you have to do stuff like secure the consoel before production standard - as far as I know, this is only for JEE certification? web - just web stuff with JTA, JCA and JPA all - everything we can throw in, but mostly used for clustering I think something like the following would better suit most user's needs. This satisfies the emerging requirement to have profiles that are useful to development and production: minimal - same as before web - JEE web profile standard - I guess we still need this? development - no admin console and less logging - super-fast boot time - (JSF2 PROJECT_STAGE set to "Development") production - includes admin console - secure - (JSF2 PROJECT_STAGE set to "Production") clustered development - same as development, but with clustered services available clustered production - same as production, but with clustered services available Also see http://community.jboss.org/message/521946#521946 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-7535) Handle nested transactions in transaction-sticky load balance policies

by Brian Stansberry (JIRA)

Handle nested transactions in transaction-sticky load balance policies ---------------------------------------------------------------------- Key: JBAS-7535 URL: https://jira.jboss.org/jira/browse/JBAS-7535 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.CR1 If the client creates a nested transaction, ClientUserTransactionStickyInterceptor doesn't detect that the TransactionPropagationContext has changed following the response, and thus doesn't associate the target with the new TPC. Effect is the new TPC is not sticky. One possibility is to throw NotSupportedTransaction if we detect a nested transaction. But from a quick look at this code, it seems easier to support nested transactions than to throw NotSupportedTransaction. Is it as simple as detecting if the TPC changes from before and after the invocation and storing the target if it has? public class ClientUserTransactionStickyInterceptor extends AbstractTransactionStickyInterceptor { @Override public Object invoke(Invocation invocation) throws Throwable { putIfExistsTransactionTarget(invocation); Object existingTPC = getTransactionPropagationContext(); // NEW Object response = getNext().invoke(invocation); invocationHasReachedAServer(invocation, response, existingTPC); //NEW return response; } public void invocationHasReachedAServer(Invocation invocation, Object response, Object existingTPC) { Object tpc = getTransactionPropagationContext(); if (tpc == null || tpc.equals(existingTPC) == false) // NEW { /* If tpc is null when invoking a UserTransaction operation, begin() * is being called, so we remember the target where the transaction * was started. */ rememberTransactionTarget(invocation, response); } } } I don't much like detecting the nested transaction in advance and throwing an exception. Certainly not if we *can* support nested transactions; in that case it's not the interceptors place to decide what the server allows. AFAICT throwing an exception would require doing something ugly like this on every call Object existingTPC = getTransactionPropagationContext(); if (existingTPC != null && ("begin".equals(invocation.getMethod().getName()) && invocation.getMethod().getDeclaringClass().equals(UserTransaction.class)) { throw new NotSupportedTransaction("blah blah blah"); } putIfExistsTransactionTarget(invocation); Object response = getNext().invoke(invocation); invocationHasReachedAServer(invocation, response); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2449) OSGi like ClassLoader problem

by Jacopo Torrini (JIRA)

OSGi like ClassLoader problem ----------------------------- Key: JBRULES-2449 URL: https://jira.jboss.org/jira/browse/JBRULES-2449 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.0.1.FINAL Environment: kubuntu 9.10 Reporter: Jacopo Torrini Assignee: Mark Proctor Suppose that we have a OSGi like environment, (a system made of plugins, each of them istantiated in a separated classloader. Each classloader has dependencies on other plugin-classloaders). Suppose that you have a bundle (plugin) that owns the domain model, another bundle with drools and rules on that domain model. The second plugin depends on the first. If you try to load the drools rules, drools throws a NoDefClassFoundError for the class org.drools.base.extractors.BaseObjectClassFieldReader. Investigating on code, I've found that the problem resides on the classloader used to define the pseudoclass that extract field value. In class org.drools.base.ClassFieldAccessorFactory, line 135, a ByteClassLoader is used to define the new class, but that byteclassloader uses the domain object classloader as parent classloader. In fact this byteclassloader is created by CacheEntry that is initialized with the domain object classloader, as you can see in line 275 of ClassFieldAccessorCache. At this point, because the field extractor is defined as a subclass of BaseObjectClassFieldReader defined in drools library, the domain object classloader is unable to find that class and throw the exception metioned above. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-5197) Add "RetryInterceptor" functionality to all clustered proxies

by Brian Stansberry (JIRA)

Add "RetryInterceptor" functionality to all clustered proxies ------------------------------------------------------------- Key: JBAS-5197 URL: http://jira.jboss.com/jira/browse/JBAS-5197 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.1.0.CR1 Container issue for ensuring "RetryInterceptor" functionality is added to all clustered proxies. "RetryInterceptor" functionality consists of adding an interceptor that is able to access the cluster (currently via JNDI) and get an updated set of cluster targets when all current targets have failed. Needed when a complete cluster restart has occurred since the current list of targets was deserialized on the client. We currently have this for EJB2 proxies; need it for EJB3, HA-JNDI and generic AOP-based and ProxyFactoryHA-based proxies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

4
9
0 / 0

[JBoss JIRA] Created: (JBAS-6144) Resolve intermittent org.jboss.test.cluster.defaultcfg.web.test.ScopedSetAttributeTestCase(Default-udp).testInvalidate failure

by Brian Stansberry (JIRA)

Resolve intermittent org.jboss.test.cluster.defaultcfg.web.test.ScopedSetAttributeTestCase(Default-udp).testInvalidate failure ------------------------------------------------------------------------------------------------------------------------------ Key: JBAS-6144 URL: https://jira.jboss.org/jira/browse/JBAS-6144 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-5.0.1.CR1 This test intermittently fails. The web clustering tests in the default REPL_ASYNC config can occasionally fail due to timing, where the test fails over to the other cluster node before the replicated session arrives. There is a 200 ms delay before failover, but occasional bad luck (e.g. a full gc at wrong time) can make that too short. (Making it longer makes the whole testsuite longer.) But, this issue should cause random failures, whereas this particular test seems to pop up as a failure a high percentage of the time. Need to understand why. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

4
7
0 / 0

[JBoss JIRA] Created: (JBAS-5819) Don't call expire when processing remote invalidation of clustered session

by Brian Stansberry (JIRA)

Don't call expire when processing remote invalidation of clustered session -------------------------------------------------------------------------- Key: JBAS-5819 URL: https://jira.jboss.org/jira/browse/JBAS-5819 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-5.0.0.CR2, JBossAS-4.2.4.GA When JBC notifies JBossCacheManager that the root node for a session has been invalidated via a remote call, JBMC.processRemoteInvalidation() calls Session.expire on the local session (if there is one). The expire call includes flags that result in no notifications being sent to any listeners. I don't see any point to this expire call if there are no notifications. The other work expire does is removing content from JBC, but the remote invalidation that triggers all this is already removing that content. Just drop the session from the local session map. Perhaps flag the session so if there is a concurrency/sticky-session problem and a local request thread is handling the session it knows the session is invalid. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-6450) Embedded work

by Scott M Stark (JIRA)

Embedded work ------------- Key: JBAS-6450 URL: https://jira.jboss.org/jira/browse/JBAS-6450 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: MicroContainer bus, ProfileService, System service Reporter: Scott M Stark Assignee: Scott M Stark Fix For: JBossAS-6.0.0.Alpha1 A containing task for work to unify the server bootstrap with JBossAS embedded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-6562) Context entries don't work as explained in tomcat docs.

by Vicky Kak (JIRA)

Context entries don't work as explained in tomcat docs. ------------------------------------------------------- Key: JBAS-6562 URL: https://jira.jboss.org/jira/browse/JBAS-6562 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Web (Tomcat) service Reporter: Vicky Kak Assignee: Vicky Kak Fix For: JBossAS-5.1.0.Beta1, JBossAS-4.2.4.GA The documentation about the context configuration in Tomcat does not work in JbossAS deployments. I have just spend some time looking at the related code at http://anonsvn.jboss.org/repos/jbossas/branches/JBPAPP_4_2/tomcat/src/mai... Here is the code snippet **************************************************************** private String findConfig(URL warURL) throws IOException { String result = null; // See if the warUrl is a dir or a file File warFile = new File(warURL.getFile()); if (warURL.getProtocol().equals("file") && warFile.isDirectory() == true) { File webDD = new File(warFile, CONTEXT_CONFIG_FILE); if (webDD.exists() == true) result = webDD.getAbsolutePath(); } else { ZipFile zipFile = new ZipFile(warFile); ZipEntry entry = zipFile.getEntry(CONTEXT_CONFIG_FILE); if (entry != null) { InputStream zipIS = zipFile.getInputStream(entry); byte[] buffer = new byte[512]; int bytes; result = warFile.getAbsolutePath() + "-context.xml"; FileOutputStream fos = new FileOutputStream(result); while ((bytes = zipIS.read(buffer)) > 0) { fos.write(buffer, 0, bytes); } zipIS.close(); fos.close(); } zipFile.close(); } return result; } **************************************************************** This code needs to be modified in such a way that it uses these configurations ************************************************************************************** 1. in the $CATALINA_HOME/conf/[enginename]/[hostname]/context.xml.default file: the Context element information will be loaded by all webapps of that host 2. in individual files (with a ".xml" extension) in the $CATALINA_HOME/conf/[enginename]/[hostname]/ directory. The name of the file (less the .xml) extension will be used as the context path. Multi-level context paths may be defined using #, e.g. context#path.xml. The default web application may be defined by using a file called ROOT.xml. 3. if the previous file was not found for this application, in an individual file at /META-INF/context.xml inside the application files inside a Host element in the main conf/server.xml ************************************************************************************** The point[3] is already rejected earlier by Scott, here is the related jira https://jira.jboss.org/jira/browse/JBAS-2290 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

4
7
0 / 0

[JBoss JIRA] Created: (JBAS-6521) Remove deprecated deploy/undeploy(Deployment) from Legacy MainDeployer(MBean)

by Adrian Brock (JIRA)

Remove deprecated deploy/undeploy(Deployment) from Legacy MainDeployer(MBean) ----------------------------------------------------------------------------- Key: JBAS-6521 URL: https://jira.jboss.org/jira/browse/JBAS-6521 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: ProfileService Reporter: Adrian Brock Assignee: Emanuel Muckenhuber Fix For: JBossAS-6.0.0.Alpha1 Remove the depreacted deploy/undeploy(Deployment) from the legacy MainDeployer(MBean). These methods have been added because currently the ProfileService doesn't let me setup a profile to reproduce the problem in JBAS-6518 This requires that it is the VFSContext part that has the spaces in the path. Once this is possible, the SpacesUnitTestCase needs to reworking to use the profile service as originally intended. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

3
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2246) Several random MVEL related errors while using drools.

by Rajesh Nair (JIRA)

Several random MVEL related errors while using drools. ------------------------------------------------------ Key: JBRULES-2246 URL: https://jira.jboss.org/jira/browse/JBRULES-2246 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.7 Environment: Unix Reporter: Rajesh Nair Assignee: Mark Proctor We are getting several MVEL related exceptions while running a batch program that is multi-threaded. Sometimes the bean name gets corrupted and it complains about ClassNotFoundException. Sometimes, it complains that a specific property is not found. When we restart the batch program, the problem goes away. Is there a way to fix this? We are using JDK 1.5 and the mvel jar version is mvel-1.3.1-java1.4.jar. If this jar will not work with drools 4.0.7, please suggest the upgrade path. In the worst case, we can use Java dialect. However, all our rules are created via the BRMS. So, how do you force the BRMS to use Java dialect? Thanks, Rajesh Here is a sample stacktrace. rg.drools.RuntimeDroolsException: Exception executing predicate eval( (field1 + field2 + field3) <= 0 ) at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:216) at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137) at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:318) at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:162) at org.drools.reteoo.Rete.assertObject(Rete.java:175) at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:192) at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:71) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:911) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:883) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:684) at org.drools.reteoo.ReteooStatelessSession.executeWithResults(ReteooStatelessSession.java:198) at walgreens.pbs.ruleengine.worker.RulesetExecutor.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:803) Caused by: org.mvel.PropertyAccessException: unable to resolve property: field2 (where field2 is the name of the property) at org.mvel.optimizers.impl.asm.ASMAccessorOptimizer.compileAccessor(ASMAccessorOptimizer.java:267) at org.mvel.optimizers.impl.asm.ASMAccessorOptimizer.optimizeAccessor(ASMAccessorOptimizer.java:163) at org.mvel.ASTNode.getReducedValueAccelerated(ASTNode.java:186) at org.mvel.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:21) at org.mvel.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:21) at org.mvel.ExecutableAccessor.getValue(ExecutableAccessor.java:45) at org.mvel.ast.Substatement.getReducedValueAccelerated(Substatement.java:24) at org.mvel.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:21) at org.mvel.MVELRuntime.execute(MVELRuntime.java:90) at org.mvel.CompiledExpression.getValue(CompiledExpression.java:111) at org.mvel.MVEL.executeExpression(MVEL.java:235) at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:45) at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:209) ... 14 more Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.mvel.optimizers.impl.asm.ASMAccessorOptimizer.loadClass(ASMAccessorOptimizer.java:1003) at org.mvel.optimizers.impl.asm.ASMAccessorOptimizer._initializeAccessor(ASMAccessorOptimizer.java:206) at org.mvel.optimizers.impl.asm.ASMAccessorOptimizer.compileAccessor(ASMAccessorOptimizer.java:264) ... 26 more Caused by: java.lang.LinkageError: ASMAccessorImpl_19543133401249413540370 at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:223) at java.lang.ClassLoader.defineClass(ClassLoader.java:162) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-7721) Hot deployment scanning only enabled for profiles activate at initial startup

by Brian Stansberry (JIRA)

Hot deployment scanning only enabled for profiles activate at initial startup ----------------------------------------------------------------------------- Key: JBAS-7721 URL: https://jira.jboss.org/jira/browse/JBAS-7721 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ProfileService Affects Versions: JBossAS-6.0.0.M1 Reporter: Brian Stansberry Assignee: Scott M Stark See http://community.jboss.org/message/525556#525556 . The only place MutableProfile.enableModifiedDeploymentChecks(true) is called is as part of ProfileServiceBootstrap.start(...) This should also be handled if a profile is activated later. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-7782) EJB3 over IIOP on JBOSS5.1.0 GA

by e t (JIRA)

EJB3 over IIOP on JBOSS5.1.0 GA ------------------------------- Key: JBAS-7782 URL: https://jira.jboss.org/jira/browse/JBAS-7782 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployers, EJB3 Affects Versions: JBossAS-5.1.0.GA Environment: JBossAS 5.1.0 GA JBoss-6.0.0.20100216-M2 Windows XP Professional SUN jdk1.6.0_16 Reporter: e t Assignee: Ales Justin I encourter a problem at EJB3 over IIOP. I deploy the EJB module on JBoss 5.1.0 GA,and run the JBoss server by "run.bat -c all". It is succeed to deploy and boot the JBoss server. But I found it is no any relate naming service under JBoss CorbaNaming.It seems that the deployer no bind the EJB3 Bussiness Remote Interface to the Corbanaming service. My java code is under: EJB3 Bussiness Remote: package com.olm.ejb3; public interface HW { public String helloworld(); } EJB3 Bean Implement: package com.olm.ejb3; @javax.ejb.Remote(HW.class) @javax.ejb.Stateless(name="HWBean") public class HWBean implements HW{ public String helloworld() { return "hello,world"; } } Deployment Descriptor(jboss.xml): <jboss> <enterprise-beans> <session> <ejb-name>HWBean</ejb-name> <configuration-name>Standard Stateless SessionBean</configuration-name> <invoker-bindings> <invoker> <invoker-proxy-binding-name>iiop</invoker-proxy-binding-name> </invoker> </invoker-bindings> </session> </enterprise-beans> </jboss> what can I do for the next? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

4
7
0 / 0

[JBoss JIRA] Created: (JBRULES-1820) Exception: Input stream is not explicitly closed.

by Kris Nuttycombe (JIRA)

Exception: Input stream is not explicitly closed. ------------------------------------------------- Key: JBRULES-1820 URL: https://jira.jboss.org/jira/browse/JBRULES-1820 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 4.0.7 Environment: Java 6, Linux Reporter: Kris Nuttycombe Assignee: Mark Proctor I am using the Drools PackageBuilder to create business rules from a file. While the rules appear to function correctly, when the JVM which runs the application shuts down, an exception is thrown due to the forced closing of an unclosed stream. It looks from the stack trace like the Drools code is opening a stream using ClassLoader.getResourceAsStream which is then left unclosed and is forced close at JVM shutdown. On application server shutdown, I receive the following exception. This appears to be the result of an unclosed input stream for a system resource used by the Drools compiler. [#|2008-10-23T09:55:09.527-0600|WARNING|sun-appserver9.1|javax.enterprise.system.core.classloading|_ThreadID=22;_ThreadName=RMI TCP Connection(1197)-10.97.100.58;_RequestID=341c51d9-08de-4e67-9da1-c57375cb5f35;|Input stream has been finalized or forced closed without being explicitly closed; stream instantiation reported in following stack trace java.lang.Throwable at com.sun.enterprise.loader.EJBClassLoader$SentinelInputStream.<init>(EJBClassLoader.java:1169) at com.sun.enterprise.loader.EJBClassLoader$InternalJarURLConnection.getInputStream(EJBClassLoader.java:1262) at java.net.URL.openStream(URL.java:1009) at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1161) at com.sun.enterprise.loader.EJBClassLoader.getResourceAsStream(EJBClassLoader.java:799) at org.drools.rule.PackageCompilationData$PackageClassLoader.getResourceAsStream(PackageCompilationData.java:384) at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.isPackage(EclipseJavaCompiler.java:280) at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:222) at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:204) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:97) at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:43) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveUnresolvedType(BinaryTypeBinding.java:138) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.superclass(BinaryTypeBinding.java:936) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.getExactMethod(BinaryTypeBinding.java:724) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.getExactMethod(BinaryTypeBinding.java:727) at org.eclipse.jdt.internal.compiler.lookup.Scope.findExactMethod(Scope.java:761) at org.eclipse.jdt.internal.compiler.lookup.Scope.getMethod(Scope.java:2002) at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:384) at org.eclipse.jdt.internal.compiler.ast.ReturnStatement.resolve(ReturnStatement.java:220) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:432) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:190) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:403) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1047) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1094) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:353) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:596) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:411) at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:351) at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:51) at org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:342) at org.drools.compiler.DialectRegistry.compileAll(DialectRegistry.java:60) at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:308) at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:167) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-6983) Error configuring property: sessionIdAlphabet for WarDeployer

by Manuel Aznar Perez (JIRA)

Error configuring property: sessionIdAlphabet for WarDeployer ------------------------------------------------------------- Key: JBAS-6983 URL: https://jira.jboss.org/jira/browse/JBAS-6983 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Affects Versions: JBossAS-5.1.0.GA, JBossAS-5.0.1.GA Environment: JBoss 5.0.1.GA or JBoss 5.1.0.GA Reporter: Manuel Aznar Perez Assignee: Remy Maucherat Priority: Minor At "server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml" when i uncomment "<property name="sessionIdAlphabet">" and run JBoss. Launch exception: 2009-05-28 08:34:34,670 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Configured: name=WarDeployer state=Instantiated java.lang.RuntimeException: Error configuring property: sessionIdAlphabet for WarDeployer at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112) at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85) at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:44) at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540) at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121) at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51) at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171) at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178) at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781) at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702) That is because don't have "jboss-web-service.jar" in deployer. This jar is in "deploy/jbossweb.sar". This is fixed copy jar file to deployer directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

4
8
0 / 0

[JBoss JIRA] Created: (JBAS-7578) Clean up UnifiedInvokerHAProxy handling of GenericClusteringException

by Brian Stansberry (JIRA)

Clean up UnifiedInvokerHAProxy handling of GenericClusteringException --------------------------------------------------------------------- Key: JBAS-7578 URL: https://jira.jboss.org/jira/browse/JBAS-7578 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: JBossAS-6.0.0.M2 The invoke method includes GCE handling logic twice; first in handling GCE as a type response value and then in a catch block. Just throw the response value GCE and let the catch block handle all cases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-7579) UnifiedInvokerHAProxy does not always record that invocation has reached a server

by Brian Stansberry (JIRA)

UnifiedInvokerHAProxy does not always record that invocation has reached a server --------------------------------------------------------------------------------- Key: JBAS-7579 URL: https://jira.jboss.org/jira/browse/JBAS-7579 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-6.0.0.M1 Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: JBossAS-6.0.0.M2 This class uses the invocationHasReachedAServer() method to ensure transactions stickiness is maintained. In some cases the method isn't called, generally in catch blocks where the caught exception is rethrown. The method should be called even though the exception is going to be thrown, because the client application may catch and handle the exception and not abort any ongoing transaction. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2236) Is MVEL upgrade for Drools 4.0.7 available?

by Jayanth Seshadri (JIRA)

Is MVEL upgrade for Drools 4.0.7 available? ------------------------------------------- Key: JBRULES-2236 URL: https://jira.jboss.org/jira/browse/JBRULES-2236 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.7 Environment: UNIX Reporter: Jayanth Seshadri Assignee: Mark Proctor We are using Drools 4.0.7 which ships with the mvel-1.3.1-java1.4.jar dependency. At times, we get the following MVEL error (stack trace below) and the Rule Engine skips processing some records. However, during a second run with the same data set we do not get the same error. What we would like to know is if there is a way to upgrade the MVEL jar in Drools 4.0.7? Please see stack trace below: at org.mvel.MVELRuntime.execute(MVELRuntime.java:90) at org.mvel.CompiledExpression.getValue(CompiledExpression.java:111) at org.mvel.MVEL.executeExpression(MVEL.java:235) at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:45) at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:209) ... 16 more Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.mvel.optimizers.impl.asm.ASMAccessorOptimizer.loadClass(ASMAccessorOptimizer.java:1003) at org.mvel.optimizers.impl.asm.ASMAccessorOptimizer._initializeAccessor(ASMAccessorOptimizer.java:206) at org.mvel.optimizers.impl.asm.ASMAccessorOptimizer.compileAccessor(ASMAccessorOptimizer.java:264) ... 31 more Caused by: java.lang.LinkageError: ASMAccessorImpl_1246513741246377473850 at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:223) at java.lang.ClassLoader.defineClass(ClassLoader.java:162) ... 37 more Jun 30, 2009 10:57:53 AM walgreens.pbs.ruleengine.worker.RulesetExecutor run WARNING: Exception caught while processing data from row 150001 to 155000 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-7862) Servlet can't reach JNDI standard resources

by Carlo de Wolf (JIRA)

Servlet can't reach JNDI standard resources ------------------------------------------- Key: JBAS-7862 URL: https://jira.jboss.org/jira/browse/JBAS-7862 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Reporter: Carlo de Wolf Assignee: Remy Maucherat Servlet 3.0 15.2.3 java:global[/<app-name>]/<module-name>!ROOT java:app/<module-name>!ROOT JavaEE 6 EE.5.15 java:app/AppName java:module/ModuleName -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

5
15
0 / 0

[JBoss JIRA] Created: (JBAS-7908) Re-enable the NamingServletTestCase once the naming components are integrated into jboss-web

by John Bailey (JIRA)

Re-enable the NamingServletTestCase once the naming components are integrated into jboss-web -------------------------------------------------------------------------------------------- Key: JBAS-7908 URL: https://jira.jboss.org/jira/browse/JBAS-7908 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-6.0.0.M3 Reporter: John Bailey Assignee: John Bailey Fix For: JBossAS-6.0.0.M4 The NamingServletTestCase fails because it is testing functionality that does not currently exist in jboss-web. The test are commented out now, and should be re-enabled when jboss-web correctly uses the naming components. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

3
4
0 / 0

[JBoss JIRA] Created: (JBEE-12) getRequestCookieMap() only contains sessionid

by Florian Scandella (JIRA)

getRequestCookieMap() only contains sessionid --------------------------------------------- Key: JBEE-12 URL: https://jira.jboss.org/jira/browse/JBEE-12 Project: JBoss JavaEE APIs Issue Type: Bug Components: Servlet API Affects Versions: 5.0.1.GA Environment: gentoo/linux x86_64, icedtea 1.4.1, seam 2.1.1GA, jboss 5.0.1GA java 1.6 build Reporter: Florian Scandella Assignee: Shelly McGowan i store some cookies on the client. the cookie gets transmitted by the browser (checked with firebug) but does not end up in externalcontext.getRequestCookieMap(). this map only contains the JSESSIONID. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

4
7
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1074) Circular @EJB3 references in session beans fail to deploy.

by Gunnar Grim (JIRA)

Circular @EJB3 references in session beans fail to deploy. ---------------------------------------------------------- Key: EJBTHREE-1074 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1074 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.1.GA Reporter: Gunnar Grim The following circular references makes the application undeployable: In ArchiveBrokerBean: @EJB private SeriesBrokerLocal itsSeriesBroker; In SeriesBrokerBean @EJB private ArchiveBrokerLocal itsArchiveBroker; Circular references like these work fine in Glassfish but JBoss shows the following error message: ObjectName: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveBroker,service=EJB3 State: NOTYETINSTALLED I Depend On: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=SeriesBroker,service=EJB3 jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveTypeBroker,service=EJB3 persistence.units:ear=klara5.ear,jar=klara5.jar,unitName=KlaraPU Depends On Me: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveOrigBroker,service=EJB3 jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=SeriesBroker,service=EJB3 ObjectName: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveOrigBroker,service=EJB3 State: NOTYETINSTALLED I Depend On: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveBroker,service=EJB3 persistence.units:ear=klara5.ear,jar=klara5.jar,unitName=KlaraPU ObjectName: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=SeriesBroker,service=EJB3 State: NOTYETINSTALLED I Depend On: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveBroker,service=EJB3 persistence.units:ear=klara5.ear,jar=klara5.jar,unitName=KlaraPU Depends On Me: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveBroker,service=EJB3 jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=VolumeBroker,service=EJB3 ObjectName: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=VolumeBroker,service=EJB3 State: NOTYETINSTALLED I Depend On: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=SeriesBroker,service=EJB3 persistence.units:ear=klara5.ear,jar=klara5.jar,unitName=KlaraPU -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

10
11
0 / 0

[JBoss JIRA] Created: (JGRP-747) RELAY: replication between data centers

by Bela Ban (JIRA)

RELAY: replication between data centers --------------------------------------- Key: JGRP-747 URL: http://jira.jboss.com/jira/browse/JGRP-747 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.x [from JGroups/doc/design/DataCenterReplication.txt] Replication between data centers ================================ Author: Bela Ban Version: $Id: DataCenterReplication.txt,v 1.6 2008/04/25 15:54:30 belaban Exp $ We have data centers in New York (NYC) and San Francisco (SFO). The idea is to replicate traffic from NYC to SFO asynchronously. In case of a site failure of NYC, all clients can be switched over to SFO and continue working with (almost) up-to-date data. The failing over of clients to SFO is outside the scope of this proposal, and could be done for example by changing DNS entries, load balancers etc. There is no replication going on from SFO to NYC by default, only when SFO becomes the primary site. The assumption is that there is no message between data centers which requires a response. This would require NAT functionlity, which we may provide in a future version. For the example, we assume that each site uses a UDP based stack, and replication between the sites use a TCP based stack, see figure DataCenterReplication.png. There is a local cluster, based on UDP, at each site and one global cluster, based on TCP, which connects the two sites. Each coordinator of the local cluster is also a member of the global cluster, e.g. member E in NYC (assuming it is the coordinator) is also member X of the TCP cluster. This is called a *relay* member. A relay member is always member of the local and global cluster. A relay member has a UDP stack which additionally contains a protocol RELAY at the top (shown in the bottom part of the figure). RELAY has a JChannel which connects to the TCP group, but *only* when it is (or becomes) coordinator of the local cluster. The configuration of the TCP channel is done via a property in RELAY. Any *multicast* message (we don't relay unicast messages) that is received by RELAY traveling up the stack is sent via the TCP channel to the other site. When received there, the corresponding RELAY protocol changes the destination of the message to null (those are multicast messages after all) and leaves the src (which might point to X if sent from NYC), then it sends the message down the stack, where it will get multicast to all members of the local cluster (including the sender). When a response is received which points to any non-local address (e.g. X), RELAY simply drops it. When forwarding a message to the local cluster, RELAY adds a header. When it receives the multicast message it forwarded itself, and a header is present, it does *not* relay it back to the other site but simply drops it. Otherwise, we would have a cycle. When a coordinator crashes or leaves, the next-in-line becomes coordinator and activates the RELAY protocol, connecting to the TCP channel and starting to relay messages. However, if we receive messages from the local cluster while the coordinator has crashed and the new one hasn't taken over yet, we'd lose messages. Therefore, we need additional functionality in RELAY which buffers the last N messages (or M bytes, or for T seconds) and numbers all messages sent. This is done by the second-in-line. When there is a coordinator failover, the new coordinator communicates briefly with the other site to determine which was the highest message relayed by it. It then forwards buffered messages with lower numbers and removes the remaining messages in the buffer. During this replay, message relaying is suspended. Therefore, a relay has to handle 3 types of messages from the global (TCP) cluster: (1) Regular multicast messages (2) A message asking for the highest sequence number received from another relay, and the response to this (3) A message stating that the other side will go down gracefully (no need to replay buffered messages) Example walkthrough ------------------- - C (in the NYC cluster, with coordinator E) multicasts a message - A, B, C, D and E receive the multicast - D (second-in-line) buffer the message (bounded buffer) - E is the relay. The byte buffer is extracted and a new message M is created. M's source is C, the dest is null (= send to all). Note that the original headers are *not* sent with M. If this is needed, we need to revisit. - X receives M, drops it (because it is the sender, determined by the header). - Y receives M, adds a RELAY header and sends it down the stack - T, U, V, W and S receive M and deliver it - Y does not relay M because M has a header - Should some member reply (to X), then RELAY at Y will drop the message -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
8
0 / 0

[JBoss JIRA] Created: (SECURITY-136) jboss-web defined authenticators in JBoss 4.2.x?

by Darran Lofthouse (JIRA)

jboss-web defined authenticators in JBoss 4.2.x? ------------------------------------------------ Key: SECURITY-136 URL: http://jira.jboss.com/jira/browse/SECURITY-136 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: Negotiation Reporter: Darran Lofthouse Assigned To: Darran Lofthouse -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
6
0 / 0

[JBoss JIRA] Created: (SECURITY-358) Make logging configurable with JBoss 4.0.5.GA

by Darran Lofthouse (JIRA)

Make logging configurable with JBoss 4.0.5.GA --------------------------------------------- Key: SECURITY-358 URL: https://jira.jboss.org/jira/browse/SECURITY-358 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: Negotiation Affects Versions: Negotiation_2.0.3.GA Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Optional Fix For: Negotiation_2.0.4.GA If possible make the logging compatible with JBoss 4.0.5.GA to allow JBoss Negotation to be deployed on this AS version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1073) SessionContext.getBusinessObject(...) throws IllegalStateException on @Service EJB

by Michael McKibben (JIRA)

SessionContext.getBusinessObject(...) throws IllegalStateException on @Service EJB ---------------------------------------------------------------------------------- Key: EJBTHREE-1073 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1073 Project: EJB 3.0 Issue Type: Bug Components: EJB3 Extensions Affects Versions: AS 4.2.1.GA Reporter: Michael McKibben Calling SessionContext.getBusinessObject(...) throws an IllegalStateException within a @Service EJB. This should behave like a Stateless/Stateful EJB no? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-6994) Improve developer javadoc

by Thomas Diesler (JIRA)

Improve developer javadoc ------------------------- Key: JBAS-6994 URL: https://jira.jboss.org/jira/browse/JBAS-6994 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Other Reporter: Thomas Diesler Fix For: JBossAS-6.0.0.Alpha1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
3
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2010