[JBoss-dev] Suggestion for JBoss-Tomcat !
Hi, Thank you very much for providing a full-function J2EE server for our developers to testing. I use Apache for Web Server. In the JBoss document, it said that can use Apache as the Web Server. Since the Tomcat is embbed in JBoss2.1, and it also will call the server.xml in Tomcat. But it will not producr a file called "mod_jk.conf-auto", so I can't use Apache to be the Web Server easily. So I hope the enxt release of JBoss can add a function to produce that file automatically as Tomcat done. Secondly, I can use Apache as the Web Server for JBoss-Tomcat, it can run JSP/Servelt sucessfully, but failed to load EAR(Enterprised Application). Best regatds, Eric ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-414854 ] res-jndi-name always prefixed with java:
Bugs item #414854, was updated on 2001-04-09 03:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=414854group_id=22866 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: res-jndi-name always prefixed with java: Initial Comment: The ApplicationMetaData importJbossXml always prefixes the value of res-jndi-name elements with java: which makes it impossible to access resources that are not under the java: context. One example are the JMS queue and topic factories which are bound under the top level names TopicConnectionFactory and QueueConnectionFactory respectively. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=414854group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] ApplicationMetaData always prefixes the res-jndi-name element with java:/
The ApplicationMetaData importJbossXml always prefixes the value of res-jndi-name elements from jboss.xml with java:/ which makes it impossible to access resources that are not under the java: context. One example are the JMS queue and topic factories which are bound under the top level names TopicConnectionFactory and QueueConnectionFactory respectively. Why the assumption that all resources accessed by EJBs must be under the java:/ context? The following valid jboss.xml descriptor results in an incorrect link to java:/QueueConnectionFactory under the java:comp/env/jms/QueFactory EJB ENC. jboss enterprise-beans session ejb-nameENCBean/ejb-name resource-ref resource-nameQueFactory/resource-name res-ref-namejms/QueFactory/res-ref-name /resource-ref /session /enterprise-beans resource-managers resource-manager res-class="" res-nameQueFactory/res-name res-jndi-nameQueueConnectionFactory/res-jndi-name /resource-manager /resource-managers /jboss ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite index.html
User: juhalindfors Date: 01/04/09 08:13:25 Modified:.index.html Log: Bugzilla link redirected to SourceForge Bug Tracker Added links for submitting patches and RFEs. Revision ChangesPath 1.7 +3 -1 newsite/index.html Index: index.html === RCS file: /cvsroot/jboss/newsite/index.html,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- index.html2001/04/01 17:51:11 1.6 +++ index.html2001/04/09 15:13:25 1.7 @@ -176,7 +176,9 @@ a class="linkmenu" href="business/lists.html"Mailing Lists/abr a class="linkmenu" href="business/testimonials.html"Success Stories/aa class="linkmenu" href="#FIXME"/a - a class="linkmenu" href="bugzilla/index.html"Bugzilla/abr + a class="linkmenu" href="http://sourceforge.net/tracker/?func=addgroup_id=22866atid=376685"Submit a Bug/abr + a class="linkmenu" href="http://sourceforge.net/tracker/?func=addgroup_id=22866atid=376687"Submit a Patch/abr + a class="linkmenu" href="http://sourceforge.net/tracker/?func=addgroup_id=22866atid=376688"Submit a RFE/abr a class="linkmenu" href="business/faq.html"FAQ/abr /td td valign="top"img src="pictures/tb5.gif"/td ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: newsite index.html
please re-enter them at sourceforge, I'm not aware of any tools that would allow us to move the items automatically. -- Juha At 17:16 9.4.2001 +0100, you wrote: Hi, -Original Message- From: [EMAIL PROTECTED] Modified:.index.html Log: Bugzilla link redirected to SourceForge Bug Tracker Added links for submitting patches and RFEs. What are the plans for the old bugzilla items - are they going to be moved across - or are you relying on the important items being re-entered "as and when" ? Thanks in advance, Chris === = This electronic message (email) and any attachments to it are subject to copyright and are sent for the personal attention of the addressee. Although you may be the named recipient, it may become apparent that this email and its contents are not intended for you and an addressing error has been made. This email may include information that is legally privileged and exempt from disclosure. If you have received this email in error, please advise us immediately and delete this email and any attachments from your computer system.Rabobank International is the trading name of Coperatieve Centrale Raiffeisen-Boerenleenbank B.A. which is incorporated in the Netherlands. Registered with the Registrar of Companies for England Wales No. BR002630 and regulated by the SFA for the conduct of investment business in the UK. The presence of this footnote also confirms that this email has been automatically checked by Rabobank International for the presence of computer viruses prior to it being sent, however, no guarantee is given or implied that this email is virus free upon delivery. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jnp/src/main/org/jnp/interfaces NamingContext.java
User: starksm Date: 01/04/09 13:50:27 Modified:src/main/org/jnp/interfaces NamingContext.java Log: Fix the author tag Revision ChangesPath 1.6 +4 -3 jnp/src/main/org/jnp/interfaces/NamingContext.java Index: NamingContext.java === RCS file: /cvsroot/jboss/jnp/src/main/org/jnp/interfaces/NamingContext.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- NamingContext.java2001/04/09 06:46:50 1.5 +++ NamingContext.java2001/04/09 20:50:27 1.6 @@ -31,8 +31,9 @@ * description * * @see related - * @author $Author: starksm $ - * @version $Revision: 1.5 $ + * @author oberg + * @author [EMAIL PROTECTED] + * @version $Revision: 1.6 $ */ public class NamingContext implements Context, java.io.Serializable @@ -797,4 +798,4 @@ } } // Inner classes - -} \ No newline at end of file +} ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib idb.jar
User: binaryfeed Date: 01/04/09 16:04:07 Modified:src/lib idb.jar Log: Updating to 3.26 version of InstantDB -- this version has a deadlock bug fix. Revision ChangesPath 1.3 +721 -691 jboss/src/lib/idb.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [JBoss-user] bug when server is under load
I've moved this over to jboss-dev, where this bit will seem more appropriate. danch wrote: For what it's worth, I've seen similiar behavior under heavy threading (see archives under JBoss vs. Orion or Performance). I'm suspicious of the transaction interceptor (just because it seems to take about half of the time used in processing a request), but the code looks good. The message you're seeing (which I saw also in a multithreaded test) is particularly disturbing because the way JBoss' stateless session instance pool works, there should never be contention for a stateless session bean (as far as I can tell at any rate - I may be wrong). Well, what can I say: when I'm wrong I'm wrong. This has nothing to do with locks on beans. This was a lock on an internal bits of the JBoss transaction manager. The JBoss tm is written so that it attempts to reuse 'TxCapsule' instances by pooling them up in SoftReferences in a linked list. The problem is that they're not _quite_ available for reuse when the get put into the free list - they still have to do a hueristic check (and with trace on, throw something in the log) before they're unlocked. There _is_ a bit of a race condition here: it's possible for the capsule to get reused before (or while) it's doing its hueristic checks, which could potentially prevent the right thing from happening if a hueristic exception needs to happen. That, however, is highly unlikely in the test you're running. As far as fixing this bit of a race condition goes, I see two possiblilities: 1. Release the instance in the finally clause. Problem is that there are plenty of cases where it shouldn't be release, leading to a flag for it. 2. Make the method that initializes the capsule for re-use lock it. That way he'll wait for the hueristic checks to happen before blowing away the various state and status fields. We'll still see this message, but won't have this bit of a race condition behind it. If nobody objects, I'll implement option 2 tommorrow eve. For the record, there are some other things that make me nervous in this tm code: the TxCapsule and TransactionImpl have a circular dependency and in the process of cleaning up, the TransactionImpl will lose his referece to the TxCapsule before TxCapsule.commit() has actually returned to TransactionImpl.commit(). This just makes me nervous, like I said. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
