[JBoss JIRA] Created: (JBAS-4052) NPE in RepositoryClassLoader when loading BouncyCastle
by Jon Stevens (JIRA)
NPE in RepositoryClassLoader when loading BouncyCastle
------------------------------------------------------
Key: JBAS-4052
URL: http://jira.jboss.com/jira/browse/JBAS-4052
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ClassLoading
Affects Versions: JBossAS-4.0.5.GA
Reporter: Jon Stevens
Assigned To: Scott M Stark
Occasionally, I will get the exception below when trying to load the bouncy castle library. One would think it is a problem in BC, except for the fact that the NPE is clearly coming from JBoss's RepositoryClassLoader.
The hard part about this bug is that it happens some of the time and not other times. It's been impossible to reliably reproduce. Restarting the appserver/jvm causes the problem to go away and everything works just fine, but eventually it will happen again.
BC is being started in a @Service Bean. The start() method looks like this:
public void start() throws Exception
{
Security.addProvider(new BouncyCastleProvider());
}
Has anyone else seen this problem?
Caused by: java.security.NoSuchAlgorithmException: No such algorithm: AES/CBC/PKCS5Padding
at javax.crypto.Cipher.getInstance(DashoA13*..)
at javax.crypto.Cipher.getInstance(DashoA13*..)
at com.kink.heart.biz.system.EncryptorBean.encrypt(EncryptorBean.java:349)
... 73 more
Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: AES, provider: BC, class: org.bouncycastle.jce.provider.JCEBlockCipher$AES)
at java.security.Provider$Service.newInstance(Provider.java:1201)
... 76 more
Caused by: java.lang.NullPointerException
at org.jboss.mx.loading.RepositoryClassLoader.findClass(RepositoryClassLoader.java:620)
at java.lang.ClassLoader.loadClass(ClassLoader.java:316)
at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:464)
at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:405)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.security.Provider$Service.getImplClass(Provider.java:1218)
at java.security.Provider$Service.newInstance(Provider.java:1176)
... 76 more
--
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
16 years, 5 months
[JBoss JIRA] Created: (EJBTHREE-1603) EJB with dependencies upon itself fails deployment
by Andrew Lee Rubinger (JIRA)
EJB with dependencies upon itself fails deployment
--------------------------------------------------
Key: EJBTHREE-1603
URL: https://jira.jboss.org/jira/browse/EJBTHREE-1603
Project: EJB 3.0
Issue Type: Bug
Components: core
Reporter: Andrew Lee Rubinger
Assignee: Andrew Lee Rubinger
Priority: Critical
Fix For: 1.0.0-CR1
The following construct:
@Stateless
@Remote(SelfDependencyRemoteBusiness.class)
@Local(SelfDependencyLocalBusiness.class)
public class SelfDependencyBean implements SelfDependencyLocalBusiness, SelfDependencyRemoteBusiness
{
@EJB
private SelfDependencyLocalBusiness local;
...
}
...fails deployment:
21:55:09,828 WARN [MainDeployer] Failed to deploy: file:/home/alrubinger/business/jboss/wc/jbossas/projects/ejb3/trunk/testsuite/target/test-lib/ejbthreexxx.jar
org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
*** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
jboss.j2ee:jar=ejbthreexxx.jar,name=SelfDependencyBean,service=EJB3
-> <UNKNOWN jboss.j2ee:jar=ejbthreexxx.jar,name=SelfDependencyBean,service=EJB3>{Described:** UNRESOLVED Demands 'jndi:SelfDependencyBean/local-org.jboss.ejb3.test.ejbthreexxx.SelfDependencyLocalBusiness' **}
*** CONTEXTS IN ERROR: Name -> Error
<UNKNOWN jboss.j2ee:jar=ejbthreexxx.jar,name=SelfDependencyBean,service=EJB3> -> ** UNRESOLVED Demands 'jndi:SelfDependencyBean/local-org.jboss.ejb3.test.ejbthreexxx.SelfDependencyLocalBusiness' **
This is the cause of 3 regressions in "asynchronous" tests currently
--
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
16 years, 5 months
[JBoss JIRA] Created: (JBAS-7161) update bindingservice.beans/META-INF/bindings-jboss-beans.xml to rewrite redirectPort only conditionally
by Juergen none (JIRA)
update bindingservice.beans/META-INF/bindings-jboss-beans.xml to rewrite redirectPort only conditionally
--------------------------------------------------------------------------------------------------------
Key: JBAS-7161
URL: https://jira.jboss.org/jira/browse/JBAS-7161
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Other
Affects Versions: JBossAS-5.1.0.GA
Environment: 22:07:47,787 INFO [ServerInfo] Java version: 1.6.0_14,Sun Microsystems Inc.
22:07:47,788 INFO [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
22:07:47,788 INFO [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 14.0-b16,Sun Microsystems Inc.
22:07:47,788 INFO [ServerInfo] OS-System: Linux 2.6.9-22.0.1.ELsmp,amd64
Reporter: Juergen none
Attachments: bindings-jboss-beans.xml
update conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml:
<xsl:when test="(name() = 'redirectPort' and . = '8443' and /Server/Service/Connector[@port = .])">
As ajp connector services apache who in turn runs on port 80, I change ajp connector redirect port from default 8443 to https 443 (serviced by apache).
bindings-jboss-beans.xml unconditionally rewrites this binding.
I suggest a conditional rewrite, to change (any connectors) redirectPort only if there exists a tomcat connector to that runs on that port:
/Server/Service/Connector[@port = .]
I added ". = '8443'" as well, due to the fact that current binding config only rewrites 8080, 8009 8443 and not all connectors in server.xml
so /Server/Service/Connector[@port = .] is not really needed but works in case you add additional connectors to server.xml and change bindings-jboss-beans.xml to rewrite them as well
--
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
16 years, 5 months
[JBoss JIRA] Created: (JASSIST-85) IllegalAccessError when trying to call clone() on a class generated by ProxyFactory
by Tobias Meyer (JIRA)
IllegalAccessError when trying to call clone() on a class generated by ProxyFactory
-----------------------------------------------------------------------------------
Key: JASSIST-85
URL: https://jira.jboss.org/jira/browse/JASSIST-85
Project: Javassist
Issue Type: Bug
Affects Versions: 3.10.0.GA
Reporter: Tobias Meyer
Assignee: Shigeru Chiba
Hibernate 3.3 uses javassist (by default) to generate LazyInitializer Objects.
If a lazily loaded object implements the clone() method, and makes it public, there will be a runtime IllegalAccessError because the javassist proxy object exports the protected definition of Object.clone() instead of the definition in the MethodHandler's Interface.
The supplied patch makes the ProxyFactory to never reduce the visibility of a public method, even if implemented in a higher interface or the superclass.
Normally the java compiler would catch such an error, so this is assumed to be save.
Side effect is of course that a superclass method given to ProxyFactory might not be called as before because a public definition of the MethodHandler (Interface) overloads it.
--
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
16 years, 5 months
[JBoss JIRA] Created: (JGRP-1058) Split Cluster Never Recovers
by Stuart Jensen (JIRA)
Split Cluster Never Recovers
----------------------------
Key: JGRP-1058
URL: https://jira.jboss.org/jira/browse/JGRP-1058
Project: JGroups
Issue Type: Bug
Affects Versions: 2.6.7
Environment: Suse Linux
Reporter: Stuart Jensen
Assignee: Bela Ban
Priority: Critical
We are using JGroups Version 2.6.7 GA.
When a cluster spans at least two subnets, cluster members become disconnected and the only way to get them to reconnect to the cluster is to bring all of the processes down and bring them back up at the same time.
Bouncing one box at a time does not work. We have not seen this issue at all when all of the cluster members are in the same subnet.
Also happened in JGroups version 2.3 SP1.
This is an intermittent problem. Customers can normally run for several days without issue. Then the cluster will split and never fix itself. The only solution is to bring down all boxes.
The configuration that is active when the situation occurs is:
TCP(start_port=7801;external_addr=192.168.218.62):
TCPPING(initial_hosts=192.168.218.62[7801],192.168.128.62[7801];port_range=2;timeout=3500;num_initial_members=2;up_thread=true;down_thread=true):
MERGE2(min_interval=5000;max_interval=10000):
FD_SOCK(bind_addr=192.168.218.62):
FD(shun=true;timeout=2500;max_tries=5;up_thread=true;down_thread=true):
VERIFY_SUSPECT(timeout=2000;down_thread=false;up_thread=false):
pbcast.NAKACK(down_thread=true;up_thread=true;gc_lag=100;retransmit_timeout=3000):
pbcast.STABLE(desired_avg_gossip=20000;down_thread=false;up_thread=false):
pbcast.STATE_TRANSFER(down_thread=false;up_thread=false):
pbcast.GMS(join_timeout=60000;join_retry_timeout=60000;shun=true;print_local_addr=true;down_thread=true;up_thread=true)
I will be posting logs from the customer's site shortly.
--
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
16 years, 5 months
[JBoss JIRA] Created: (JGRP-840) Probe: provide API to programmatically execute queries and handle results
by Bela Ban (JIRA)
Probe: provide API to programmatically execute queries and handle results
-------------------------------------------------------------------------
Key: JGRP-840
URL: https://jira.jboss.org/jira/browse/JGRP-840
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 2.8
Currently, probe gets its results as a plain text, read from a datagram socket. An API would allow clients to gets responses aggregated by cluster member, in hashmap format. A client should be able to register and get notified whenever a response was received, and also retrieve the entire response set after a timeout.
Such an API makes it simpler for (e.g.) management applications to ping the cluster members and get information about them. Without the API, a client has to parse the returned text and arrange it into keys and values.
--
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
16 years, 5 months
[JBoss JIRA] Created: (JGRP-729) Support for NAT
by Bela Ban (JIRA)
Support for NAT
---------------
Key: JGRP-729
URL: http://jira.jboss.com/jira/browse/JGRP-729
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.8
Using external_addr, members behind NATs can communicate. However, members behind the same NAT cannot communicate as the NATted address is unknown [email by Terence Chan below].
We need to fix this with logical addresses, where the identity of a member is independent from the physical address
I am using JGroups to connect multiple servers in 2 zones, separated by
2 firewalls with Network Address Translation (NAT). The servers cannot
connect to each other due to NAT.
The situation is as follows:
-- Server A is behind Firewall A
-- Server A's local address is 10.253.40.80
-- Server A's NAT address is 10.253.2.80
-- Server B is behind Firewall B
-- Server B's local address is 172.16.80.33
-- Server B's NAT address is 10.1.1.39
When Server A initiates a connection to Server B, Server A sends a
"connection message" with source address = its local address (ie.,
10.253.40.80). Then, Server B replies a message with destination
address = the source address of the original message (ie., Server A's
local address). Since the local address (10.253.40.80) is not
reachable, so Server A cannot receive the reply.
Then I try to use "external_addr" attribute in the config file to set
the message's source address to the NAT address.
<TCP start_port="7900" external_addr="10.253.2.80" ...../>
But, since the message's source address becomes NAT address, servers
"within" the same network segment cannot send messages to each other,
because NAT address is ONLY recognized by servers outside the firewall.
For example, if Server A1 sends a message to another Server A2 in the
same network segment, A2 cannot reply to A1 because A2 doesn't recognize
A1's NAT address.
For your reference, below is the error message when Server B sends a
message to itself via its NAT address:
2008-03-27 20:36:55,871 DEBUG [ DownHandler (TCP)]
jgroups.protocols.TCP#sendToSingleMember() - failure sending message to
10.1.1.39:7000
java.lang.Exception: connection to 10.1.1.39:7000 could not be
established
at
org.jgroups.blocks.BasicConnectionTable.send(BasicConnectionTable.java:2
38)
--
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
16 years, 6 months
[JBoss JIRA] Created: (JBAS-6327) Servlet hangs in classloader
by Carlo de Wolf (JIRA)
Servlet hangs in classloader
----------------------------
Key: JBAS-6327
URL: https://jira.jboss.org/jira/browse/JBAS-6327
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-5.0.0.GA
Environment: Testsuite ejb3/servlet
Reporter: Carlo de Wolf
Assignee: Emanuel Muckenhuber
Priority: Critical
Fix For: JBossAS-5.0.1.CR1
"http-localhost%2F127.0.0.1-8080-1" daemon prio=1 tid=0x10ae3118 nid=0x6b36 runnable [0x7897c000..0x7897df20]
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:62)
at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:509)
at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:469)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:467)
- locked <0x9a2ff1a8> (a org.jboss.classloader.spi.base.BaseClassLoader)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:444)
at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:254)
at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:148)
at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:256)
at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1099)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:735)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:378)
- locked <0x9a2ff1a8> (a org.jboss.classloader.spi.base.BaseClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
- locked <0x9a757fb8> (a org.jboss.web.tomcat.service.WebCtxLoader$ENCLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
- locked <0x9a757fb8> (a org.jboss.web.tomcat.service.WebCtxLoader$ENCLoader)
at $Proxy156.getWarTestObject(Unknown Source)
at org.jboss.ejb3.test.servlet.servlets.EJBServlet.processRequest(EJBServlet.java:95)
at org.jboss.ejb3.test.servlet.servlets.EJBServlet.doGet(EJBServlet.java:146)
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(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
--
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
16 years, 6 months