[JBoss JIRA] (WFLY-3850) NPE Deploying EJB @WebService without Security Domain
by Seth Miller (JIRA)
Seth Miller created WFLY-3850:
---------------------------------
Summary: NPE Deploying EJB @WebService without Security Domain
Key: WFLY-3850
URL: https://issues.jboss.org/browse/WFLY-3850
Project: WildFly
Issue Type: Bug
Components: EJB, Web (JBoss Web)
Affects Versions: 8.1.0.Final
Reporter: Seth Miller
Assignee: David Lloyd
Disable EJB security interceptors by altering the standalone.xml ejb subsystem to remove the security domain, then deploy an .ear file with a @WebService within an EJB. The EAR will fail to deploy with the following:
{code}
Caused by: java.lang.NullPointerException
at org.jboss.as.webservices.tomcat.AbstractSecurityMetaDataAccessorEJB.getSecurityDomain(AbstractSecurityMetaDataAccessorEJB.java:63)
at org.jboss.as.webservices.tomcat.WebMetaDataCreator.createJBossWebAppDescriptor(WebMetaDataCreator.java:120)
at org.jboss.as.webservices.tomcat.WebMetaDataCreator.create(WebMetaDataCreator.java:80)
at org.jboss.as.webservices.tomcat.WebMetaDataCreatingDeploymentAspect.start(WebMetaDataCreatingDeploymentAspect.java:41)
at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
... 5 more
{code}
Workaround:
To keep security interceptors disabled on all other EJBs, annotate @WebService classes with a security domain: @SecurityDomain("other") via the pom.xml dependency:
{code}
<dependency>
<groupId>org.jboss.ejb3</groupId>
<artifactId>jboss-ejb3-ext-api</artifactId>
<version>${version.org.jboss.ejb3.ext-api}</version>
<scope>provided</scope>
</dependency>
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-794) javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-794?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated WFLY-794:
-----------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=959565, https://bugzilla.redhat.com/show_bug.cgi?id=951993, https://bugzilla.redhat.com/show_bug.cgi?id=958166, https://bugzilla.redhat.com/show_bug.cgi?id=1140755 (was: https://bugzilla.redhat.com/show_bug.cgi?id=959565, https://bugzilla.redhat.com/show_bug.cgi?id=951993, https://bugzilla.redhat.com/show_bug.cgi?id=958166)
> javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-794
> URL: https://issues.jboss.org/browse/WFLY-794
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Reporter: Alex Corvino
> Assignee: Eduardo Martins
> Labels: investigation_required
> Fix For: 9.0.0.Alpha1
>
> Attachments: jmx-test.jar, JmxClient.java, JMXConnectionBean.java, JmxServer.java
>
>
> When trying to create a MBeanServerConnection to a NON-JBoss application from within an EJB a "javax.naming.NameNotFoundException" is thrown.
> Steps to reproduce:
> Set up a stand-alone application that exposes an MBean. (ActiveMQ will work in this case.)
> Modify the attached JMXConnectionBean.java to connect to the ActiveMQ instance.
> Deploy the bean. A NameNotFoundException will be thrown.
> I've seen this behavior in 7.1.1.Final, 7.1.2.Final (EAP), 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final).
> Note that this behavior is NOT seen when connecting to another JBoss server.
> Full stack trace:
> {code}
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:340) [:1.6.0_26]
> at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) [:1.6.0_26]
> at com.example.JMXConnectionBean.init(JMXConnectionBean.java:28)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
> at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
> at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:70)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:211)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:313)
> at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56)
> at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:42)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:152)
> ... 9 more
> Caused by: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:87)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:173)
> at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:47)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:209)
> at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_26]
> at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1888) [:1.6.0_26]
> at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1858) [:1.6.0_26]
> at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257) [:1.6.0_26]
> ... 37 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (LOGMGR-104) SyslogHandler doesn't handle multi-byte characters correctly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-104?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on LOGMGR-104:
------------------------------------------------
James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1096053|https://bugzilla.redhat.com/show_bug.cgi?id=1096053] from ASSIGNED to MODIFIED
> SyslogHandler doesn't handle multi-byte characters correctly
> ------------------------------------------------------------
>
> Key: LOGMGR-104
> URL: https://issues.jboss.org/browse/LOGMGR-104
> Project: JBoss Log Manager
> Issue Type: Bug
> Components: core
> Affects Versions: 1.5.2.Final
> Environment: - WildFly 8.0.0.Final
> - Oracle JDK7u51
> - OS X 10.9.2
> Reporter: Kyle Shanahan
> Assignee: James Perkins
> Fix For: 1.5.3.Final, 2.0.0.Beta1
>
> Attachments: corrupted.png, corrupted2.png, corrupted3.png
>
>
> SyslogHandler doesn't handle multi-byte characters correctly.
> I tried to log multi-byte message with both of org.jboss.logmanager.handlers.SyslogHandler and org.apache.log4j.net.SyslogAppender for same message, only SyslogHandler output were corrupted.
> Step to reproduce (It might need to define -Dfile.encoding=UTF-8 in _JAVA_OPTIONS):
> 1. define a facility local1 at localhost and make syslog accept UDP packets.
> 2. define a logger:
> {noformat}
> /subsystem=logging/logger=utf8mb4log:add(level=INFO)
> {noformat}
> 3. define a SyslogHandler:
> {noformat}
> /subsystem=logging/custom-handler=TEST_SH:add(class="org.jboss.logmanager.handlers.SyslogHandler", module="org.jboss.logmanager", formatter="SyslogHandler: %s%e", level=INFO, properties={serverHostname="localhost:514", facility="LOCAL_USE_1", truncate=false, maxLength=1024, syslogType="RFC3164" })
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_SH)
> {noformat}
> 4. define a SyslogAppender:
> {noformat}
> /subsystem=logging/custom-handler=TEST_LOG4J:add(class="org.apache.log4j.net.SyslogAppender", module="org.apache.log4j", formatter="log4j: %s%e", level=INFO, properties={syslogHost="localhost:514", facility="local1"})
> /subsystem=logging/logger=utf8mb4log:assign-handler(name=TEST_LOG4J)
> {noformat}
> 5. get and deploy example project at https://github.com/lbtc-xxx/utf8mb4log
> 6. Access the servlet http://localhost:8080/utf8mb4log/
> And you will get like this: (I can't put 4 byte UTF-8 characters here... because database error occured):
> {noformat}
> Mar 8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????
> {noformat}
> I would send a pull request later.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1877 at 9/11/14 11:32 AM:
----------------------------------------------------------
Investigate:
* -Responses-
* -Promise-
* _Request (UnicastRequest, GroupRequest)_
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* LazyRemovalCache
* -TimeService-
* Discovery: ping responses
was (Author: belaban):
Investigate:
* -Responses-
* -Promise-
* _Request (UnicastRequest, GroupRequest)_
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* ExpiryCache
* LazyRemovalCache
* -TimeService-
* Discovery: ping responses
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1877 at 9/11/14 11:29 AM:
----------------------------------------------------------
Investigate:
* -Responses-
* -Promise-
* _Request (UnicastRequest, GroupRequest)_
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* ExpiryCache
* LazyRemovalCache
* -TimeService-
* Discovery: ping responses
was (Author: belaban):
Investigate:
* -Responses-
* -Promise-
* _Request (UnicastRequest, GroupRequest)_
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* ExpiryCache
* -TimeService-
* Discovery: ping responses
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (DROOLS-594) Accumulation causes node propagation failure which results in rule firing when it is not supposed to
by John Le (JIRA)
[ https://issues.jboss.org/browse/DROOLS-594?page=com.atlassian.jira.plugin... ]
John Le closed DROOLS-594.
--------------------------
validated
> Accumulation causes node propagation failure which results in rule firing when it is not supposed to
> ----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-594
> URL: https://issues.jboss.org/browse/DROOLS-594
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.Beta1
> Reporter: John Le
> Assignee: Mario Fusco
> Labels: backport-to-6.0.x
> Fix For: 6.2.0.CR1
>
> Attachments: AggregateIssue.java
>
>
> Accumulation causes node propagation failure which results in rule firing when it is not supposed to. Please see attached code file to reproduce the issue. Rule "RS7402.42.2" is supposed to fire once but it manages to fire twice without getting deactivate.
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - ACTIVATION CREATED rule:RS7365.4.6_ activationId:RS7365.4.6_ [1, 2, 3, 4, 12] declarations: $benefitAssessmentResults=BenefitAssessmentResults
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - BEFORE ACTIVATION FIRED rule:RS7365.4.6_ activationId:RS7365.4.6_ [1, 2, 3, 4, 12] declarations: $benefitAssessmentResults=BenefitAssessmentResults
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - OBJECT ASSERTED value:EvaluatedData factId: 13
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - OBJECT MODIFIED value:BenefitAssessmentResults factId: 12
> RS7365.4.6_ FIRED
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - AFTER ACTIVATION FIRED rule:RS7365.4.6_ activationId:RS7365.4.6_ [1, 2, 3, 4, 12] declarations: $benefitAssessmentResults=BenefitAssessmentResults
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - ACTIVATION CREATED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 11, 4, 12, 13, 15] declarations: $currentMortgagePaymentAmount=0.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - ACTIVATION CREATED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 10, 4, 12, 13, 14] declarations: $currentMortgagePaymentAmount=0.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - BEFORE ACTIVATION FIRED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 11, 4, 12, 13, 15] declarations: $currentMortgagePaymentAmount=0.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - OBJECT MODIFIED value:EvaluatedData factId: 13
> RS7402.42.2_ FIRED
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - AFTER ACTIVATION FIRED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 11, 4, 12, 13, 15] declarations: $currentMortgagePaymentAmount=9180.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - BEFORE ACTIVATION FIRED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 10, 4, 12, 13, 14] declarations: $currentMortgagePaymentAmount=9180.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - OBJECT MODIFIED value:EvaluatedData factId: 13
> RS7402.42.2_ FIRED
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - AFTER ACTIVATION FIRED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 10, 4, 12, 13, 14] declarations: $currentMortgagePaymentAmount=18360.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years