[JBoss JIRA] Created: (EJBTHREE-1434) 5.0.0CR1: EJB refs across EARs don't work
by Juergen Zimmermann (JIRA)
5.0.0CR1: EJB refs across EARs don't work
-----------------------------------------
Key: EJBTHREE-1434
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1434
Project: EJB 3.0
Issue Type: Bug
Affects Versions: AS 5.0.0.CR1
Environment: JBoss 5.0.0.CR1, JDK 6u10beta
Reporter: Juergen Zimmermann
I'm having 2 different EARs and stateless session beans of the 2nd EAR are referencing stateless session beans of the 1st ear. It worked fine with 4.2.2
I'll attach a stripped down testcase:
* src.zip: source of projects for Eclipse w/ JBoss Tools
* hska.ear.zip: exploded EAR 1 (and zipped for transferring)
* testHska.ear.zip: exploded EAR 1 (and zipped for transferring)
src.zip:
* hska is the 1st EAR project
* hskaEJB contains the ejb module for hska
* testHska is the EAR project for the 2nd EAR
* testHskaEJB is the ejb module for testHska and references a SLSB of hskaEJB
* testHskaClient is an application client module for testHska using JUnit
--
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, 10 months
[JBoss JIRA] Created: (JBAS-7883) @Resource mail session injection, injects incrrect mail session
by Mark Lowe (JIRA)
@Resource mail session injection, injects incrrect mail session
---------------------------------------------------------------
Key: JBAS-7883
URL: https://jira.jboss.org/jira/browse/JBAS-7883
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-5.1.0.GA, JBossAS-5.0.1.GA
Environment: Linux 64 bit , sun JDK 1.6.0.14
Reporter: Mark Lowe
Please forgive me if I've posted this to the incorrect component or failed to find an existing bug, I did look.
I'm porting our applications from Jboss 4.2.3 and found the following problem injecting mail sessions in EJBs and Servlet components.
I have several mails sessions configured. For example
<mbean code="org.jboss.mail.MailService" name="jboss:service=MyMailServer1">
<attribute name="JNDIName">foo/MyMailServer1</attribute>
<attribute name="User">myuser</attribute>
<attribute name="Password">myuserpw</attribute>
<attribute name="Configuration">
<configuration>
</configuration>
</attribute>
<depends>jboss:service=Naming</depends>
</mbean>
The jndi tree is created and all is present and correct.
@Resource(name="MyMailServer1",mappedName="foo/MyMailServer1")
private Session session;
Returns the default mail session (java:/Mail). When I removed the java:/Mail session jboss find the last session from the configuration and arbitrarily injects it. I also tested this placing another configuration after the java:/Mail config, and the result was that the session configured below (i.e. last) was referenced.
In short to recreate the bug.
Create 2 additional mail sessions in a *-service.xml file. Deploy a servlet, ejb or other component that supports @Resource. Attempt to inject one of the custom sessions (not java:/Mail using @Resource(mappedName="[jndi name]".
I also attempted to force the issue using a resource-ref in jboss.xml matching the resource-ref-name with the @Resource(name=".") and using the jndi-name (in case the usage of mappedname as been changed since 4.2.3. ) With no result.
Assuming this is a real bug, workarounds?
--
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, 10 months
[JBoss JIRA] Created: (JBREM-1261) Prevent DOS attack on BisocketServerInvoker$SecondaryServerSocketThread
by Ron Sigal (JIRA)
Prevent DOS attack on BisocketServerInvoker$SecondaryServerSocketThread
-----------------------------------------------------------------------
Key: JBREM-1261
URL: https://issues.jboss.org/browse/JBREM-1261
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.3.SP3, 2.5.3.SP1
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.5.3.SP2, 2.2.3.SP4
>From the original bug report:
Exploiting and thus confirming this vulnerability is extremely simple: Simply
connect to the bisocket control connection (ie. "telnet <jboss-host>
<control-connection-port>") without sending any data on the connection. As long
as this connection is open, no clients can connect to the bisocket control port
because the connections are not accepted at server side.
The cause of this vulnerability is found in method
org.jboss.remoting.transport.bisocket.BisocketServerInvoker$SecondaryServerSocketThread.run(),
which contains the accept-loop for the bisocket control connection. After
having accepted a connection, the accept loop thread reads from the newly
created connection expecting the client to send an action code and a listener
id. If the client sends nothing, the accept loop thread will block in the read
call, causing no other connections to be accepted.
To fix, the accept loop thread should not do the read on the new connection.
Instead it should start a new thread that does the read
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (EJBTHREE-1429) SFSB replication soak testing
by Brian Stansberry (JIRA)
SFSB replication soak testing
-----------------------------
Key: EJBTHREE-1429
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1429
Project: EJB 3.0
Issue Type: Task
Components: Clustering
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: AS 5.0.0.CR2
Long running tests of SFSB replication under heavy load.
Should include:
1) Letting a significant percentage of sessions passivate and later activate.
2) Letting a significant percentage of sessions expire due to time out.
3) Invalidating remaining sessions after a while (i.e. don't use any sessions for the life of test; all get used and replaced after a while).
4) Perhaps, a low (say 1/1000) probability of failover.
--
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, 10 months