March 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-4240) NameNotFoundException thrown when trying to read java:*/env context in Servlet container.

by Robert Edgecombe (JIRA)

Robert Edgecombe created AS7-4240: ------------------------------------- Summary: NameNotFoundException thrown when trying to read java:*/env context in Servlet container. Key: AS7-4240 URL: https://issues.jboss.org/browse/AS7-4240 Project: Application Server 7 Issue Type: Bug Components: Naming Affects Versions: 7.1.1.Final Environment: Windows7 Enterprise x64 Intel Core 2 Duo Oracle Java jdk1.6.0_29 Reporter: Robert Edgecombe Assignee: John Bailey We have many J2EE 1.4 apps that need to be migrated from Oracle Application Server These applications rely on configuration using Environment Entries Most of the answers to issues I have read indicate that this is done using jboss-web.xml but this is not an acceptable solutin as it requires repackaging of the deployment artifact for different servers and different environments and is therefor contrary to the spirit (and I believe the letter) of the JavaEE spec. The documentation on this capability is either hidden or missing. I was tasked with working out how to use the JBOSS tools to configure these values and have been unable to do so. I modified the quickstart helloworld example to accept a value using the @Resource annotation and attempted to set this value using jboss-cli. After several attempts to guess how to do this I modified the servlet to walk down the context tree. This servlet throws a NameNotFoundException when trying to list the bindings at: * java:comp/env * java:app/env * java:module/env I have written the servlet to perform this walk in the following contexts: * Ithe initial context * java: * java:jboss * java:comp * java:module * java:app * java:global java:global seems to be able to accept values added using jboss-cli (not surprising) java:comp, java:module and java:app seem to return some of the expected values (eg ModuleName and AppName) but throw the exception when trying to list entries under */env The initial context and java: seem to display the entries added through jboss-cli Adding a Deployment descriptor (web.xml), that provides values for these entries, results in no entries that are visible through jboss-cli or any of the contexts listed in the servlet. I then ran the following command through jboss-cli and restarted the app /profile=full/subsystem=naming/binding=\/java\:app\/jboss-as-helloworld-ear\/env\/GREETING_TEXT:add(binding-type="simple",value="RE") This resulted in the same NameNotFoundException being thrown at java:app/env when walking the initial context as has been thrown all along when listing env in java:app It also resulted in java:app appearing in the java: context but being empty. Prior to running the add command, java:app did not appear in the initial context or java: context at all. I then ran the following command through jboss-cli and restarted the app /profile=full/subsystem=naming/binding=\/java\:module\/jboss-as-helloworld-ear\/jboss-as-helloworld\/env\/GREETING_TEXT:add(binding-type="simple",value="SJM") This resulted in the same NameNotFoundException being thrown at java:module/env when walking the initial context as has been thrown all along when listing env in java:module It also resulted in java:module appearing in the java: context but being empty. Prior to running the add command, java:module did not appear in the initial context or java: context at all. My conclusion is that my commands in jboss-cli may be the appropriate ones to add the correct entries but that the servlet cannot reach the java:module/env or java:app/env contexts that should be available to it according to the javaEE6 spec. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

6
22
0 / 0

[JBoss JIRA] (AS7-3621) f:validateBean disabled="true" is lost following POST-back

by Richard Kennard (JIRA)

Richard Kennard created AS7-3621: ------------------------------------ Summary: f:validateBean disabled="true" is lost following POST-back Key: AS7-3621 URL: https://issues.jboss.org/browse/AS7-3621 Project: Application Server 7 Issue Type: Bug Reporter: Richard Kennard As discussed on FORGE-460: Richard: "I think an 'easy default' would be to just add <f:validateBean disabled="#{true}"/> to each search field. However this doesn't appear to survive POST-back (i.e. it works for one click, but then fails after that). Are you aware of this? Is it a bug? I attach a minimal test case. I'd be most grateful if you could look at it". Emmanuel: "Yes that's definitely a bug. I'd bet in the JSF engine". Pete: "Richard, could you open an AS7 bug. Assign it to Stan (or if you can't assign, ask me to)". Minimal test case attached to FORGE-460: https://issues.jboss.org/secure/attachment/12351185/emmanuel.zip -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

4
7
0 / 0

[JBoss JIRA] Created: (AS7-1044) Add ability to launch H2 console from AS7 console for standalone mode

by Pete Muir (JIRA)

Add ability to launch H2 console from AS7 console for standalone mode --------------------------------------------------------------------- Key: AS7-1044 URL: https://issues.jboss.org/browse/AS7-1044 Project: Application Server 7 Issue Type: Feature Request Reporter: Pete Muir See http://www.h2database.com/html/tutorial.html#tutorial_starting_h2_console for the console. Add ability to easily access this for the H2 datasources. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

