[JBoss JIRA] Created: (EJBTHREE-2124) NPE in SetDefaultLocalBusinessInterfaceProcessor.process() -> Class.forName()
by Ondrej Žižka (JIRA)
NPE in SetDefaultLocalBusinessInterfaceProcessor.process() -> Class.forName()
-----------------------------------------------------------------------------
Key: EJBTHREE-2124
URL: https://jira.jboss.org/browse/EJBTHREE-2124
Project: EJB 3.0
Issue Type: Bug
Affects Versions: EAP 5
Environment: EAP 5.0.1
Reporter: Ondrej Žižka
STR:
1) Deploy the attached .jar (probably misconfigured) to EAP 5.0.1 and see the exception below.
---------------------------------------------------------------------------------------------------------------------------------------------------
21:18:04,734 ERROR [AbstractKernelController] Error installing to PostClassLoader: name=vfszip:/home/ondra/work/perf-eap/EAP-501/server/default/deploy/ejb3-calculator-001.jar/ state=ClassLoader mode=Manual requiredState=PostClassLoader
org.jboss.deployers.spi.DeploymentException: Error during deploy: vfszip:/home/ondra/work/perf-eap/EAP-501/server/default/deploy/ejb3-calculator-001.jar/
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:177)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:409)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:294)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at org.jboss.metadata.process.processor.ejb.jboss.SetDefaultLocalBusinessInterfaceProcessor.process(SetDefaultLocalBusinessInterfaceProcessor.java:114)
at org.jboss.metadata.process.chain.ejb.jboss.JBossMetaDataProcessorChain.process(JBossMetaDataProcessorChain.java:115)
at org.jboss.ejb3.deployers.Ejb3MetadataProcessingDeployer.deploy(Ejb3MetadataProcessingDeployer.java:115)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
... 24 more
21:18:04,735 WARN [HDScanner] Failed to process changes
org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
*** DEPLOYMENTS IN ERROR: Name -> Error
vfszip:/home/ondra/work/perf-eap/EAP-501/server/default/deploy/ejb3-calculator-001.jar/ -> org.jboss.deployers.spi.DeploymentException: Error during deploy: vfszip:/home/ondra/work/perf-eap/EAP-501/server/default/deploy/ejb3-calculator-001.jar/
DEPLOYMENTS IN ERROR:
Deployment "vfszip:/home/ondra/work/perf-eap/EAP-501/server/default/deploy/ejb3-calculator-001.jar/" is in error due to the following reason(s): java.lang.NullPointerException
at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:994)
at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:940)
at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.checkComplete(MainDeployerAdapter.java:128)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:416)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:294)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (JGRP-1401) RELAY: messages lost when relay coordinator crashes
by Bela Ban (Created) (JIRA)
RELAY: messages lost when relay coordinator crashes
---------------------------------------------------
Key: JGRP-1401
URL: https://issues.jboss.org/browse/JGRP-1401
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.1
When we have sites {A,B,C} and {X,Y,Z} (with relay coords A and X), during the time X leaves (or crashes) and Y taking over, all messages sent by the first site are not relayed to the second site.
Because the sites are autonomous, there won't be any retransmission of the dropped messages.
This can have an adverse affect, e.g. in Infinispan:
- Say key K is stored on A, B and Z
- Now we're updating K, on A and B, but before the change is relayed to the other site, X crashes
- If there is no rebalancing, e.g. because K is still to be stored on A, B and Z, since the update on Z was dropped, Z has a stale value !
SOLUTION 1:
- Have a backup coordinator B cache the last N messages in memory (with overflow to disk)
- A numbers relayed messages
- As soon as A has relayed message #50, it sends this info to B. Or, alternatively, this could be done periodically, or based on the number of relayed messages (e.g. every 10 messages)
- B can then purge those messages
- When A crashes, B runs a reconciliation protocol with X to determine whether to relay some backed up messages
- C now starts acting as backup relay to B
This solution is probably the simplest to implement, and doesn't require any code changes in Infinispan. However, there is still a chance of message loss if both the relay *and* the backup relay crash at the same time.
SOLUTION 2:
- After a crash (not a graceful leave !) of a relay coordinator, there has to be a full rebalancing of all keys
- This is wasteful though
- May not be needed, perhaps Infinispan could check whether a full rebalancing is required ?
--
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
12 years
[JBoss JIRA] (AS7-3081) Misplaced @PersistenceContext Causes Untraceable Deployment Failure
by Jim Brownfield (Created) (JIRA)
Misplaced @PersistenceContext Causes Untraceable Deployment Failure
-------------------------------------------------------------------
Key: AS7-3081
URL: https://issues.jboss.org/browse/AS7-3081
Project: Application Server 7
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 7.0.2.Final
Environment: Macintosh 10.7.2
Reporter: Jim Brownfield
Assignee: Scott Marlow
When deploying an ear file that contains an Entity bean with an inappropriate @PersistenceContext annotation, the following stacktrace is generated, and the deployment fails:
15:36:16,322 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-9) MSC00001: Failed to start service jboss.deployment.subunit."xxx.xxxxxx.xxxxx.deploy.ear"."xxx.xxxxxx.xxxxx.ejb-0.0.1-SNAPSHOT.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."xxx.xxxxxx.xxxxx.deploy.ear"."xxx.xxxxxx.xxxxx.ejb-0.0.1-SNAPSHOT.jar".PARSE: Failed to process phase PARSE of subdeployment "xxx.xxxxxx.xxxxx.ejb-0.0.1-SNAPSHOT.jar" of deployment "xxx.xxxxxx.xxxxx.deploy.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) [jboss-as-server-7.0.2.Final.jar:7.0.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_29]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_29]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_29]
Caused by: java.lang.IllegalArgumentException: Class level annotations must provide a name.
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processClass(JPAAnnotationParseProcessor.java:233)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processPersistenceAnnotations(JPAAnnotationParseProcessor.java:127)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.deploy(JPAAnnotationParseProcessor.java:90)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) [jboss-as-server-7.0.2.Final.jar:7.0.2.Final]
... 5 more
The IllegalArgumentException gives no data for the annotation, the class, or any relevant data to the cause. I built JBoss debug from source to discover that the culprit in my case was a misplaced PersistenceContext annotation in an entity bean. The offending annotation had actually existed in a version of our code running in JBoss 4 without error.
--
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
12 years
[JBoss JIRA] Created: (JBAS-8316) Simple command line installer
by Brian Stansberry (JIRA)
Simple command line installer
-----------------------------
Key: JBAS-8316
URL: https://jira.jboss.org/browse/JBAS-8316
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Fix For: 7.0.0.M1
The AS is going to support two different running modes (see "Standalone Server" vs the rest of the discussion on http://community.jboss.org/docs/DOC-15215) and a flexible configuration for defining the "profile" a server will run. Profiles will not be represented via filesystem directories; rather they will be pure configuration.
The two different running modes will result in slightly different filesystem layouts -- see discussion in http://community.jboss.org/thread/153858.
The upshot of all this is using AS 7 will not be like previous versions where you could download the distribution, unzip, cd to bin/ and type ./run.sh -c some-std-config". Rather, I envision something like this:
1) download, unzip, cd bin
2) ./install.sh --someparamstotellitwhatyouwant
Params to tell it what you want would be whether you're running in standalone mode or full domain, which of a set of pre-packaged profiles you want, maybe some more stuff. From this, installer would create the appropriate filesystem layout, generate a domain.xml+host.mxl or standalone.xml
3) ./run.sh
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] Created: (AS7-784) Remove deployment doesn't really remove it
by Stan Silvert (JIRA)
Remove deployment doesn't really remove it
------------------------------------------
Key: AS7-784
URL: https://issues.jboss.org/browse/AS7-784
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.0.0.Beta3
Reporter: Stan Silvert
Assignee: Brian Stansberry
Steps:
1) Deploy something by copying an archive to the standalone/deployments directory.
2) Using the CLI or Console, remove the deployment.
i.e. /deployment=mywar.war/:remove
The deployment will stop, but the .war file and .deployed marker remain on the file system. When you restart the server, mywar.war will deploy again.
The problem is that "remove" doesn't really remove. It only stops the deployment until the next full restart. If you try to do some other operation on the deployment you will get a NoSuchElementException.
And from the file system, it looks like the deployment is still deployed.
So we need to do something to fully "remove" the deployment. Perhaps we need (yet another) marker file called .removed
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] Created: (JBAS-8791) log4j-appender seems not working in jboss-logging (AS6 final)
by Gregoire Botquin (JIRA)
log4j-appender seems not working in jboss-logging (AS6 final)
-------------------------------------------------------------
Key: JBAS-8791
URL: https://issues.jboss.org/browse/JBAS-8791
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Logging
Affects Versions: 6.0.0.Final
Reporter: Gregoire Botquin
Assignee: David Lloyd
We are using some custom logger based on log4j appenders. I made a jboss-logging.xml configuration but it seems that my log4j-appender doesn't log anything. I'm working in AS6 final version.
I made an example with a standard log4j appender (neither working). The category "com.sample" should be managed by the log4jappender. Every second the bean should write something, but nothing happens, the log file is not even created. I tried with other log4j loggers/ custom loggers and no success.
When activating CONSOLE handler the logs are correctly written in console, but when only using the log4j-appender nothing happens after server started.
The configuration file seems correct (?), but can't unfortunately check it against a documentation yet.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
<logging xmlns="urn:jboss:logging:6.0" xmlns:b="urn:jboss:bean-deployer:2.0">
<!-- ================================= -->
<!-- Preserve messages in a local file -->
<!-- ================================= -->
<!-- A time/date based rolling handler -->
<periodic-rotating-file-handler
file-name="${jboss.server.log.dir}/server.log"
name="FILE"
autoflush="true"
append="true"
suffix=".yyyy-MM-dd"> <!-- To roll over at the top of each hour, use ".yyyy-MM-dd-HH" instead -->
<error-manager>
<only-once/>
</error-manager>
<formatter>
<!-- To revert back to simple stack traces without JAR versions, change "%E" to "%e" below. -->
<!-- Uncomment this to get the class name in the log as well as the category
<pattern-formatter pattern="%d %-5p [%c] %C{1} (%t) %s%E%n"/>
-->
<!-- Uncomment this to log without the class name in the log -->
<pattern-formatter pattern="%d %-5p [%c] (%t) %s%E%n"/>
</formatter>
</periodic-rotating-file-handler>
<!-- ============================== -->
<!-- Append messages to the console -->
<!-- ============================== -->
<console-handler name="CONSOLE" autoflush="true" target="System.out">
<error-manager>
<only-once/>
</error-manager>
<level name="INFO"/>
<formatter>
<pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] %s%E%n"/>
</formatter>
</console-handler>
<log4j-appender name="Log4jAppender" class="org.apache.log4j.DailyRollingFileAppender">
<error-manager>
<only-once/>
</error-manager>
<level name="DEBUG"/>
<properties>
<!-- <property name="directory">${jboss.server.log.dir}/</property> -->
<property name="file">${jboss.server.log.dir}/log4j.log</property>
<property name="append">true</property>
<property name="datePattern">'.'yyyy-MM-dd</property>
</properties>
<formatter>
<pattern-formatter pattern="%d %-5p [%c] %m%n"/>
</formatter>
</log4j-appender>
<logger category="com.sample">
<level name="DEBUG"/>
<handlers>
<handler-ref name="Log4jAppender"/>
</handlers>
</logger>
<!-- ======================= -->
<!-- Setup the Root category -->
<!-- ======================= -->
<root-logger>
<!-- Set the root logger priority via a system property, with a default value. -->
<level name="${jboss.server.log.threshold:INFO}"/>
<handlers>
<handler-ref name="Log4jAppender"/>
<!--
<handler-ref name="CONSOLE"/>
<handler-ref name="FILE"/>
-->
</handlers>
</root-logger>
</logging>
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
package com.sample;
import javax.ejb.Schedule;
import javax.ejb.Stateless;
import org.apache.log4j.Logger;
//@Singleton
@Stateless
public class TestBean {
public static final Logger LOG = Logger.getLogger(TestBean.class);
public TestBean(){
System.out.println("TestBean is instantiated and should write someting in the log file");
LOG.info("This is information log");
}
@Schedule(second="*/1", minute="*",hour="*", persistent=false)
public void writeSomething(){
System.out.println("This should write something in the log file at scheduled times");
LOG.info("This is scheduled information log");
}
}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] Created: (JBAS-7468) Memory leak in org.jboss.security.plugins.authorization.JBossAuthorizationContext
by Ganesh Ingle (JIRA)
Memory leak in org.jboss.security.plugins.authorization.JBossAuthorizationContext
---------------------------------------------------------------------------------
Key: JBAS-7468
URL: https://jira.jboss.org/jira/browse/JBAS-7468
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: JBossAS-5.1.0.GA, JBossAS-5.0.1.GA, JBossAS-5.0.0.GA
Environment: JBoss Version: jboss-5.1.0.GA, OS: Linux (2.6.18-164.el5), Architecture: amd64 64bit, JVM: Java HotSpot(TM) 64-Bit Server VM (14.0-b16, mixed mode)
Reporter: Ganesh Ingle
Assignee: Anil Saldhana
Our use case (only security related portion is mentioned here):
Axis 1.4 webservice, standard J2EE declarative security through WEB-INF/web.xml, a http client sends soap request and BASIC auth information, the JBoss server performs authentication and authorization as per WEB-INF/web.xml configuration.
We did a performance/stability test on above web service. After 8.5 million requests the server gone out of memory. We did heap dump analysis using VisualVM tool and found that the class org.jboss.security.plugins.authorization.JBossAuthorizationContext is consuming most of the memory. This class has a memer array named "controlFlags", this array was showing 25.7 million ControlFlag entries.
When we investigated the code we found that there is one instance of JBossAuthorizationManager per security domain and this manager has one instance of JBossAuthorizationContext. For every authorization the JBossAuthorizationContext initializes authorization modules and pushes their control flags (instances of class ControlFlag) in member arrays. When the authorization is complete, a commit/abort is invoked on all modules and finally the "modules" array is cleared. However, the "controlFlags" array is not cleared. We checked the entire class, this array never gets cleared.
We changed the code to clear both "modules" and "controlFlags" array in a finally block in method JBossAuthorizationContext.authorize(final Resource resource, final Subject subject, final RoleGroup callerRoles). We ran a 50million test after this fix, the test was successful which proves the fix worked.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years