[JBoss JIRA] (AS7-5363) NPE on tab completion
by Jeff Mesnil (JIRA)
Jeff Mesnil created AS7-5363:
--------------------------------
Summary: NPE on tab completion
Key: AS7-5363
URL: https://issues.jboss.org/browse/AS7-5363
Project: Application Server 7
Issue Type: Bug
Components: CLI
Reporter: Jeff Mesnil
Assignee: Alexey Loubyansky
I encountered this issue on 7.1 branch
When pressing TAB to get autocompletion on a path that has already been autocompleted, it throws a NPE.
{noformat}
$ ./bin/jboss-cli.sh
[disconnected /] connect
[standalone@localhost:9999 /] cd /subsystem=me<TAB>
=> this works and completes the "messaging" address
[standalone@localhost:9999 /] cd /subsystem=messaging<TAB>
=> this throws an NPE
java.lang.NullPointerException
at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:349)
at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:72)
at org.jboss.as.cli.operation.OperationRequestCompleter$1.complete(OperationRequestCompleter.java:56)
at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:222)
at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:95)
at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:141)
at jline.ConsoleReader.complete(ConsoleReader.java:832)
at jline.ConsoleReader.readLine(ConsoleReader.java:518)
at jline.ConsoleReader.readLine(ConsoleReader.java:448)
at org.jboss.as.cli.impl.Console$Factory$1.readLine(Console.java:212)
at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:1109)
at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:243)
at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.modules.Module.run(Module.java:270)
at org.jboss.modules.Main.main(Main.java:294)
{noformat}
iirc, the previous behaviour (that I was expecting) was to propose completion for the resource children.
--
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, 9 months
[JBoss JIRA] (AS7-5635) Changing the package of a class containing a @Schedule method does not remove previously scheduled method
by Kevin Hooke (JIRA)
Kevin Hooke created AS7-5635:
--------------------------------
Summary: Changing the package of a class containing a @Schedule method does not remove previously scheduled method
Key: AS7-5635
URL: https://issues.jboss.org/browse/AS7-5635
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.1.0.Final
Reporter: Kevin Hooke
Assignee: jaikiran pai
Priority: Minor
If you have a class deployed in a war with a method annotated with @Schedule, if you change the package of the class and redeploy, the server attempts to execute the scheduled method in the previous version of the class.
It looks like there's some metadata saved to the \standalone\data\timer-service-data\ dir that does not get cleaned up. Deleting the dir that matching the webapp modified and then restarting appears to fix the issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-5575) Cannot bind under java:jboss/exported via new IntitialContext()
by James Livingston (JIRA)
James Livingston created AS7-5575:
-------------------------------------
Summary: Cannot bind under java:jboss/exported via new IntitialContext()
Key: AS7-5575
URL: https://issues.jboss.org/browse/AS7-5575
Project: Application Server 7
Issue Type: Bug
Components: Naming
Affects Versions: 7.1.2.Final (EAP)
Reporter: James Livingston
Assignee: Eduardo Martins
Somewhat related to AS7-5492, org.jboss.as.naming.InitialContext does not deal with java:jboss/exported correctly.
For java:/jboss/exported/abc/def parse() will return namespace=jboss,remaining=exported/abc/def which causes all the calling methods to use the wrong (java:jboss) naming store.
(That code could probably be re-factored out of all the individual methods into a helper method too)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-5605) Make RestEasy modules public
by Ondrej Zizka (JIRA)
Ondrej Zizka created AS7-5605:
---------------------------------
Summary: Make RestEasy modules public
Key: AS7-5605
URL: https://issues.jboss.org/browse/AS7-5605
Project: Application Server 7
Issue Type: Feature Request
Components: REST
Affects Versions: 7.1.2.Final (EAP), 7.2.0.Alpha1
Reporter: Ondrej Zizka
Assignee: Shelly McGowan
Fix For: 7.1.3.Final (EAP)
The RestEasy modules are all jboss:api="private".
This blocks many use cases - not only RestEasy's annotations, but different providers as well (e.g. Jackson's @JsonIgnore).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-5523) WritableServiceBasedNamingStore (jndi) installs a new msc service and waits for it, which could cause deadlocks
by Radai Rosenblatt (JIRA)
Radai Rosenblatt created AS7-5523:
-------------------------------------
Summary: WritableServiceBasedNamingStore (jndi) installs a new msc service and waits for it, which could cause deadlocks
Key: AS7-5523
URL: https://issues.jboss.org/browse/AS7-5523
Project: Application Server 7
Issue Type: Bug
Components: MSC, Server
Affects Versions: 7.1.1.Final
Environment: windows 2008 server, single core VM
Reporter: Radai Rosenblatt
Assignee: David Lloyd
class WritableServiceBasedNamingStore installs a new MSC service (instance of BinderService) and then waits for that MSC service to boot - by creating a new listener of type BindListener (an inner class) and calling listener.await() (line 72 in WritableServiceBasedNamingStore.java).
i have a @Singleton @Startup EJB which, in its @PostConstruct method calls (new InitialContext().bind(...)), and hits this code.
that @PostConstruct method was itself invoked by an MSC thread. the end result looks like this:
"MSC service thread 1-2" prio=6 tid=0x000000000e146000 nid=0x960 in Object.wait() [0x000000000f6fd000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000007f652e400> (a org.jboss.as.naming.WritableServiceBasedNamingStore$BindListener)
at java.lang.Object.wait(Object.java:503)
at org.jboss.as.naming.WritableServiceBasedNamingStore$BindListener.await(WritableServiceBasedNamingStore.java:153)
- locked <0x00000007f652e400> (a org.jboss.as.naming.WritableServiceBasedNamingStore$BindListener)
at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:72)
at org.jboss.as.naming.NamingContext.bind(NamingContext.java:221)
at org.jboss.as.naming.InitialContext.bind(InitialContext.java:172)
at org.jboss.as.naming.NamingContext.bind(NamingContext.java:230)
at javax.naming.InitialContext.bind(Unknown Source)
[application code ommitted]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:112)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:112)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:112)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:112)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ee.component.ManagedReferenceInterceptorFactory$ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptorFactory.java:95)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:333)
at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:85)
at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:116)
- locked <0x000000078b4108e8> (a java.lang.Object)
at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:130)
at org.jboss.as.ee.component.ComponentStartService.start(ComponentStartService.java:44)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
notice that this stack is during ComponentStartService.start(), which is in itself an MSC service. this is against the Service contract which states services should never block (or use the async api)
this also has real world implications -
the specific vm this was run on has a single (virtual) cpu, which means the MSC pool size is 2, one of which is now waiting.
if two of my @Singletons happen to coincide the server deadlocks and will never finish booting (the thread dump excerpt above was taken just from such a situation)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-5631) add-user script confusing error: Password must not have atleast one digit.
by Cheng Fang (JIRA)
Cheng Fang created AS7-5631:
-------------------------------
Summary: add-user script confusing error: Password must not have atleast one digit.
Key: AS7-5631
URL: https://issues.jboss.org/browse/AS7-5631
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.2.0.Alpha1
Reporter: Cheng Fang
Assignee: Brian Stansberry
when running add-user.sh to add an application user, and entering a weal password, got the following error:
Password :
Re-enter Password :
What roles do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]:
* Error *
JBAS015266: Password must not have atleast one digit.
I guess what it meant is password must have at least one digit.
A search showed the following files referencing this message:
./domain-management/src/main/java/org/jboss/as/domain/management/DomainManagementMessages.java
This file also contains some other typo like "atleast".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months