[JBoss JIRA] (WFLY-3266) Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3266?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3266:
-----------------------------------------------
Panagiotis Sotiropoulos <psotirop(a)redhat.com> changed the Status of [bug 1127593|https://bugzilla.redhat.com/show_bug.cgi?id=1127593] from NEW to POST
> Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3266
> URL: https://issues.jboss.org/browse/WFLY-3266
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Priority: Critical
>
> In case of large parameter input for EJB invocations the ejb-client throw the Exception below.
> The underlying OutOfMemory is complete hidden, neither in the server.log nor in the ejb-client with TRACE a hint will be found.
> java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed
> at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy6.uploadData(Unknown Source)
> at de.info.biene.konsens.TestServiceWithAPITest.testUploadData(TestServiceWithAPITest.java:81)
> 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:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> 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:606)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-1172) mechanism to load tag libraries from module
by Frank Langelage (JIRA)
[ https://issues.jboss.org/browse/WFLY-1172?page=com.atlassian.jira.plugin.... ]
Frank Langelage commented on WFLY-1172:
---------------------------------------
With latest master including this patch times are normal again.
You also can see this on wildfly-ci. Times are down to ~ 1h again, from ~ 1h 18m.
> mechanism to load tag libraries from module
> -------------------------------------------
>
> Key: WFLY-1172
> URL: https://issues.jboss.org/browse/WFLY-1172
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Ivica Loncar
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: modules, tag, taglib, tld
> Fix For: 9.0.0.Beta1
>
> Attachments: ExternalTld.txt, ExternalTldParsingDeploymentProcessor.java.diff
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> tag libraries are scanned only if they appear in jar inside WEB-INF/lib or are defined in tld under WEB-INF.
> The simplest scenario to explain why this is a problem: portlet 2 defines standard portlet taglib, but the classes in this file come from concrete implementations. Currently I see no way to use 2 different portals in a portable way.
> Please provide a way to notify a relevant subsystem for web applications that specific module contains a .tld.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-1119) Assign an unique NodeID automatically
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-1119?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-1119:
------------------------------
Assignee: Tom Jenkinson (was: Jeff Mesnil)
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: WFLY-1119
> URL: https://issues.jboss.org/browse/WFLY-1119
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Transactions
> Reporter: Clebert Suconic
> Assignee: Tom Jenkinson
> Priority: Optional
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-3774) CDI bean with StereoType is not injectable in implicit bean archive
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-3774?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger updated WFLY-3774:
----------------------------------
Fix Version/s: 8.2.0.CR1
{quote}Sorry I wasn't clear on that point. CDI 1.2 clearly listed what is injectable, but it also applies to CDI 1.1. This behavior is nothing changed between versions, it just got clearer definistion.{quote}
You are wrong. @Stereotypes being recognized as bean defining annotations is a new feature of CDI 1.2 - see e.g. http://www.cdi-spec.org/news/2014/04/14/CDI-1_2-released/
More precisely, in CDI 1.1, only scope annotations are considered bean defining annotations:
http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_defining_annotations
In CDI 1.2 this was extended to cover @Stereotypes and some other annotations:
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_defining_annotations
> CDI bean with StereoType is not injectable in implicit bean archive
> -------------------------------------------------------------------
>
> Key: WFLY-3774
> URL: https://issues.jboss.org/browse/WFLY-3774
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.1.0.Final
> Reporter: Takayoshi Kimura
> Assignee: Jozef Hartinger
> Fix For: 8.2.0.CR1, 9.0.0.Beta1
>
> Attachments: logs.zip, stereotype.zip
>
>
> CDI 1.2 defines bean defining annotations and with beans with these annotations should be injectable. However a bean with StereoType, one of bean defining annotations, is not injectable within implicit bean archive on WildFly.
> Attached a simple war project to reproduce this problem. This works on GlassFish 4 but doesn't work on WildFly 8.1.0 nor WildFly 9 master at this time. Making this an explicit bean archive by adding empty beans.xml (or set bean-discovery-mode=all) fixes the problem, the container recognizes the CDI bean correctly.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-1119) Assign an unique NodeID automatically
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-1119?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-1119:
------------------------------
Component/s: Transactions
(was: JMS)
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: WFLY-1119
> URL: https://issues.jboss.org/browse/WFLY-1119
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Transactions
> Reporter: Clebert Suconic
> Assignee: Jeff Mesnil
> Priority: Optional
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFCORE-29) IllegalStateException when patching MBeans are queried during shutdown
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-29?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFCORE-29:
-----------------------------------------------
Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1120535|https://bugzilla.redhat.com/show_bug.cgi?id=1120535] from ON_QA to VERIFIED
> IllegalStateException when patching MBeans are queried during shutdown
> ----------------------------------------------------------------------
>
> Key: WFCORE-29
> URL: https://issues.jboss.org/browse/WFCORE-29
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management, Patching
> Reporter: James Livingston
> Assignee: Emanuel Muckenhuber
> Attachments: shutdownmbeanquery.jar
>
>
> If the MBeans for the patching subsystem are queried during server shutdown, it can result in an IllegalStateException. InstallationManagerService has already had stop() called on it, so the value is null.
> This can be reproduced by the attached EJB, which does a MBeanServer.queryMBeans(null, null); from the @PreDestroy method. It's in a loop to ensure it runs after the installation manager gets de-initialised.
> java.lang.IllegalStateException
> at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:87) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:28) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.children(PatchResource.java:139) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.hasChildren(PatchResource.java:134) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.registry.AbstractModelResource.hasChildren(AbstractModelResource.java:81) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.hasChildren(AbstractModelResource.java:279) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:57) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:43) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.ModelControllerMBeanHelper.queryMBeans(ModelControllerMBeanHelper.java:125) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.queryMBeans(ModelControllerMBeanServerPlugin.java:159) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.queryMBeans(PluggableMBeanServerImpl.java:816) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at example.ShutdownMBeanQuery.destroy(ShutdownMBeanQuery.java:23)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (SECURITY-640) Jboss Negotiation fallback to login page if NTLM token is received or the user is not present in active directory.
by Hrishi Salvi (JIRA)
[ https://issues.jboss.org/browse/SECURITY-640?page=com.atlassian.jira.plug... ]
Hrishi Salvi closed SECURITY-640.
---------------------------------
Thank you..
> Jboss Negotiation fallback to login page if NTLM token is received or the user is not present in active directory.
> ------------------------------------------------------------------------------------------------------------------
>
> Key: SECURITY-640
> URL: https://issues.jboss.org/browse/SECURITY-640
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Environment: Active Directory Winwos 2003, Client Machine windows XP, Jboss Server Machine Window XP and Jboss 6.1
> Reporter: Hrishi Salvi
> Assignee: Derek Horton
> Fix For: Negotiation_2_2_8, Negotiation_2_3_0_CR2
>
>
> We are trying to configure the single sign on using jboss negotiation.
> We are able to login successfully if the user is present in active directory.
> But in case if user is not present in active directory users, it throw 401 error page.
> Instead of 401 we want user to access login form and authenticate user using different login module.
> In our case we have login page we authenticate user on that page.
> If we receive user credentials we login the user without asking for password.
> Now if the user credentials are not received then we want user to open login form present
> on login page, but before that is throws 401 error.
> We have configure the login-config.xml, web.xml and jboss-web.xml as per the documentation.
> Also defined
> <web-resource-collection>
> <web-resource-name>Restricted</web-resource-name>
> <url-pattern>/Request</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> in web.xml
> Our application is access through Request servlet.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-3799) Wrong WildFly version when WildFly standalone is started
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-3799?page=com.atlassian.jira.plugin.... ]
Thomas Diesler updated WFLY-3799:
---------------------------------
Assignee: (was: Thomas Diesler)
Component/s: Server
(was: ConfigAdmin)
> Wrong WildFly version when WildFly standalone is started
> --------------------------------------------------------
>
> Key: WFLY-3799
> URL: https://issues.jboss.org/browse/WFLY-3799
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 9.0.0.Beta1
> Reporter: Juergen Zimmermann
>
> I compiled the WildFly snapshot from GitHub. When I start WildFly standalone, then I see this final log message with the version number from WildFly Core:
> {code}
> INFO [org.jboss.as] WFLYSRV0025: WildFly 1.0.0.Alpha5 "Kenny" started in 2454ms - Started 216 of 319 services (143 services are lazy, passive or on-demand)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months