[JBoss JIRA] Created: (JBMETA-195) NullPointerException when assinging a named invoker binding to a Remote bean
by Shadow Creeper (JIRA)
NullPointerException when assinging a named invoker binding to a Remote bean
----------------------------------------------------------------------------
Key: JBMETA-195
URL: https://jira.jboss.org/jira/browse/JBMETA-195
Project: JBoss Metadata
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBoss AS 5.1.0.CR1
Reporter: Shadow Creeper
Assignee: Alexey Loubyansky
NullPointerException thrown from Class.forName0() when assigning a named invoker binding to a Remote bean in JBoss AS 5.1.0.CR1.
Following the documentation on the Wiki (all the documentation I found said the same general thing), you create an invoker-proxy-bindings node in jboss.xml and assign it via invoker-proxy-binding-name in the session bean definition. I also tried assigning it via the @RemoteBinding(name="invoker-name-here") annotation instead but with the same result.
jboss.xml:
[code]
<?xml version="1.0"?>
<!DOCTYPE jboss PUBLIC "-//JBoss//DTD JBOSS 5.0//EN"
"http://www.jboss.org/j2ee/dtd/jboss_5_0.dtd">
<jboss>
<enterprise-beans>
<session>
<ejb-name>MyStatelessRemoteBean</ejb-name>
<configuration-name>Standard Stateless SessionBean</configuration-name>
<invoker-bindings>
<invoker>
<invoker-proxy-binding-name>
stateless-ssl-invoker
</invoker-proxy-binding-name>
</invoker>
</invoker-bindings>
</session>
</enterprise-beans>
<invoker-proxy-bindings>
<invoker-proxy-binding>
<name>stateless-ssl-invoker</name>
<invoker-mbean>jboss:service=invoker,type=jrmp,socketType=SSL</invoker-mbean>
<proxy-factory>org.jboss.proxy.ejb.ProxyFactory</proxy-factory>
<proxy-factory-config>
<client-interceptors>
<home>
<interceptor>org.jboss.proxy.ejb.HomeInterceptor</interceptor>
<interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>
<interceptor>org.jboss.proxy.TransactionInterceptor</interceptor>
<interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>
</home>
<bean>
<interceptor>org.jboss.proxy.ejb.StatelessSessionInterceptor</interceptor>
<interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>
<interceptor>org.jboss.proxy.TransactionInterceptor</interceptor>
<interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>
</bean>
</client-interceptors>
</proxy-factory-config>
</invoker-proxy-binding>
</invoker-proxy-bindings>
</jboss>
[/code]
jboss-service.xml:
[code]
<?xml version="1.0" encoding="UTF-8" ?>
<server>
<mbean code="org.jboss.security.plugins.JaasSecurityDomain"
name="jboss.security:service=JaasSecurityDomain,domain=RMI+SSL">
<constructor>
<arg type="java.lang.String" value="RMI+SSL"/>
</constructor>
<attribute name="KeyStoreURL">file:///home/shadow/example.keystore</attribute>
<attribute name="KeyStorePass">rmi+ssl</attribute>
</mbean>
<mbean code="org.jboss.invocation.jrmp.server.JRMPInvoker" name="jboss:service=invoker,type=jrmp,socketType=SSL">
<attribute name="RMIObjectPort">14445</attribute>
<attribute name="RMIClientSocketFactory">org.jboss.security.ssl.RMISSLClientSocketFactory</attribute>
<attribute name="RMIServerSocketFactory">org.jboss.security.ssl.RMISSLServerSocketFactory</attribute>
<attribute name="SecurityDomain">java:/jaas/RMI+SSL</attribute>
<depends>jboss.security:service=JaasSecurityDomain,domain=RMI+SSL</depends>
</mbean>
</server>
[/code]
Logged stacktrace:
<pre>
15:45:12,962 ERROR [AbstractKernelController] Error installing to PostClassLoader: name=vfsfile:/hom
e/shadow/debug/jboss-5.1.0.CR1/server/default/deploy/myApplication.ear/ state=ClassLoader mode=Manua
l requiredState=PostClassLoader
org.jboss.deployers.spi.DeploymentException: Error during deploy: vfsfile:/home/shadow/debug/jboss-5
.1.0.CR1/server/default/deploy/myApplication.ear/ejb.jar/
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.jav
a:49)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:177)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157
)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210
)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:34
8)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapte
r.java:117)
at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployActio
n.java:70)
at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileA
ction.java:53)
at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfile
Service.java:361)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:34
8)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(Abstrac
tProfileService.java:306)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.jav
a:271)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
at org.jboss.Main.boot(Main.java:216)
at org.jboss.Main$1.run(Main.java:546)
at java.lang.Thread.run(Thread.java:636)
Caused by: java.lang.NullPointerException
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.jboss.metadata.process.processor.ejb.jboss.SetDefaultLocalBusinessInterfaceProcessor.process
(SetDefaultLocalBusinessInterfaceProcessor.java:114)
at org.jboss.metadata.process.chain.ejb.jboss.JBossMetaDataProcessorChain.process(JBossMetaDataProc
essorChain.java:115)
at org.jboss.ejb3.deployers.Ejb3MetadataProcessingDeployer.deploy(Ejb3MetadataProcessingDeployer.ja
va:115)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
... 30 more
</pre>
--
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
13 years, 1 month
[JBoss JIRA] Created: (JGRP-931) Logical addresses: canonicalize UUIDs with IDs (shorts)
by Bela Ban (JIRA)
Logical addresses: canonicalize UUIDs with IDs (shorts)
-------------------------------------------------------
Key: JGRP-931
URL: https://jira.jboss.org/jira/browse/JGRP-931
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.9
Instead of using UUIDs as addresses, the cluster members should agree on shorts, e.g. 1 for A, 2 for B and so on, and use these instead of UUIDs.
This happens after a certain warmup time. E.g. the coord could assign these IDs, so they're unique.
IdAddress and UUID have to be able to do equals() or compareTo() with each other !
Advantage:
- we send a short (2 bytes) instead of a UUID (16 bytes)
- we use an IdAddress (class with a short) instead of a UUID. This is 6 bytes less per instance
- IdAddress might be faster with equals() and hashCode() than UUID
--
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
13 years, 1 month
[JBoss JIRA] Created: (JBBUILD-523) Issues with custom packaging in maven
by Paul Gier (JIRA)
Issues with custom packaging in maven
-------------------------------------
Key: JBBUILD-523
URL: https://jira.jboss.org/jira/browse/JBBUILD-523
Project: JBoss Build System
Issue Type: Task
Components: Maven
Reporter: Paul Gier
Fix For: Maven Build - Maint 2009
Steve ran into some issues when using custom packaging for the jdocbook plugin.
- Transitive dependency resolution does not work
- Two dependencies with the same packaging but different artifact handlers cannot both be resolved, because no info about the handler is encoded into the repo
- The plugin containing the custom packaging needs to programmatically register the artifact handler in addition to specifiying it in the components.xml
this has to be done by:
(1) retrieve the handler using @parameter expression="${component.org.apache.maven.artifact.handler.ArtifactHandler#jdocbook-style}"
(2) manually register it using project.getArtifact().setArtifactHandler( artifactHandler );
--
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
13 years, 1 month
[JBoss JIRA] Created: (JGRP-364) When using TCP_NIO, starting two nodes at the same time causes one of the nodes not to join group
by Matthew Todd (JIRA)
When using TCP_NIO, starting two nodes at the same time causes one of the nodes not to join group
-------------------------------------------------------------------------------------------------
Key: JGRP-364
URL: http://jira.jboss.com/jira/browse/JGRP-364
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Environment: linux 2.6 kernel x86_64 running java 1.5.0_06
Reporter: Matthew Todd
Assigned To: Bela Ban
I am testing a jgroups tcp_nio configuration using the draw demo.If I start up my 3 nodes one by one then everything works fine. However if I start up node 1, then attempt to start node 2 and 3 in parallel then only node 2 will work. Node 3 will be isolated and not see the other nodes and logs the following message:
org.jgroups.protocols.pbcast.ClientGmsImpl join
WARNING: join(192.158.70.200:7802) sent to 192.158.70.200:7800 timed out, retrying
I am starting the draw demo like this;
java -cp jgroups-all.jar:commons-logging.jar:concurrent.jar:jmxri.jar org.jgroups.demos.Draw -props test.xml
Here is the configuration for one of my nodes:
<config>
<TCP_NIO
bind_addr="192.158.70.200"
recv_buf_size="20000000"
send_buf_size="640000"
loopback="false"
discard_incompatible_packets="true"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
use_outgoing_packet_handler="true"
down_thread="false" up_thread="false"
enable_bundling="true"
start_port="7800"
end_port="7800"
use_send_queues="false"
sock_conn_timeout="300" skip_suspected_members="true"
/>
<MPING timeout="2000" num_initial_members="3" mcast_addr="229.6.7.8"
bind_addr="192.158.70.200" down_thread="false" up_thread="false"/>
<MERGE2 max_interval="100000"
down_thread="false" up_thread="false" min_interval="20000"/>
<FD_SOCK down_thread="false" up_thread="false"/>
<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/>
<pbcast.NAKACK max_xmit_size="60000"
use_mcast_xmit="false" gc_lag="0"
retransmit_timeout="300,600,1200,2400,4800"
down_thread="true" up_thread="true"
discard_delivered_msgs="true"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
down_thread="false" up_thread="false"
max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000"
down_thread="true" up_thread="true"
join_retry_timeout="2000" shun="true"
view_bundling="true"/>
<!-- <FC max_credits="2000000" down_thread="false" up_thread="false"
min_threshold="0.10"/>
<FRAG2 frag_size="60000" down_thread="false" up_thread="false"/> -->
<pbcast.STATE_TRANSFER/>
<!-- <pbcast.FLUSH down_thread="false" up_thread="false"/>-->
</config>
Node 2 and 3 have the same configuration except the port they bind to has been changed
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] Created: (JGRP-356) TCP_NIO: failure starting correctly with bundling enabled
by Bela Ban (JIRA)
TCP_NIO: failure starting correctly with bundling enabled
---------------------------------------------------------
Key: JGRP-356
URL: http://jira.jboss.com/jira/browse/JGRP-356
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.5
Stack is (default tcp-nio.xml with bundling enabled), the error is:
$ jg Draw -props ./tcp-nio.xml
-------------------------------------------------------
GMS: address is 127.0.0.1:7800
-------------------------------------------------------
** View=[127.0.0.1:7800|0] [127.0.0.1:7800]
0 [WARN] [TimeScheduler.Thread] TimeScheduler._run(): task org.jgroups.protocols.TP$Bundler$BundlingTimer@1c65216 took 20921ms to execute, please check why it is taking so long. It is delaying other tasks
<config>
<TCP_NIO
recv_buf_size="20000000"
send_buf_size="640000"
loopback="false"
discard_incompatible_packets="true"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
use_outgoing_packet_handler="false"
down_thread="false" up_thread="false"
enable_bundling="true"
start_port="7800"
use_send_queues="false"
sock_conn_timeout="300" skip_suspected_members="true"
reader_threads="8"
writer_threads="8"
processor_threads="8"
processor_minThreads="8"
processor_maxThreads="8"
processor_queueSize="100"
processor_keepAliveTime="-1"/>
<TCPPING timeout="3000"
down_thread="false" up_thread="false"
initial_hosts="${jgroups.tcpping.initial_hosts:localhost[7800],localhost[7801]}"
port_range="1"
num_initial_members="3"/>
<MERGE2 max_interval="100000"
down_thread="false" up_thread="false" min_interval="20000"/>
<FD_SOCK down_thread="false" up_thread="false"/>
<FD timeout="10000" max_tries="5" down_thread="false" up_thread="false" shun="true"/>
<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/>
<pbcast.NAKACK max_xmit_size="60000"
use_mcast_xmit="false" gc_lag="0"
retransmit_timeout="300,600,1200,2400,4800"
down_thread="false" up_thread="false"
discard_delivered_msgs="true"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
down_thread="false" up_thread="false"
max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000"
down_thread="false" up_thread="false"
join_retry_timeout="2000" shun="true"
view_bundling="true"/>
<FC max_credits="2000000" down_thread="false" up_thread="false"
min_threshold="0.10"/>
<FRAG2 frag_size="60000" down_thread="false" up_thread="false"/>
<pbcast.STREAMING_STATE_TRANSFER down_thread="false" up_thread="false"
use_flush="true" use_reading_thread="true"/>
<!-- pbcast.STATE_TRANSFER down_thread="false" up_thread="false" use_flush="false"/ -->
<pbcast.FLUSH down_thread="false" up_thread="false"/>
</config>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months