Antwort: RE: [JBoss-dev] JBossMQ rewrite
Hi Nathan, thanks for the information. I already have seen your first CVS code. Is there any further information available about the planed design and feature set ? You already gave some interesting insights about the p2p feature. When using jms in an enterprise production environment - as we would like to do - the following aspects are of even more importance ( and most of these isues are not handled very well in the current JBossMQ implementation ) (1) EFFICIENT handling of large / high numbers of PERSISTENT topic and queue messages (2) message redelivery / message throttling clustering / failover (3) messaging system monitoring / administration I there a way to participate in the your ongoing rewrite ? Regards Ulf Nathan Phelps [EMAIL PROTECTED] Gesendet von: [EMAIL PROTECTED] 15.06.2003 00:00 Bitte antworten an jboss-development An:[EMAIL PROTECTED] Kopie: Thema:RE: [JBoss-dev] JBossMQ rewrite JBossMQthe current code basewill continue to ship with JBoss 3.2 which is, and will remain for some time, the production version. Therefore, making changes to the current code base IS NOT worthless. However, I am working on a brand new implementation with assistance from Adrian, Bela, Bill, Tom Elrod, and Troy Daley. The framework code has recently been checked in to the jboss-jms module in CVS. It is early, but a start. In addition to the traditional client-server oriented JMS we're working on, at Bela's suggestion, I was able to implement a pure p2p implementation of the JMS topic messaging domain that does non-durable subscribers over JavaGroups. At Bill's request, we're going to get this code out there quickly (July). To my knowledge this will be the first pure p2p (server-less) JMS implementation in open source and it will provide very fast in-firewall publish and subscribe over multicast. Thanks, Nathan Phelps JMS/JBoss (Reloaded) Project Lead JBoss Group, L.L.C. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, June 13, 2003 4:45 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] JBossMQ rewrite Can anyone give me some informations about the current state of the announced rewrite of JBossMQ for JBoss 4 ? Does it still make sense to implement needed features on the current JBossMQ implementation ? I don't want to spend time on something that gets nuked in short time :-) Regards Ulf --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss (Branch_3_0/linux1) Compilation failed
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === 09:24 Jun 16 java version 1.4.1_02 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) build.sh: Executing: /home/jbossci/jbossci2/jboss-head/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger -Dinstall.id=testbuild release Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property configure-project: [echo] groups: default [echo] modules: common,aop,naming,remoting,jmx,system,cache,j2ee,transaction,persistence,server,blocks,security,messaging,connector,varia,cluster,aspects,management,console,jetty,jboss.net,iiop _buildmagic:modules:most: == == == Executing 'most' in module 'common'... == == compile-mbean-sources: [mkdir] Created dir: /home/jbossci/jbossci2/jboss-head/common/output/gen/classes BUILD FAILED file:/home/jbossci/jbossci2/jboss-head/common/build.xml:119: Could not create task or type of type: jmxdoclet. Ant could not find the task or a class this task relies upon. This is common and has a number of causes; the usual solutions are to read the manual pages then download and install needed JAR files, or fix the build file: - You have misspelt 'jmxdoclet'. Fix: check your spelling. - The task needs an external JAR file to execute and this is not found at the right place in the classpath. Fix: check the documentation for dependencies. Fix: declare the task. - The task is an Ant optional task and optional.jar is absent Fix: look for optional.jar in ANT_HOME/lib, download if needed - The task was not built into optional.jar as dependent libraries were not found at build time. Fix: look in the JAR to verify, then rebuild with the needed libraries, or download a release version from apache.org - The build file was written for a later version of Ant Fix: upgrade to at least the latest release version of Ant - The task is not an Ant core or optional task and needs to be declared using taskdef. Remember that for JAR files to be visible to Ant tasks implemented in ANT_HOME/lib, the files must be in the same directory or on the classpath Please neither file bug reports on this problem, nor email the Ant mailing lists, until all of these causes have been explored, as this is not an Ant bug. Total time: 3 seconds ===Mon Jun 16 09:24:15 BST 2003 ===Linux quarks2 2.4.20-18.7 #1 Thu May 29 06:51:53 EDT 2003 i686 unknown ===java version 1.4.1_02 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-559628 ] Incorrectly throwing RollbackException
Bugs item #559628, was opened at 2002-05-23 17:43 Message generated for change (Comment added) made by aparup You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=559628group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 7 Submitted By: Michael Hussey (mhussey) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrectly throwing RollbackException Initial Comment: Using bean managed persistence, and container managed transactions, if the ejbStore method of an entity bean fails by throwing an EJBException, a javax.transaction.RollbackException is thrown instead of a javax.transaction.TransactionRolledBackException. This is a problem because the client will not be able to get a nested exception to find the original problem. For example, in our case, our EJBException wraps an exception describing which unique constraint was violated. The user needs that nested exception to modify his/her entry on the screen to successfully update the object. Weblogic throws its own exception in this case which extends RollbackException and has methods to obtain the nested exception. They also should be throwing TransactionRolledBackException for portability, but at least their solution is useable in the current form. I'm using jboss 2.4.4 windows 2000 ejb 2.0 dtd commit option A for the entity. -- Comment By: Aparup Banerjee (aparup) Date: 2003-06-16 15:34 Message: Logged In: YES user_id=786442 Plz Assign This to me -- Comment By: Michael Hussey (mhussey) Date: 2002-05-28 22:42 Message: Logged In: YES user_id=357070 if you interpret the call to ejbStore as a method invocation on the bean, instead of some helper method called by the container, then it should throw TransactionRolledBackException because the bean method (ejbStore) runs in the context of the callers transaction. -- Comment By: Michael Hussey (mhussey) Date: 2002-05-28 22:20 Message: Logged In: YES user_id=357070 I'm looking at the EJB 2.0 specifications from Sun: Please see table 15 on page 375. Or clarifying text on page 379 If the exception or error happened during the processing of a client invoked method, throw the java.rmi.RemoteException to the client if the client is a remote client or throw the javax.ejb.EJBException to the client if the client is a local client. If the instance exe-cuted in the client#8217;s transaction, the Container should throw the javax.transac-tion. TransactionRolledbackException to a remote client or the javax.ejb.TransactionRolledbackLocalException to a local client, because it provides more information to the client. (The client knows that it is fruitless to continue the transaction.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=559628group_id=22866 --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Antwort: RE: [JBoss-dev] JBossMQ rewrite
Hi Ulf, (2) message redelivery / message throttling clustering / failover since Nathan's design is based on JavaGroups, these issues are JavaGroups issues: - Message retransmission is handled by JavaGroups. - Failover: what do you understand by failover ? - Throttling: we are working on a multicast flow control protocol, JG currently ships with one, but it has a number of bugs and needs further work. I'm also working on a new flow control protocol. Also, note that you can run JG with TCP as transport, then you essentially have the classic JMS client-server implementation. (3) messaging system monitoring / administration I there a way to participate in the your ongoing rewrite ? Give us some more time; Nathan essentially designed the serverless JMS last weekend... -- Bela Ban http://www.javagroups.com Cell: (408) 316-4459 --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Antwort: RE: [JBoss-dev] JBossMQ rewrite
Ulf, Our primary goal with JMS reloaded is to address the items you highlighted. Adrian and I had a very interesting discussion about number one, and Bill and I discussed clustering a bit in SF last week. So we are certainly focused on number 1 and 2. Number 3 is less of a concern to me right now. Overall, however, our goals are certainly aligned. I'm going to be putting together a formilized project plan next week that I'll publish on the website. From it, you and I should be able to determine where you have the time and skill to contriute the most. Thanks, Nathan Phelps JMS/JBoss (Reloaded) Project Lead JBoss Group, L.L.C. Quoting [EMAIL PROTECTED]: Hi Nathan, thanks for the information. I already have seen your first CVS code. Is there any further information available about the planed design and feature set ? You already gave some interesting insights about the p2p feature. When using jms in an enterprise production environment - as we would like to do - the following aspects are of even more importance ( and most of these isues are not handled very well in the current JBossMQ implementation ) (1) EFFICIENT handling of large / high numbers of PERSISTENT topic and queue messages (2) message redelivery / message throttling clustering / failover (3) messaging system monitoring / administration I there a way to participate in the your ongoing rewrite ? Regards Ulf Nathan Phelps [EMAIL PROTECTED] Gesendet von: [EMAIL PROTECTED] 15.06.2003 00:00 Bitte antworten an jboss-development An: [EMAIL PROTECTED] Kopie: Thema: RE: [JBoss-dev] JBossMQ rewrite JBossMQ?the current code base?will continue to ship with JBoss 3.2 which is, and will remain for some time, the production version. Therefore, making changes to the current code base IS NOT worthless. However, I am working on a brand new implementation with assistance from Adrian, Bela, Bill, Tom Elrod, and Troy Daley. The framework code has recently been checked in to the jboss-jms module in CVS. It is early, but a start. In addition to the traditional client-server oriented JMS we're working on, at Bela's suggestion, I was able to implement a pure p2p implementation of the JMS topic messaging domain that does non-durable subscribers over JavaGroups. At Bill's request, we're going to get this code out there quickly (July). To my knowledge this will be the first pure p2p (server-less) JMS implementation in open source and it will provide very fast in-firewall publish and subscribe over multicast. Thanks, Nathan Phelps JMS/JBoss (Reloaded) Project Lead JBoss Group, L.L.C. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, June 13, 2003 4:45 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] JBossMQ rewrite Can anyone give me some informations about the current state of the announced rewrite of JBossMQ for JBoss 4 ? Does it still make sense to implement needed features on the current JBossMQ implementation ? I don't want to spend time on something that gets nuked in short time :-) Regards Ulf --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossMQ rewrite
On the marketing front... Reloaded for the matrix is a great idea but will have too short a shelflife :) plus what we are doing is truly revolutionary so... Start hooking your wagon on that marketing speed train, marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Phelps Sent: Saturday, June 14, 2003 6:00 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBossMQ rewrite JBossMQthe current code basewill continue to ship with JBoss 3.2 which is, and will remain for some time, the production version. Therefore, making changes to the current code base IS NOT worthless. However, I am working on a brand new implementation with assistance from Adrian, Bela, Bill, Tom Elrod, and Troy Daley. The framework code has recently been checked in to the jboss-jms module in CVS. It is early, but a start. In addition to the traditional client-server oriented JMS we're working on, at Bela's suggestion, I was able to implement a pure p2p implementation of the JMS topic messaging domain that does non-durable subscribers over JavaGroups. At Bill's request, we're going to get this code out there quickly (July). To my knowledge this will be the first pure p2p (server-less) JMS implementation in open source and it will provide very fast in-firewall publish and subscribe over multicast. Thanks, Nathan Phelps JMS/JBoss (Reloaded) Project Lead JBoss Group, L.L.C. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, June 13, 2003 4:45 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] JBossMQ rewrite Can anyone give me some informations about the current state of the announced rewrite of JBossMQ for JBoss 4 ? Does it still make sense to implement needed features on the current JBossMQ implementation ? I don't want to spend time on something that gets nuked in short time :-) Regards Ulf --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697- 6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Antwort: RE: [JBoss-dev] JBossMQ rewrite
Nathan's design will not be based on JavaGroups, but will rather use JavaGroups as one type of transport mechanism. I would rather see JBoss Remoting used as an abstraction with JavaGroups as a plugin rather than JavaGroups at the center of things. BUTdon't let this requirement hold you up from getting a first iteration in place. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bela Ban Sent: Monday, June 16, 2003 1:12 PM To: [EMAIL PROTECTED] Subject: Re: Antwort: RE: [JBoss-dev] JBossMQ rewrite Hi Ulf, (2) message redelivery / message throttling clustering / failover since Nathan's design is based on JavaGroups, these issues are JavaGroups issues: - Message retransmission is handled by JavaGroups. - Failover: what do you understand by failover ? - Throttling: we are working on a multicast flow control protocol, JG currently ships with one, but it has a number of bugs and needs further work. I'm also working on a new flow control protocol. Also, note that you can run JG with TCP as transport, then you essentially have the classic JMS client-server implementation. (3) messaging system monitoring / administration I there a way to participate in the your ongoing rewrite ? Give us some more time; Nathan essentially designed the serverless JMS last weekend... -- Bela Ban http://www.javagroups.com Cell: (408) 316-4459 --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Antwort: RE: [JBoss-dev] JBossMQ rewrite
Bill Burke wrote: Nathan's design will not be based on JavaGroups, but will rather use JavaGroups as one type of transport mechanism. Don't get all nervous; that's what I meant. 2 transports, one is the traditional c/s, the other one is implemented using JavaGroups. I would rather see JBoss Remoting used as an abstraction with JavaGroups as a plugin rather than JavaGroups at the center of things. Tom, Jeff, Nathan and I have tentatively scheduled JBoss bootcamp in Atlanta to be the place and time for an in-depth discussion of whether Remoting can accommodate a one-to-many paradigm in addition to a one-to-one paradigm. Nathan already has a thin abstraction layer over the transport, for both traditional and serverless design. -- Bela Ban http://www.javagroups.com Cell: (408) 316-4459 --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Antwort: RE: [JBoss-dev] JBossMQ rewrite
I'm pretty excited about the JavaGroups implementation. Should scale quite well. I also really liked the idea of the AppServer being just another subscriber for durable topics. Should be interesting how all this develops over the next few months. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bela Ban Sent: Monday, June 16, 2003 2:28 PM To: [EMAIL PROTECTED] Subject: Re: Antwort: RE: [JBoss-dev] JBossMQ rewrite Bill Burke wrote: Nathan's design will not be based on JavaGroups, but will rather use JavaGroups as one type of transport mechanism. Don't get all nervous; that's what I meant. 2 transports, one is the traditional c/s, the other one is implemented using JavaGroups. I would rather see JBoss Remoting used as an abstraction with JavaGroups as a plugin rather than JavaGroups at the center of things. Tom, Jeff, Nathan and I have tentatively scheduled JBoss bootcamp in Atlanta to be the place and time for an in-depth discussion of whether Remoting can accommodate a one-to-many paradigm in addition to a one-to-one paradigm. Nathan already has a thin abstraction layer over the transport, for both traditional and serverless design. -- Bela Ban http://www.javagroups.com Cell: (408) 316-4459 --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Antwort: RE: [JBoss-dev] JBossMQ rewrite
As Bela and I have recently discussed with Tom Elrod, we all think that exposing JavaGroups as a transport of the remoting framework is indeed the best approach. However, I struggle with how the client-server nature of the remoting framework maps to the client-client nature of mulicast. I think this can indeed be overcome. However, as Tom doesn't have much time to spend on it, I think the road I'm gong to go down is to code directly to JavaGroups right now, and abstract it later. However, the real important point here FOR EVERYONE TO GET is that the multicast implementation is just ONE implementation of the client-side JMS interfaces. We will also support the traditional client-server based implementation that the new code is building toward. The only reason I'm even talking about the multicast stuff is because Bela showed me just how JavaGroups makes it so simple to implement and it will give us an opportunity to get something out the door in short order. Additionally, multicast will always provide better performance for pub/sub then a traditional client-server design. So for clients that want in-firewall messaging that is super fast, the multicast stuff will best serve their needs. For clients that need Internet messaging, etc. the traditional design will be used. We are VERY focused on building a best-of-breed JMS implementation. The current code causes us pain and that is all the motivation we need. I was very encouraged to talk to the guys last week and gather ideas. Andrian Brock is brilliant and has all sorts of ideas for the new JMS codebase that have all grown out of his dealings with the old codebase. We will not repeat the mistakes of the old codebase which is why we're starting anew from scratch. I'm going to get the project page on the website set up to better communicate the plan (which is something I should have done long ago) over the next week. Oh, and to address Marc's comment on the reloaded thing... that is just a code name for now--it sounds better then saying rewrite. The branding is clearly JMS/JBoss. Thanks, Nathan Phelps JMS/JBoss Project Lead JBoss Group, L.L.C. Quoting Bill Burke [EMAIL PROTECTED]: Nathan's design will not be based on JavaGroups, but will rather use JavaGroups as one type of transport mechanism. I would rather see JBoss Remoting used as an abstraction with JavaGroups as a plugin rather than JavaGroups at the center of things. BUTdon't let this requirement hold you up from getting a first iteration in place. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bela Ban Sent: Monday, June 16, 2003 1:12 PM To: [EMAIL PROTECTED] Subject: Re: Antwort: RE: [JBoss-dev] JBossMQ rewrite Hi Ulf, (2) message redelivery / message throttling clustering / failover since Nathan's design is based on JavaGroups, these issues are JavaGroups issues: - Message retransmission is handled by JavaGroups. - Failover: what do you understand by failover ? - Throttling: we are working on a multicast flow control protocol, JG currently ships with one, but it has a number of bugs and needs further work. I'm also working on a new flow control protocol. Also, note that you can run JG with TCP as transport, then you essentially have the classic JMS client-server implementation. (3) messaging system monitoring / administration I there a way to participate in the your ongoing rewrite ? Give us some more time; Nathan essentially designed the serverless JMS last weekend... -- Bela Ban http://www.javagroups.com Cell: (408) 316-4459 --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] New Affordable Voice Chat Solution
Title: Hello Hello, Now you can have a full featured voice chat solution and much more for a fraction of the cost that has been available until now. Please take a moment to compare: » One low payment starting at $50.00 with No annual fees . » Extremely user friendly » Excellent sound quality » Integrated browser for web presentation » Sophisticated text chat » Password protection of rooms » A full spectrum of moderator features » Share and send web pages » Lock the room for private meetings Take charge of those meetings or seminars with the ability to audio mute, Text mute, clear the current speaker, cue or kick users out of the room for complete traffic control. Recording Feature Now you can record events and presentations with a single click. Your recording includes all voice chat, text chat and web pages pushed during the session and can be archived and displayed at a later date through a simple 3-step process. 1 Enter a chat room and start recording. 2. Create your presentation 3. Upload the result to your web site. Then watch the entire presentation with voice, slides, and text be reproduced completely Create the ultimate presentation about the company's best product line. Create an on-line course on a program that your boss wants you to teach to the company next week. Create a multi-media tour of your website. With the easiest recording feature around you can have your presentations uploaded to your web site in minutes. The Broadcaster feature. Ask us about the most recent feature of iVocalize: Broadcaster. Broadcast LIVE all sound and web pages to users using the iVocalize Player. Your audience can listen in and watch your presentation without actually participating in the room. Perfect for Web seminars, virtual meetings, talk radio, and more. Check it out at http://talkingcommunities.com To be removed and never again receive information about iVocalize, click here Thanks, George Buys Voice Chat solution at it's best. http://www.talkingcommunities.com Phone: 760 778 2765 --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-751495 ] JBoss MBeanServer not found correctly
Bugs item #751495, was opened at 2003-06-09 18:50
Message generated for change (Comment added) made by ejort
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=751495group_id=22866
Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce Wilson (bgw2)
Assigned to: Adrian Brock (ejort)
Summary: JBoss MBeanServer not found correctly
Initial Comment:
JBoss version 3.0.7
OS: Solaris 2.8
JDK: java version 1.4.1_02
Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.1_02-b06)
Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode)
JBoss Bootstrap Environment
JBOSS_HOME: /export/home/jboss
JAVA: /export/home/ems/jre/bin/java
JAVA_OPTS: -server -Xms200m -Xmx800m
-Djava.endorsed.dirs=/export/home/jboss/server/insight/endorsed
-Djava.security.manager
-Djava.security.policy==/export/home/jboss/server/insight/conf/server.policy
-DinstallRoot=/export/home/ems -DsystemFile=/exp
ort/home/ems/server/sonusEms/data/sys/Insight.init
-DsystemConfigFile=/export/home/ems/weblogic/sonusEms/data/sys/SystemConf
ig.txt
-Djava.io.tmpdir=/export/home/jboss/server/insight/tmp
-Dsonus.jboss.home.dir=/export/home/jboss
-Dsonus.jboss.server.h
ome.dir=/export/home/jboss/server/insight
-Dorg.jboss.logging.Log4jService.catchSystemOut=false
-Dorg.jboss.logging.Log4jServi
ce.catchSystemErr=false -DISO_8859_1=UTF-8
-Dorg.mortbay.http.HttpRequest.maxFormContentSize=30
-Dsun.rmi.dgc.server.gcInt
erval=180 -Dsun.rmi.dgc.client.gcInterval=180
-Dprogram.name=run.sh
CLASSPATH:
/export/home/jboss/bin/run.jar:/export/home/ems/jre/lib/tools.jar
04:19:39,466 INFO [Server] JBoss Release: JBoss-3.0.7
CVSTag=JBoss_3_0_7
There are several locations in the JBoss code where the
code is looking up a
MBean that's deployed as part of JBoss; the code calls
MBeanServerFactory.findMBeanServer(null), then uses the
0-th (first) element
of the ArrayList that's returned. This doesn't work if
someone has created
additional MBeanServers in the same JVM - it seems that
the initial
MBeanServer created by JBoss doesn't stay first in the
list. It would be
better if the code would look for the MBeanServer by
its specific name
(jboss in the case of 3.0.7, at least).
Some places where the code uses the 0-th MBeanServer:
(1)
jboss-src/messaging/src/main/org/jboss/mq/sm/file/DynamicLoginModule.java:
// Lokup the state manager. FIXME
ArrayList l =
javax.management.MBeanServerFactory.findMBeanServer(null);
if (l != null l.size() 0) {
javax.management.MBeanServer server =
(javax.management.MBeanServer)l.get(0);
sm =
(DynamicStateManager)server.getAttribute( smObjectName,
Instance);
}
If the correct MBeanServer isn't found, an exception
like the following
seems to occur when JBoss starts up and attempts to
start up JMS:
19:06:17,899 ERROR [DynamicLoginModule] Failed to load
DynamicSecurityManager
javax.management.InstanceNotFoundException:
jboss.mq:service=StateManager is not registered.
at
org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:362)
at
org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:413)
at
org.jboss.mq.sm.file.DynamicLoginModule.initialize(DynamicLoginModule.java:53)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
javax.security.auth.login.LoginContext.invoke(LoginContext.java:662)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:129)
at
javax.security.auth.login.LoginContext$4.run(LoginContext.java:610)
at
java.security.AccessController.doPrivileged(Native Method)
at
javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:607)
at
javax.security.auth.login.LoginContext.login(LoginContext.java:534)
at
org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:462)
at
org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:417)
at
org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:244)
at
org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:219)
at
org.jboss.mq.security.SecurityManager.authenticate(SecurityManager.java:157)
at
org.jboss.mq.security.ServerSecurityInterceptor.authenticate(ServerSecurityInterceptor.java:51)
at
org.jboss.mq.server.TracingInterceptor.authenticate(TracingInterceptor.java:649)
Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
This is not consistent with the move to extract the metadata parsing from the current deployers into filters or interceptors associated with the deployers. The key issue is to support transformation of multiple versions of the various descriptors into metadata used by the current deployer. Converting the XSLSubDeployer into a filter for the different transformations that need to be supported is also something that make more sense than leaving this as a deployer. We also need the ability for multiple deployers to operation on a given deployment if we do not already. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, June 15, 2003 9:32 PM Subject: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment I've modified the deployment system to allow for multiple xml deployment descriptors. XSLSubDeployer can be configured via the Properties valued DdNameToKeyMap property to import the specified dds and store them in the DeploymentInfo under the specified key. The properties lines look like dd-name=KEY. I've also added the new DeploymentInfoURIResolverFactory which can resolve uris to documents in the current deployment info or documents in other DeploymentInfo mbeans. URIs are of the form jboss-di://deployment-info-name#key#xpath expression. The deployment-info-name and xpath-expression are optional. The DeploymentInfoDocumentURIResolver is now obsolete. I've discovered that use of two # characters in a URI is ungrammatical so the first will be changed to ! shortly. I've simplified the ejb container mbeans to remove common code to the Container class and allow deployment of MDBs with arbitrary interfaces per the ejb 2.1 spec. However, only jms MessageListener MDBs can be deployed at the moment. Deployment proceeds by constructing and deploying an ActivationSpec xmbean instance from the ejb 2.0 mdb dd. Finally, I've modified message delivery to always use the jmsra jca 1.5 adapter and correspondingly removed the asf classes. thanks david jencks /** * David Jencks * Partner * Core Developers Network * http://www.coredevelopers.net **/ --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-753718 ] Mismatching MBean attribute names in RARDeployment.java
Bugs item #753718, was opened at 2003-06-13 03:53 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=753718group_id=22866 Category: JBossCX Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Brian Wallis (bwallis42) Assigned to: Adrian Brock (ejort) Summary: Mismatching MBean attribute names in RARDeployment.java Initial Comment: Linux (Mandrake 9.1) Sun JDK 1.4.1_01 Running jboss version 3.0.7 (but error persists into 3.2) Reproduce: In the jmx-console JMX Agent View, find the jboss.jca section and click on the first RARDeployment service MBean link, mine was: * name=JBoss JDBC XATransaction ResourceAdapter,service=RARDeployment and you get the stack trace attached. The reason seems to be a mismatch in attribute names for the DynamicMBean RARDeployment. getAttribute() uses RARMetaData and the name setup in setupMBeanInfo() is RARMetaDataElement. The source file is jbosscx/src/main/org/jboss/resource/RARDeployment.java and the mismatched names are on lines 122 and 194 -- Comment By: Adrian Brock (ejort) Date: 2003-06-16 21:42 Message: Logged In: YES user_id=9459 Fixed in 3.0 and 3.2 CVS -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=753718group_id=22866 --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss (HEAD/winxp) Test Results: 96 % ( 1299 / 1347 ) - nearly there - who is gonna get us to 100%!
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === JBoss daily test results SUMMARY Number of tests run: 1347 Successful tests: 1299 Errors:28 Failures: 20 [time of test: 2003-06-16.23-21 GMT] [java.version: 1.4.1_02] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.1_02-b06] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows XP] [os.arch: x86] [os.version: 5.1] See http://jboss1.kimptoc.net/winxp/logtests/testresults/reports/html//. for the junit report of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: StandaloneTest Test:testFieldInterception(org.jboss.test.aop.nonjunit.StandaloneTest) Type:error Exception: java.lang.InternalError Message: Test timeout - Suite: BankStressTestCase Test:org.jboss.deployment.DeploymentException: Could not create deployment: file:/F:/jboss/jboss-head-test/testsuite/output/lib/bankiiop.jar; - nested throwable: (MBeanException: org.jboss.deployment.DeploymentException: error in create of EjbModule: file:/F:/jboss/jboss-head-test/testsuite/output/lib/bankiiop.jar; - nested throwable: (java.lang.NullPointerException) Cause: org.jboss.deployment.DeploymentException: error in create of EjbModule: file:/F:/jboss/jboss-head-test/testsuite/output/lib/bankiiop.jar; - nested throwable: (java.lang.NullPointerException)) Type:error Exception: org.jboss.deployment.DeploymentException Message: Could not create deployment: file:/F:/jboss/jboss-head-test/testsuite/output/lib/bankiiop.jar; - nested throwable: (MBeanException: org.jboss.deployment.DeploymentException: error in create of EjbModule: file:/F:/jboss/jboss-head-test/testsuite/output/lib/bankiiop.jar; - nested throwable: (java.lang.NullPointerException) Cause: org.jboss.deployment.DeploymentException: error in create of EjbModule: file:/F:/jboss/jboss-head-test/testsuite/output/lib/bankiiop.jar; - nested throwable: (java.lang.NullPointerException)) - Suite: TreeCacheAopUnitTestCase Test:testSet(org.jboss.test.cache.test.aop.TreeCacheAopUnitTestCase) Type:error Exception: java.lang.reflect.UndeclaredThrowableException Message: - Suite: ReplTreeCacheUnitTestCase Test: testSyncRepl(org.jboss.test.cache.test.replicated.ReplTreeCacheUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: java.lang.NullPointerException - Suite: BmpUnitTestCase Test:testUserTransaction(org.jboss.test.cts.test.BmpUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: - Suite: BmpUnitTestCase Test:testServerFound(org.jboss.test.cts.test.BmpUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RuntimeException; nested exception is: java.lang.RuntimeException: Transaction marked for rollback, possibly a timeout - ===Tue Jun 17 01:34:46 GMTDT 2003 ===CYGWIN_NT-5.1 nog 1.3.22(0.78/3/2) 2003-03-18 09:20 i686 unknown unknown Cygwin ===java version 1.4.1_02 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
On Monday, June 16, 2003, at 01:53 PM, Scott M Stark wrote: This is not consistent with the move to extract the metadata parsing from the current deployers into filters or interceptors associated with the deployers. The key issue is to support transformation of multiple versions of the various descriptors into metadata used by the current deployer. Please explain your point of view. The XSLSubdeployer IS an interceptor. This change is in the direction of allowing a single chain of subdeployers that can deploy anything. Why would we want to preserve the current ejb metadata classes? Converting the XSLSubDeployer into a filter for the different transformations that need to be supported is also something that make more sense than leaving this as a deployer. We also need the ability for multiple deployers to operation on a given deployment if we do not already. As noted, my changes to XSLSubDeployer supply a considerable amount of this functionality. They are not proposed as a complete solution, but they do allow deployment of mdbs in accordance with the jca 1.5 spec. david jencks /** * David Jencks * Partner * Core Developers Network * http://www.coredevelopers.net **/ Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, June 15, 2003 9:32 PM Subject: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment I've modified the deployment system to allow for multiple xml deployment descriptors. XSLSubDeployer can be configured via the Properties valued DdNameToKeyMap property to import the specified dds and store them in the DeploymentInfo under the specified key. The properties lines look like dd-name=KEY. I've also added the new DeploymentInfoURIResolverFactory which can resolve uris to documents in the current deployment info or documents in other DeploymentInfo mbeans. URIs are of the form jboss-di://deployment-info-name#key#xpath expression. The deployment-info-name and xpath-expression are optional. The DeploymentInfoDocumentURIResolver is now obsolete. I've discovered that use of two # characters in a URI is ungrammatical so the first will be changed to ! shortly. I've simplified the ejb container mbeans to remove common code to the Container class and allow deployment of MDBs with arbitrary interfaces per the ejb 2.1 spec. However, only jms MessageListener MDBs can be deployed at the moment. Deployment proceeds by constructing and deploying an ActivationSpec xmbean instance from the ejb 2.0 mdb dd. Finally, I've modified message delivery to always use the jmsra jca 1.5 adapter and correspondingly removed the asf classes. thanks david jencks /** * David Jencks * Partner * Core Developers Network * http://www.coredevelopers.net **/ --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
The XSLSubdeployer is acting as an interceptor and a deployer. The transformation activity needs to be factored out from the subdeployer behavior. It makes no sense to add subdeployers that really do not deploy anything simply to achive the side effect of an interceptor. Futher, the deployers need to stop dealing with the descriptor xml document parsing and instead operate on the descriptor metadata object model. This allows for a 4.0 deployer to deal with previous version deployment decriptors as the transformation from 3.0, 3.2, 4.0 deployment descriptors to the current deployment metadata is done outside of the deployer by a filter. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 16, 2003 5:48 PM Subject: Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment On Monday, June 16, 2003, at 01:53 PM, Scott M Stark wrote: This is not consistent with the move to extract the metadata parsing from the current deployers into filters or interceptors associated with the deployers. The key issue is to support transformation of multiple versions of the various descriptors into metadata used by the current deployer. Please explain your point of view. The XSLSubdeployer IS an interceptor. This change is in the direction of allowing a single chain of subdeployers that can deploy anything. Why would we want to preserve the current ejb metadata classes? Converting the XSLSubDeployer into a filter for the different transformations that need to be supported is also something that make more sense than leaving this as a deployer. We also need the ability for multiple deployers to operation on a given deployment if we do not already. As noted, my changes to XSLSubDeployer supply a considerable amount of this functionality. They are not proposed as a complete solution, but they do allow deployment of mdbs in accordance with the jca 1.5 spec. david jencks /** * David Jencks * Partner * Core Developers Network * http://www.coredevelopers.net **/ --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Startup failures in head
A clean checkout of the current head branch is failing to complete correctly due to the following errors: 20:24:23,979 INFO [EJBDeployer] Creating 20:24:23,996 INFO [EJBDeployer] Created 20:24:23,998 INFO [XSLSubDeployer] Creating 20:24:24,032 ERROR [XSLSubDeployer] Initialization failed: org.dom4j.DocumentException: null Nested exception: null 20:24:24,033 WARN [ServiceController] Problem creating service jboss.ejb:service=ActivationSpecDeployer org.dom4j.DocumentException: null Nested exception: null at org.dom4j.io.SAXReader.read(SAXReader.java:342) at org.dom4j.io.SAXReader.read(SAXReader.java:246) at org.jboss.deployment.XSLSubDeployer.createService(XSLSubDeployer.java:348) at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:198) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:72) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:45) at org.jboss.mx.server.Invocation.invoke(Invocation.java:70) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:155) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:544) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:1036) at $Proxy13.create(Unknown Source) at org.jboss.system.ServiceController.create(ServiceController.java:307) at org.jboss.system.ServiceController.create(ServiceController.java:247) at org.jboss.system.ServiceController.create(ServiceController.java:344) at org.jboss.system.ServiceController.create(ServiceController.java:247) at org.jboss.system.ServiceController.create(ServiceController.java:344) at org.jboss.system.ServiceController.create(ServiceController.java:247) at org.jboss.system.ServiceController.create(ServiceController.java:344) at org.jboss.system.ServiceController.create(ServiceController.java:247) at org.jboss.system.ServiceController.create(ServiceController.java:344) at org.jboss.system.ServiceController.create(ServiceController.java:247) at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:72) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:45) at org.jboss.mx.server.Invocation.invoke(Invocation.java:70) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:155) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:544) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:172) at $Proxy6.create(Unknown Source) at org.jboss.deployment.SARDeployer.create(SARDeployer.java:194) at org.jboss.deployment.DeploymentInfo.create(DeploymentInfo.java:243) at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:72) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:45) at org.jboss.mx.server.Invocation.invoke(Invocation.java:70) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:155) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:544) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:1036) at $Proxy13.create(Unknown Source) at org.jboss.system.ServiceController.create(ServiceController.java:307) at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:72) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:45) at org.jboss.mx.server.Invocation.invoke(Invocation.java:70) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:155) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:544) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:748) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:593) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:558) at
[JBoss-dev] [ jboss-Bugs-755690 ] Source code shown in IExplore
Bugs item #755690, was opened at 2003-06-17 09:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=755690group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Amanpreet Singh (amanpreet_1980) Assigned to: Nobody/Anonymous (nobody) Summary: Source code shown in IExplore Initial Comment: Hi, i am developing a web application with Jboss3.2.0 as web application server with Jetty. while development we found that when we do the extension .jsp say http;/localhost/login.jsp it works well. but when i put the extension http://localhost/login.JSP it displays full code of my login.JSP in IExplore stumped !! Am I wrong or r u playing with developers?? and if i am right.. i am sorry to say this is my worst experience of a Application web server. never mind if i am wrong.. make me correct asap. i dont want to change the Jboss3.2.0-jetty. I am also surprised that I could not find jboss 3.2.0 with jetty or tomcat anymore on Jboss.org?? which i chose while developement. well can u tell me why dont u provide that version now..? thank you for consideration, Amanpreet Singh Software Engineer [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=755690group_id=22866 --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-755690 ] Source code shown in IExplore
Bugs item #755690, was opened at 2003-06-17 09:46 Message generated for change (Comment added) made by amanpreet_1980 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=755690group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Amanpreet Singh (amanpreet_1980) Assigned to: Nobody/Anonymous (nobody) Summary: Source code shown in IExplore Initial Comment: Hi, i am developing a web application with Jboss3.2.0 as web application server with Jetty. while development we found that when we do the extension .jsp say http;/localhost/login.jsp it works well. but when i put the extension http://localhost/login.JSP it displays full code of my login.JSP in IExplore stumped !! Am I wrong or r u playing with developers?? and if i am right.. i am sorry to say this is my worst experience of a Application web server. never mind if i am wrong.. make me correct asap. i dont want to change the Jboss3.2.0-jetty. I am also surprised that I could not find jboss 3.2.0 with jetty or tomcat anymore on Jboss.org?? which i chose while developement. well can u tell me why dont u provide that version now..? thank you for consideration, Amanpreet Singh Software Engineer [EMAIL PROTECTED] -- Comment By: Amanpreet Singh (amanpreet_1980) Date: 2003-06-17 10:07 Message: Logged In: YES user_id=802770 hi juhalindfors nevermind this was not an answer. anways can u pelase tell me are u an authorised person from JBoss to answer it or u r a user of this website. i am not clear about this website as well as i am new here. thankyou for response. Amanpreet Singh -- Comment By: Juha Lindfors (juhalindfors) Date: 2003-06-17 10:02 Message: Logged In: YES user_id=175239 Update to 3.2.2 and see if the problem persists. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=755690group_id=22866 --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-755690 ] Source code shown in IExplore
Bugs item #755690, was opened at 2003-06-17 07:16 Message generated for change (Comment added) made by juhalindfors You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=755690group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Amanpreet Singh (amanpreet_1980) Assigned to: Nobody/Anonymous (nobody) Summary: Source code shown in IExplore Initial Comment: Hi, i am developing a web application with Jboss3.2.0 as web application server with Jetty. while development we found that when we do the extension .jsp say http;/localhost/login.jsp it works well. but when i put the extension http://localhost/login.JSP it displays full code of my login.JSP in IExplore stumped !! Am I wrong or r u playing with developers?? and if i am right.. i am sorry to say this is my worst experience of a Application web server. never mind if i am wrong.. make me correct asap. i dont want to change the Jboss3.2.0-jetty. I am also surprised that I could not find jboss 3.2.0 with jetty or tomcat anymore on Jboss.org?? which i chose while developement. well can u tell me why dont u provide that version now..? thank you for consideration, Amanpreet Singh Software Engineer [EMAIL PROTECTED] -- Comment By: Juha Lindfors (juhalindfors) Date: 2003-06-17 07:32 Message: Logged In: YES user_id=175239 Update to 3.2.2 and see if the problem persists. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=755690group_id=22866 --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Monday, June 16, 2003 8:49 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment On Monday, June 16, 2003, at 01:53 PM, Scott M Stark wrote: This is not consistent with the move to extract the metadata parsing from the current deployers into filters or interceptors associated with the deployers. The key issue is to support transformation of multiple versions of the various descriptors into metadata used by the current deployer. Please explain your point of view. The XSLSubdeployer IS an interceptor. This change is in the direction of allowing a single chain of subdeployers that can deploy anything. Why would we want to preserve the current ejb metadata classes? Why? Because everybody is very familiar with them. Why? because its simple and easy to maintain and modify. Yes, the XML parsing needs to be moved to a separate module, but the classes themselves have held up fine. I will not allow you to add anything overly complex like the mess you did with datasources. David, you have never ever built a piece of software for JBoss that was even remotely intuitive to configure. Configuration is not your strength so please STAY AWAY from it. I'm warning you. If I see an XSLT translation anywhere within EJB land I will roll it back. Guys guys! These are configuration files! We're doing something seriously wrong here if we're doing XSLT transformations and jumping through hoops just to configure a bit of metadata. The implementation of configuration needs to be simple enough so that the casual JBoss contributor can easily add his/her little configuration tweak. All you're doing by adding all these configuration abstractions is putting up barriers for new developers. Bill --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Scott M Stark Sent: Monday, June 16, 2003 11:35 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment The XSLSubdeployer is acting as an interceptor and a deployer. The transformation activity needs to be factored out from the subdeployer behavior. It makes no sense to add subdeployers that really do not deploy anything simply to achive the side effect of an interceptor. Futher, the deployers need to stop dealing with the descriptor xml document parsing and instead operate on the descriptor metadata object model. This allows for a 4.0 deployer to deal with previous version deployment decriptors as the transformation from 3.0, 3.2, 4.0 deployment descriptors to the current deployment metadata is done outside of the deployer by a filter. Not sure I like this idea. Tell me why we need to support 3.2 and 3.0 descriptors in 4.0? I'd much rather a 3.2 component crap out gracefully in 4.0 than have to maintain 3 separate configuration mechanisms. I do like the idea of having a metamodel separate from XML parsing. BUT STILL, it is quite easy to navigate the current metadata/XML marriage that now exists in current configuration. Are you sure we're actually gaining any maintainability by changing the status quo? Bill --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
