[JBoss JIRA] Created: (JBAS-7225) NullPointerException on 5.1.0 when using ejb-local-ref
by Rafael Ribeiro (JIRA)
NullPointerException on 5.1.0 when using ejb-local-ref
------------------------------------------------------
Key: JBAS-7225
URL: https://jira.jboss.org/jira/browse/JBAS-7225
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployers
Affects Versions: JBossAS-5.1.0.GA
Environment: Windows XP 32 bits / JDK 1.6.0_16
Reporter: Rafael Ribeiro
Assignee: Ales Justin
A NullPointerException is being thrown when a ejb-local-ref is specified on web.xml and only "description", "ejb-ref-name" and "ejb-link" are filled for the reference.
------------------------------------------------------------------------------------------------------------------------------------------------------------
web.xml fragment
------------------------------------------------------------------------------------------------------------------------------------------------------------
<ejb-local-ref>
<description>ejb/AbrtBean/local</description>
<ejb-ref-name>ejb/AbrtBean/local</ejb-ref-name>
<ejb-link>AbrtBean</ejb-link>
</ejb-local-ref>
------------------------------------------------------------------------------------------------------------------------------------------------------------
SessionBean fragment
------------------------------------------------------------------------------------------------------------------------------------------------------------
@Stateless(name="AbrtBean")
@Name("abrtBean")
public class AbrtBean implements AbrtLocal, AbrtRemote {
------------------------------------------------------------------------------------------------------------------------------------------------------------
Stacktrace for the issue:
------------------------------------------------------------------------------------------------------------------------------------------------------------
15:26:20,483 ERROR [AbstractKernelController] Error installing to PostClassLoade
r: name=vfszip:/C:/workspaces/drools/project/ear/target/ear-1.0.ear/ state=Class
Loader mode=Manual requiredState=PostClassLoader
org.jboss.deployers.spi.DeploymentException: java.lang.NullPointerException
at org.jboss.deployment.MappedReferenceMetaDataResolverDeployer.internal
Deploy(MappedReferenceMetaDataResolverDeployer.java:174)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(
AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(Deployer
Wrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(Deployer
sImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentLa
st(DeployersImpl.java:1299)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentLa
st(DeployersImpl.java:1248)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(Deployers
Impl.java:1100)
at org.jboss.dependency.plugins.AbstractControllerContext.install(Abstra
ctControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractContr
oller.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(Abstra
ctController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(Abstr
actController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(Abstr
actController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractContro
ller.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractContro
ller.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(Deployers
Impl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeploye
rImpl.java:702)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:830)
at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:604)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:258)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$4.run(HtmlAdaptorServle
t.java:391)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$4.run(HtmlAdaptorServle
t.java:388)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdap
torServlet.java:387)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdap
torServlet.java:312)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdap
torServlet.java:106)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doGet(HtmlAdaptorServle
t.java:81)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFi
lter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:235)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:191)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(Securit
yAssociationValve.java:190)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValv
e.java:92)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.proce
ss(SecurityContextEstablishmentValve.java:126)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invok
e(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedC
onnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:330)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:829)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
ss(Http11Protocol.java:598)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:44
7)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
at org.jboss.deployment.MappedReferenceMetaDataResolverDeployer.resolveE
jbLocalRefs(MappedReferenceMetaDataResolverDeployer.java:906)
at org.jboss.deployment.MappedReferenceMetaDataResolverDeployer.resolve(
MappedReferenceMetaDataResolverDeployer.java:743)
at org.jboss.deployment.MappedReferenceMetaDataResolverDeployer.internal
Deploy(MappedReferenceMetaDataResolverDeployer.java:170)
... 56 more
15:26:21,483 WARN [MainDeployer] Failed to deploy: file:/C:/workspaces/drools/p
roject/ear/target/ear-1.0.ear
------------------------------------------------------------------------------------------------------------------------------------------------------------
Seam JNDI pattern (not so relevant for the bug report)
------------------------------------------------------------------------------------------------------------------------------------------------------------
jndi-pattern="java:comp/env/ejb/#{ejbName}/local"
--
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
14 years, 7 months
[JBoss JIRA] Closed: (JBAS-2299) OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
by Dimitris Andreadis (JIRA)
[ https://jira.jboss.org/jira/browse/JBAS-2299?page=com.atlassian.jira.plug... ]
Dimitris Andreadis closed JBAS-2299.
------------------------------------
Fix Version/s: JBossAS-5.2.0.Beta1
JBossAS-6.0.0.Alpha1
Resolution: Done
The update is done (JBAS-6364), but it took some time to realise apache commons-beanutils is just a test dependency for some jsf/myfaces integration tests, it's not bundled with AS.
> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
> Key: JBAS-2299
> URL: https://jira.jboss.org/jira/browse/JBAS-2299
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Deployers
> Affects Versions: JBossAS-4.0.3RC2
> Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
> Reporter: Amar Syed
> Assignee: Dimitris Andreadis
> Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
> Attachments: commons-beanutils-1.8.0-SNAPSHOT.jar, commons-beanutils.jar, commons-digester-1.8.jar, Data.txt, deploy-undeploy.sh, paths-from-GC-roots.png, paths-from-gc-roots2.png, SampleApp.ear, Sampleapp.zip, struts.jar, test-jbas-2299.tar.gz, UndeploymentNotificationListener.java, UndeploymentNotificationListenerMBean.java
>
> Time Spent: 2 hours
> Remaining Estimate: 0 minutes
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3@c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder.
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4
--
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
14 years, 7 months
[JBoss JIRA] Updated: (JBAS-2520) HASingleton cannot be redeployed if stopSingleton() throws an Exception
by Dimitris Andreadis (JIRA)
[ https://jira.jboss.org/jira/browse/JBAS-2520?page=com.atlassian.jira.plug... ]
Dimitris Andreadis updated JBAS-2520:
-------------------------------------
Assignee: Scott Marlow (was: Scott Marlow (old account))
Use Scott's new account.
> HASingleton cannot be redeployed if stopSingleton() throws an Exception
> -----------------------------------------------------------------------
>
> Key: JBAS-2520
> URL: https://jira.jboss.org/jira/browse/JBAS-2520
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: JBossAS-4.0.3 SP1
> Environment: Java 1.5.0_04 on RHEL 4
> Reporter: Mirko Nasato
> Assignee: Scott Marlow
> Fix For: Backlog
>
> Attachments: ha-test.sar.zip
>
>
> If a Service MBean is a Clustered HA Singleton (it extends HASingletonSupport, or it is run by HASingletonController) and it throws an Exception when stopping then it is impossible to redeploy that Service until the whole JBoss is restarted.
> Any attempts at deploying the Service will results in the following error
> 15:47:43,766 WARN [ServiceController] Problem starting service hatest:service=MyHASingletonService
> java.lang.NullPointerException
> at org.jboss.ha.jmx.HAServiceMBeanSupport.getServiceHAName(HAServiceMBeanSupport.java:361)
> at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:195)
> ...
> and then
> --- MBeans waiting for other MBeans ---
> ObjectName: hatest:service=MyHASingletonService
> State: FAILED
> Reason: java.lang.NullPointerException
> I Depend On:
> jboss:service=DefaultPartition
> --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
> ObjectName: hatest:service=MyHASingletonService
> State: FAILED
> Reason: java.lang.NullPointerException
> I Depend On:
> jboss:service=DefaultPartition
--
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
14 years, 7 months
[JBoss JIRA] Updated: (JBAS-1888) Incorrect variable expansion in org.jboss.util.propertyeditor.PropertiesEditor
by Dimitris Andreadis (JIRA)
[ https://jira.jboss.org/jira/browse/JBAS-1888?page=com.atlassian.jira.plug... ]
Dimitris Andreadis updated JBAS-1888:
-------------------------------------
Assignee: Scott Marlow (was: Scott Marlow (old account))
Use Scott's new account.
> Incorrect variable expansion in org.jboss.util.propertyeditor.PropertiesEditor
> ------------------------------------------------------------------------------
>
> Key: JBAS-1888
> URL: https://jira.jboss.org/jira/browse/JBAS-1888
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Deployers
> Reporter: Bela Ban
> Assignee: Scott Marlow
> Priority: Minor
> Fix For: JBossAS-6.0.0.Alpha1
>
>
> When I use the ${jboss.server.data.dir} variable in the example below, it is correctly expanded:
> <attribute name="bla">${jboss.server.data.dir}</attribute>
> However, when I use it in a Properties attribute, the expansion removes backslashes on Windows, e.g. in the example below:
> <attribute name="CacheLoaderConfig">
> location = ${jboss.server.data.dir}/myCache
> </attribute>
> , I get c:JBoss3.2.7serverdefaultdata/myCache.
> Scott Stark's reply:
> The org.jboss.util.propertyeditor.PropertiesEditor which is what should be used for an attribute of type java.util.Properties does replace ${x} property references in values. The problem is that calling setProperty with the replacement value is not using an escaped string and so the win32 backslash is seen as a char escape sequence. Create a jira issue for this.
--
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
14 years, 7 months
[JBoss JIRA] Created: (JBREM-1150) Lease should update client list if PING invocation has same time as previous PING
by Ron Sigal (JIRA)
Lease should update client list if PING invocation has same time as previous PING
---------------------------------------------------------------------------------
Key: JBREM-1150
URL: https://jira.jboss.org/jira/browse/JBREM-1150
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.3, 2.5.1 (Flounder)
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.5.2 (Flounder), 2.2.3.SP1
When an org.jboss.remoting.lease is created, in response to org.jboss.remoting.MicroRemotingClientInvoker sending a PING, it has no clients. The next PING invocation, generated by org.jboss.remoting.LeasePinger.addClient(), supplies a list of clients. However, Lease updates its client list only if the timestamp in the InvocationRequest is greater than the timestamp of the previous InvocationRequest. Since the two PINGs that create a Lease could have the same timestamp, the test in Lease should be >= instead of >.
--
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
14 years, 7 months