[JBoss JIRA] (JBLOGGING-86) Logger full class name issue in generated sources
by Alessio Soldano (JIRA)
Alessio Soldano created JBLOGGING-86:
----------------------------------------
Summary: Logger full class name issue in generated sources
Key: JBLOGGING-86
URL: https://issues.jboss.org/browse/JBLOGGING-86
Project: JBoss Logging
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.1.2.GA
Reporter: Alessio Soldano
Assignee: David Lloyd
I'm running the log file generation as described in https://community.jboss.org/wiki/JBossLoggingTooling#mavencompilerplugin (jboss-logging-processor 1.0.3.Final) and getting compile errors if the name of my @MessageLogger annotated interface is Logger (regardless of the package).
Here is part of the generated source:
{code}
package org.jboss.ws.api;
...
@Generated(value = "org.jboss.logging.processor.model.MessageLoggerImplementor", date = "2012-09-18T11:56:34+0200")
public class Logger_$logger
extends DelegatingBasicLogger
implements Serializable, BasicLogger, org.jboss.ws.api.Logger
{
...
public Logger_$logger(final org.jboss.logging.Logger log) {
super(log);
}
public final void creatingUnifiedWebservicesDeploymentModel(final Object unit) {
super.log.logf(FQCN, (Logger.Level.TRACE), null, ((projectCode +"015503: ")+ creatingUnifiedWebservicesDeploymentModel$str()), unit);
}
{code}
Please note the "Logger.Level.TRACE" should actually be "org.jboss.logging.Logger.Level.TRACE"; the constructor parameter has the proper full class name specified instead.
--
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-4140) Change distribution of -Dmcast through testsuite
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/AS7-4140?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar updated AS7-4140:
--------------------------------
Assignee: Radoslav Husar (was: Ondrej Zizka)
Fix Version/s: 7.1.4.Final (EAP)
(was: 7.1.2.Final (EAP))
Component/s: Clustering
As it turns out, the patch for removing JGroups diagnostics *hasnt* made it upstream -- created AS7-5577. I have submitted the PR for this and I will finish this patch as well.
> Change distribution of -Dmcast through testsuite
> ------------------------------------------------
>
> Key: AS7-4140
> URL: https://issues.jboss.org/browse/AS7-4140
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Clustering, Test Suite
> Affects Versions: 7.1.1.Final
> Reporter: Pavel Janousek
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 7.1.4.Final (EAP)
>
>
> Please change present behavior.
> We need to define only one property -Dmcast (for ex., the name doesn't matter now) as command line parameter - this multicast address is needed to be distributed to every subsystem which manages any multicast communication. It is needed to be unique in every subsystem - JGroups, HornetQ etc. because we must avoid to interfere each other => port assignation must be unique for every a such component.
> This change is needed in both - IPV4 and IPv6...
--
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-5577) CLONE - Disable JGroups diagnostics service by default
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/AS7-5577?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar reassigned AS7-5577:
-----------------------------------
Assignee: Radoslav Husar (was: Paul Ferraro)
> CLONE - Disable JGroups diagnostics service by default
> ------------------------------------------------------
>
> Key: AS7-5577
> URL: https://issues.jboss.org/browse/AS7-5577
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP)
> Reporter: Dennis Reed
> Assignee: Radoslav Husar
> Priority: Blocker
> Labels: eap6_need_triage
> Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
>
>
> The JGroups diagnostics service should be disabled by default.
> This can be accomlished by removing the "diagnostics-socket-binding" attribute from the <transport> tags in the JGroups subsystem.
> This is a security issue, because the diagnostics port enables many security-sensitive operations, with no authentication, including:
> - full thread dump of the JVM
> - add/remove JGroups protocols
> - call any method on any JGroups protocol, passing in arbitrary arguments
--
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-5577) CLONE - Disable JGroups diagnostics service by default
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/AS7-5577?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar moved JBPAPP-9954 to AS7-5577:
---------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-5577 (was: JBPAPP-9954)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: 7.1.2.Final (EAP)
7.1.3.Final (EAP)
(was: EAP 6.0.0 ER 7)
Release Notes Docs Status: (was: Documented as Resolved Issue)
Release Notes Text: (was: * Cause
When a JGroups channel is started, the JGroups diagnostics service will be enabled by default with no authentication. This service is exposed via IP multicast.
* Consequence
An attacker on an adjacent network can exploit this flaw to read diagnostics information and invoke JMX operations on the server (limited remote code execution).
* Fix
The jgroups-diagnostics socket binding has been removed.
* Result
The JGroups diagnostics service is not exposed unless explicitly enabled.
)
Component/s: Clustering
(was: Clustering)
Security: (was: JBoss Internal)
Fix Version/s: 7.2.0.Alpha1
7.1.4.Final (EAP)
(was: EAP 6.0.0)
Docs QE Status: (was: NEW)
> CLONE - Disable JGroups diagnostics service by default
> ------------------------------------------------------
>
> Key: AS7-5577
> URL: https://issues.jboss.org/browse/AS7-5577
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP)
> Reporter: Dennis Reed
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: eap6_need_triage
> Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
>
>
> The JGroups diagnostics service should be disabled by default.
> This can be accomlished by removing the "diagnostics-socket-binding" attribute from the <transport> tags in the JGroups subsystem.
> This is a security issue, because the diagnostics port enables many security-sensitive operations, with no authentication, including:
> - full thread dump of the JVM
> - add/remove JGroups protocols
> - call any method on any JGroups protocol, passing in arbitrary arguments
--
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] (JBPORTAL-118) Logout does not work consistently
by Moushmi Bej (JIRA)
[ https://issues.jboss.org/browse/JBPORTAL-118?page=com.atlassian.jira.plug... ]
Moushmi Bej commented on JBPORTAL-118:
--------------------------------------
HI,
Can any one let me know how did you implement the sign out process in drools guvnor.
I have made changes to the source code of SecurityServiceServlet class in logout() method.
Best regards,
Moushmi
> Logout does not work consistently
> ---------------------------------
>
> Key: JBPORTAL-118
> URL: https://issues.jboss.org/browse/JBPORTAL-118
> Project: JBoss Portal
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: SourceForge legacy user
> Assignee: julien1
>
> SourceForge Submitter: juhalindfors .
> Logout from Nukes website does not work consistently.
> User is reported as logged out but his session will
> continue to be active.
> Nukes with current jboss.org website, Mozilla 1.5 Win32
--
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] (JBRULES-3628) Exception jitting a constaint invoking a constructor
by Mario Fusco (JIRA)
Mario Fusco created JBRULES-3628:
------------------------------------
Summary: Exception jitting a constaint invoking a constructor
Key: JBRULES-3628
URL: https://issues.jboss.org/browse/JBRULES-3628
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Mario Fusco
Assignee: Mario Fusco
If the constraint invokes a constructor with a primitive type as argument but passing the corresponding class type to it as in the following example:
class Person {
public Integer getAgeAsInteger() { return age; }
}
rule R1 when
Person( new Integer( ageAsInteger ) < 40 )
then
end
when the constraint is jitted the following Exception is thrown:
java.lang.RuntimeException: Exception jitting: new Integer( ageAsInteger ) < 40
at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:274)
at org.drools.rule.constraint.MvelConstraint.jitEvaluator(MvelConstraint.java:229)
at org.drools.rule.constraint.MvelConstraint.forceJitEvaluator(MvelConstraint.java:222)
at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:191)
at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:156)
at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)
at org.drools.integrationtests.MiscTest.testJit(MiscTest.java:11520)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:76)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.VerifyError: (class: ConditionEvaluatord12c0fbaca644b0eaff422a71b8812cc, method: evaluate signature: (Ljava/lang/Object;Lorg/drools/common/InternalWorkingMemory;Lorg/drools/reteoo/LeftTuple;)Z) Expecting to find integer on stack
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
at java.lang.Class.getConstructor(Class.java:1657)
at org.drools.rule.builder.dialect.asm.ClassGenerator.newInstance(ClassGenerator.java:198)
at org.drools.rule.constraint.ASMConditionEvaluatorJitter.jitEvaluator(ASMConditionEvaluatorJitter.java:53)
at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:272)
... 40 more
--
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-5539) JBOSS7 server hangs up completely when a EJB2.1 entity bean business method is called in same transaction in a separate thread from the thread which started the transaction
by Mayank Gupta (JIRA)
Mayank Gupta created AS7-5539:
---------------------------------
Summary: JBOSS7 server hangs up completely when a EJB2.1 entity bean business method is called in same transaction in a separate thread from the thread which started the transaction
Key: AS7-5539
URL: https://issues.jboss.org/browse/AS7-5539
Project: Application Server 7
Issue Type: Bug
Components: EJB, Transactions
Affects Versions: 7.1.1.Final, 7.1.3.Final (EAP), 7.2.0.Alpha1
Reporter: Mayank Gupta
Assignee: jaikiran pai
JBOSS7 server hangs up completely while trying to access a EJB2.1 entity bean method in a specific scenario.
I am using a session facade pattern in which I call my EntityBean from a Stateless session bean. For moth the beans I have defined the transaction attribute as REQUIRED.
On debugging the code I found that if the same Entity bean is accessed from two different threads in same transaction then this issue occurs.
So for the first time my code enters "EntityBeanSynchronizationInterceptor" code is able to take the lock and assign the requester thread as the lock owner. When second time it comes to access the same entity bean from different thread in SAME TRANSACTION (as 2nd required results in joining the transaction), JBOSS7 server code completely stalls in taking the lock. Moreover this time requester thread is not given the owner status of the transaction.
Code snippet where code hangs:
final Object lockOwner = getLockOwner(transactionSynchronizationRegistry);
lock.pushOwner(lockOwner);
try {
lock.lock(); //line 80 in EntityBeanSynchronizationInterceptor
and subsequently in:
public void lock() {
if (compareAndSetState(0, 1))
owner = currentRequestor();
else
acquire(1); //Here line 86 in OwnableReentrantLock
}
This is a completely blocking issue for migrating my application from JBOSS6 to JBOSS7.
I get this error in numerous places in my application code.
--
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-4444) Web deployment metrics missing
by Stefan Negrea (JIRA)
Stefan Negrea created AS7-4444:
----------------------------------
Summary: Web deployment metrics missing
Key: AS7-4444
URL: https://issues.jboss.org/browse/AS7-4444
Project: Application Server 7
Issue Type: Enhancement
Components: Web
Reporter: Stefan Negrea
Assignee: Remy Maucherat
The following web deployment metrics are missing from AS7 when compared to AS5 exposed metrics:
Clustered - True if this web application context is clustered
Virtual Host - the virtual host with which this context is associated
Response Time - the minimum, maximum, and average response times for requests serviced by this webapp
Currently Active Sessions - the number of sessions that are currently active for this WAR
Maximum Active Sessions - the maximum number of sessions that have been active for this WAR
Created Sessions - the number of sessions created for this WAR
Created Sessions per Minute - the number of sessions created for this WAR
Expired Sessions - the number of expired sessions for this WAR
Expired Sessions per Minute - the number of expired sessions for this WAR
Rejected Sessions - the number of sessions rejected for this WAR
Rejected Sessions per Minute - the number of sessions rejected for this WAR
Average Session Alive Time - the average alive time of sessions for this WAR
Max Session Alive Time - the maximum alive time of sessions for this WAR
--
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