January 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-3298) Deployment of POJO web service faild, if virtual server by name "default-host" does not exist.

by Tomaz Zupan (JIRA)

Tomaz Zupan created AS7-3298: -------------------------------- Summary: Deployment of POJO web service faild, if virtual server by name "default-host" does not exist. Key: AS7-3298 URL: https://issues.jboss.org/browse/AS7-3298 Project: Application Server 7 Issue Type: Bug Components: Web Services Affects Versions: 7.1.0.CR1b Environment: Windows 7, Oracle Java 1.7.02 Reporter: Tomaz Zupan Assignee: Alessio Soldano If you change the name of the virtual-sarver in web subsystem, then deployment of any POJO web service failed with the folowing message: {quote} 13:21:25,506 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014774: Service status report}} JBAS014775: New missing/unsatisfied dependencies: service jboss.web.host.default-host (missing) dependents: [service jboss.ws.port-component-link, service jboss.web.deployment.default-host./server] {quote} -- 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, 5 months

3
3
0 / 0

[JBoss JIRA] (AS7-2792) CLI doesn't show resolved multicast address for socket-binding definition like jgroups-udp or jgroups-mping

by Rostislav Svoboda (Created) (JIRA)

CLI doesn't show resolved multicast address for socket-binding definition like jgroups-udp or jgroups-mping ----------------------------------------------------------------------------------------------------------- Key: AS7-2792 URL: https://issues.jboss.org/browse/AS7-2792 Project: Application Server 7 Issue Type: Bug Components: CLI, Domain Management Affects Versions: 7.1.0.Beta1 Reporter: Rostislav Svoboda Assignee: Alexey Loubyansky Fix For: 7.1.0.CR1 Hi Alexey. CLI doesn't show resolved multicast address for socket-binding definition like jgroups-udp or jgroups-mping. I would expect to see 'resolved-multicast-address' or something similar to 'resolved-address' for interface definition. I hope management model can provide such information. If not please reassign to Brian. {code} $ bin/standalone.sh -c standalone-ha.xml -u 224.34.3.154 $ bin/jboss-admin.sh -c [standalone@localhost:9999 /] cd /socket-binding-group=standard-sockets/socket-binding=jgroups-udp [standalone@localhost:9999 socket-binding=jgroups-udp] :read-resource(include-runtime=true) { "outcome" => "success", "result" => { "bound" => false, "bound-address" => undefined, "bound-port" => undefined, "fixed-port" => false, "interface" => undefined, "multicast-address" => expression "${jboss.default.multicast.address:230.0.0.4}", "multicast-port" => 45688, "name" => "jgroups-udp", "port" => 55200 } } {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, 5 months

6
8
0 / 0

[JBoss JIRA] Created: (AS7-1264) Add schema references to standalone.xml, domain.xml, host.xml

by Gerry Matte (JIRA)

Add schema references to standalone.xml, domain.xml, host.xml ------------------------------------------------------------- Key: AS7-1264 URL: https://issues.jboss.org/browse/AS7-1264 Project: Application Server 7 Issue Type: Task Components: Domain Management Affects Versions: 7.0.0.CR1 Reporter: Gerry Matte Assignee: Brian Stansberry It appears that users of Jboss 7 will be often modifying these configuration files as they fine tune their server and when they discover how to implement new features. It seems quite surprising to me that these files do not have the schema references identified in the file header. Any good XML editor would use those references to validate changes and new entries and thereby avoid a great deal of frustration for users and those who provide support for forum issues. I realise that if jboss validated each xml file when starting up there would be performance penalty that may be unacceptable to many users. A command-line switch could be used to either turn on xml validation (if the default were that no validation is performed) or conversely to turn off xml validation if the default state was that xml validation was on. Personally I favor having a switch that turns off validation - to be used on production servers only. If the schema/dtd files were published online and referenced within the configuration xml files, future changes to the schema structure would be "enforced" upon the user community as they attemted to use an out-of-date version when upgrading to a new version of Jboss 7. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

7
13
0 / 0

[JBoss JIRA] Created: (AS7-1547) Problem starting jboss 7 with Java Service Wrapper

by andrei povodyrev (JIRA)

Problem starting jboss 7 with Java Service Wrapper -------------------------------------------------- Key: AS7-1547 URL: https://issues.jboss.org/browse/AS7-1547 Project: Application Server 7 Issue Type: Bug Components: Logging Affects Versions: 7.0.0.Final Environment: Red Hat, Windows 7 Reporter: andrei povodyrev Assignee: David Lloyd Fix For: Open To Community Problem starting jboss 7 with Java Service Wrapper We tried to upgrade Java Service Wrapper (JSW) configuration from Jboss 5 to Jboss 7. Jboss fails to start with these messages WARNING: Failed to load the specified logmodule org.jboss.logmanager:main followed by IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager") Software: Jboss-as-7.0.0-Final wrapper-windows-x86-64-3.5.10-st (Java Service Wrapper win 64 distribution) Issue: org.jboss.modules.Main generates the warning as LogManager is already initialized to java.util.logging.LogManager by the Wrapper. With jboss 7 org.jboss.logmanager.LogManager is required. Per LogManager design only one instance may exist in jvm. jboss 7 assume that it is the first in line to initialize java.util.logger.LogManager. Wrapper is the one who inits LogManager first (thus triggering primordial configuration initialization). Jboss then fails to start since it requiresits own logging implementation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

5
5
0 / 0

[JBoss JIRA] (AS7-2213) Provide an operation to retrieve the last 10 errors form the log

by Heiko Braun (Created) (JIRA)

Provide an operation to retrieve the last 10 errors form the log ---------------------------------------------------------------- Key: AS7-2213 URL: https://issues.jboss.org/browse/AS7-2213 Project: Application Server 7 Issue Type: Feature Request Components: Domain Management Reporter: Heiko Braun Assignee: Brian Stansberry Fix For: 7.1.0.CR1 -- 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, 5 months

8
31
0 / 0

[JBoss JIRA] Created: (AS7-1833) CLI usability: operation :shutdown results in "Communication error"

by Radoslav Husar (JIRA)

CLI usability: operation :shutdown results in "Communication error" ------------------------------------------------------------------- Key: AS7-1833 URL: https://issues.jboss.org/browse/AS7-1833 Project: Application Server 7 Issue Type: Enhancement Components: CLI Affects Versions: 7.0.1.Final, 7.0.0.Final Reporter: Radoslav Husar Assignee: Alexey Loubyansky Priority: Minor If you shutdown the server, you get an error: {code} [standalone@localhost:9999 /] :shutdown Communication error: Channel closed Closed connection to localhost:9999 {code} Even though its considered by this comment clean - https://issues.jboss.org/browse/AS7-689?focusedCommentId=12614756&page=co... - I is not really clean as you get an error but termination of the channel can be anticipated. Users might be confused now knowing if its an actual error or not. For example take a look at SSH. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

6
10
0 / 0

[JBoss JIRA] Created: (JBAS-9203) EJBAccessException dont contains my LoginException thrown in a custom LoginModule during login-Method

by Felix Ullrich (JIRA)

EJBAccessException dont contains my LoginException thrown in a custom LoginModule during login-Method ----------------------------------------------------------------------------------------------------- Key: JBAS-9203 URL: https://issues.jboss.org/browse/JBAS-9203 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: 6.0.0.Final Reporter: Felix Ullrich Assignee: Anil Saldhana This problem was already mentioned here: [http://community.jboss.org/message/114379] A thrown LoginException in a custom LoginModule is not correctly wrapped into the javax.ejb.EJBAccessException on client-side. The cause of EJBAccessException is just not set - its null... The RemoteClient-Code looks like this try { ejb.someMethod(); } catch (final EJBAccessException e) { e.printStackTrace(); throw e.getCause(); } and the Stacktrace: javax.ejb.EJBAccessException: Invalid User at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:161) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:603) at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53) at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91) at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:898) at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:791) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:744) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:548) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:216) at org.jboss.remoting.Client.invoke(Client.java:1961) at org.jboss.remoting.Client.invoke(Client.java:804) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:77) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.async.impl.interceptor.AsynchronousClientInterceptor.invoke(AsynchronousClientInterceptor.java:143) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62) at $Proxy8.invoke(Unknown Source) at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:185) at $Proxy7.findAll(Unknown Source) at RemoteClient.main(RemoteClient.java:22) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:77) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.async.impl.interceptor.AsynchronousClientInterceptor.invoke(AsynchronousClientInterceptor.java:143) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62) at $Proxy8.invoke(Unknown Source) at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:185) at $Proxy7.findAll(Unknown Source) at RemoteClient.main(RemoteClient.java:22) Exception in thread "main" java.lang.NullPointerException at RemoteClient.main(RemoteClient.java:25) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

6
15
0 / 0

[JBoss JIRA] (JBRULES-3283) Concurrency issue: Invalid bytecode generated by KnowledgeBuilder.add()

by Thomas Kruse (Created) (JIRA)

Concurrency issue: Invalid bytecode generated by KnowledgeBuilder.add() ----------------------------------------------------------------------- Key: JBRULES-3283 URL: https://issues.jboss.org/browse/JBRULES-3283 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler (expert) Affects Versions: 5.3.0.Final, 5.3.0.CR1 Environment: Oracle Java 6, Oracle Java 7, Linux, MacOS java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode) Reporter: Thomas Kruse Assignee: Mark Proctor Priority: Minor Since Drools 5.3.0.CR1 concurrent creation of different knowledgebases from filesystem DRL rule definition leads to illegal bytecode. Reproduceable with Janino and eclipse compiler. I have a maven based test project which executes the unit tests in parallel, this is the result: {code} runFirst(de.trion.drools53.TwoTest): -1 runFirst(de.trion.drools53.FourTest): (class: de/trion/drools53/Rule_When_a_user_is_young__print_his_name_DefaultConsequenceInvoker, method: equals signature: (Ljava/lang/Object;)Z) Expecting to find integer on stack runSecond(de.trion.drools53.FourTest): (class: de/trion/drools53/Rule_When_a_user_is_young__print_his_name_DefaultConsequenceInvoker, method: equals signature: (Ljava/lang/Object;)Z) Expecting to find integer on stack runFirst(de.trion.drools53.OneTest): (class: de/trion/drools53/Rule_When_a_user_is_young__print_his_name_DefaultConsequenceInvoker, method: equals signature: (Ljava/lang/Object;)Z) Expecting to find integer on stack runFirst(de.trion.drools53.ThreeTest): (class: de/trion/drools53/Rule_When_a_user_is_young__print_his_name_DefaultConsequenceInvoker, method: equals signature: (Ljava/lang/Object;)Z) Incompatible object argument for function call runSecond(de.trion.drools53.ThreeTest): (class: de/trion/drools53/Rule_When_there_is_god__the_light_always_shines_DefaultConsequenceInvoker, method: equals signature: (Ljava/lang/Object;)Z) Unable to pop operand off an empty stack {code} Workaround: synchronize access Not affected: Drools 5.3.0.Beta -- 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, 5 months

6
12
0 / 0

[JBoss JIRA] (AS7-2086) TS: Tests grouping

by Ondrej Zizka (Created) (JIRA)

TS: Tests grouping ------------------ Key: AS7-2086 URL: https://issues.jboss.org/browse/AS7-2086 Project: Application Server 7 Issue Type: Sub-task Reporter: Ondrej Zizka Assignee: Ondrej Zizka Decide which mechanism to use to assign the tests into one or multiple groups. Posibilities: 1) {code} @Test @Category(IntegrationTests.class) {code} http://weblogs.java.net/blog/johnsmart/archive/2010/04/25/grouping-tests-... Also, Arquillian itself supports grouping: https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/o... 2) {code} @Ignore {code} 3) Maven Surefire <includes> and <excludes> -- 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, 5 months

6
33
0 / 0

[JBoss JIRA] (JBWEB-214) More than one JSESSIONID cookie headers set in JBoss Web

by Nagai Eiichi (Created) (JIRA)

More than one JSESSIONID cookie headers set in JBoss Web -------------------------------------------------------- Key: JBWEB-214 URL: https://issues.jboss.org/browse/JBWEB-214 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Tomcat Affects Versions: JBossWeb-2.1.11.GA Reporter: Nagai Eiichi Assignee: Remy Maucherat More than one JSESSIONID cookie headers set if execute following JSP. <% session.invalidate(); session = request.getSession(); session.invalidate(); session = request.getSession(); %> This issue has been reported from Bug 49158[1] in tomcat. [1] Bug 49158 - More than one JSESSIONID cookie headers set https://issues.apache.org/bugzilla/show_bug.cgi?id=49158 http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalin... http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalin... I guess that same fix is required in JBoss Web. -- 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, 5 months

4
7
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 January 2012