10
10
0 / 0

[JBoss JIRA] (AS7-3332) c:catch tag apparently doesn't work when using facelets.

by Alexander Picoli (JIRA)

Alexander Picoli created AS7-3332: ------------------------------------- Summary: c:catch tag apparently doesn't work when using facelets. Key: AS7-3332 URL: https://issues.jboss.org/browse/AS7-3332 Project: Application Server 7 Issue Type: Bug Components: JSF Affects Versions: 7.0.2.Final Environment: JBoss application server running on a Windows 7 platform, inside eclipse platform. Reporter: Alexander Picoli Assignee: Stan Silvert When using the JSTL c:catch tag inside JSP pages, and I access an EL expression that throws a custom exception, the tag works fine. But when I use it with facelets, the c:catch is ignored and a HTTP500 message is sent to the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
8
0 / 0

[JBoss JIRA] Created: (AS7-974) Re-enable Embedded Arquillian Container

by Andrew Rubinger (JIRA)

Re-enable Embedded Arquillian Container --------------------------------------- Key: AS7-974 URL: https://issues.jboss.org/browse/AS7-974 Project: Application Server 7 Issue Type: Task Components: Test Suite Reporter: Andrew Rubinger Assignee: Andrew Rubinger Priority: Critical Fix For: 7.0.0.CR1 Get the Embedded container back up. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

4
4
0 / 0

[JBoss JIRA] (AS7-3403) Add TCLFilter/Context-based filter for logging confguration

by Andrei Tuzhilin (JIRA)

Andrei Tuzhilin created AS7-3403: ------------------------------------ Summary: Add TCLFilter/Context-based filter for logging confguration Key: AS7-3403 URL: https://issues.jboss.org/browse/AS7-3403 Project: Application Server 7 Issue Type: Feature Request Affects Versions: 7.1.0.CR1b Reporter: Andrei Tuzhilin JBoss AS7 logging configuration lacks logging separation options (per-deployment log file). Previously TCLFilter was used for that, now this option is gone with no acceptable replacement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
4
0 / 0

[JBoss JIRA] (JBRULES-3317) Planner should support a null planning value

by Geoffrey De Smet (Created) (JIRA)

Planner should support a null planning value -------------------------------------------- Key: JBRULES-3317 URL: https://issues.jboss.org/browse/JBRULES-3317 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-planner Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Fix For: 5.4.0.Beta1 Several users on the user mailing list have run into this, especially for task assignment use cases. Example use case: @PlanningEntity TaskAssignment assigns a Task to a @PlanningVariable Employee There are so many Tasks, that's better to not assign some Tasks for now. Current workaround: Make a Employee representing NONE, which is the only Employee instance that returns true on employee.isNone() and the score rules are written to deal with that. Technical difficulty to fix: The @PlanningVariable(s) of a @PlanningEntity with planning value null are considered to be "uninitialized". Partial uninitialized solution detection are fundamental for repeated planning (including real-time planning), because the construction heuristics need to detect which parts of the solution to intialize, but not everything because that takes to long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

5
10
0 / 0

[JBoss JIRA] (AS7-4331) Management operations for accessing transaction logs should be exposed in the web console

by Michael Musgrove (JIRA)

Michael Musgrove created AS7-4331: ------------------------------------- Summary: Management operations for accessing transaction logs should be exposed in the web console Key: AS7-4331 URL: https://issues.jboss.org/browse/AS7-4331 Project: Application Server 7 Issue Type: Bug Components: Console Affects Versions: 7.1.1.Final Reporter: Michael Musgrove Assignee: Heiko Braun Fix For: 7.1.2.Final Task AS7-925 provides CLI management operations for accessing transaction logs. We need the same information to be made available in the web console. The operations are part of the log store sub model: org.jboss.as.txn.subsystem.LogStoreAddHandler We also need to expose the attribute for switching our log store implementation: TransactionSubsystemRootResourceDefinition.USEHORNETQSTORE -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
10
0 / 0

[JBoss JIRA] (AS7-4216) Failure while deploying simple struts app

by Thomas Diesler (JIRA)

