[JBoss JIRA] (WFLY-6293) <ejb-name> tag in <interceptor-binding> should support regular expression usages
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created WFLY-6293:
--------------------------------------
Summary: <ejb-name> tag in <interceptor-binding> should support regular expression usages
Key: WFLY-6293
URL: https://issues.jboss.org/browse/WFLY-6293
Project: WildFly
Issue Type: Feature Request
Components: EJB
Reporter: Wolf-Dieter Fink
Assignee: Stuart Douglas
>From the ejb specification the only possibility is to use the full EJB name or the wildcard "*".
* If the application is too large with many hundreds or thousand ejbs then it is complex to define the interceptor individually for number of beans having a common name pattern.
The <ejb-name> element in <interceptor-binding> should support regular expression usages. Like following via "ejb-jar.xml" or using "jboss-ejb3.xml":
{code}
<interceptor-binding>
<ejb-name>Intercepted*Bean</ejb-name>
<interceptor-class>interceptors.InterceptorOne</interceptor-class>
</interceptor-binding>
<interceptor-binding>
<ejb-name>[AB]*Bean</ejb-name>
<interceptor-class>interceptors.InterceptorOne</interceptor-class>
</interceptor-binding>
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6292) A Warning should be logged if an interceptor is ignored because of missing configuration
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created WFLY-6292:
--------------------------------------
Summary: A Warning should be logged if an interceptor is ignored because of missing configuration
Key: WFLY-6292
URL: https://issues.jboss.org/browse/WFLY-6292
Project: WildFly
Issue Type: Enhancement
Reporter: Wolf-Dieter Fink
Assignee: Stuart Douglas
Every class can be used as interceptor without an annotation. The class must be listed within the ejb-jar.xml deployment descriptor.
>From the spec there are two elements in ejb-jar.xml:
<!-- definition of Iterceptor classes -->
<interceptor>
<interceptor-class>ACLASS</interceptor-class>
<!--
no around-invoke needed if the method is unique
-->
</interceptor>
</interceptors>
<!-- the binding to EJB's -->
<assembly-descriptor>
<interceptor-binding>
<ejb-name>*</ejb-name>
<interceptor-class>ACLASS</interceptor-class>
</interceptor-binding>
</assembly-descriptor>
The problem is that the <interceptor> is needed to define the interceptor class unless the class contains the @AroundInvoke annotation.
The binding need this to take effect.
The problem here is that any wrong configuration, like typo in the class name, might have the effect that the interceptor is ignored silent.
As an enhancement a WARN message should be logged that the interceptor-binding can't find the related interceptor or even a ClassNotFoundException if the class is not available.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6214) Change CMTTxInterceptor.endTransaction() handling of Status.ROLLING_BACK
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6214?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-6214:
--------------------------------
Summary: Change CMTTxInterceptor.endTransaction() handling of Status.ROLLING_BACK (was: Change CMTTxInterceptor.endTransaction() handling of various status')
> Change CMTTxInterceptor.endTransaction() handling of Status.ROLLING_BACK
> ------------------------------------------------------------------------
>
> Key: WFLY-6214
> URL: https://issues.jboss.org/browse/WFLY-6214
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Reporter: Scott Marlow
> Assignee: Tom Jenkinson
> Priority: Blocker
> Fix For: 10.1.0.Final
>
>
> See recent comment [https://developer.jboss.org/message/950898#950898]
> {quote}
> Status.STATUS_COMMITTING:
> Status.STATUS_COMMITTED:
> Status.STATUS_PREPARED:
> Status.STATUS_PREPARING:
> * Someone has called commit in parallel and the transaction is trying to commit so try to commit too: call tm.commit
> {quote}
> I think that TimerCMTTxInterceptor/LifecycleCMTTxInterceptor are using CMTTxInterceptor.endTransaction(), so they shouldn't need changes.
> Status.STATUS_ROLLING_BACK can happen if the reaper has started to rollback the transaction
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (SECURITY-897) Unable to authenticate in SPNEGO Login Module with NullPointerException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-897?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-897:
--------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1236606|https://bugzilla.redhat.com/show_bug.cgi?id=1236606] from MODIFIED to ON_QA
> Unable to authenticate in SPNEGO Login Module with NullPointerException
> -----------------------------------------------------------------------
>
> Key: SECURITY-897
> URL: https://issues.jboss.org/browse/SECURITY-897
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_2_3_6_Final
> Environment: Red Hat JBoss EAP 6.3.2
> Reporter: Kunjan Rathod
> Assignee: Chao Wang
> Labels: jboss, jboss-as
> Fix For: Negotiation_3_0_0_Final, Negotiation_2_3_11_Final
>
>
> Description of problem:
> The configuration with SPNEGO works fine, however from time to time the authentication fails with the following error:
> ERROR (HTTP-341) [org.jboss.security.auth.spi.AbstractServerLoginModule] Unable to authenticate: java.lang.NullPointerException
> at org.jboss.security.negotiation.spnego.SPNEGOLoginModule$AcceptSecContext.run(SPNEGOLoginModule.java:420)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:356)
> Version-Release number of selected component (if applicable):
> JBoss Security Negotiation 2.3.3.Final
> How reproducible:
> This happens very rarely (20 times in a day on a system where about 50 users are working) and it is extremely hard to reproduce.
> Additional info:
> At line 420 in [1], the GSSToken is null
> ~~~~
> if (respToken != null)
> {
> NegotiationMessage response;
> if (requestMessage instanceof KerberosMessage)
> {
> response = new KerberosMessage(Constants.KERBEROS_V5, respToken);
> }
> else
> {
> NegTokenTarg negTokenTarg = new NegTokenTarg();
> negTokenTarg.setResponseToken(respToken);
> response = negTokenTarg;
> }
> ~~~~
> It looks like a GSSToken can be or is null, check the line#344 as follows:-
> ~~~~~~~~~
> public Object run()
> {
> try
> {
> // The message type will have already been checked before this point so we know it is
> // a SPNEGO message.
> NegotiationMessage requestMessage = negotiationContext.getRequestMessage();
> // TODO - Ensure no way to fall through with gssToken still null.
> byte[] gssToken = null;
> if (requestMessage instanceof NegTokenInit)
> {
> ...
> ~~~~~~~~~
> [1] : https://github.com/wildfly-security/jboss-negotiation/blob/2.3.3.Final/jb...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6291) EJB scheduler Timeout invoking every 3 seconds inspite of ScheduleExpression
by Surendran Duraisamy (JIRA)
Surendran Duraisamy created WFLY-6291:
-----------------------------------------
Summary: EJB scheduler Timeout invoking every 3 seconds inspite of ScheduleExpression
Key: WFLY-6291
URL: https://issues.jboss.org/browse/WFLY-6291
Project: WildFly
Issue Type: Bug
Components: Batch
Affects Versions: 8.2.0.Final, 8.1.0.Final
Reporter: Surendran Duraisamy
Assignee: Cheng Fang
Priority: Minor
When I write a EJB Scheduler using TimerService and ScheduleExpression. @Timeout function is invoking every 3 seconds inspite of the configured minutes / seconds.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6290) XTS does not work with jbossws.undefined.host in WS config
by Gytis Trikleris (JIRA)
Gytis Trikleris created WFLY-6290:
-------------------------------------
Summary: XTS does not work with jbossws.undefined.host in WS config
Key: WFLY-6290
URL: https://issues.jboss.org/browse/WFLY-6290
Project: WildFly
Issue Type: Bug
Components: XTS
Reporter: Gytis Trikleris
Assignee: Gytis Trikleris
Fix For: 10.1.0.Final
XTS uses ServerConfig to initialise it's configuration. However, we should rely on jboss.bind.address instead, because wsdl-host could take "jbossws.undefined.host" as a value.
"jbossws.undefined.host" will cause UnknownHostException, because address rewriting is not executed in XTS.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months