Thomas Diesler created AS7-4216: ----------------------------------- Summary: Failure while deploying simple struts app Key: AS7-4216 URL: https://issues.jboss.org/browse/AS7-4216 Project: Application Server 7 Issue Type: Bug Components: Web Reporter: Thomas Diesler Assignee: Remy Maucherat {code} 14:53:15,474 WARN [com.opensymphony.xwork2.util.FileManager] (MSC service thread 1-1) Could not create JarEntryRevision for [vfs:/content/StrutsBasics.war/WEB-INF/lib/struts2-core-2.2.3.1]!: java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) [rt.jar:1.6.0_29] at java.util.zip.ZipFile.<init>(ZipFile.java:127) [rt.jar:1.6.0_29] at java.util.jar.JarFile.<init>(JarFile.java:135) [rt.jar:1.6.0_29] at java.util.jar.JarFile.<init>(JarFile.java:99) [rt.jar:1.6.0_29] at com.opensymphony.xwork2.util.FileManager$JarEntryRevision.build(FileManager.java:307) [xwork-core-2.2.3.1.jar:2.2.3.1] at com.opensymphony.xwork2.util.FileManager.loadFile(FileManager.java:145) [xwork-core-2.2.3.1.jar:2.2.3.1] at com.opensymphony.xwork2.util.FileManager.loadFile(FileManager.java:105) [xwork-core-2.2.3.1.jar:2.2.3.1] at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.loadConfigurationFiles(XmlConfigurationProvider.java:898) [xwork-core-2.2.3.1.jar:2.2.3.1] at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.loadDocuments(XmlConfigurationProvider.java:154) [xwork-core-2.2.3.1.jar:2.2.3.1] at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.init(XmlConfigurationProvider.java:121) [xwork-core-2.2.3.1.jar:2.2.3.1] at com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:179) [xwork-core-2.2.3.1.jar:2.2.3.1] at com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:66) [xwork-core-2.2.3.1.jar:2.2.3.1] at org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:380) [struts2-core-2.2.3.1.jar:2.2.3.1] at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:424) [struts2-core-2.2.3.1.jar:2.2.3.1] at org.apache.struts2.dispatcher.FilterDispatcher.init(FilterDispatcher.java:195) [struts2-core-2.2.3.1.jar:2.2.3.1] at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:447) [jbossweb-7.0.13.Final.jar:] at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3269) [jbossweb-7.0.13.Final.jar:] at org.apache.catalina.core.StandardContext.start(StandardContext.java:3865) [jbossweb-7.0.13.Final.jar:] at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
3
0 / 0

[JBoss JIRA] Created: (JBRULES-2794) Running More Than 100 Threads Results in ArrayIndexOutOfBoundsException from Drools AbstractHashTable

by Anatoly Polinsky (JIRA)

Running More Than 100 Threads Results in ArrayIndexOutOfBoundsException from Drools AbstractHashTable ----------------------------------------------------------------------------------------------------- Key: JBRULES-2794 URL: https://jira.jboss.org/browse/JBRULES-2794 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.1.1.FINAL, FUTURE Environment: Ubuntu, Intellij / Windows XP, Eclipse Reporter: Anatoly Polinsky Assignee: Mark Proctor Unfortunately it is not a consistent behaviour, but happens quite often. This is not observed at all when running with e.g. 50 threads. java.util.concurrent.ExecutionException: org.drools.RuntimeDroolsException: Unexpected exception executing action org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction@1102fab at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) at java.util.concurrent.FutureTask.get(FutureTask.java:83) at com.jpmc.tss.admincenter.framework.workflow.stress.test.WorkflowStressTest.shouldRunFlow(WorkflowStressTest.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74) at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:82) at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:180) at org.junit.runner.JUnitCore.run(JUnitCore.java:157) at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:94) at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:192) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:64) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:115) Caused by: org.drools.RuntimeDroolsException: Unexpected exception executing action org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction@1102fab at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1473) at org.drools.common.AbstractWorkingMemory.startProcess(AbstractWorkingMemory.java:1631) at org.drools.impl.StatefulKnowledgeSessionImpl.startProcess(StatefulKnowledgeSessionImpl.java:318) at org.drools.command.runtime.process.StartProcessCommand.execute(StartProcessCommand.java:99) at org.drools.command.runtime.process.StartProcessCommand.execute(StartProcessCommand.java:38) at org.drools.persistence.session.SingleSessionCommandService.execute(SingleSessionCommandService.java:285) at org.drools.command.impl.CommandBasedStatefulKnowledgeSession.startProcess(CommandBasedStatefulKnowledgeSession.java:193) at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:191) at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:692) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:625) at org.custom.workflow.stress.test.WorkflowRunner.call(WorkflowRunner.java:18) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.ArrayIndexOutOfBoundsException: -1 at org.drools.core.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:317) at org.drools.reteoo.EntryPointNode.updateSink(EntryPointNode.java:323) at org.drools.reteoo.ObjectTypeNode.attach(ObjectTypeNode.java:303) at org.drools.reteoo.builder.PatternBuilder.attachObjectTypeNode(PatternBuilder.java:257) at org.drools.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:92) at org.drools.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:68) at org.drools.reteoo.Rete.assertObject(Rete.java:111) at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:280) at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:360) at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1471) ... 24 more -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
9
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 March 2012