Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
The change is too big for a patch. I'd rather commit on a branch. Another option is to refactor it some more so that it becomes part of the new module that Nathan is working on. Either way, please let me know which way you prefer it. I have completed most of my clean up and the jms and mdb unit tests are once again passing with flying colors. The mailing list does not seem to have received a couple of emails I sent a few days back. Is there something wrong with the mailing list? Regards, Hiram On Fri, 2003-07-11 at 13:01, Scott M Stark wrote: > Hiram, no one sits around for months without interacting with the day > to day developers of JBoss > Group and then decides to commit a large change without it being > discussed. Some of > what you have most likely has merit but it has to be reviewed so either > submit it as a patch > or commit it to a branch off of head so that it can be reviewed for > incorporation. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > > > > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] Behalf Of > >> Hiram > >> Chirino > >> Sent: Wednesday, July 09, 2003 12:16 AM > >> To: [EMAIL PROTECTED] > >> Subject: Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite > >> > >> > >> Scott, > >> > >> Why does it matter? Nathan has not expressed interested in growing > >> from > >> the current JMS implementation. I've been waiting for several months > >> for the new general purpose implementation to 'appear' and it has not. > > > > There has been a skeleton since early Jun. > > > > > >> So it's time for me to start the engine again and make some needed > >> improvements to the current JBossMQ implementation. > >> > > > > Where have you been the past year when Adrian and Scott have been > > fixing > > this buggy MQ implementation? You failed to keep up the old stuff so > > please > > don't make it sound like you're coming to the rescue. > > > > I'm not so sure I want a total refactoring of the old JMS in the > > remoting > > subsystem and the interceptor chains and such. The current JMS > > rewrite by > > Nathan, Adrian, and Bela is going quite well and we will be replacing > > the > > old system in the fall. > > > > What I don't want is a CVS HEAD of the old JMS that doesn't look like > > the > > 3.2 series since it will be much harder to migrate 3.2 fixes to a CVS > > HEAD > > that has been totally refactored. The old JMS needs to live a bit > > beyond > > 4.0's release and 4.0 will not be released until the late late fall, > > between > > Thanksgiving and Christmas. I guess what I'm saying is that a lot of > > users > > will still depend on the old JMS for at least another year and we need > > some > > to have fluidity between 3.2 and 4.0. We're already experiencing the > > pain > > of an unnecessary rewrite of the Entity Container that is making it > > difficult to merge fixes in 3.2 to 4.0. I don't want the same thing to > > happen with a codebase that is going to be retired eventually anyways > > and > > that needs to live in depracated mode for awhile. > > > > > --- > This SF.Net email sponsored by: Parasoft > Error proof Web apps, automate testing & more. > Download & eval WebKing and get a free book. > www.parasoft.com/bulletproofapps1 > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development -- /** * Hiram Chirino * Partner * Core Developers Network **/ --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
On Tue, 2003-07-08 at 23:41, Nathan Phelps wrote: In line... > Hiram, > > As you may know, we are going in a different direction with JMS than the > original architecture coded by Norbert Lataille. We are doing a rewrite I guess I had it good. Norbert made a good start. At least basic pub/sub worked. That's better than starting from scratch. > so patches to the old JBossMQ have a limited lifetime. That means that > changes made to the old JBossMQ will most likely not be part of HEAD or > the distribution as we move forward. You may be right. or wrong. The current JMS will ship until there is a better replacement. Do you plan to replace the current implementation with the peer based implementation you have been working on? Regards, Hiram > > Thanks, > > Nathan Phelps > JMS Lead > JBoss Group, L.L.C. > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:jboss- > > [EMAIL PROTECTED] On Behalf Of Hiram Chirino > > Sent: Tuesday, July 08, 2003 8:41 PM > > To: [EMAIL PROTECTED] > > Subject: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite > > > > > > Hi guys, > > > > Over the past two weeks I have started to make a few improvements the > > current JBossMQ implementation that is in CVS HEAD. I would consider > a > > large porting of what I did refactoring to simplify the current code > > base to allow future growth without having to sacrifice current > features > > or performance. > > > > I just wanted to give provide an update on the development status of > the > > original JBossMQ client-server JMS implementation. > > > > Here's a summary of what has changed: > > > > - It exclusively uses the remoting subsystem for client server > > communications. The existing IL subsystem has been removed. The > > 'async' remoting protocol allows two way communications solely over > > client sockets (this should allow applet/firewalled clients to connect > > to the server). Multiple JMS connections made by the client will also > > share a singe pool of sockets to communicate with the server. > > - Manually creating JBossMQ ConnectionFactory objects have been > > simplified since a remoting URI takes care setting up most of the > > connection options. > > - The server interceptors have been simplified since they now operate > on > > a typeless invocations (it now matches the style of the other jboss > > interceptors) > > - The implementations for the p2p and pub/sub JMS API classes have > been > > consolidated since that is the direction that the JMS 1.1 API is > taking > > (being able to mix the us of p2p and pub/sub with in the same > session). > > - Many (almost all) of the bug fixes/performance enhancements made in > > the 3.2 branch have been ported forward. > > - All the PMs except JDBC2 have been removed to make it easier to more > > quickly make enhancements to the persistence manager interface. I > hope > > a cmp/jdo implementation can be created in the future. > > - the old org.jboss.mq.xml package that provided a simple xml dom was > > removed and all code that was using was changed to use dom4j instead. > > - JNDI Reference object handling was simplified (only StringRefs are > > used). > > - The sources were refactored so that the back-end messing server is > > much less coupled the javax.jms.* classes. The server side is still > > importing many of the JMSException classes, this can be cleaned up in > > the future. This might start to lead the way to allow this messaging > > server to support other messaging APIs (JavaSpaces?) > > > > Things to watch out for with this new version: > > - The jboss API to manually create ConnectionFactory and Destination > > objects has changed. Most users should not be affected since the JMS > > spec states that they should be using JNDI to get those objects. > > - Previous JBossMQ clients will not be able to connect to this new > > server version (since it is using remoting for communications). Those > > clients need to upgrade their jbossmq-client.jar. > > - The message format has changed so the new server will not be able to > > restore messages saved to persistence storage by the new server. > > > > I hope to commit the changes CVS in the next few days. I have 3 jms > > test cases that I still need to fix and then I still need to run the > MDB > > test cases. > > > > Regards, > > Hiram > > > > -- > > /** > > * Hiram Chirino
Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
Scott, Why does it matter? Nathan has not expressed interested in growing from the current JMS implementation. I've been waiting for several months for the new general purpose implementation to 'appear' and it has not. So it's time for me to start the engine again and make some needed improvements to the current JBossMQ implementation. Nathan, Your doing great work in the peer based JMS arena. But have you formulated a game plan for the rewrite of general purpose implementation? Right now I'm going down the route of simplifying our current c/s implementation down enough so that we can start taking it apart more easily if required to add the needed features. On Tue, 2003-07-08 at 23:00, Scott M Stark wrote: > And what interaction has there been with Nathan who originally responded to > the rewrite query? -- /****** * Hiram Chirino * Partner * Core Developers Network **/ --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
Hi guys, Over the past two weeks I have started to make a few improvements the current JBossMQ implementation that is in CVS HEAD. I would consider a large porting of what I did refactoring to simplify the current code base to allow future growth without having to sacrifice current features or performance. I just wanted to give provide an update on the development status of the original JBossMQ client-server JMS implementation. Here's a summary of what has changed: - It exclusively uses the remoting subsystem for client server communications. The existing IL subsystem has been removed. The 'async' remoting protocol allows two way communications solely over client sockets (this should allow applet/firewalled clients to connect to the server). Multiple JMS connections made by the client will also share a singe pool of sockets to communicate with the server. - Manually creating JBossMQ ConnectionFactory objects have been simplified since a remoting URI takes care setting up most of the connection options. - The server interceptors have been simplified since they now operate on a typeless invocations (it now matches the style of the other jboss interceptors) - The implementations for the p2p and pub/sub JMS API classes have been consolidated since that is the direction that the JMS 1.1 API is taking (being able to mix the us of p2p and pub/sub with in the same session). - Many (almost all) of the bug fixes/performance enhancements made in the 3.2 branch have been ported forward. - All the PMs except JDBC2 have been removed to make it easier to more quickly make enhancements to the persistence manager interface. I hope a cmp/jdo implementation can be created in the future. - the old org.jboss.mq.xml package that provided a simple xml dom was removed and all code that was using was changed to use dom4j instead. - JNDI Reference object handling was simplified (only StringRefs are used). - The sources were refactored so that the back-end messing server is much less coupled the javax.jms.* classes. The server side is still importing many of the JMSException classes, this can be cleaned up in the future. This might start to lead the way to allow this messaging server to support other messaging APIs (JavaSpaces?) Things to watch out for with this new version: - The jboss API to manually create ConnectionFactory and Destination objects has changed. Most users should not be affected since the JMS spec states that they should be using JNDI to get those objects. - Previous JBossMQ clients will not be able to connect to this new server version (since it is using remoting for communications). Those clients need to upgrade their jbossmq-client.jar. - The message format has changed so the new server will not be able to restore messages saved to persistence storage by the new server. I hope to commit the changes CVS in the next few days. I have 3 jms test cases that I still need to fix and then I still need to run the MDB test cases. Regards, Hiram -- /** * Hiram Chirino * Partner * Core Developers Network **/ --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why is JDOM version in JBoss so old
yes the replacment is dom4j. Check it out at dom4j.org Regards, Hiram --- Tom Coleman <[EMAIL PROTECTED]> wrote: > > Is there something that replaces JDOM in 4.x? > > JDOM can make XML experts out of dummies, and if > you're working with > XML-based apps, it's nice to have in the server > classpath. > > Scott Stark wrote: > > > > > ... On head jdom should be dropped. > > > > > --- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of > bandwidth! > No other company gives more support or power for > your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
That might be a problem if you have a big object graph. You get a big penalty even if you only modify a small peice of the object graph. You could do a shallow copy by getting a snapshot of the fields of the object. Then wrap up the children objects with "Versioned.makeVersioned(child)" when they are accessed. The cool thing is that you would not have any serialization at all. I know that there has to be some down-sides to this approach, help me figure them out. Regards, Hiram --- Bill Burke <[EMAIL PROTECTED]> wrote: > Yes, its a deep copy which is why I require > Serializable. > > new MarshalledObject(obj).get(); > > Maybe there is a better way to make copies? > > > -Original Message- > > From: > [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > Behalf Of Hiram > > Chirino > > Sent: Thursday, March 27, 2003 10:15 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] AOP versioned ACID > objects 1st iteration > > > > > > > > Bill, > > > > If you use versioning on a POJO that is a the top > of > > an object graph, will the children objects also be > > versions when they are modified??? > > > > I assume No. But I think it would make sense for > your > > Versioning interceptor to wrap up children objets > with > > the versioning proxy also when they are accessed. > > That way if you do a: > > > > pojo = (POJO)Versioned.makeVersioned(pojo); > > pojo.getAccount().getBalance().add(10.00); > > > > The modification of the Balance object will be > > versioned too. Does that make sense to you?? Do > you > > do this now?? > > > > Regards, > > Hiram > > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > > > > > > > > > -Original Message- > > > > From: > > > [EMAIL PROTECTED] > > > > > > > > > > [mailto:[EMAIL PROTECTED] > > > Behalf Of > > > > Karthik > > > > Sent: Thursday, March 27, 2003 1:25 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [JBoss-dev] AOP versioned ACID > > > objects 1st iteration > > > > > > > > > > > > Hi bill, > > > >The versioning of POJO is very good. I have > > > some issues here. If I > > > > version a object, then I have to maintain all > the > > > state in the same POJO > > > > > > How is this not the general case? All > application > > > code accesses the POJO > > > through the proxy. I am going to write a > > > constructor-pointcut that will > > > always return a proxy instead of the real POJO > on > > > construction. > > > > > > > which is not the general case and will bloat > the > > > code. The states are > > > > maintained in the helper classes. Also > defining > > > each POJO as versioned is > > > > meaningless. If new proxies are created for > each > > > transaction with the deep > > > > copy of all the state or maintain a pool and > > > synchronize the state after > > > > update, it will become real performance > > > bottleneck.How do you tackle this > > > > problem? > > > > > > There is only one proxy, but you are correct. > For > > > each transaction, a full > > > snapshot is taken of the real object. All > access to > > > the object is done > > > through one proxy. > > > > > > The performance hit is the full deep copy not > the > > > synchronization. > > > Synchronization is only: > > > > > > realObject = snapshot; > > > > > > Remember, we're optimistically locking here. > > > (Although I'd like to > > > optionally provide a transactional lock in the > near > > > future). > > > > > > The alternative solution is much much more > complex. > > > The biggest problem > > > being, how do you determine when a POJO's state > has > > > changed? For instance: > > > > > > Pojo.someHashMapField.get().setValue(blah). You > see > > > my point? > > > > > > A full deep copy greatly simplifies the code. > > > Simplicity == robustness. > > > Plus I'm not even sure versioned fields would be > > > better performing. Field > > > interception is quite expensive and versioned > fields > > > would need fiel
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
Bill, If you use versioning on a POJO that is a the top of an object graph, will the children objects also be versions when they are modified??? I assume No. But I think it would make sense for your Versioning interceptor to wrap up children objets with the versioning proxy also when they are accessed. That way if you do a: pojo = (POJO)Versioned.makeVersioned(pojo); pojo.getAccount().getBalance().add(10.00); The modification of the Balance object will be versioned too. Does that make sense to you?? Do you do this now?? Regards, Hiram --- Bill Burke <[EMAIL PROTECTED]> wrote: > > > > -Original Message- > > From: > [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > Behalf Of > > Karthik > > Sent: Thursday, March 27, 2003 1:25 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] AOP versioned ACID > objects 1st iteration > > > > > > Hi bill, > >The versioning of POJO is very good. I have > some issues here. If I > > version a object, then I have to maintain all the > state in the same POJO > > How is this not the general case? All application > code accesses the POJO > through the proxy. I am going to write a > constructor-pointcut that will > always return a proxy instead of the real POJO on > construction. > > > which is not the general case and will bloat the > code. The states are > > maintained in the helper classes. Also defining > each POJO as versioned is > > meaningless. If new proxies are created for each > transaction with the deep > > copy of all the state or maintain a pool and > synchronize the state after > > update, it will become real performance > bottleneck.How do you tackle this > > problem? > > There is only one proxy, but you are correct. For > each transaction, a full > snapshot is taken of the real object. All access to > the object is done > through one proxy. > > The performance hit is the full deep copy not the > synchronization. > Synchronization is only: > > realObject = snapshot; > > Remember, we're optimistically locking here. > (Although I'd like to > optionally provide a transactional lock in the near > future). > > The alternative solution is much much more complex. > The biggest problem > being, how do you determine when a POJO's state has > changed? For instance: > > Pojo.someHashMapField.get().setValue(blah). You see > my point? > > A full deep copy greatly simplifies the code. > Simplicity == robustness. > Plus I'm not even sure versioned fields would be > better performing. Field > interception is quite expensive and versioned fields > would need field > interception. > > The code is under: > varia/src/main/org/jboss/aop/plugins/Version*.java > testcase is under > testsuite/src/main/org/jboss/test/aop/bean/Version*.java > (take a look at the AOP DD under > testsuite/src/resource/aop/META-INF/jboss-aop.xml > too). > > Bill > > > > >Correct me if I am missing something. > > > >Where or when can get the code from the CVS? > > > > Thanks > > > > Karthi > > > > > -Original Message- > > > From: > [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] > > > Behalf Of Bill > > > Burke > > > Sent: Thursday, March 27, 2003 10:43 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] AOP versioned ACID > objects 1st iteration > > > > > > > > > > > > > > > > -Original Message- > > > > From: > [EMAIL PROTECTED] > > > > > [mailto:[EMAIL PROTECTED] > > > Behalf Of Jeff > > > > Haynie > > > > Sent: Wednesday, March 26, 2003 11:51 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [JBoss-dev] AOP versioned ACID > objects 1st iteration > > > > > > > > > > > > > > > > >JBoss Remoting is much more fabulous. We > need to get the > > > word out on > > > > it... > > > > > > > > I need to write some darn docs.. Too busy > trying to get a > > > new release > > > > out on our side. Not enough hours in a day. > > > > > > > > > > > > > I totally agree. And yes, a constructor > pointcut is the > > > way to go. > > > > The only downside of constructor pointcuts is > that > > > reflection bypasses > > > > the interception! > > > > > Same thing with field interception. The > problem is that unlike > > > > methods, you have to modify the bytecode of > the calling logic. > > > > > > > > Could you dynamically do an insertBefore into > the > > > CtConstructor of the > > > > advised class which would do the interception, > even on reflection? > > > > > > > > > > I'm not sure...The problem with Versioning and > Remoting is > > > that a proxy > > > object is required. You have to return a > different object > > > than the one > > > actually constructed. You getting me? I'm not > sure if this > > > can be done > > > within bytecode manipulation. I'll have to ask > the Javassist guys. > > > > > > > > I will write some testcases that put the > whole stack together with > > > > constructor pointcuts. > > > > > > > > > > I'm also working on the concept of an > abstract Container. > > > But you got > > > > me thinking t
RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
The AOP case is even more similar to the DP if you think of AOP like this: If the AOP intrumented methods are: < Interceptors are: [] The original (but renamed) object methods are: ( The object is: O An AOP stack then is: <[](O Which is almost the same as the DP case: |[](O Regards, Hiram > If an object is > > |(O > > | is the interface > ( are the methods to the object > O is the actual implementation > > or > (O for a pojo > > then using > > |[](O > is the DP approach where the [] interception is like > the current EJB > implementation and what Hiram was proposing to do in > the very beginning > > ([]O > is the current AOP approach for POJO's. > > > There shouldn't be a war in these two approaches and > the interface one > should systematically use DP > > marcf > __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Eclipse is so amazing...
Well, if you are willing to shell out some cash, then you might consider trying webshpere studio. Since it's built on eclipse, it has all the eclipse goodies plus a ton of other stuff like a jsp editor. Regards, Hiram --- Aleksandr Shneyderman <[EMAIL PROTECTED]> wrote: > > Hate to say this but netbeans (www.netbeans.org) > beats eclipse hands down. > > Hate to tell you but that thing is just damn slow. > What amazes me is that no matter how much RAM your > machine has NetBeans is just always hungry for it. > > > Does all of the below and lots more. Go take a > look at the module > > selection > > at www.netbeans.org/devhome and > > > http://www.netbeans.org/devhome/modules/by-module.html > > I am not sure about much more, but one thing I miss > from there is JSP editor. I have not seen any decent > eclipse JSP plugin yet. > > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Eclipse is so amazing...
--- Jason Dillon <[EMAIL PROTECTED]> wrote: > I think it is better to use the jars from the module > output directory, > cause the exact location under build/output will > change from version to > version. > true.. but it's easier to do a multiple selection in 2 or 3 directories rather than going through each project. > Is there any way to make Eclipse create jars? Or > any way to make it I think you can select a set of packages/classes and then use the export feature to export them to a jar. But I don't think this is what you are looking for. > conditionally compile stuff for 1.3 and others for > 1.4? Or a way to not that I know of > force it to use ant to do all compiles? Seems like > that would be best > to solve most problems. I've been able to get it to run our ant build files directly. You might have to go into the eclipse properties and add all the tools/lib/*.jar files to the ANT runtime classpath. > > So far I am pretty happy, but it is by no means > perfect. > I agree. Regards, Hiram > --jason > > > On Thursday, February 27, 2003, at 03:42 AM, Hiram > Chirino wrote: > > > > > I've tried it various ways.. lately I've been > doing > > the following: > > > > - compile source code manualy. > > - adjust eclipse build path by: adding the source > > folders of sub projects that I will be working > with as > > source folders. (the default is no good) > > - adjust eclipse build path by: adding all the > jars in > > the build/output/jboss*/lib and > > build/output/jboss*/client and > > build/output/jboss*/server/all/lib directories to > the > > project classpath. > > > > Regards, > > Hiram > > > > --- Nathan Phelps <[EMAIL PROTECTED]> wrote: > >> While we're on the subject of Eclipse... > >> > >> Can anyone give me some tips for working with the > >> JBoss source in > >> Eclipse via the built-in extssh client? I can > get > >> it all checked out, > >> but then it gets very confused about the package > >> names. It tries to do > >> j2ee.src.main.org.jboss.j2ee, > >> messaging.src.main.org.jboss.mq, etc. I > >> guess it wants individual projects for each > >> directory? > >> > >> I was hoping to set it up as a SINGLE project so > I > >> can just check out > >> the source and start working. I read the "The > >> Developing JBoss using > >> Eclipse HOWTO," but it only explores setting it > up > >> as multiple projects. > >> This question is echoed on the forums as well at > >> > > > http://www.jboss.org/forums/thread.jsp?forum=162&thread=28822. > >> > >> Up to now I've been using NetBeans, but I'd > really > >> like to get this up > >> and running on Eclipse with the JBoss IDE plug-in > >> and all if possible. > >> > >> Thanks, > >> > >> Nathan > >> > >> > >> > >> > > > --- > >> This SF.net email is sponsored by: Scholarships > for > >> Techies! > >> Can't afford IT training? All 2003 ictp students > >> receive scholarships. > >> Get hands-on training in Microsoft, Cisco, Sun, > >> Linux/UNIX, and more. > >> www.ictp.com/training/sourceforge.asp > >> ___ > >> Jboss-development mailing list > >> [EMAIL PROTECTED] > >> > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > __ > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, more > > http://taxes.yahoo.com/ > > > > > > > --- > > This SF.net email is sponsored by: Scholarships > for Techies! > > Can't afford IT training? All 2003 ictp students > receive scholarships. > > Get hands-on training in Microsoft, Cisco, Sun, > Linux/UNIX, and more. > > www.ictp.com/training/sourceforge.asp > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > --- > This SF.net email is sponsored by: Scholarships for > Techies! > Can't afford IT training? All 2003 ic
RE: [JBoss-dev] Eclipse is so amazing...
I've tried it various ways.. lately I've been doing the following: - compile source code manualy. - adjust eclipse build path by: adding the source folders of sub projects that I will be working with as source folders. (the default is no good) - adjust eclipse build path by: adding all the jars in the build/output/jboss*/lib and build/output/jboss*/client and build/output/jboss*/server/all/lib directories to the project classpath. Regards, Hiram --- Nathan Phelps <[EMAIL PROTECTED]> wrote: > While we're on the subject of Eclipse... > > Can anyone give me some tips for working with the > JBoss source in > Eclipse via the built-in extssh client? I can get > it all checked out, > but then it gets very confused about the package > names. It tries to do > j2ee.src.main.org.jboss.j2ee, > messaging.src.main.org.jboss.mq, etc. I > guess it wants individual projects for each > directory? > > I was hoping to set it up as a SINGLE project so I > can just check out > the source and start working. I read the "The > Developing JBoss using > Eclipse HOWTO," but it only explores setting it up > as multiple projects. > This question is echoed on the forums as well at > http://www.jboss.org/forums/thread.jsp?forum=162&thread=28822. > > Up to now I've been using NetBeans, but I'd really > like to get this up > and running on Eclipse with the JBoss IDE plug-in > and all if possible. > > Thanks, > > Nathan > > > > --- > This SF.net email is sponsored by: Scholarships for > Techies! > Can't afford IT training? All 2003 ictp students > receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, > Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Eclipse is so amazing...
+1 I use it all them time. The Refactoring support and the Quick Assist features rock. Regards, Hiram --- Jason Dillon <[EMAIL PROTECTED]> wrote: > I can not believe how fast, intelligent and > functional this little IDE. > I have tears in my eyes I am so pleased. Okay > perhaps I need to get > out more... but still. I think I am going to have > to say goodbye to > XEmacs. Perhaps I am just getting old and lazy... > > --jason > > > > --- > This SF.net email is sponsored by: Scholarships for > Techies! > Can't afford IT training? All 2003 ictp students > receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, > Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
I though what I sugested was KISS. Tx imporation is currently done at the invoker level. I want to keep it there but make it plugable via interceports at the invoker level. I guess it would be more KISS to just duplicate the code that is in the trunk invoker over to all ther other java based transports. But that seems more error prone to me. Regards, Hiram --- Bill Burke <[EMAIL PROTECTED]> wrote: > What I'm saying is, why add this complication? Do > we really need it? KISS. > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Behalf Of Hiram > Chirino > Sent: Tuesday, February 25, 2003 11:23 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is > still the best thing since > sliced bread > > > How about implementing some kind of seperate > interceptor framwork around > the client side and server side invocation layers?? > > David, if yoiu had a configurable way to plug in > your tx interceptors at > the invocation layer you would be ok right? I think > david just needs to > avoid duplicating the code that is in the trunk > invoker all over the place. > > Bill, how doable is that? > > Regards, > Hiram > >Bill Burke <[EMAIL PROTECTED]> wrote: > > > > IMHO, CORE client interceptors such as security > and tx should be written > such that if the client doesn't support > interceptors (C++) you don't > break > the server side or put additional configuration > requirements on the > server > side. > > > Bill > > > > > > > > > > -- > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, and > more > __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
How about implementing some kind of seperate interceptor framwork around the client side and server side invocation layers?? David, if yoiu had a configurable way to plug in your tx interceptors at the invocation layer you would be ok right? I think david just needs to avoid duplicating the code that is in the trunk invoker all over the place. Bill, how doable is that? Regards,Hiram Bill Burke <[EMAIL PROTECTED]> wrote: IMHO, CORE client interceptors such as security and tx should be writtensuch that if the client doesn't support interceptors (C++) you don't breakthe server side or put additional configuration requirements on the serverside.BillDo you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more
RE: [JBoss-dev] TxInterceptor split is really really bad
--- Bill Burke <[EMAIL PROTECTED]> wrote: > > > > This might sound a little crazy... but how about > > allowing multiple server-side interceptor stacks > per > > object? One for local access, one for stuff over > IIOP > > (that does tx the ots way), one for stuff over > JRMP > > etc. > > > > In the long run, maybe this can't be avoided, but I > would like to avoid it. > What are the problems related in implementing this?? Regards. Hiram __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is really really bad
--- Bill Burke <[EMAIL PROTECTED]> wrote: > > > > > > I would like to note that my future plans for this > involve method specific > > interceptor chains with a variety of "client side" > and "server side" tx > > interceptors, each one performing half of the > TxSupport work. No maps, > > just different specialized interceptors, with > different interceptors per > > method depending on the tx support. > > > > H...thanks for mentioning this. The AOP > framework will have to change > to support his type of per method intercepiton. > > Currently the ClassAdvisor asks the > InterceptorFactory for an instance of an > Interceptor and adds it to the interceptor chain. > For what you want to do, > this will have to change. The InterceptorFactory > should be responsible for > adding interceptors to the chain. Otherwise, my > isolation and separation of > metadata, interceptors, and pointcuts will be > broken. > I don't think that you model would be too broken. His interceptors should only hav to implement the org.jboss.aop.InvocationFilterInterceptor interface: boolean intercepts(Invocation invocation); The org.jboss.aop.Invocation.invokeNext() will skip over interceptors that do not interested the invocation. Currently invokeNext() interogates the intercetors on every invocation, but I think that we should be able to keep a per Invocation interceptor stack cache so that we can skip the interogation after the first method call. > > > I also think you will admit that even in aop you > could have two > > interceptors even if both were on the server side: > one to get the tx from > > the context if appropriate or remove it if > appropriate, one to start a new > > tx if appropriate. > > > > Yes, but I still have to figure out whether or not > the method call went > through a proxy or was a regular java method call. > > Bill > > > > > --- > This SF.net email is sponsored by: SlickEdit Inc. > Develop an edge. > The most comprehensive and flexible code editor you > can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. > FREE 30-Day Trial. > www.slickedit.com/sourceforge > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is really really bad
> > I have to disagree. Take a higher level look at > the > > basics: All client proxies have a dependency on > their > > corresponsing server side stub. You can't mix a > > Yes, obviously, but the old tx client proxy just > stuffed the tx context in Orthoganal problem. The ability to have smarter client proxies that have highly coupled interations with a serverside components is a requirment that everybody will agree with. > the invocation. The problem with AOP is that (at > least for 1st iteration) > the POJO can be accessed directly and through a > proxy at the same time. This might sound a little crazy... but how about allowing multiple server-side interceptor stacks per object? One for local access, one for stuff over IIOP (that does tx the ots way), one for stuff over JRMP etc. > yes, I can work around this by having a flag in the > Invocation object on > whether or not the invocation passed through a > proxy, but IMHO, this is a > hack. yes. I am starting to agree. > > > different proxys and stub types. Therefore it is > ok > > for a client side interceptor to have a dependency > on > > the server side interceptor. > > > Can you describe your AOP problem in more detail. > How > > are you going to be remoting POJO with AOP?? With > a > > proxy? Who will create the proxy objet? > > > > 1st iteration, DynamicProxy. This is trivial since > we have already done > this sort of thing for EJB and how to do AOP (or how > to do it wrong, depends > how you look at it), is already there for us to see. > Remote AOP with DP is > just an iteration to me from the current EJB stuff. > > 2nd iteration will be with all java classes. The > hard part will be how > instrumentation works on the client side, how the > client receives pointcuts > and such. In either case, I'm more intersted in WHO will be responsible creaing proxy objects?? Will it be automatic done when the object is serialized? Or will the application have to make an API call to get a proxy?? Regards, Hiram > > Bill > > > Regards, > > Hiram > > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > > Ok, maybe I shouldn't have said "fatally > flawed". > > > But again, my gut tells > > > me that it is bad to have a dependency between > > > server and client > > > interceptors if it is not absolutely needed. > > > > > > > -Original Message- > > > > From: > > > [EMAIL PROTECTED] > > > > > > > > > > [mailto:[EMAIL PROTECTED] > > > Behalf Of Bill > > > > Burke > > > > Sent: Friday, February 21, 2003 4:12 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [JBoss-dev] TxInterceptor split > is > > > really really bad > > > > > > > > > > > > I've been thinking and should have posted this > > > before. Your design is > > > > fataly flawed when I start applying it to the > AOP > > > framework. Your design > > > > assumes that there is a proxy sitting in front > of > > > everything. In AOP this > > > > is not the case. If you look at > > > > varia/src/org/jboss/aop/plugins/TxSupport.java > > > you'll see that I had to > > > > combine the clientInvoke and serverInvoke into > one > > > method because there is > > > > no proxy object between the application code > and > > > the object instance. > > > > > > > > Ok...no problem you sayWell, think of what > > > happens when the app > > > > developer decides to remote an AOP'd object. > I > > > will have to have > > > > 2 sets of > > > > interceptor chains and have to figure out > whether > > > the call is a > > > > remote call > > > > or local. Well, I guess I could insert a flag > > > into the Invocation on > > > > whether the call went through a proxy or not. > But > > > do you see where I'm > > > > going? I don't think its a good design to > rely on > > > the client to handle > > > > transaction semantics. I don't think its a > good > > > idea for the "server" to > > > > have to rely on client logic unless it really > has > > > to. > > > > > > > > All and all, my gut tells me that the current > > > client/tx design will cause > > > > problems. I want interceptor designers in > general > > > to avoid this kind of > > > > dependency. > > > > > > > > Bill > > > > > > > > > -Original Message- > > > > > From: > > > [EMAIL PROTECTED] > > > > > > > > > > > [mailto:[EMAIL PROTECTED] > > > Behalf Of David > > > > > Jencks > > > > > Sent: Wednesday, February 19, 2003 11:02 AM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: RE: [JBoss-dev] TxInterceptor split > is > > > really really good > > > > > > > > > > > > > > > On 2003.02.19 09:37 Bill Burke wrote: > > > > > > > > > > > > > > What you implemented is fine. My only > > > problem with it is that I > > > > > > > think it is more logical to let the > server > > > decide if it needs the > > > > > > > tx, and that I think the registration > > > callback could be avoided > > > > > > > (with minimal redundant client side > > > bookkeeping) even if the > > > > > > > decision is made on the server side. > > > > > > > > > > >
RE: [JBoss-dev] TxInterceptor split is really really bad
I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke <[EMAIL PROTECTED]> wrote: > Ok, maybe I shouldn't have said "fatally flawed". > But again, my gut tells > me that it is bad to have a dependency between > server and client > interceptors if it is not absolutely needed. > > > -Original Message- > > From: > [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > Behalf Of Bill > > Burke > > Sent: Friday, February 21, 2003 4:12 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is > really really bad > > > > > > I've been thinking and should have posted this > before. Your design is > > fataly flawed when I start applying it to the AOP > framework. Your design > > assumes that there is a proxy sitting in front of > everything. In AOP this > > is not the case. If you look at > > varia/src/org/jboss/aop/plugins/TxSupport.java > you'll see that I had to > > combine the clientInvoke and serverInvoke into one > method because there is > > no proxy object between the application code and > the object instance. > > > > Ok...no problem you sayWell, think of what > happens when the app > > developer decides to remote an AOP'd object. I > will have to have > > 2 sets of > > interceptor chains and have to figure out whether > the call is a > > remote call > > or local. Well, I guess I could insert a flag > into the Invocation on > > whether the call went through a proxy or not. But > do you see where I'm > > going? I don't think its a good design to rely on > the client to handle > > transaction semantics. I don't think its a good > idea for the "server" to > > have to rely on client logic unless it really has > to. > > > > All and all, my gut tells me that the current > client/tx design will cause > > problems. I want interceptor designers in general > to avoid this kind of > > dependency. > > > > Bill > > > > > -Original Message- > > > From: > [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] > Behalf Of David > > > Jencks > > > Sent: Wednesday, February 19, 2003 11:02 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] TxInterceptor split is > really really good > > > > > > > > > On 2003.02.19 09:37 Bill Burke wrote: > > > > > > > > > > What you implemented is fine. My only > problem with it is that I > > > > > think it is more logical to let the server > decide if it needs the > > > > > tx, and that I think the registration > callback could be avoided > > > > > (with minimal redundant client side > bookkeeping) even if the > > > > > decision is made on the server side. > > > > > > > > > > I got the impression that this > implementation would also be used > > > > > in the other invokers, and that made me > worry about CORBA > > > > > interoperability. If this approach will not > be used with the IIOP > > > > > invoker, I have no problem with it. > > > > > > > > > > > > > Yes this was my exact worry and still is. > That we'll have to have a > > > > different set of interceptors on the server > side for different > > > > transports. > > > > This is unexceptable because we want each EJB > to be able to > > > listen to and > > > > service calls from different transports at the > same time. > > > > > > > > David, I'm not suggesting to redesign your > code, but is the design > > > > flexible > > > > enough so that we could switch to a > server-side based design? > > Iteration > > > > is > > > > a fine thing > > > > > > I don't think we will have problems adapting my > current design to use > > > corba. Before we continue I think we should get > a clear > > understanding of > > > what is supposed to happen when the corba tx > policy and the j2ee > > > tx support > > > disagree. Does anyone know where this is > described in specs? > > > > > > Basically the corba design says "if there is a > transaction in > > the context > > > it must always be transmitted and imported on > the server" whereas > > > j2ee does > > > not always need to import the tx. The purpose > of the client side > > > interceptor is to not generate tx branches that > won't be used. I think > > > that any reasonable corba implementation is > going to follow corba > > > semantics > > > and always generate a transaction branch on the > client for the > > > remote call, > > > since as far as the corba spec goes, if the call > is made within a tx the > > > transaction will in fact be used on the server. > > > > > > In my view the heaviest part of the process is > generating a tx branch on > > > the client: once it is generated, then it has to > be prepared and/or > >
Re: [JBoss-dev] JMS and JSR77 stats mismatch
Arhh... It would be simpler if the JMX objects were
updated from client side. But since that is out of
the question for now, I'll just give you a few
sugestions:
- fake the session problem out and say there is
allways 1 session.
- Try to put the JSR77 code in an interceptor (like
the TracingInterceptor).
- To count the messages received, monitor message
acks.. they are the confimations that the messages
were processed ok.
Regards,
Hiram
--- Scott M Stark <[EMAIL PROTECTED]> wrote:
> JSR77 wants to provide a top down view of the JMS
> stats as shown in
> the attached pdf page showing the JMSStats interface
> model:
>
> JMSStats -> JMSConnectionStats[] ->
> JMSSessionStats[] -> {JMSProduerStats[],
> JMSConsumerStats[],
> messageCount, pendingMessageCount,
> expiredMessageCount, messageWaitTime{min, max,
> total},
> durableSubscriptionCount}
>
> JMSProduerStats -> {name, messageCount,
> pendingMessageCount, expiredMessageCount,
> messageWaitTime{min, max, total}}
> JMSConsumerStats -> {name, messageCount,
> pendingMessageCount, expiredMessageCount,
> messageWaitTime{min, max, total}}
>
> We don't seem to have a real good representation of
> a session on the server.
> I have looked at adding a basic
> connection/{producer/messageCount,
> consumer/messageCount} point
> using the JMSDestinationManager addMessage and
> receive methods using something like:
>
>public void addMessage(ConnectionToken dc,
> SpyMessage val, Tx txId) throws JMSException
>{
> JMSDestination queue =
>
(JMSDestination)destinations.get(val.getJMSDestination());
> ...
> // Update the client stats
> String destName =
> queue.getSpyDestination().getName();
> ClientStats stats = (ClientStats)
> clientStats.get(dc);
> if( stats != null )
> {
> stats.incProducerCount(destName);
> }
>}
>
>public SpyMessage receive(ConnectionToken dc, int
> subscriberId, long wait) throws JMSException
>{
> ClientConsumer clientConsumer =
> getClientConsumer(dc);
> SpyMessage msg =
> clientConsumer.receive(subscriberId, wait);
> JMSDestination queue =
>
(JMSDestination)destinations.get(msg.getJMSDestination());
> // Update the client stats
> String destName =
> queue.getSpyDestination().getName();
> ClientStats stats = (ClientStats)
> clientStats.get(dc);
> if( stats != null )
> {
> stats.incConsumerCount(destName);
> }
> return msg;
>}
>
> which might be ok for an initial cut but it leaves a
> lot of seemingly difficult to gather wait
> times. Any better ideas on how to provide more of
> this information?
>
>
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
>
> ATTACHMENT part 2 application/pdf name=JMSStats.pdf
__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why are we using this bogus construct
good point. I'll have to review the code in more
detail.
--- Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> Hiram,
>
> This type of construct creates some trick code. You
> iterate over the
> keys, and I assume somewhere in the code you do
> clients.get(key). Well
> there is no guarantee the the key is associated. I
> bet there are a ton
> of other issues as your iterator in the read phase
> drifts from reality
> of changing clients HashMap. Anyway, I hope you
> documented this
> heavily.
>
> -dain
>
> On Thursday, February 13, 2003, at 12:28 PM, Hiram
> Chirino wrote:
>
> > Yep.. your way is valid too but you take a
> > synchronization hit on every read. The otherway,
> the
> > performace hit is on the write. As I said
> previously,
> > if you read the map ALLOT more than you write to
> it,
> > then it makes sense to do it backwards.
> >
> > Regards,
> > Hiram
> >
> > --- Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> >> This seems backwards to me. I usually do
> something
> >> like this:
> >>
> >> class X
> >> {
> >> HashMap clients = new HashMap();
> >>
> >> public void someMethod()
> >> {
> >> synchronized(clients)
> >> {
> >> m.put(dc, cq);
> >> }
> >> ...
> >> }
> >> public void someOtherMethod()
> >> {
> >> HashMap clientsCopy = null;
> >> synchronized(clients)
> >> {
> >> clientsCopy = new HashMap(clients);
> >> }
> >> Iterator i =
> >> clientsCopy.keySet().iterator();
> >> while( i.hasNext() )
> >> {
> >> ...
> >> }
> >> }
> >> }
> >>
> >> For the insert, you only get a quick synchronized
> >> around the add, and
> >> on iteration you get a single copy in the
> >> synchronize. If the
> >> iteration very small and quick, I sometimes put
> the
> >> entire iteration in
> >> the synchronized block, but you need to be
> careful
> >> about open calls.
> >>
> >> -dain
> >>
> >> On Thursday, February 13, 2003, at 11:20 AM,
> Scott M
> >> Stark wrote:
> >>
> >>> I have seen this usage construct in a few places
> >> in the code and it
> >>> makes
> >>> no sense to me:
> >>>
> >>> class X
> >>> {
> >>> HashMap clients = new HashMap();
> >>>
> >>> public void someMethod()
> >>> {
> >>>synchronized(clients)
> >>> {
> >>> HashMap m = new HashMap(clients);
> >>> m.put(dc, cq);
> >>> clients=m;
> >>>}
> >>> ...
> >>> }
> >>> public void someOtherMethod()
> >>> {
> >>> Iterator i =
> clients.keySet().iterator();
> >>> while( i.hasNext() )
> >>> {
> >>> ...
> >>> }
> >>> }
> >>> }
> >>>
> >>> The unsynchronized clients HashMap is
> synchronized
> >> and copied when
> >>> modified and accessed without synchronization in
> >> other contexts. This
> >>> is
> >>> not thread safe for the accesses and makes for
> >> very expensive updates.
> >>> Why isn't the HashMap simply synchronized and
> used
> >> without copying?
> >>>
> >>>
> >>> Scott Stark
> >>> Chief Technology Officer
> >>> JBoss Group, LLC
> >>>
> >>>
> >>>
> >>>
> >>
> >
>
---
> >>> This SF.NET email is sponsored by: FREE SSL
> Guide
> >> from Thawte
> >>> are you planning your Web Server Security? Click
> >> here to get a FREE
> >>> Thawte SSL guide and find the answers to all
> your
> >> SSL security issues.
> >>>
> >>
> >
>
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> >>> ___
> >>> Jboss-development mailing list
> >>> [
Re: [JBoss-dev] Why are we using this bogus construct
Yep.. your way is valid too but you take a
synchronization hit on every read. The otherway, the
performace hit is on the write. As I said previously,
if you read the map ALLOT more than you write to it,
then it makes sense to do it backwards.
Regards,
Hiram
--- Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> This seems backwards to me. I usually do something
> like this:
>
> class X
> {
> HashMap clients = new HashMap();
>
> public void someMethod()
> {
> synchronized(clients)
> {
> m.put(dc, cq);
> }
> ...
> }
> public void someOtherMethod()
> {
> HashMap clientsCopy = null;
> synchronized(clients)
> {
> clientsCopy = new HashMap(clients);
> }
> Iterator i =
> clientsCopy.keySet().iterator();
> while( i.hasNext() )
> {
> ...
> }
> }
> }
>
> For the insert, you only get a quick synchronized
> around the add, and
> on iteration you get a single copy in the
> synchronize. If the
> iteration very small and quick, I sometimes put the
> entire iteration in
> the synchronized block, but you need to be careful
> about open calls.
>
> -dain
>
> On Thursday, February 13, 2003, at 11:20 AM, Scott M
> Stark wrote:
>
> > I have seen this usage construct in a few places
> in the code and it
> > makes
> > no sense to me:
> >
> > class X
> > {
> > HashMap clients = new HashMap();
> >
> > public void someMethod()
> > {
> >synchronized(clients)
> > {
> > HashMap m = new HashMap(clients);
> > m.put(dc, cq);
> > clients=m;
> >}
> > ...
> > }
> > public void someOtherMethod()
> > {
> > Iterator i = clients.keySet().iterator();
> > while( i.hasNext() )
> > {
> > ...
> > }
> > }
> > }
> >
> > The unsynchronized clients HashMap is synchronized
> and copied when
> > modified and accessed without synchronization in
> other contexts. This
> > is
> > not thread safe for the accesses and makes for
> very expensive updates.
> > Why isn't the HashMap simply synchronized and used
> without copying?
> >
> >
> > Scott Stark
> > Chief Technology Officer
> > JBoss Group, LLC
> >
> >
> >
> >
>
---
> > This SF.NET email is sponsored by: FREE SSL Guide
> from Thawte
> > are you planning your Web Server Security? Click
> here to get a FREE
> > Thawte SSL guide and find the answers to all your
> SSL security issues.
> >
>
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> >
>
https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
>
---
> This SF.NET email is sponsored by: FREE SSL Guide
> from Thawte
> are you planning your Web Server Security? Click
> here to get a FREE
> Thawte SSL guide and find the answers to all your
> SSL security issues.
>
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
>
https://lists.sourceforge.net/lists/listinfo/jboss-development
__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why are we using this bogus construct
Looks like you might be digging through some mq code
:)
I don't think that construct is too bogus... It
provides a copy write hashmap. Once the hashmap has
been updated, the rest of the read methods can treat
the hashmap as an imutable. No one will update that
hashmap ever again. To update it, you have to
generate another copy.
This is very good when you are reading the map 90% of
the time and updating it 10%. I don't see why this is
not thread safe.
Regards,
Hiram
--- Scott M Stark <[EMAIL PROTECTED]> wrote:
> I have seen this usage construct in a few places in
> the code and it makes
> no sense to me:
>
> class X
> {
> HashMap clients = new HashMap();
>
> public void someMethod()
> {
>synchronized(clients)
> {
> HashMap m = new HashMap(clients);
> m.put(dc, cq);
> clients=m;
>}
> ...
> }
> public void someOtherMethod()
> {
> Iterator i = clients.keySet().iterator();
> while( i.hasNext() )
> {
> ...
> }
> }
> }
>
> The unsynchronized clients HashMap is synchronized
> and copied when
> modified and accessed without synchronization in
> other contexts. This is
> not thread safe for the accesses and makes for very
> expensive updates.
> Why isn't the HashMap simply synchronized and used
> without copying?
>
>
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
>
>
>
>
---
> This SF.NET email is sponsored by: FREE SSL Guide
> from Thawte
> are you planning your Web Server Security? Click
> here to get a FREE
> Thawte SSL guide and find the answers to all your
> SSL security issues.
>
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
>
https://lists.sourceforge.net/lists/listinfo/jboss-development
__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is bad AND broken?
The transaction is not getting propagated across the wire. A new XID is what is getting propagated. Remember that an XID != the tx. The relationship is that a tx will have multiple XIDs (one ore each resource that is involved in the tx). David is treating the remote jboss server like any other transacted resource. He enists the XAResource of the remote server, and gives that XAResource a new XID. Since remote tm is providing an XAResource interface to the remote tx, the local tm can commit/rollback the remote tx via a 2pc. David, I hope that was accurate since I have not really looked at your code! Regards, Hiram --- Bill Burke <[EMAIL PROTECTED]> wrote: > Ok, I'm looking at the code further and I'm pretty > confused on how a > Transaction get propagated across the wire now. Can > you explain? I don't > see any code anywhere that is doing a tm.resume from > the transaction that is > past across the wire. Is this code broken? > > Bill > > > > -Original Message- > > From: Bill Burke [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, February 12, 2003 5:51 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is > bad > > > > > > Another thing David, > > > > I don't see you always stuffing the Transaction > into the > > invocation object. A few interceptors rely on the > transaction > > being in the invocation object. Any objects to > fixing this? > > > > Bill > > > > > -Original Message- > > > From: > [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]]On > Behalf Of Bill > > > Burke > > > Sent: Wednesday, February 12, 2003 5:36 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] TxInterceptor split is > bad > > > > > > > > > > > > > > > > -Original Message- > > > > From: > [EMAIL PROTECTED] > > > > > [mailto:[EMAIL PROTECTED]]On > > Behalf Of Hiram > > > > Chirino > > > > Sent: Wednesday, February 12, 2003 5:09 PM > > > > To: [EMAIL PROTECTED]; > David Jencks > > > > Subject: Re: [JBoss-dev] TxInterceptor split > is bad > > > > > > > > > > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > > > > What if you don't have java on the client > side? > > > > > What if you're CORBA with > > > > > OTS? You're making it harder for > Non-JBoss/Java > > > > > clients to integrated with > > > > > us. I think this split should be undone. > > > > > > > > > > > > > How des OTS work? The corba guys tackled the > DTM > > > > problem too right?? > > > > > > > > > > They have the concept of a ThreadLocal (Current) > (My knowledge > > > is probably > > > outdated and foggy). In O2K the client side > interceptor stuffs > > the value > > > from the transaction current into the IIOP > service context, > > much the same > > > way we used to do before David's switch. > > > > > > -1 for refactor > > > > > > > > BTW, why the split besides code readability? > Is the > > > > > DTM dependent on this > > > > > at all? Is the TM even accessed on the > client side? > > > > > > > > > > > > > I think so. In the case were a client is a > server the > > > > local TM is accessed to treat the remote TM > like a > > > > XAResource. > > > > > > > > > > +1 for refactor > > > > > > > > Another problem I see is that the TxMethod > map is > > > > > required on the client > > > > > side as well. Makes proxies even more heavy > and > > > > > what do you do about a hot > > > > > deploy? > > > > > > > > > > > > > Yes.. but same argument could be made against > any > > > > client side interceptor we create. The proxy > on the > > > > client goes stale if a redeploy changes the > proxy > > > > config. > > > > > > > > > > Ok, you're right. +2 for refactor > > > > > > > > Seems to me this is a bad idea. > > > > > > > > > > > > > I agree it is a complex solution. But the DTM > problem > > > > is complex too. Any simpler sugestions?? > > > > > > > &g
RE: [JBoss-dev] TxInterceptor split is bad
> Actually the code is much more readable. I guess my > only concern now is > non-java/jboss clients. And, do we care? > Non java code will have a seperate server-side invoker and it should deal with the TX stuff as best it can. In otherwords, do it the old way if it works better for corba. > Another thing about this is that you're requiring > the client to become > beafier and beafier. I've been kinda nervous about > the whole JMX on the > client sort of thing and the start of deploying > services on the client side. > But maybe it doesn't matter. > Ahh.. but that's the future. Unfortuanly, smarter clients means beefier clients. The chalenge will be to setup the plumbing that will allows us to create those smart clients without having to worry about thier size and distribution. In other words, the plumbing should take care of the heavy/stale proxy problem. > Bill > > P.S. Good to see you around again Hiram. > I went back to using an online mail service. Checking email only at night would really kill my response times. Regards, Hiram __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TxInterceptor split is bad
--- Bill Burke <[EMAIL PROTECTED]> wrote: > What if you don't have java on the client side? > What if you're CORBA with > OTS? You're making it harder for Non-JBoss/Java > clients to integrated with > us. I think this split should be undone. > How des OTS work? The corba guys tackled the DTM problem too right?? > BTW, why the split besides code readability? Is the > DTM dependent on this > at all? Is the TM even accessed on the client side? > I think so. In the case were a client is a server the local TM is accessed to treat the remote TM like a XAResource. > Another problem I see is that the TxMethod map is > required on the client > side as well. Makes proxies even more heavy and > what do you do about a hot > deploy? > Yes.. but same argument could be made against any client side interceptor we create. The proxy on the client goes stale if a redeploy changes the proxy config. > Seems to me this is a bad idea. > I agree it is a complex solution. But the DTM problem is complex too. Any simpler sugestions?? Regards, Hiram > Bill > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Bugs-672543 ] depends-list does not work according to documentation
dom4j has a stable 1.3 release. You can see a comparison of a few doms here: http://dom4j.org/compare.html Regards, Hiram > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott > M Stark > Sent: Wednesday, January 22, 2003 4:37 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] [ jboss-Bugs-672543 ] depends-list does not > work according to documentation > > > I have concerns about a non-standard parser that has not seen a > release in 9 months > and is stuck at beta8. Yes its supposed to conform to JSR-102, > but this was founded > nearly two years ago and I can't find any status on this. Is > this really the best XML > abstraction we can come up with? > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > - Original Message - > From: "David Jencks" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, January 22, 2003 9:14 AM > Subject: Re: [JBoss-dev] [ jboss-Bugs-672543 ] depends-list does > not work according to documentation > > > > Anyone mind if I rewrite the ServiceConfigurator et al to use JDOM > > instead of DOM? I think there are too many of these stupid > problems to > > fix economically using DOM. > > > > Thanks > > david jencks > > > > > > --- > This SF.net email is sponsored by: Scholarships for Techies! > Can't afford IT training? All 2003 ictp students receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Transaction propagation change
The original point was that JMS allows you transact the message put. If the message put is part of the global unit of work and it has not committed, then no receiver can pick up the message (the put does not actually occur till we commit). This really has VERY little to do with the fact the jms is asynchronous. In all other respects you are correct. Regards, Hiram > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Sent: Wednesday, January 15, 2003 6:37 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Transaction propagation change > > > one of my favorite topics is coming up again > One day I will sit down and write a tx spec. > > Ok frankly WHY DO WE CARE THAT MESSAGING IS ASYNCHRONOUS WITH RESPECT TO > TRANSACTION. Yeah I know the answer you could have a long running > transaction and messages and queues and bla bla bla. BS BS BS. > > So the method returns immediately. SO WHAT? the listener that will pick > up the message and act upon it may very well want to synchronize with > the GLOBAL transaction going on in the web. And commit or rollback > according to the outcome. > > The scenario is simple. > > Image A does something and sends messages to n instances with a global > transaction associated to it. > > n recievers get the message get the TPC and register with the global tx. > If the global tx is still running then all good 2phi dance starts bla > bla bla. if the tx is out (too old) then the guy who woke up late just > says "sorry can't register" and possibly no one cares or he can notify > (whatever the app rollback semantics are). > > AT A SYSTEM LEVEL I DON"T SEE A REASON FOR THIS "BAD IDEA" SYNDROME. IN > fact it always has struck me that there is NO WAY to propagate a TX with > a message. > > you know what? this is something we can VERY easily do in JBoss. Adding > the message in the new rewrite may be the usual 'put an interceptor > here' deal, once we make progress on the rewrite. > > But the point is simple, the asynchronous nature of the transport > protocol should not have an impact on the definition of a web > transaction. > > IN fact it is a requisite for web services (generic way)Tx definitions. > > Many threads TX! > > > > marcf > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] On > > Behalf Of danch > > Sent: Wednesday, January 15, 2003 6:18 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] Transaction propagation change > > > > > > And having a way to do that would probably be a Bad Idea. > > Propogating a > > transaction through asynchronous transports doesn't sound like a good > > idea to me, anyway. > > > > -danch > > > > Hiram Chirino wrote: > > > Just a small correction.. your example would have to be in > > at least 2 > > > units of work. There is NO WAY to put a JMS message and > > get it again > > > in a single transaction. > > > > > > Regards, > > > Hiram > > > > > > > > >>Having a distributed transaction context is especially > > important for > > >>example when you have a EJB from one jboss instance posting > > a message > > >>to a JMS queue > > >>on another jboss instance that in turn has a MDB that calls > > another EJB on > > >>that second instance. If I want that all to be under one > > transaction and > > >>thus rollback as one business unit of work, there is no way to do > > >>that (that > > >>i'm aware of) with "native" JBoss in the 3.x series. I > > know one could use > > >>Tyrex, but the author doesn't recommend using Tyrex in a production > > >>environment and so I'm a little leary to use it myself. > > >> > > > > > > > > > > > > > --- > > This SF.NET email is sponsored by: A Thawte Code Signing Certificate > > is essential in establishing user confidence by providing > > assurance of > > authenticity and code integrity. Download our Free Code > > Signing guide: > > http://ads.sourceforge.net/cgi-> bin/redirect.pl?thaw0028en > > > > > > ___ > > Jboss-development mailing list [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > --- > This SF.
RE: [JBoss-dev] Transaction propagation change
Just a small correction.. your example would have to be in at least 2 units of work. There is NO WAY to put a JMS message and get it again in a single transaction. Regards, Hiram > Having a distributed transaction context is especially important > for example > when you have a EJB from one jboss instance posting a message to > a JMS queue > on another jboss instance that in turn has a MDB that calls another EJB on > that second instance. If I want that all to be under one transaction and > thus rollback as one business unit of work, there is no way to do > that (that > i'm aware of) with "native" JBoss in the 3.x series. I know one could use > Tyrex, but the author doesn't recommend using Tyrex in a production > environment and so I'm a little leary to use it myself. > --- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossMQ
that sounds right..
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of John
> Fawcett
> Sent: Tuesday, January 14, 2003 8:14 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] JBossMQ
>
>
> Hi,
>
> I want to make sure I understand the asynchronous delivery mechanism.
> I've implemented my MessageConsumer to do the following:
>
> Add self to Connection's message consumer list
> While(consumer is open){
> while(server is delivering synchronously){
> Send Receive Requests until the Server is Drained
> }
> Wait for Asynch Delivery
> }
>
>
> Is this the proper pattern?
> Thanks,
> fawce
>
>
>
> -----Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of
> Hiram Chirino
> Sent: Friday, January 10, 2003 6:50 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] JBossMQ
>
>
>
> Your kinda right. the loop is there for the case where the destination
> is queue based (p2p and durable subs). The polling happens when the
> queue is full. Now when the queue is not full (or in the pub sub case,
> there is no queue), then the thread goes into asynch mode and it waits
> for the message to get delivered async via the ClientIL.receive method.
> I'll comment the code a little:
>
>// gets the next message in queue or registers us for asynch
> delivery if none available.
>mes = session.connection.receive( subscription, 0 );
>if ( mes == null ) // should always be null for pub-sub case.
>{
> // start waiting for the message to get delivered asynch
> waitingForMessage = true;
> while ( ( messages.isEmpty() && !closed ) || (
> !session.running ) )
> {
> try
> {
> // messages gets signaled once ClientIL.receive finishes
> processing the message.
> messages.wait();
> } catch ( InterruptedException e )
> {
> }
> }
> if ( closed )
> {
> waitingForMessage = false;
> break outer;
> }
> // the message sent via ClientIL.receive should now be sitting
> in messages
> mes = ( SpyMessage )messages.removeFirst();
> waitingForMessage = false;
> }
>
>
> I hope that helped! I think the XIL is great idea! We might even be
> able to develop a c base API to access mq services (important in the
> integration space).
>
> Regards,
> Hiram
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > John Fawcett
> > Sent: Thursday, January 09, 2003 8:09 PM
> > To: [EMAIL PROTECTED]
> > Subject: [JBoss-dev] JBossMQ
> >
> >
> > Hi,
> >
> > I am working on a new invocation layer (IL) for JbossMQ that encodes
> > all communication in Xml (XIL). I've got the IL pretty near
> > completion, and I am working on a C# jbossmq client. I am trying to
> > develop the TopicSubsciber, which is an extension of MessageConsumer.
> > In reviewing the code in the jbossmq java sources, it looks to me like
>
> > the client to a topic actually runs a loop sending receive requests to
>
> > the server regularly.
> >
> > Is this really necessary? Once the connection has been established,
> > why can't the server just invoke the ClientIL.receive method (which
> > actually sends the message to the client) when a message arrives at
> > the destination? It looks to me like the current implementation is not
>
> > truly asynchronous...
> > What am I missing?
> >
> > Thanks,
> > fawce
> >
> >
> > -
> > John Fawcett
> > CTO, Tamale Software, LLC
> > 26 Fox Road
> > Waltham, MA 02451
> >
> >
> >
> > ---
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> > http://www.vasoftware.com
> > ___
> > Jboss-development mailing list [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
>
> ---
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> ___
RE: [JBoss-dev] JBossMQ
Your kinda right. the loop is there for the case where the destination is
queue based (p2p and durable subs). The polling happens when the queue is
full. Now when the queue is not full (or in the pub sub case, there is no
queue), then the thread goes into asynch mode and it waits for the message
to get delivered async via the ClientIL.receive method. I'll comment the
code a little:
// gets the next message in queue or registers us for asynch delivery
if none available.
mes = session.connection.receive( subscription, 0 );
if ( mes == null ) // should always be null for pub-sub case.
{
// start waiting for the message to get delivered asynch
waitingForMessage = true;
while ( ( messages.isEmpty() && !closed ) || ( !session.running ) )
{
try
{
// messages gets signaled once ClientIL.receive finishes
processing the message.
messages.wait();
} catch ( InterruptedException e )
{
}
}
if ( closed )
{
waitingForMessage = false;
break outer;
}
// the message sent via ClientIL.receive should now be sitting in
messages
mes = ( SpyMessage )messages.removeFirst();
waitingForMessage = false;
}
I hope that helped! I think the XIL is great idea! We might even be able
to develop a c base API to access mq services (important in the integration
space).
Regards,
Hiram
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of John
> Fawcett
> Sent: Thursday, January 09, 2003 8:09 PM
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] JBossMQ
>
>
> Hi,
>
> I am working on a new invocation layer (IL) for JbossMQ that encodes all
> communication in Xml (XIL). I've got the IL pretty near completion, and
> I am working on a C# jbossmq client. I am trying to develop the
> TopicSubsciber, which is an extension of MessageConsumer. In reviewing
> the code in the jbossmq java sources, it looks to me like the client to
> a topic actually runs a loop sending receive requests to the server
> regularly.
>
> Is this really necessary? Once the connection has been established, why
> can't the server just invoke the ClientIL.receive method (which actually
> sends the message to the client) when a message arrives at the
> destination?
> It looks to me like the current implementation is not truly
> asynchronous...
> What am I missing?
>
> Thanks,
> fawce
>
>
> -
> John Fawcett
> CTO, Tamale Software, LLC
> 26 Fox Road
> Waltham, MA 02451
>
>
>
> ---
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Good-bye
Dam.. it could be this new version of eclipse that i'm running does not play nice with the sf cvs server. I'm gona have to go back to wincvs. Regards, Hiram > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Bill > Burke > Sent: Saturday, December 21, 2002 7:18 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Good-bye > > > Hiram, you still have access! We need you man! > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Hiram > > Chirino > > Sent: Saturday, December 21, 2002 2:06 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] Good-bye > > > > > > Yep.. i'd like to know the same. Seems like that same thing has > > happend to > > me too. Today I tried to do a CVS commit and i got a "[server aborted]: > > commit requires write access to the repository" > > > > I's this right? What's the inactivity period before write access is > > revoked?? > > > > Regards, > > Hiram > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > > Darrell > > > Sent: Saturday, December 21, 2002 12:47 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [JBoss-dev] Good-bye > > > > > > > > > why did they do that? > > > > > > > > > - Original Message - > > > From: "Andy" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]>; > > > <[EMAIL PROTECTED]> > > > Sent: Friday, December 20, 2002 6:39 PM > > > Subject: [JBoss-dev] Good-bye > > > > > > > > > > Hi Geeks > > > > > > > > Yesterday my CVS RW access to JBoss was revoked and therefore > > > > I will not work on the JBoss project at all. > > > > Unfortunately this also means that I cannot update my changes to the > > > > Quick Start Guide and the EJB Timer Service I was working on. > > > > > > > > Even though that it makes me angry that I spent many hours helping > > > > JBoss become a success I still wish the project all the success it > > > > deserves. > > > > > > > > Have a nice day > > > > > > > > Andreas Schaefer > > > > "Code or be coded" > > > > > > > > Check out www.madplanet.com > > > > > > > > > > > > > > > > > > > > --- > > > > This SF.NET email is sponsored by: The Best Geek Holiday Gifts! > > > > Time is running out! Thinkgeek.com has the coolest gifts for > > > > your favorite geek. Let your fingers do the typing. Visit Now. > > > > T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/ > > > > ___ > > > > Jboss-development mailing list > > > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > --- > > > This SF.NET email is sponsored by: The Best Geek Holiday Gifts! > > > Time is running out! Thinkgeek.com has the coolest gifts for > > > your favorite geek. Let your fingers do the typing. Visit Now. > > > T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/ > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > --- > > This SF.NET email is sponsored by: The Best Geek Holiday Gifts! > > Time is running out! Thinkgeek.com has the coolest gifts for > > your favorite geek. Let your fingers do the typing. Visit Now. > > T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/ > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > --- > This SF.NET email is sponsored by: Order your Holiday Geek Presents Now! > Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap, > MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty. > T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Order your Holiday Geek Presents Now! Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap, MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty. T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Good-bye
Yep.. i'd like to know the same. Seems like that same thing has happend to me too. Today I tried to do a CVS commit and i got a "[server aborted]: commit requires write access to the repository" I's this right? What's the inactivity period before write access is revoked?? Regards, Hiram > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Darrell > Sent: Saturday, December 21, 2002 12:47 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Good-bye > > > why did they do that? > > > - Original Message - > From: "Andy" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Friday, December 20, 2002 6:39 PM > Subject: [JBoss-dev] Good-bye > > > > Hi Geeks > > > > Yesterday my CVS RW access to JBoss was revoked and therefore > > I will not work on the JBoss project at all. > > Unfortunately this also means that I cannot update my changes to the > > Quick Start Guide and the EJB Timer Service I was working on. > > > > Even though that it makes me angry that I spent many hours helping > > JBoss become a success I still wish the project all the success it > > deserves. > > > > Have a nice day > > > > Andreas Schaefer > > "Code or be coded" > > > > Check out www.madplanet.com > > > > > > > > > > --- > > This SF.NET email is sponsored by: The Best Geek Holiday Gifts! > > Time is running out! Thinkgeek.com has the coolest gifts for > > your favorite geek. Let your fingers do the typing. Visit Now. > > T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/ > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > --- > This SF.NET email is sponsored by: The Best Geek Holiday Gifts! > Time is running out! Thinkgeek.com has the coolest gifts for > your favorite geek. Let your fingers do the typing. Visit Now. > T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/ > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: The Best Geek Holiday Gifts! Time is running out! Thinkgeek.com has the coolest gifts for your favorite geek. Let your fingers do the typing. Visit Now. T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] 3 Transactions?
David, Is a ThreadLocal lookup more expensive than a hashmap lookup?? Regards, Hiram -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Tuesday, November 26, 2002 8:23 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] 3 Transactions? On 2002.11.26 22:26:30 -0500 Dain Sundstrom wrote: > OK we have a transaction associated with the thread, each invocation > and the each context has a transaction (very confusing). Once we get > by the tx interceptor should all of these be the same thing? yes (at least the thread and invocation, I don't know about the context, isn't that a UserTx, which is almost completely unrelated?) If we are > suspending the transaction for the invocation (Not Supported) should > the ctx and invocation tx be null or just a suspended transaction? Invocation should have null. You shouldn't be able to tell if there was a tx associated "upstream". IMO the invocation is the "master" and the threadlocal is there in case you can't get to the invocation (such as in the jca stuff). So the tx interceptor needs to figure out what the current tx actually is, and make sure the txManager knows it so it can supply it per thread. david jencks > > -dain > > > > --- > This SF.net email is sponsored by: Get the new Palm Tungsten T > handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new direction for JBoss AOP
wow... This will take AOP to the next level (interceptors on fields and and constructors? WOW.). I'll checkout your stuff tonight. Regards, Hiram -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Tuesday, November 26, 2002 3:39 PM To: Jboss-Dev Cc: Bob Lee; Jboss-Group@Jboss. Org Subject: [JBoss-dev] new direction for JBoss AOP Code is under jboss-head/aop It compiles but that's about it. Its incomplete. The new direction is shown in the below xml if you can follow along. Don't have much time for explanation before Thanksgiving, but the idea is POJOs and DynamicProxies married into one framework. Field access, Constructors and methods interceptable on POJOs. More funtionality can be inferred if you read the following XML. --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new PooledInvoker: speeds up invocations
That's
the way It kinda works now, but I don't like it because it's not
generalized. We don't have to do that with RMI proxies today, why do we
have to do that with trunk proxies? And RMI proxy could be sent down the
the invocation as an argument and all would be ok. You should be able to
do the same with a trunk proxy.
Regards,
Hiram
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
BurkeSent: Monday, November 18, 2002 11:57 PMTo:
[EMAIL PROTECTED]Subject: RE: [JBoss-dev] new
PooledInvoker: speeds up invocations
Why
does the proxy object have to setup the callback channel on
deserialization? Just stuff the proxy in the invocation object as party
of the payload. Invoker pulls this proxy shell out of the invocation and
initializes it with the real callback channel..
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Hiram ChirinoSent: Tuesday, November 19, 2002 4:03
AMTo: [EMAIL PROTECTED]Subject:
RE: [JBoss-dev] new PooledInvoker: speeds up
invocations
I
agree.. same socket bi-directionality is exotic and does not have to be in
the public interface.
Currently, it's not very nice how the proxy going back client
gets setup. I won't go into details about the current way I do it
(it sucks).
Here's the route I
hope I can change too soon:
1) client sends a proxy object down an
invocation to the server..
2) server invoker sets either (a) an
Invocation attribute or (b) and ThreadLocal to identify the socket the
invocation came over.
3) When the proxy object is
de-serialized, he looks up the object in (2) to setup the callback channel
to go through the original socket.
But for this to work in the (a)
case the proxy object would need to be able to access the Invocation
object during deserization.
And for it to work in the (b) case the
proxy object has to be deserialized while in the context of the thread the
invocation came in.
I don't think I'll be able to do this
the way invocations are done right now. You think this is a bad
route?
Regards,
Hiram
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Bill BurkeSent: Sunday, November 17, 2002 11:16
PMTo: [EMAIL PROTECTED]Subject:
RE: [JBoss-dev] new PooledInvoker: speeds up
invocations
I agree Scott (no public interface for bi-directionality). It
will be tricky to implement the bi-directional behavior if Invokers don't
have a bi-directional public interface. I wonder how you abstract
this out now Hiram.
One way to do this would be to use the trick I used with EJBs and
multiple-invokers.
1. Have a proxy factory.
2. Pass this information with the client
request.
3. Look up the proxy factory whenever you have to create proxies
via the tag in the invocation.
Bill
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Scott M StarkSent: Saturday, November 16, 2002 1:49
PMTo:
[EMAIL PROTECTED]Subject: Re:
[JBoss-dev] new PooledInvoker: speeds up
invocations
It should be possible to route invocations
over the incoming channel, but it cannot be
a requirement. This does not imply the
invocation interfaces are bi-directional however.
There simply needs to be the ability to
compose the invokers such that there is a shared
communications channel.
Scott StarkChief Technology
OfficerJBoss Group, LLC
- Original Message -
From:
Victor Langelo
To: [EMAIL PROTECTED]
Sent: Friday, November 15, 2002
7:11 PM
Subject: Re: [JBoss-dev] new
PooledInvoker: speeds up invocations
Hiram Chirino wrote:
Hiram Chirino wrote: > Anyways. JMS need bi-directional invocations (BADLY). Should this > become a requirement for the other invokers??I completely disagree. There is no reason server to clientcommunication has to go over the back channel of a client to serverI might have said this before, but there is one reason it's a nice feature:This allows callback to clients that are sitting behind a firewall.Let
me agree with Hiram. I would add it is essential to use the client
connection if the client network is using NAT (network address
translation). With the advent of new security measures, many of our
clients are adding fi
RE: [JBoss-dev] new PooledInvoker: speeds up invocations
I agree.. same socket bi-directionality is exotic and does not have to be in the public interface. Currently, it's not very nice how the proxy going back client gets setup. I won't go into details about the current way I do it (it sucks). Here's the route I hope I can change too soon: 1) client sends a proxy object down an invocation to the server.. 2) server invoker sets either (a) an Invocation attribute or (b) and ThreadLocal to identify the socket the invocation came over. 3) When the proxy object is de-serialized, he looks up the object in (2) to setup the callback channel to go through the original socket. But for this to work in the (a) case the proxy object would need to be able to access the Invocation object during deserization. And for it to work in the (b) case the proxy object has to be deserialized while in the context of the thread the invocation came in. I don't think I'll be able to do this the way invocations are done right now. You think this is a bad route? Regards, Hiram -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill BurkeSent: Sunday, November 17, 2002 11:16 PMTo: [EMAIL PROTECTED]Subject: RE: [JBoss-dev] new PooledInvoker: speeds up invocations I agree Scott (no public interface for bi-directionality). It will be tricky to implement the bi-directional behavior if Invokers don't have a bi-directional public interface. I wonder how you abstract this out now Hiram. One way to do this would be to use the trick I used with EJBs and multiple-invokers. 1. Have a proxy factory. 2. Pass this information with the client request. 3. Look up the proxy factory whenever you have to create proxies via the tag in the invocation. Bill -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M StarkSent: Saturday, November 16, 2002 1:49 PMTo: [EMAIL PROTECTED]Subject: Re: [JBoss-dev] new PooledInvoker: speeds up invocations It should be possible to route invocations over the incoming channel, but it cannot be a requirement. This does not imply the invocation interfaces are bi-directional however. There simply needs to be the ability to compose the invokers such that there is a shared communications channel. Scott StarkChief Technology OfficerJBoss Group, LLC - Original Message - From: Victor Langelo To: [EMAIL PROTECTED] Sent: Friday, November 15, 2002 7:11 PM Subject: Re: [JBoss-dev] new PooledInvoker: speeds up invocations Hiram Chirino wrote: Hiram Chirino wrote: > Anyways. JMS need bi-directional invocations (BADLY). Should this > become a requirement for the other invokers??I completely disagree. There is no reason server to clientcommunication has to go over the back channel of a client to serverI might have said this before, but there is one reason it's a nice feature:This allows callback to clients that are sitting behind a firewall.Let me agree with Hiram. I would add it is essential to use the client connection if the client network is using NAT (network address translation). With the advent of new security measures, many of our clients are adding firewalls and NAT. The worst case is when the server has a public IP and the local LAN clients are on the otherside of a NAT router.--Victor
RE: [JBoss-dev] Metadata Service
Peter.. why doesn't this have a JMS interface into it?? any ideas. 1600 message/second is GREAT number! Regards, HIram > On 14 Nov, Bill Burke wrote: > > Wow Peter! This is exactly what I was thinking of. Any JMX > guys have any > > ideas how we could integrate this? > > The server is already integrated: > > http://www.xmlBlaster.org/xmlBlaster/doc/requirements/j2ee.jmx.html > > There is also an JCA RA adaper if one want's to use it. > > http://www.xmlBlaster.org/xmlBlaster/doc/requirements/j2ee.k2.html > > Both developed by yours truly ;-) > > I also have a connection/subscriber pool MBean thingy, where you add > subscribers through the MBean interface and get the callback/messages > through JMX notifications. > > If someone is interested to take a look at it, fine. It uses some stuff > I can not release, but the pool stuff and concepts around it I could > share, if you will continue to like XmlBlaster after som more looks into > it. > > I must say I have personally had verry good experiences from it. I have > been woring with it for almost 2 years now, on and of, and it has worked > great. It has high throughput (1600 XML messages/second), and has been > running fine in a production environment for the last 6 month. > > A real gem. > > //Peter > > > > Bill > > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED]]On > Behalf Of Peter > >> Antman > >> Sent: Thursday, November 14, 2002 4:12 AM > >> To: [EMAIL PROTECTED] > >> Subject: Re: [JBoss-dev] Metadata Service > >> > >> > >> Hi, > >> have any one of you looked at XmlBlaster? (www.xmlBlaster.org). > >> > >> I guess it could really work as a central XmlRepository. XmlBlaster is > >> an XML based MOM. You publish your XML to it and it will save it in an > >> Xml DOM tree, even persist it a RDMB or Xincice. > >> > >> You can then subscribe to event with an XPath expression (or do a > >> synchronous get (with an XPath). > >> > >> Ok. You can not just subsribe to one element, thats true, but you can > >> subscribe on a "domain" or "config", say MyMessageDrivenBean > and get any > >> update notifications for that XML config. Or you could do a > >> get(//x/y/port) (pseudocode!) and get all configs wich contains that > >> element. There are a lot more to XmlBlaster (I have done the JBoss > >> integration thats currently is available in XmlBlaster ;.)) > >> > >> Well, just a thought. > >> > >> //Peter > >> > >> On 13 Nov, Bill Burke wrote: > >> > 1. I'm not talking about a central config file...Components > >> register their > >> > XML with this service. MBean, EJB, whatever... > >> > > >> > 2. You know what XPATHs are right? If not, look them up. They > >> are really > >> > cool. Xerces/Xalan (forget which) support looking up Elements > >> via XPATHS. > >> > What's not supported, which we would have to write, would be > >> the ability to > >> > register for change notifications via an XPATH. > >> > > >> > Other ideas: > >> > - A redeployed bean, updates the Centralized (in-memory) > Xerces XML Doc. > >> > Services/components registered as listening for changes, recieve > >> > notification. > >> > > >> > - JMX console needs an additional XML editor for MBean > >> attributes that are > >> > XML elements. > >> > > >> > - This sort of centralized service allows you to query, via > >> XPATHS, for all > >> > components that have a "port" attribute for instance. > Allows you to do > >> > global things on configuration when you don't know the > actual components > >> > that have that type of attribute > >> > > >> > Another thing about configuration I wanted to have is the concept of > >> > Configuration Domains. A component would get configuration by > >> searching a > >> > set of chained configuration domains. > >> > > >> > invocation domain->instance domain->component domain->app server > >> > domain->cluster domain etc... > >> > > >> > So, when a component needs config information, it looks it up > >> via the chain. > >> > Any domain in the chain can override a config value. As the chain is > >> > traversed, if the config info is not there, it searches > farther up the > >> > chain. > >> > > >> > This would allow us to have a layered way of obtaining default config > >> > information, or overriding existing configuration at > different levels at > >> > different times. > >> > > >> > Bill > >> > > >> > > >> > > >> >> -Original Message- > >> >> From: [EMAIL PROTECTED] > >> >> [mailto:[EMAIL PROTECTED]]On > Behalf Of Matt > >> >> Munz > >> >> Sent: Wednesday, November 13, 2002 1:26 PM > >> >> To: [EMAIL PROTECTED] > >> >> Subject: RE: [JBoss-dev] Metadata Service > >> >> > >> >> > >> >> Dain, > >> >> > >> >> > Meta data for an invocation. > >> >> > >> >> I assume you refer here to EJB/servlet invocations. > >> >> > >> >> Just out of curiosity, how is that metadata currently stored? > >> >> > >> >> - Matt > >> >> > >> >> -Original Message- > >> >> From: [EMAIL PROTECTED] > >> >> [mailto:[EMAIL PRO
RE: [JBoss-dev] new PooledInvoker: speeds up invocations
> > > Perhaps.. I've not double checked the pool code. The first time an > > invocation comes though shure, but the second time, the pooled > > thread should > > get reused. > > > > Please make sure. It didn't read that way when I looked at it last. > I'll double check. > > > > Yep.. But this is good, if servicing requests has a delay in > it.. You can > > sqeeze more requests into one socket. I need to make the > > connections pooled > > also so that a single socket does not get over-used. > > > > Yeah, maybe good for your design, but not good for performance. BTW, with > the PooledInvoker vs. RMI tests, I'm pretty sure that RMI caches the > connection. If I re-use the the same RMI proxy then Pooled is only 30% > faster. Also, BTW, I borrowed your marshalling code at first and it was > significantly slower than straight ObjectStreams. (Don't remember > percentages.) > Ok.. I'll test the differences.. Where are your performances tests located? I might go back to the drawing board and Re-implement my taking your PoolInovker as the base and adding the 1 feature I want (client-callback). > > > > The JMS server uses callbacks. Thats how it drives asynchronous message > > delivery. A normal RMI callback object cannot allways be used since the > > client may be behind a firewall. I want to be able to > > communicate with the > > client over the same socket that he established with the server. Make > > sense?? > > > > Are the callbacks both for subscribers and Acks? Or are acks > delivered as a > response. > The server delivers asynch messages via the clients back-channel. The client then acks the message via his normal ivocation channel. Regards, Hiram --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new PooledInvoker: speeds up invocations
> Hiram Chirino wrote: > > Anyways. JMS need bi-directional invocations (BADLY). Should this > > become a requirement for the other invokers?? > > I completely disagree. There is no reason server to client > communication has to go over the back channel of a client to server I might have said this before, but there is one reason it's a nice feature: This allows callback to clients that are sitting behind a firewall. > invoker. It is a nice feature but should not be a requirement. For > example, I may want a system that uses RMI for client to server and > Juxta for server to client. To me it is just another RPC. This is why > I want JMX on the client side, so I can reuse any invoker for the server > to client (or client to client) communication. Yep.. I guess that's what I'm complaining about. I want to have invokers on the client side too. I want JMS call backs to go via an invoker too. I can't do that today because we don't do client side invokers. Regards, Hiram > > -dain --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new PooledInvoker: speeds up invocations
> > - Thread pooling (same as the PooledInvoker). > > When I looked at code it looked like there still was a thread > being spawned > for each invocation. Sure, when you hand off the message, there is a pool > there, but there seemed to be a thread spawn before this. This > needs to be > avoided. > Perhaps.. I've not double checked the pool code. The first time an invocation comes though shure, but the second time, the pooled thread should get reused. > > - Connection sharing. Multiple invocations can be sent to the > > server at the > > same time. Sending an invocation down the socket does not stop other > > invocation from going down the pipe. > > Is this possible? Doesn't the socket get synchronized (and thus > serialized > invocations) when a lot of threads hit it? > Yep.. But this is good, if servicing requests has a delay in it.. You can sqeeze more requests into one socket. I need to make the connections pooled also so that a single socket does not get over-used. > > - Uses NIO if running under java 1.4, normal blocking IO if on 1.3 > > > > My performance testing did not show it was better than RMI. > Perhaps I was > > running a bad test, perhaps I need to add connection pooling so > that more > > than one socket is established from the client to the server. > Perhaps all > > this functionality is just adding too much overhead. > > > > I'll add the benchmark to the pooled test in the testsuite. It already > benchmarks RMI vs. Pooled. > thanks. > > Anyways. JMS need bi-directional invocations (BADLY). Should > > this become a > > requirement for the other invokers?? > > > > Could a InvocationResponse object be used instead? Or, if you had detyped > invocations, couldn't you just pass a callback object along with > the request > via a client-side interceptor? Just curious...why do you need > bi-directional invocations? Acknowledgements? Callbacks? Is David using > the bi-directional capability for Distributed Trans callbacks? The whole > point of the Invoker architecture is to detach the transport > layer from the > actual service. > The JMS server uses callbacks. Thats how it drives asynchronous message delivery. A normal RMI callback object cannot allways be used since the client may be behind a firewall. I want to be able to communicate with the client over the same socket that he established with the server. Make sense?? Regards, Hiram > Bill > > > > --- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new PooledInvoker: speeds up invocations
> > Could a InvocationResponse object be used instead? Or, if you > had detyped > > invocations, couldn't you just pass a callback object along with > > the request > > via a client-side interceptor? Just curious...why do you need > > bi-directional invocations? Acknowledgements? Callbacks? Is > David using > > the bi-directional capability for Distributed Trans callbacks? > The whole > > point of the Invoker architecture is to detach the transport > > layer from the > > actual service. > > I guess it is for the asynchronous push of JMS messages from the server to > the client. > yes. --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss.net email transport
The point i was making is that it's easier to the original e-mail than it is to store the original encripted https post. Regards, Hiram > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Scott > M Stark > Sent: Friday, November 15, 2002 1:12 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] jboss.net email transport > > > So send a signed HTTP post over SSL. A digital sig is a digital sig > whether by email or post. The only advantange email has is that the > clients are better setup to manage the keys and perform the signing. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxx > > - Original Message - > From: "Hiram Chirino" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, November 14, 2002 4:19 PM > Subject: RE: [JBoss-dev] jboss.net email transport > > > > The cool thing about a signed secure e-mail message is that you get > > non-repudiation. If at a later time company B tells company A, > hey I never > > sent you a Purchase Order for 1 million widgets.. company A > can show them > > the signed secure e-mail message that they received the PO in. > It would be > > harder to do something like that over http. > > > > Regards, > > Hiram > > > > > > --- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new PooledInvoker: speeds up invocations
> > scenario. The PooledInvoker is 300% faster than the default > > RMI Invoker. > > > > 2nd scenario: > > invokor is 30% faster than the default RMI based invoker. > > > P.S. This code is extremely more simple than the Trunk > > Invoker and I've been told that the Trunk Invoker provides no > > performance boost. > > Plus the name sucks. Let's stir clear of 'cute names', PooledInvoker > clearly describes what it is. > Yes the 'trunk' name sucks.. Maybe you can help me give it a better name. here are the things it does: - bi-directional invocations. client can invoke the server, server can invoke the client. - Thread pooling (same as the PooledInvoker). - Connection sharing. Multiple invocations can be sent to the server at the same time. Sending an invocation down the socket does not stop other invocation from going down the pipe. - Uses NIO if running under java 1.4, normal blocking IO if on 1.3 My performance testing did not show it was better than RMI. Perhaps I was running a bad test, perhaps I need to add connection pooling so that more than one socket is established from the client to the server. Perhaps all this functionality is just adding too much overhead. Anyways. JMS need bi-directional invocations (BADLY). Should this become a requirement for the other invokers?? Regards, Hiram --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss.net email transport
The cool thing about a signed secure e-mail message is that you get non-repudiation. If at a later time company B tells company A, hey I never sent you a Purchase Order for 1 million widgets.. company A can show them the signed secure e-mail message that they received the PO in. It would be harder to do something like that over http. Regards, Hiram > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Matt > Munz > Sent: Thursday, November 14, 2002 10:55 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] jboss.net email transport > > > Jason, > > Well, you've peaked my interest... > > > This method(with digital signatures/encryption) would be more secure > > than the Http(s) transport, > > Really? Any articles on the subject? > > > Authentication would be near definite > > (rather hard to fake), > > Is there something in the mail protocol that facilitates this? > I'd love to > see a strong argument for "email is more secure than https"... > > > the server would not be exposed to the big bad > > internet, > > Hmmm. Email attacks are fairly common. Email is, by definition, > a part of > the internet. I'm not sure where you're going with this... > > > and the company's IT guys don't have to set up a VPN to every > > outside source that needs to update data in the server. > > VPNs are bad ;) What's wrong with the tried and true "poking a > hole in the > firewall" technique? What about https? > > Is the idea that "they have to have email anyway, so let's just > tunnel over > that"? Wasn't this same argument used for HTTP tunnelling? > > - Matt > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Jason > Essington > Sent: Thursday, November 14, 2002 10:33 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] jboss.net email transport > > > Hi Matt, > > Given an instance where a company would place a server on its intranet > (behind a firewall that does not allow incoming connections from the > internet). > > Now, If this company wanted to receive periodic updates to some > semi-static data (iso country codes for instance) from a source on the > internet. This source would need a VPN to get through the companies > firewall (major hassle if this source has to update many servers, or if > the company needs data updated from many different sources) or it could > send a Signed and possibly Encrypted email to a mail account the > company has set up for the server. The server checks it's email at a > configured interval and processes any soap messages it finds there. The > digital signature is used for message verification and authentication, > while encryption could be used to protect sensitive parts of the > message. The message is processed and it's response (or fault) is > returned to the original sender via the mail server. > > This method(with digital signatures/encryption) would be more secure > than the Http(s) transport, Authentication would be near definite > (rather hard to fake), the server would not be exposed to the big bad > internet, and the company's IT guys don't have to set up a VPN to every > outside source that needs to update data in the server. > > All in all, and email transport with digital signatures and encryption > has quite a bit of promise as a secure way to allow data to pass > through/around a firewall without too much extra hassle. There would > need to be a mechanism for key exchange, but no work on the part of IT. > > -jason > > On Thursday, November 14, 2002, at 07:21 AM, Matt Munz wrote: > > > Jason, > > > > Just out of curiosity, what would you use this for? > > > > - Matt > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of > > Jason > > Essington > > Sent: Wednesday, November 13, 2002 5:48 PM > > To: [EMAIL PROTECTED] > > Subject: [JBoss-dev] jboss.net email transport > > > > > > Hi all > > > > I have managed to get a fairly crude email transport working in > > jboss.net (It is lurking in head). I would appreciate any comments / > > design ideas from folks who are interested. > > > > Check the javadocs in org.jboss.net.axis.mail.MailTransportService to > > see how to set it up. > > > > It will currently process emails with simple soap messages (no > > attachments). It requires the content type to be application/soap+xml > > with the action attribute set to the desired service. > > > > i.e. content-type: application/soap+xml; action=SomeService > > > > The response message is returned to the sender via email. > > > > Since email doesn't really have any type of authentication framework > > the transport will only work with ejb's / ejb methods's that have > > unchecked permissions. > > > > I have been able to sign (DSA) a soap message using apache's > > xml-security library and have jboss.net verify the signature (I haven't > > submit
RE: [JBoss-dev] MetaDataRepository Proposal
> > David, > > Actually it simplifies the code. If you take a look at our interceptor > stack most have a ton of code just to load and maintain the metadata, Yes there is alot of Metadata now. 1/2 the ton of code that we have there is just taking XML and creating a metadata objects. I think that something like Jelly (http://jakarta.apache.org/commons/sandbox/jelly/) should be able eliminate that code. A tool that will take XML config and generate the Metadata objects that our interceptors can use directly. > and the worst part is we have no control over it at runtime. It is way > simpler. You'll see. > I agree there. But wouldn't it be simpler if we just exposed an API to the client that would allow him to modify the metadata (thus turning something that is static now, into something dynamic)? For example. Say you have a CMP bean x, and the configuration API is exposed via an aspect, then on the client side you would do: CMPConfiguration c = (CMPConfiguration)x; c.setReadAhead( 500 ); And the would in turn create a Invocation with method=setReadAhead that the CMP interceptor would handle by updating the metadata configuration for the bean. Does this make sense? Are you trying to achieve something similar but in a more automated way? Regards, Hiram > The easiest case for me the read ahead configuration in entity beans. > There is no reason for this to be static. In fact it should be > manageable at runtime, and if I'm luck I'll be able to pull it off for > 4.0. Scott tells me there is a similar need to manage security at > runtime. There really is no need to shut down an application in > production just to change some configuration data. > > Even if there is no real need the code is simpler. > > -dain --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Metadata Service
> > IMHO, JMX is limiting. MBeans are declarations of object instances. > > standardjboss.xml, standardcmp-jdbc.xml, the new aspect configs, > > etc... are templates/defaultconfigs for object > > creations/instantiations. A major difference. > > > > Sometimes config is just config and there's really no object you can > > attach it to. > > This is one of the big problems I see with Jboss today. Jorg came to me > a few months ago and said I want to use a database for the cmp mapping > info... a data dictionary and I had to say can't be done. We need the > physical storage abstracted away from the server use. We need metadata > to be more configurable at runtime. > I like that. If it was more configurable at runtime, the JBossMQ would be able to CMP 2.0 for it's message persistence. It would configure CMP engine via API calls. Regards, Hiram --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX on the client side?
What do you mean by the micokernel? Regards, Hiram > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Scott > M Stark > Sent: Monday, November 11, 2002 3:36 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JMX on the client side? > > > JMX is not what is important, its the microkernel and services on > top of it. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxx > > - Original Message - > From: "Hiram Chirino" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, November 10, 2002 8:25 PM > Subject: RE: [JBoss-dev] JMX on the client side? > > > > > > > > Hiram, I think you missed the point. Of course we could do this with > > > out requiring JMX; anything is possible. The point is if we > agree that > > > JMX is always on the client side then entire system is simplified. > > > > > > > I guess the disconnect is happening right here. IMO JMX does not always > > make things easier. What do you think JMX provides that would > simplify "the > > entire system"? Is it: > > (1) Runtime server administration > > (2) Service creation/configuration/lookup. > > > > Even though those are super important on the server side, I > just don't see > > how important those would be on the client side. Am I missing something > > else? > > > > Regards, > > Hiram > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX on the client side?
Ok.. i buy into that. I think running a JMX server on the client side should be a piece of cake. The hard part is figuring out how the client-side deployment system going to work. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of David > Jencks > Sent: Monday, November 11, 2002 12:45 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JMX on the client side? > > > Let me give you my example of why I want it. > > I worked over the trunk invoker so it would do distributed transactions. > This requires at least a source of xid's on the calling side, and > preferably a TransactionManager. Well, they are already there if the > calling side is a jboss instance. If it's a client, the only way you will > be propagating a transaction is if you have a UserTransaction. So, I'd > like to implement the client-side UserTransaction to use the same > mechanism, based on at least an XidFactory and perhaps a > TransactionManager. These are pretty much dependent on the jmx > framework. > If the jmx framework is on the client, I just register the mbeans and I'm > done. If not, I have to rewrite a bunch of the code to be independent of > the jmx framework. Incidently, I think the client end of the > trunk invoker > would also be simpler if it were an mbean: in fact I think there > could be a > lot more code sharing between the two ends. > > david jencks > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX on the client side?
> > Hiram, I think you missed the point. Of course we could do this with > out requiring JMX; anything is possible. The point is if we agree that > JMX is always on the client side then entire system is simplified. > I guess the disconnect is happening right here. IMO JMX does not always make things easier. What do you think JMX provides that would simplify "the entire system"? Is it: (1) Runtime server administration (2) Service creation/configuration/lookup. Even though those are super important on the server side, I just don't see how important those would be on the client side. Am I missing something else? Regards, Hiram --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX on the client side?
> > > JMX on the client side and JBoss on the client side are two different > > > things, right? AFAIK, MBeanServerFactory.createMBeanServer() doesn't > > > require the service deployer. If it does, that's another thing... > > > > Agreed. All I am talking about is an MBean server. If someone wants > > more JBoss services on the client side they can do that, but it > > shouldn't be required. > > Conceptually I like this, but... > > Are you thinking that these mbeans won't have any attributes? Or do you > plan to set them hardcoded in code? Or where does the configuration come > from? Can we serialize a prototype from the server and register the > deserialized copy on the client? Is there some way to use the new remote > jmx stuff for something like this? > > david > Could all of this MBean server configuration happen in a client-side interceptor?? So the first client-side interceptor might initialize the MBean server. Then the rest of the interceptors in the client chain can use the interceptor (register services or lookup other services). This approach would allow you to choose if you use JMX on the client or not. Regards, Hiram --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX on the client side?
> +1. This all came about because I was thinking about client side caches > with server invalidation. Without the JMX kernel it is a pain because > we have invent a totally new architecture to handle server to client > invocations. If we have the kernel, we quickly prototype this by > reusing the server invokers. Of course our existing invokers won't work > for a real deployment with clients behind a firewall, but it is a good > start. > > -dain > What I would like to know, is: what are the features that JMX provides that you need on the client side?? (1) Is it the interceptor architecture built around JMX? (2) Is it the ability to look up other services via JMX? I want to know because I think that we can provide client side container without having to use JMX. I think that stuff will actually get simpler if we do not FORCE jmx on the client side. Our Aspect API is all about that. It's about providing at least #1 in a clean generic fashion. But for it successfully use for client side containers, I need to understand what all the requirements will be. Bill, I know you started doing some work on client side interceptors using the aspect stuff. What JMX features were you wishing you had on the client side?? Regards, Hiram --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMS - priority queueing
You are not using the JMS API correctly. Read the JMS spec or post this message to the user forums. Regards, Hiram > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of T. > Subramanian > Sent: Wednesday, October 30, 2002 11:54 AM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] JMS - priority queueing > > > Hi All, > I am using JBoss 3.0.0 version. When I tried with JMS > examples that uses > the priority , it doesn't work as expected. > > Following are the steps I have done. In a class used to send JMS messages > to a queue I set the priority ranging from 0 -9. I used > setJMSPriority(int) method in TextMessage object. But in the > receiving end > when I received the messages I always the get the priority as 4. Method I > used to get the priority is getJMSPriority() method in TextMessage object. > > I am using the JMS implementation that comes with JBoss 3.0.0. > > Can any one using the priority feature of JMS ?. Any > pointers will be of > great help to me > > Thanks, > Subramanian T > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
> Previously we were on opposite sides of this debate:-) > > I think for simplicity we should have only stateless interceptors, any > interceptor can store per-stack state in a the stack top in a hashmap. > This was the way I created the aspect stuff initially. The interceptors were tottaly statless. Even intercetor config was not stored in the interceptor. The config was put at the top of the stack. Advantage: 1 interceptor instance could be used for all stack instances. (less memory usage?? not really, the config objects are created and put at the top of the stack) Disadvantages: Hard to develop the interceptors and I think it lead to worse perfomance. I had to do a hashmap look up of the config every time it had to handle an invocation. --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Eclipse and JBoss Howto posted.
> Hiram, > > great news! > > Two things though, > > a) does this explain how to get servlet, jsp and ejb debugging > working with > jboss? Some of the other help files explain how to do this with > independent > versions of jboss and tomcat, but not for the integrated version. > No. What I have setup is for the development of JBoss it self. > b) if the website isn't going to be rebuilt soon, can you tell us > where to > find the file in the meantime? > IF your are still interested, the JBoss website is in CVS. Regards, Hiram > > cheers, > > Bruce --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Eclipse and JBoss Howto posted.
> I like project/output/eclipse-classses. ok i'll change this soon. > > One more thing. I have JBoss launch configuration, so you can run/debug > JBoss right from within Eclipse. What would be the best place to put it? > Do you thing build/etc/eclipse/jboss-4.0.0alpha.launch is appropriate? > sounds good to me. --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Eclipse and JBoss Howto posted.
Thanks for pointing that problem out. We could also adjust the project/.cvsignore file so that the directory that eclipse uses for building gets ignored. I don't want eclipse building to the same directory that ant builds to because it that will throw ant's timestamps off. I've noticed some weird things in the past like: - You edit somefile.java and save it and save it with an error. - Eclipse generates somefile.class ( even though it has a compile error ) - You run the ant build and it builds OK (because somfile.class is older than somefile.java) - You run your program and you get a runtime exception saying the somefile.class file is screwed. But It might be worth moving the eclipse build directory to something like: project/output/eclipse-classses Since the would match what the ant build does a little better. Regards, Hiram > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Igor > Fedorenko > Sent: Monday, October 14, 2002 9:31 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Eclipse and JBoss Howto posted. > > > Hiram Chirino wrote: > > A thread concerning how to use Eclipse to develop Jboss was > started a while > > back.. I finally got the time to put together a little howto > to explain how > > to use eclipse to develop JBoss. > > > > You will find it in the Developer Guides section of the Jboss > website the > > next time the website gets rebuilt. > > > > Thank you very much, Hiram! I have one cosmetic improvement I would like > to check in if you do not mind. All projects except jboss.net have > output dir set to project/bin (i.e. not to project/output/classes). This > makes Eclipse think that project/bin is a "Local addition not under CVS > control" and mark all these projects as having outgoing changes. > Changing projects' output dir to project/output/classes fixes this > problem. What do you think? > > -- > Igor Fedorenko > Think smart. Think automated. Think Dynamics. > www.thinkdynamics.com > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Eclipse and JBoss Howto posted.
A thread concerning how to use Eclipse to develop Jboss was started a while back.. I finally got the time to put together a little howto to explain how to use eclipse to develop JBoss. You will find it in the Developer Guides section of the Jboss website the next time the website gets rebuilt. Regards, Hiram --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jbossmq and jca 1.5
Hey David.. I want to see If I can start working on this. I know like amost zero about jca but I know quite a bit about the XA stuff and how jbossmq txs work with the MDB. anyways.. I guess what I need to know is how is the contianer going to initialize the jms stuff so that it can deliver the container it's messages. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of David > Jencks > Sent: Friday, August 30, 2002 1:35 PM > To: jboss-dev > Subject: [JBoss-dev] jbossmq and jca 1.5 > > > I started looking at modifying jbossmq and/or the jmsra adapter to work > with the j2ee connector architecture 1.5 facilities. I am > definitely not a > jms expert so a lot of what I say may not make sense. > > Here's what the new spec provides that I think is relevant: > > thread pooling through the WorkManager interface. You submit Work > instances to be done in other threads. The app server controls the thread > pooling. > > message inflow through the MessageEndpoint interfaces. In particular, I > think we should use Option B which involves the jms system calling, on a > MessageEndpoint supplied from the app server, > > beforeDelivery([the onMessage method]); //this starts the jta tx and > informs the adapter via an XAResource the adapter supplied earlier. > > onMessage(message); //actual message delivery to MessageListener > > afterDelivery(); //ends the tx, again the adapter is informed via the > XAResource. > > > > I keep getting lost looking at the jms code. My impression so far is that > although the jca 1 jmsra adapter appears to work ok without modifying > jbossmq, using the contracts mentioned above will require additional code > in jbossmq itself, namely an additional way of delivering > messages within a > transaction. > > Does this make sense? Do any of the jbossmq experts want to work on this? > > There are very simple examples of using the work and message endpoint > interfaces in the testsuite in .../jca/inflow. > > I haven't written the deployment portion of the connector 1.5 > support yet: > I'm hoping for a real adapter example that can be used to test it. > However, I think for now everything needed can be set up without > a deployer > as explicit mbeans: this is what I did in the tests. > > Thanks > david jencks > > > --- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Proxy generator broken
I'll look into it right away. Regards, Hiram > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott > M Stark > Sent: Friday, September 20, 2002 7:10 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Proxy generator broken > > > I fixed the immeadiate problem which was causing the NPE, but > these recent changes > still need to be validated against the full testsuite. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > - Original Message - > From: "Scott M Stark" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, September 20, 2002 3:41 AM > Subject: Re: [JBoss-dev] Proxy generator broken > > > > There have been a number of changes to the proxy compiler code > in the past > > 7 days by Hiram. Were these changes tested against the full > testsuite? Also, > > the formatting of these changes is screwed up. Please test and > fix both the > > problem and the formatting. > > > > > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > > > > > - Original Message - > > From: "Dain Sundstrom" <[EMAIL PROTECTED]> > > To: "JBoss-dev" <[EMAIL PROTECTED]> > > Sent: Thursday, September 19, 2002 9:24 PM > > Subject: [JBoss-dev] Proxy generator broken > > > > > > > Does anyone know how the proxy generator works? > > > > > > It looks like it it totally broken in head. When I deploy > any cmp2 bean > > > I get the following exception: > > > > > > 22:27:28,336 ERROR [EntityContainer] Starting failed: > > > org.jboss.util.NestedRuntimeException: Failed to create new proxy > > > target; - nested throwable: (java.lang.N > > > ullPointerException) > > > 22:27:28,341 WARN [ServiceController] Problem starting service > > > jboss.j2ee:jndiName=cmp2/readonly/Book,service=EJB > > > org.jboss.util.NestedRuntimeException: Failed to create new proxy > > > target; - nested throwable: (java.lang.NullPointerException) > > > > > > + nested throwable: > > > java.lang.NullPointerException > > > at > > > org.jboss.proxy.compiler.ProxyCompiler.getCode(ProxyCompiler.java:174) > > > at > org.jboss.proxy.compiler.Runtime.makeProxyType(Runtime.java:66) > > > at > > > org.jboss.proxy.compiler.ProxyCompiler.(ProxyCompiler.java:87) > > > at > > > org.jboss.proxy.compiler.Proxies$Impl.newTarget(Proxies.java:594) > > > at > org.jboss.proxy.compiler.Proxies.newTarget(Proxies.java:77) > > > at > org.jboss.proxy.compiler.Proxy.newProxyInstance(Proxy.java:49) > > > at > > > > org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateBeanClassInstanceCommand. > (JDBCCreateBeanClassInstanceCommand.java:52) > > > at > > > > org.jboss.ejb.plugins.cmp.jdbc.JDBCCommandFactory.createCreateBean > ClassInstanceCommand(JDBCCommandFactory.java:107) > > > at > > > > org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.startStoreManager( > JDBCStoreManager.java:436) > > > at > > > > org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreMan > ager.java:369) > > > > > > I'm going to look at this, but if someone knows what is going on, I > > > would appreciate the help. > > > > > > -- > > > > > > Dain Sundstrom > > > Chief Architect JBossCMP > > > JBoss Group, LLC > > > > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
sorry.. forgot to add my renamed file. Should be fixed now. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > [EMAIL PROTECTED] > Sent: Tuesday, September 17, 2002 7:45 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed > > > > = > ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= > = > > JAVA VERSION DETAILS > java version "1.3.1_03" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) > Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) > > = > > HERE ARE THE LAST 50 LINES OF THE LOG FILE > > /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss > /aspect/AspectClassLoader.java:165: cannot resolve symbol > symbol : class AspectDefinition > location: class org.jboss.aspect.AspectClassLoader > return (AspectDefinition) aspectDefinitions.get(clazz); > ^ --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: FW: [JBoss-dev] configuration of interceptors
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bill
> Burke
> Sent: Thursday, September 12, 2002 6:33 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: FW: [JBoss-dev] configuration of interceptors
>
>
> Its more like
>
> DynamicProxy -> interceptor stack -> Target MBean
>
That should be easy with the stuff I just commited.
> There should be no concept of server or client.
>
> I also believe the interceptor chain, Aspect Oriented framework
> should be a
> generic framework and should work with any type of Object. It should be
> core to JMX. Sure, the MBeanDeployer could look at some XML and be the
> bridge between Aspects and MBeans, but lets keep Aspects a separate,
> lightweight framework.
It's currently implemented like that.. seperate nice and light weight. The
only dependency it currently has is on the org.jboss.proxy.compiler.*
package. So we could take my stuff and the org.jboss.proxy.compiler.* stuff
and make it and standalone module that can provide an interceptor stack to
any POJO.
+ this should run on 1.2 JVM since the Proxy classes are BECL generated.
>
> We have totaly freedom as far as MBean XML config files go, right?
>
> Here was my idea for an Aspect framework. I drew up the API while in
> Germany. The features were:
>
> - Interceptors could be services/singletons OR instantiated per chain.
My current implementation forces them to be singletons. But I don't think
this should be a major issue.
> - You could prepend or append an interceptor to the chain globally at
> runtime
> - You could prepend or append an interceptor to an individual chain.
So if you change a chain configuration when would it take effect on a proxy
that was using the previous configuration??
> - DynamicProxies would have a generic Aspect interface
I like the Aspect interface Idea.
>
>
>
> interface AspectManager
> {
> void createChain(String name);
> void registerInterceptorSingleton(String name, Interceptor interceptor);
>
> // These methods globally modify the chain of any Aspect in system with
> the given name
> void prependAspect(String chainname, String interceptorName,
> Class clazz,
> Element metadata);
> void appendAspect(String chainname, String interceptorName, Class clazz,
> Element metadata);
>
> void prependAspect(String chainname, String singletonName);
> void appendAspect(String chainname, String singletonName);
>
> void removeAspect(String chainname, String interceptorName);
>
>
> /**
>* Given any old object, make it Aspect Oriented.
>* metadata could hold InvocationContext-like information
>*/
> Aspect metamorphisis(String chainName, Class[] interfaces, Element
> metadata, Object targetObject);
>
> /**
>* No target object, useful for remote invocations.
>* metadata could hold InvocationContext-like information like
> MBean name
> to invoke on
>* and stuff like that.
>*/
> Aspect createAspect(String chainName, Class[] interfaces, Element
> metadata);
> }
>
> /**
> * Every DynamicProxy would implement this interface
> */
> interface Aspect
> {
>String getAspectName();
>
>/**
> * Allows you to detach this particular aspect
> */
>void setAspectName(String newName);
>
>Object[] getInterceptors();
>Interceptor findInterceptor(String name);
>
>Object getTargetObject();
>
> }
>
>
> So, XML would look something like this. An AspectChain MBean would create
> chains within the AspectManager. Add a new keyword to XML .
> This would give the deployer a reference to the name of the interceptor
> chain to use. The Deployer would create a Proxy via the
> AspectManager with
> this chain name and register this Proxy with the MBeanServer.
>
> name="MyMBean">
>
> jboss.AspectChains:name=SomeOldChain
>
>
> name="jboss.AspectChains:name=ClientProxyChain>
>
>
> name="Transaction"
> type="instance"
> class="org.jboss.proxy.TransactionInterceptor"
> />
>
>
>
>
>
Looks cool. I'll send you the javadocs for what I commited to CVS today.
My stuff is lacking on the JMX features. Anyways.. I'm glad we are all
exited about this kinda stuff.
Regards,
Hiram
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Hiram
> > Chirino
> > Sent: Thursday, September 12, 2002 2:25 PM
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> >
RE: FW: [JBoss-dev] configuration of interceptors
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of marc
> fleury
> Sent: Thursday, September 12, 2002 3:55 PM
> To: 'Hiram Chirino'
> Cc: [EMAIL PROTECTED]
> Subject: RE: FW: [JBoss-dev] configuration of interceptors
>
>
> > Ok I imagine a client invocation chain will look like:
> >
> > clientproxy -> client-interceptor-stack ->
> > serverproxy -> server-interceptor-stack -> targetMbean
>
> not quite there is no typed serverproxy in the middle just a straight
> invoke() stack.
>
> The server/client nature just appear do to a invoker in the JBoss sense.
>
Yeah. I forgot.. David reminded me in his email.
>
> so...
>
> > Would doing some think like this satisfy you client-server
> > requirments? :
> >
> > serverproxy =
> > factory.createAspect("server-interceptor-stack",
> > targetMbean); clientproxy =
> > factory.createAspect("client-interceptor-stack", serverproxy
> > );
> >
>
> so... no that would be overkill as you introduce an additional Dynamic
> Proxy in the middle. Right now there are straight invoke().
>
right again.
> The point of the separation is that you may want travelling proxies and
> you may want inVM proxies all the time. While our client/server
> separation works today as inVM proxies (we have the EJB proxies working
> this way).
>
> It needs to be a construct in the factory whether you want distributable
> proxies or standalone. Note that the full client/server merged with no
> distribution would cover both cases however.
>
> > files. If we
> > provide a JMX interface to the factory so that you can
> > view/update stack
> > configurations, would that satisfy your requirement "to have
> > these puppies
> > manageable."
>
> It is a bit more deep than that. I am really looking for a central
> repository of that name-> configuration mapping and a way to interact
> with it, clearly JMX is the way to go and it needs to be centralized.
I thought thats kinda what I said. The Factory right now manages the
name->configuration mapping. We need and uber cool JMX MBean that allows us
to manipulate those configurations.
> Don't worry about it for now. Bill and I are thinking about that
> centralization. There also needs to be a callback in the interceptors
> for configuration changes. This dynamicity of configuration is
> completely missing from the current codebase and the EJB spec in
> general. This would take care of that.
You need to expand on this a little.. a small use case maybe.
>
> Gents I really think we got it this time. This is the end of our
> journey... the real AOP framework in JBoss. 10 years of industry
> dominance... a monopoly in the making
>
wow that gives me the tingles..
> marc f
> >
> > Regards,
> > Hiram
> >
> >
> > >From: "marc fleury" <[EMAIL PROTECTED]>
> > >To: <[EMAIL PROTECTED]>
> > >Subject: FW: [JBoss-dev] configuration of interceptors
> > >Date: Thu, 12 Sep 2002 13:44:03 -0400
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED]] On
> > Behalf Of
> > > > marc fleury
> > > > Sent: Thursday, September 12, 2002 1:23 PM
> > > > To: 'Bill Burke'; 'juha lindfors'; 'Adrian Brock'
> > > > Cc: 'Hiram Chirino'; 'Jboss-Development@Lists. Sourceforge. Net'
> > > > Subject: [JBoss-dev] configuration of interceptors
> > > >
> > > >
> > > > Ok
> > > >
> > > > just had an interesting IM with hiram. He essentially has
> > > > implemented the proxy factory we were talking about. I
> > think he is
> > > > missing the client/server side of it but we can very simply add
> > > > these.
> > > >
> > > > Essentially it would revolve around a central
> > > > proxyFactory.createProxy(Interfaces[], client-interceptors[],
> > > > client-configurations[], server-interceptors[],
> > > > serverconfigurations[] targetMbean);
> > > >
> > > > that returns a Dynamic Proxy, hooked up for remote/local
> > calls with
> > > > client and server side interceptors. If you are in one
> > vm you can
> > > > safely assume client=server and only configure one or the other.
> > > > (meaning if one is null then don't configure transport it will be
> > > > invm
RE: FW: [JBoss-dev] configuration of interceptors
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of David
> Jencks
> Sent: Thursday, September 12, 2002 3:24 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: FW: [JBoss-dev] configuration of interceptors
>
>
> I'm a little confused about one part of this...
>
> I thought the plan was to turn our current ejb interceptors into mbean
> interceptors and the Containers into fancy MBeanInvokers (If I remember
> correctly, anyway the top thing on the mbean interceptor stack). If this
> is correct, the ServerInterceptors would be behind the target
> MBean and not
> part of this new factory.
>
> This would look more like
> clientproxy -> client-interceptor-stack ->
> serverproxy -> targetMbean -> mbean-interceptor-stack
>
ya i think this is a better picture..
>
> In any case, I think all the stack factories should be mbeans as Hiram
> mentions.
>
> david jencks
>
>
> On 2002.09.12 14:25:25 -0400 Hiram Chirino wrote:
> >
> > Ok I imagine a client invocation chain will look like:
> >
> > clientproxy -> client-interceptor-stack ->
> > serverproxy -> server-interceptor-stack -> targetMbean
> >
> > Would doing some think like this satisfy you client-server
> requirments? :
> >
> > serverproxy = factory.createAspect("server-interceptor-stack",
> > targetMbean);
> > clientproxy = factory.createAspect("client-interceptor-stack",
> > serverproxy
> > );
> >
> > Please note: that "server-interceptor-stack" in essence will resolve to
> > a set of { server-interfaces[], server-interceptors[],
> > server-configurations[] }
> >
> > On another note, right now the factory that generates the proxys for say
> > the
> > "server-interceptor-stack", is configured through static xml files. If
> > we
> > provide a JMX interface to the factory so that you can
> view/update stack
> > configurations, would that satisfy your requirement "to have these
> > puppies
> > manageable."
> >
> > Regards,
> > Hiram
> >
> >
> > >From: "marc fleury" <[EMAIL PROTECTED]>
> > >To: <[EMAIL PROTECTED]>
> > >Subject: FW: [JBoss-dev] configuration of interceptors
> > >Date: Thu, 12 Sep 2002 13:44:03 -0400
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED]] On
> > > > Behalf Of marc fleury
> > > > Sent: Thursday, September 12, 2002 1:23 PM
> > > > To: 'Bill Burke'; 'juha lindfors'; 'Adrian Brock'
> > > > Cc: 'Hiram Chirino'; 'Jboss-Development@Lists. Sourceforge. Net'
> > > > Subject: [JBoss-dev] configuration of interceptors
> > > >
> > > >
> > > > Ok
> > > >
> > > > just had an interesting IM with hiram. He essentially has
> > > > implemented the proxy factory we were talking about. I think
> > > > he is missing the client/server side of it but we can very
> > > > simply add these.
> > > >
> > > > Essentially it would revolve around a central
> > > > proxyFactory.createProxy(Interfaces[], client-interceptors[],
> > > > client-configurations[], server-interceptors[],
> > > > serverconfigurations[] targetMbean);
> > > >
> > > > that returns a Dynamic Proxy, hooked up for remote/local
> > > > calls with client and server side interceptors. If you are
> > > > in one vm you can safely assume client=server and only
> > > > configure one or the other. (meaning if one is null then
> > > > don't configure transport it will be invm
> > > > only)
> > > >
> > > > In the case of hiram he has only one aspect of it (and he
> > > > calls it aspect everywhere) but that construct is really what
> > > > we need. I also think we should have the "MBean" in there,
> > > > even though we are talking about a POJO.
> > > >
> > > > I believe he has solid code for it and I am really interested
> > > > in adding this to the base. I am not sure it is a JMX level
> > > > construct (due to the pojo nature) but having the JMX base
> > > > manage these configurations and associations between target
> > > > and interceptors/configuration is the only sane way I can
> > > > imagi
Re: FW: [JBoss-dev] configuration of interceptors
Ok I imagine a client invocation chain will look like:
clientproxy -> client-interceptor-stack ->
serverproxy -> server-interceptor-stack -> targetMbean
Would doing some think like this satisfy you client-server requirments? :
serverproxy = factory.createAspect("server-interceptor-stack", targetMbean);
clientproxy = factory.createAspect("client-interceptor-stack", serverproxy
);
Please note: that "server-interceptor-stack" in essence will resolve to
a set of { server-interfaces[], server-interceptors[],
server-configurations[] }
On another note, right now the factory that generates the proxys for say the
"server-interceptor-stack", is configured through static xml files. If we
provide a JMX interface to the factory so that you can view/update stack
configurations, would that satisfy your requirement "to have these puppies
manageable."
Regards,
Hiram
>From: "marc fleury" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Subject: FW: [JBoss-dev] configuration of interceptors
>Date: Thu, 12 Sep 2002 13:44:03 -0400
>
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]] On
> > Behalf Of marc fleury
> > Sent: Thursday, September 12, 2002 1:23 PM
> > To: 'Bill Burke'; 'juha lindfors'; 'Adrian Brock'
> > Cc: 'Hiram Chirino'; 'Jboss-Development@Lists. Sourceforge. Net'
> > Subject: [JBoss-dev] configuration of interceptors
> >
> >
> > Ok
> >
> > just had an interesting IM with hiram. He essentially has
> > implemented the proxy factory we were talking about. I think
> > he is missing the client/server side of it but we can very
> > simply add these.
> >
> > Essentially it would revolve around a central
> > proxyFactory.createProxy(Interfaces[], client-interceptors[],
> > client-configurations[], server-interceptors[],
> > serverconfigurations[] targetMbean);
> >
> > that returns a Dynamic Proxy, hooked up for remote/local
> > calls with client and server side interceptors. If you are
> > in one vm you can safely assume client=server and only
> > configure one or the other. (meaning if one is null then
> > don't configure transport it will be invm
> > only)
> >
> > In the case of hiram he has only one aspect of it (and he
> > calls it aspect everywhere) but that construct is really what
> > we need. I also think we should have the "MBean" in there,
> > even though we are talking about a POJO.
> >
> > I believe he has solid code for it and I am really interested
> > in adding this to the base. I am not sure it is a JMX level
> > construct (due to the pojo nature) but having the JMX base
> > manage these configurations and associations between target
> > and interceptors/configuration is the only sane way I can
> > imagine to have these puppies manageable. I want visibility
> > on that configuration for a given mbean (the generalized
> > mbean againg being just a pojo or target). This is our generalized
> > proxy factory.
> >
> > The AOP framework of the future is staring us in the eye...
> > we got it.
> >
> > marc f
> >
> >
> > xx
> > Marc Fleury, Ph.D.
> > President, Founder
> > JBoss Group, LLC
> > xx
> >
> >
> >
> > ---
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > ___
> > Jboss-development mailing list [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
_
Join the worlds largest e-mail service with MSN Hotmail.
http://www.hotmail.com
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Unwrapping exceptions in client proxy
> > > This is just another reason to get rid of the lame Sun RMI > > implementation (JBoss 4.0). In the meantime, I agree that we > > we are not there yet, You guys talking about replacing RMI for the remote EJB invocations?? Isn't that what we have the JBoss.IIOP and JBoss.Net projects?? Regards, Hiram > > > (you) will > > need to make patched to the unwrapping code. > > let's do the workaround > > marc f > > > > > --- > In remembrance > www.osdn.com/911/ > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss monitoring: Thread-Pool
yes.. please.. jboss-mq would benefit also. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Dain > Sundstrom > Sent: Thursday, August 29, 2002 10:56 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JBoss monitoring: Thread-Pool > > > I agree, but all of our stuff can use it. This would make it much > easier to debug thread problems (like the interrupted bug). > > -dain > > Scott M Stark wrote: > > Its a good idea to have such a service available, but using it cannot > > be a requirement for integration at this point as in general we cannot > > get a third party to use our thread pool. The pool component should > > really just fall out of the JCA work. > > > > > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > > > - Original Message - > > From: "Dain Sundstrom" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, August 29, 2002 7:21 AM > > Subject: Re: [JBoss-dev] JBoss monitoring: Thread-Pool > > > > > > > >>I think it would be cool to have a centralized thread pool mbean that > >>anyone that needs a worker thread goes to. The pool would need to be > >>partitioned, but that is fairly simple. > >> > >>What do you think? > >> > >>-dain > >> > >>Sacha Labourey wrote: > >> > >>>Cool. But do you mean that each part/module of JBoss consuming threads > >>>should hood in JCA? Isn't that overkill? > >>> > >>>For example, the invokers, great consumers of threads, will > they need to > >>>hook in JCA? How do you see that? > >>> > >>> > >>> > >>> > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de > David Jencks > Envoyé : jeudi, 29 août 2002 15:49 > À : [EMAIL PROTECTED] > Objet : Re: [JBoss-dev] JBoss monitoring: Thread-Pool > > > One of the parts of jca 1.5 is a thread pool with transaction import > capabilities. (Work contracts) I hope to get this committed > in the next > couple of days, it's written and somewhat tested. > > david jencks > > On 2002.08.29 09:21:01 -0400 Sacha Labourey wrote: > > > >Hello, > > > >As part of JBoss monitoring, the thread usage is a very interesting > >indication. Furthermore, for performance reasons, having a > thread pool > >would > >be a good thing (TM). > > > >What do you think about integrating a thread pool in JBoss? > > Parts such as > > > >JavaGroups would also need to be integrated in this > framework (JG is a > >big > >thread consumer) > > > >David, Mr. Pool ;), what do you think about it? > > > >Cheers, > > > > > > > >Sacha > > > > > > > >--- > >This sf.net email is sponsored by:ThinkGeek > >Welcome to geek heaven. > >http://thinkgeek.com/sf > >___ > >Jboss-development mailing list > >[EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > >>> > >>> > >>> > >>> > >>>--- > >>>This sf.net email is sponsored by:ThinkGeek > >>>Welcome to geek heaven. > >>>http://thinkgeek.com/sf > >>>___ > >>>Jboss-development mailing list > >>>[EMAIL PROTECTED] > >>>https://lists.sourceforge.net/lists/listinfo/jboss-development > >> > >> > >>-- > >> > >>Dain Sundstrom > >>Chief Architect JBossCMP > >>JBoss Group, LLC > >> > >> > >> > >> > >>--- > >>This sf.net email is sponsored by:ThinkGeek > >>Welcome to geek heaven. > >>http://thinkgeek.com/sf > >>___ > >>Jboss-development mailing list > >>[EMAIL PROTECTED] > >>https://lists.sourceforge.net/lists/listinfo/jboss-development > >> > > > > > > > > > > --- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > -- > > Dain Sundstrom > Chief Architect JBossCMP > JBoss Group, LLC > > > > > --- > This sf.net email is spo
RE: [JBoss-dev] jboss modules as eclipse projects
I do my JBoss development with eclipse.. but it is not easy to setup :( If you are REALY interested, I can exand on how I do it, but it's not all that nice. Regards, Hiram > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Igor > Fedorenko > Sent: Saturday, August 17, 2002 10:23 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] jboss modules as eclipse projects > > > Marius Kotsbak wrote: > > On Sat, 2002-08-17 at 16:00, Igor Fedorenko wrote: > > > >> Hi, > >> > >> I have setup eclipse project for most of jboss modules. It required > >> some changes to one of build.xml files but now I can use eclipse as > >> a convenient jboss source code browser or > > > > > >> (theoretically) start jboss under eclipse debugger. Anyone > >> interested? > > > > It works almost 100% using EASIE-plugin, or by simlpy adding all jars > > of jboss manually. > > > Are you talking about debugging applications (ejbs for instance) > deployed into jboss or about debugging jboss itself? I am talking > *jboss* source code and debugging *jboss*. I do not remember it was > possible to do anything like that with easie. > > -- > Igor Fedorenko > Think smart. Think automated. Think Dynamics. > www.thinkdynamics.com > > > > --- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMS 1.1
Good job! > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Andreas Schaefer > Sent: Saturday, August 17, 2002 10:16 PM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] JMS 1.1 > > > Hi Geeks > > JMS 1.1 is in (it compiles and most test runs trough except one). > I will remove some redundant classes next week to make the > implementation clearer and then adjust the JUnit tests to cover > JMS 1.1. > > Please note that this step only covers the necessary steps to > implement the common interfaces for PTP and P/S models > but I did not implement behind the scene changes. > > Have fun > > x > Andreas Schaefer > Senior Consultant > JBoss Group, LLC > x > > > > > --- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] what does trunk mean in the context of an invoker?
Why not.. Right not It creates a byte[] of the invocation before it puts it on the wire. If it's greater than a certain size, we could do the compression. The current status of the "trunk" invoker is that it seems to have better throughput than RMI, but worse latency. In otherwords, We can push out allot of concurrent requests out to the server but the response times of those requests seems to blow. Still need to figure where my latency bottle neck is comming from. Regards, Hiram > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jason > Dillon > Sent: Thursday, August 08, 2002 5:10 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] what does trunk mean in the context of an > invoker? > > > Coo, just curious. This is a replacement for remote invocation which is > optimized for connections and data transfer? Do you know if the data is > very large that gets passed back and forth? If so, might want to add > optional compression. I have found that the time/cpu to compress (on > the fly) to a remote server is negligible compared to the time it would > take to upload uncompressed. Anyways, just a though. > > --jason > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:jboss- > > [EMAIL PROTECTED]] On Behalf Of Hiram Chirino > > Sent: Wednesday, August 07, 2002 8:33 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] what does trunk mean in the context of an > > invoker? > > > > > > It kinda describes the way this invoker works. It setup up a single > > "trunk" > > socket connection to the server which all client threads share. I > know, > > the > > name sucks.. I'm open to sugestions. > > > > What I'm trying to provide with this "trunk" invoker is provide an > invoker > > that will allow the server scale to a higher number of client > connections. > > Still not ready for prime time use but I wantted to add it in before > my > > CVS > > snapshot got too out of date with the current stuff. > > > > Regards, > > Hiram > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > Jason > > > Dillon > > > Sent: Wednesday, August 07, 2002 10:12 PM > > > To: 'Jboss-Development@Lists. Sourceforge. Net' > > > Subject: [JBoss-dev] what does trunk mean in the context of an > invoker? > > > > > > > > > Just curious, > > > > > > --jason > > > > > > > > > > > > > > > > > > --- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > --- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] InvocationLayerStressTestCase timing out
Should be fixed now.. could you verify on your dual processor machines.. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott > M Stark > Sent: Wednesday, July 31, 2002 7:42 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] InvocationLayerStressTestCase timing out > > > Yes, both my win32 and OSX box are dual processor boxes. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxx > - Original Message - > From: "Hiram Chirino" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, July 31, 2002 4:14 PM > Subject: RE: [JBoss-dev] InvocationLayerStressTestCase timing out > > > > > > Are those multi-processor machines?? I've got a feeling that I have a > > deadlock happening and those machines you run them on just makes the > > deadlock show up quicker than on my machine. > > > > I also did not intend this testcase to be run as part of the normal > testcase > > runs... It's just mainly for for peformance comparisons. > > > > Regards, > > Hiram > > > > > --- > This sf.net email is sponsored by: Dice - The leading online job board > for high-tech professionals. Search and apply for tech jobs today! > http://seeker.dice.com/seeker.epl?rel_code=31 > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] InvocationLayerStressTestCase timing out
OK.. working on it.. I can recreate under heavy load.. Regards, Hiram > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott > M Stark > Sent: Wednesday, July 31, 2002 7:42 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] InvocationLayerStressTestCase timing out > > > Yes, both my win32 and OSX box are dual processor boxes. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxx > - Original Message - > From: "Hiram Chirino" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, July 31, 2002 4:14 PM > Subject: RE: [JBoss-dev] InvocationLayerStressTestCase timing out > > > > > > Are those multi-processor machines?? I've got a feeling that I have a > > deadlock happening and those machines you run them on just makes the > > deadlock show up quicker than on my machine. > > > > I also did not intend this testcase to be run as part of the normal > testcase > > runs... It's just mainly for for peformance comparisons. > > > > Regards, > > Hiram > > > > > --- > This sf.net email is sponsored by: Dice - The leading online job board > for high-tech professionals. Search and apply for tech jobs today! > http://seeker.dice.com/seeker.epl?rel_code=31 > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] InvocationLayerStressTestCase timing out
Are those multi-processor machines?? I've got a feeling that I have a deadlock happening and those machines you run them on just makes the deadlock show up quicker than on my machine. I also did not intend this testcase to be run as part of the normal testcase runs... It's just mainly for for peformance comparisons. Regards, Hiram > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott > M Stark > Sent: Wednesday, July 31, 2002 11:52 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] InvocationLayerStressTestCase timing out > > > I see the same timeout problems on OSX. The nightly emails sent > by Chris are periodically showing timeouts and he is running JDK > 1.3.1_03 on linux: > > Java Version 1.3.1_03 > Java Vendor Sun Microsystems Inc. > Java VM Name Java HotSpot(TM) Server VM > Java VM Version 1.3.1_03-b03 > Java VM Info mixed mode > OS Name Linux > OS Version 2.4.9-34 > OS Arch i386 > > > See http://www.lubega.com/testarchive/?M=D > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > - Original Message - > From: "Seth Sites" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, July 31, 2002 8:07 AM > Subject: Re: [JBoss-dev] InvocationLayerStressTestCase timing out > > > > I have tested with 1.4.0 and 1.3.1_01 jdks on win2k. The timeout only > > occurs in the OIL2 IL. I can even double the number of workers and > > messages being pushed through the other ILs without a problem. > > > > The OIL2 IL test seems to run fine on Linux. I have not tested > any other > > platforms yet. > > > > -Seth > > > > > --- > This sf.net email is sponsored by: Dice - The leading online job board > for high-tech professionals. Search and apply for tech jobs today! > http://seeker.dice.com/seeker.epl?rel_code=31 > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] New JBossMQ IL : OIL2
Hi guys, Just wanted to let you guys know about a new Invocation Layer for JBossMQ. It's called OIL2 because it's closest relative is the current OIL Invocation Layer. I'm very exited about this new IL because it has some very nice performance features. It has low serialization over-head like the old OIL used to have, but it only uses one socket like the UIL. Furthermore, when multiple client threads share the connection, the connection will be multiplexed between the sockets. The OIL and UIL ILs used to suffer severely when multiple client threads shared the connection. I've added a new test to the test suite which can be used to view the performance of the different ILs when multiple threads are sharing a single connection. The results for test case which uses 20 threads sending and receiving 200 messages are: As you can see the OIL2 IL did nicely. Hopefully we can make this the default IL soon. Regards, Hiram --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
Should be fixed now.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> [EMAIL PROTECTED]
> Sent: Monday, July 22, 2002 8:19 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
>
>
>
> =
> ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
> =
>
> JAVA VERSION DETAILS
> java version "1.4.0_01"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03)
> Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)
>
> =
>
> HERE ARE THE LAST 50 LINES OF THE LOG FILE
>
>[javacc] Copyright (c) 1997-2000 Metamata, Inc.
>[javacc] (type "javacc" with no arguments for help)
>[javacc] Reading from file
> /disk/orig/home/lubega/jbossro/jboss-all/messaging/src/main/org/jb
> oss/mq/selectors/SelectorParser.jj . . .
>[javacc] Warning: Lookahead adequacy checking not being
> performed since option LOOKAHEAD is more than 1. Set option
> FORCE_LA_CHECK to true to force checking.
>[javacc] File "TokenMgrError.java" does not exist. Will create one.
>[javacc] File "ParseException.java" does not exist. Will create one.
>[javacc] File "Token.java" does not exist. Will create one.
>[javacc] File "ASCII_CharStream.java" does not exist. Will create one.
>[javacc] Parser generated with 0 errors and 1 warnings.
> [mkdir] Created dir:
> /disk/orig/home/lubega/jbossro/jboss-all/messaging/output/classes
> [javac] Compiling 8 source files to
> /disk/orig/home/lubega/jbossro/jboss-all/messaging/output/classes
>
> compile-classes:
> [javac] Compiling 165 source files to
> /disk/orig/home/lubega/jbossro/jboss-all/messaging/output/classes
> /disk/orig/home/lubega/jbossro/jboss-all/messaging/src/main/org/jb
> oss/mq/server/jmx/DestinationManager.java:44: cannot resolve symbol
> symbol : class DestinationManagerMBean
> location: class org.jboss.mq.server.jmx.DestinationManager
>implements DestinationManagerMBean
> ^
> /disk/orig/home/lubega/jbossro/jboss-all/messaging/src/main/org/jb
> oss/mq/server/jmx/InterceptorLoader.java:25: cannot resolve symbol
> symbol : class InterceptorLoaderMBean
> location: class org.jboss.mq.server.jmx.InterceptorLoader
>implements InterceptorLoaderMBean
> ^
> /disk/orig/home/lubega/jbossro/jboss-all/messaging/src/main/org/jb
> oss/mq/server/jmx/Invoker.java:25: cannot resolve symbol
> symbol : class InvokerMBean
> location: class org.jboss.mq.server.jmx.Invoker
>implements InvokerMBean
> ^
> /disk/orig/home/lubega/jbossro/jboss-all/messaging/src/main/org/jb
> oss/mq/server/jmx/Queue.java:29: cannot resolve symbol
> symbol : class QueueMBean
> location: class org.jboss.mq.server.jmx.Queue
>implements QueueMBean
> ^
> /disk/orig/home/lubega/jbossro/jboss-all/messaging/src/main/org/jb
> oss/mq/server/jmx/Topic.java:33: cannot resolve symbol
> symbol : class TopicMBean
> location: class org.jboss.mq.server.jmx.Topic
>implements TopicMBean
> ^
> /disk/orig/home/lubega/jbossro/jboss-all/messaging/src/main/org/jb
> oss/mq/server/jmx/DelayInterceptor.java:42: cannot resolve symbol
> symbol : class DelayInterceptorMBean
> location: class org.jboss.mq.server.jmx.DelayInterceptor
>implements DelayInterceptorMBean {
> ^
> 6 errors
>
> BUILD FAILED
> file:/disk/orig/home/lubega/jbossro/jboss-all/messaging/build.xml:
390: Compile failed; see the compiler error output for details.
Total time: 4 minutes 12 seconds
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] current cvs version can't be built
try it again.. I forgot to check something in.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Alex
> Loubyansky
> Sent: Monday, July 22, 2002 2:54 AM
> To: JBoss-Dev
> Subject: [JBoss-dev] current cvs version can't be built
>
>
> Hello guys,
>
> just have checked out cvs for jboss-3.1.0alpha and couldn't build it.
>
> compile-classes:
> [javac] Compiling 165 source files to
> C:\CVSROOT\jboss-all\messaging\output\classes
> C:\CVSROOT\jboss-all\messaging\src\main\org\jboss\mq\server\jmx\De
> layInterceptor.java:42: cannot resolve symbol
> symbol : class DelayInterceptorMBean
> location: class org.jboss.mq.server.jmx.DelayInterceptor
>implements DelayInterceptorMBean {
> ^
> C:\CVSROOT\jboss-all\messaging\src\main\org\jboss\mq\server\jmx\De
> stinationManager.java:44: cannot resolve symbol
> symbol : class DestinationManagerMBean
> location: class org.jboss.mq.server.jmx.DestinationManager
>implements DestinationManagerMBean
> ^
> C:\CVSROOT\jboss-all\messaging\src\main\org\jboss\mq\server\jmx\In
> terceptorLoader.java:25: cannot resolve symbol
> symbol : class InterceptorLoaderMBean
> location: class org.jboss.mq.server.jmx.InterceptorLoader
>implements InterceptorLoaderMBean
> ^
> C:\CVSROOT\jboss-all\messaging\src\main\org\jboss\mq\server\jmx\In
> voker.java:25: cannot resolve symbol
> symbol : class InvokerMBean
> location: class org.jboss.mq.server.jmx.Invoker
>implements InvokerMBean
> ^
> C:\CVSROOT\jboss-all\messaging\src\main\org\jboss\mq\server\jmx\Qu
> eue.java:29: cannot resolve symbol
> symbol : class QueueMBean
> location: class org.jboss.mq.server.jmx.Queue
>implements QueueMBean
> ^
> C:\CVSROOT\jboss-all\messaging\src\main\org\jboss\mq\server\jmx\To
> pic.java:33: cannot resolve symbol
> symbol : class TopicMBean
> location: class org.jboss.mq.server.jmx.Topic
>implements TopicMBean
> ^
> 6 errors
>
> BUILD FAILED
>
> file:C:/CVSROOT/jboss-all/messaging/build.xml:390: Compile
> failed; see the compiler error output for details.
> at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:842)
> at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682)
> at org.apache.tools.ant.Task.perform(Task.java:317)
> at org.apache.tools.ant.Target.execute(Target.java:309)
> at org.apache.tools.ant.Target.performTasks(Target.java:334)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
> at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261)
> at
> org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModul
> e(ExecuteModules.java:292)
> at
> org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(Exec
> uteModules.java:194)
> at org.apache.tools.ant.Task.perform(Task.java:317)
> at org.apache.tools.ant.Target.execute(Target.java:309)
> at org.apache.tools.ant.Target.performTasks(Target.java:334)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1250)
> at org.apache.tools.ant.Main.runBuild(Main.java:610)
> at org.apache.tools.ant.Main.start(Main.java:196)
> at org.apache.tools.ant.Main.main(Main.java:235)
>
>
> --
> Best regards,
> Alex Loubyansky
>
>
>
>
> ---
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] is x++ an atomic operation??
Quick question for you Java Language Gurus out there, I heard one that the post increment operator was an atomic operation. For example, if you have a multi-threaded application with: id=lastRequestId++; You would not need to put this in a synchronized block be cause the ++ would be atomic and thus you would not get 2 duplicate ids. I was wondering if this is true or not. Can anybody confirm this for me?? Regards, Hiram --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Obvious JMS Bug that I need fixed right away. ->other possiblebug
yes.. typo. fixed now in CVS.
Regards,
Hiram
>From: Marius Kotsbak <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: Re: [JBoss-dev] Obvious JMS Bug that I need fixed right away.
>->other possible bug
>Date: 09 Jun 2002 10:01:23 +0200
>
>From login-config.xml for jbossmq:
>
>
>
>
> flag = "sufficient">
> "unauthenticatedIdentity">guest
> "sm.objectnam">jboss.mq:service=StateManager >
>
>
>
>Is "sm.objectnam" a typing error? Shoudn't it be "sm.objectname" ?
>
>Marius K
>Boostcom
>
>
>On søn, 2002-06-09 at 02:47, Hiram Chirino wrote:
> > Post a patch to sourceforge and I'll bring it into the code base.
> >
> > Regards,
> > Hiram
> >
> >
> > >From: "Joshua D. Cough" <[EMAIL PROTECTED]>
> > >Reply-To: [EMAIL PROTECTED]
> > >To: [EMAIL PROTECTED]
> > >Subject: [JBoss-dev] Obvious JMS Bug that I need fixed right away.
> > >Date: Fri, 7 Jun 2002 12:28:50 -0400
> > >
> > >It is impossible to call recover in SpySession.java
> > >
> > >here is why:
> > >
> > >
> > >if ( transacted ) {
> > > throw new IllegalStateException( "The session is transacted"
>);
> > > }
> > >if ( !transacted ) {
> > > throw new IllegalStateException( "The session is not
> > >transacted"
> > >);
> > > }
> > >
> > >This obviously doesnt make sense. I need to call recover from a
> > >nontransacted session and have my unacknowledged messages redelivered.
>Here
> > >is the code that needs to be fixed:
> > >
> >
> >
> > >=
> > >
> > > //Rollback a transacted session
> > >public synchronized void rollback()
> > > throws JMSException {
> > >
> > > synchronized ( runLock ) {
> > >
> > > if ( spyXAResource != null ) {
> > > throw new javax.jms.TransactionInProgressException(
>"Should
> > >not
> > >be call from a XASession" );
> > > }
> > > if ( closed ) {
> > > throw new IllegalStateException( "The session is closed"
>);
> > > }
> > > if ( !transacted ) {
> > > throw new IllegalStateException( "The session is not
> > >transacted"
> > >);
> > > }
> > >
> > > // rollback transaction
> > > try {
> > > connection.spyXAResourceManager.endTx(
>currentTransactionId,
> > >true );
> > > connection.spyXAResourceManager.rollback(
>currentTransactionId
> > >);
> > > } catch ( javax.transaction.xa.XAException e ) {
> > > throw new SpyJMSException( "Could not rollback", e );
> > > } finally {
> > > try {
> > >currentTransactionId =
> > >connection.spyXAResourceManager.startTx();
> > > } catch ( Exception ignore ) {
> > > }
> > > }
> > >
> > > }
> > >}
> > >
> > >
> > >public synchronized void recover()
> > > throws JMSException {
> > > if ( closed ) {
> > > throw new IllegalStateException( "The session is closed" );
> > > }
> > > if ( transacted ) {
> > > throw new IllegalStateException( "The session is transacted"
>);
> > > }
> > >
> > > rollback();
> > >
> > >}
> > >
> > >
> > >___
> > >
> > >Don't miss the 2002 Sprint PCS Application Developer's Conference
> > >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> > >
> > >___
> > >Jboss-development mailing list
> > >[EMAIL PROTECTED]
> > >https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
> >
> > _
> > Get your FREE
Re: [JBoss-dev] Obvious JMS Bug that I need fixed right away.
Post a patch to sourceforge and I'll bring it into the code base.
Regards,
Hiram
>From: "Joshua D. Cough" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: [JBoss-dev] Obvious JMS Bug that I need fixed right away.
>Date: Fri, 7 Jun 2002 12:28:50 -0400
>
>It is impossible to call recover in SpySession.java
>
>here is why:
>
>
>if ( transacted ) {
> throw new IllegalStateException( "The session is transacted" );
> }
>if ( !transacted ) {
> throw new IllegalStateException( "The session is not
>transacted"
>);
> }
>
>This obviously doesnt make sense. I need to call recover from a
>nontransacted session and have my unacknowledged messages redelivered. Here
>is the code that needs to be fixed:
>
>
>=
>
> //Rollback a transacted session
>public synchronized void rollback()
> throws JMSException {
>
> synchronized ( runLock ) {
>
> if ( spyXAResource != null ) {
> throw new javax.jms.TransactionInProgressException( "Should
>not
>be call from a XASession" );
> }
> if ( closed ) {
> throw new IllegalStateException( "The session is closed" );
> }
> if ( !transacted ) {
> throw new IllegalStateException( "The session is not
>transacted"
>);
> }
>
> // rollback transaction
> try {
> connection.spyXAResourceManager.endTx( currentTransactionId,
>true );
> connection.spyXAResourceManager.rollback( currentTransactionId
>);
> } catch ( javax.transaction.xa.XAException e ) {
> throw new SpyJMSException( "Could not rollback", e );
> } finally {
> try {
>currentTransactionId =
>connection.spyXAResourceManager.startTx();
> } catch ( Exception ignore ) {
> }
> }
>
> }
>}
>
>
>public synchronized void recover()
> throws JMSException {
> if ( closed ) {
> throw new IllegalStateException( "The session is closed" );
> }
> if ( transacted ) {
> throw new IllegalStateException( "The session is transacted" );
> }
>
> rollback();
>
>}
>
>
>___
>
>Don't miss the 2002 Sprint PCS Application Developer's Conference
>August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
>___
>Jboss-development mailing list
>[EMAIL PROTECTED]
>https://lists.sourceforge.net/lists/listinfo/jboss-development
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
Log4j on the client side is the only way to trace/debug problems with client side code. In the case of JBossMQ, 1/2 of all the work is done on the client side! It's super important to keep the ability to trace client side code. Regards, Hiram >From: "Sacha Labourey" <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: <[EMAIL PROTECTED]> >CC: "Jason Dillon" <[EMAIL PROTECTED]> >Subject: RE: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on >client side >Date: Wed, 29 May 2002 12:26:20 +0200 > >Jason, > >Which is the part you don't understand? > >Cheers, > > > Sacha > > > Um... what? > > > > --jason > > >___ > >Don't miss the 2002 Sprint PCS Application Developer's Conference >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _ Chat with friends online, try MSN Messenger: http://messenger.msn.com ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] HEAD & JBossMQ failures
Mucked up jdbc PM. Fixed now. Regards, Hiram >From: Jason Dillon <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >Subject: [JBoss-dev] HEAD & JBossMQ failures >Date: Sun, 26 May 2002 16:32:51 -0700 > >I am seeing lots of these for various JBossMQ and other JMS related tests: > > >org.jboss.mq.SpyJMSException: Cannot acknowlege a message >... > >Any idea what is up with this? > >--jason > >- >This mail sent through IMP: http://horde.org/imp/ > >___ > >Don't miss the 2002 Sprint PCS Application Developer's Conference >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _ Chat with friends online, try MSN Messenger: http://messenger.msn.com ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CCEs make jbossmq.perf and jbossmq.test fail
This should be fixed now. Thanks for pointing it out. Regards, Hiram >From: Giorgio42 <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >Subject: [JBoss-dev] CCEs make jbossmq.perf and jbossmq.test fail >Date: Sat, 25 May 2002 18:25:32 -0500 > >I'm running the test suite for CVS head (200205252357) >on W2K / Sun JDK 1.4. > >The exceptions in the report say that a message could not >be removed due to not being able to delete the record in the database (0 >rows affected), but the log shows that >a CCE occured: > >2002-05-26 00:26:51,234 WARN [org.jboss.mq.il.oil.OILServerILService] >Client request resulted in a server exception: >org.jboss.mq.SpyJMSException: Could not delete the message from the >database: delete affected 0 rows > at >org.jboss.mq.pm.jdbc2.PersistenceManager.remove(PersistenceManager.java:801) > at org.jboss.mq.server.BasicQueue.acknowledge(BasicQueue.java:306) > at org.jboss.mq.server.JMSQueue.acknowledge(JMSQueue.java:97) > at org.jboss.mq.server.ClientConsumer.acknowledge(ClientConsumer.java:323) > at >org.jboss.mq.server.JMSDestinationManager.acknowledge(JMSDestinationManager.java:522) > at >org.jboss.mq.server.JMSDestinationManager.acknowledge(JMSDestinationManager.java:506) > at >org.jboss.mq.server.JMSServerInterceptorSupport.acknowledge(JMSServerInterceptorSupport.java:197) > at >org.jboss.mq.server.TracingInterceptor.acknowledge(TracingInterceptor.java:351) > at >org.jboss.mq.server.JMSServerInvoker.acknowledge(JMSServerInvoker.java:199) > at >org.jboss.mq.il.oil.OILServerILService$Client.run(OILServerILService.java:229) > at java.lang.Thread.run(Thread.java:536) >2002-05-26 00:26:51,234 ERROR [STDERR] >[b]java.lang.ClassCircularityError:[/b] sun/reflect/ConstructorAccessorImpl >2002-05-26 00:26:51,265 ERROR [STDERR] at >sun.misc.Unsafe.defineClass(Native Method) >2002-05-26 00:26:51,265 ERROR [STDERR] at >sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:45) >2002-05-26 00:26:51,265 ERROR [STDERR] at >sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:381) >2002-05-26 00:26:51,265 ERROR [STDERR] at >java.security.AccessController.doPrivileged(Native Method) >2002-05-26 00:26:51,468 ERROR [STDERR] at >sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:377) >2002-05-26 00:26:51,468 ERROR [STDERR] at >sun.reflect.MethodAccessorGenerator.generateConstructor(MethodAccessorGenerator.java:76) >2002-05-26 00:26:51,468 ERROR [STDERR] at >sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:30) >2002-05-26 00:26:51,468 ERROR [STDERR] at >sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >2002-05-26 00:26:51,500 ERROR [STDERR] at >java.lang.reflect.Constructor.newInstance(Constructor.java:274) >2002-05-26 00:26:51,500 ERROR [STDERR] at >java.lang.Class.newInstance0(Class.java:296) >2002-05-26 00:26:51,500 ERROR [STDERR] at >java.lang.Class.newInstance(Class.java:249) >2002-05-26 00:26:51,500 ERROR [STDERR] at >org.jboss.ejb.plugins.jaws.JAWSPersistenceManager.createBeanClassInstance(JAWSPersistenceManager.java:163) >2002-05-26 00:26:51,500 ERROR [STDERR] at >org.jboss.ejb.plugins.CMPPersistenceManager.createBeanClassInstance(CMPPersistenceManager.java:165) >2002-05-26 00:26:51,531 ERROR [STDERR] at >org.jboss.resource.connectionmanager.CachedConnectionInterceptor.createBeanClassInstance(CachedConnectionInterceptor.java:251) >2002-05-26 00:26:51,531 ERROR [STDERR] at >org.jboss.ejb.EntityContainer.createBeanClassInstance(EntityContainer.java:273) >2002-05-26 00:26:51,531 ERROR [STDERR] at >org.jboss.ejb.plugins.AbstractInstancePool.add(AbstractInstancePool.java:148) >2002-05-26 00:26:51,531 ERROR [STDERR] at >org.jboss.ejb.plugins.TimedInstancePoolFeeder.run(TimedInstancePoolFeeder.java:61) >2002-05-26 00:26:51,546 ERROR [STDERR] at >java.util.TimerThread.mainLoop(Timer.java:432) >2002-05-26 00:26:51,546 ERROR [STDERR] at >java.util.TimerThread.run(Timer.java:382) > >Is JBossMQ OK in CVS head (usable for production)? >Any similar problem known with 3.0 RC3? > >Thanks. >Georg > >* * * > >View thread online: >http://jboss.org/forums/thread.jsp?forum=66&thread=16555 > >___ > >Don't miss the 2002 Sprint PCS Application Developer's Conference >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
I think that would be safer. That will also allow the session to go back into the session pool thus you will share your resources better. Regards, Hiram >From: Jason Dillon <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED], "Scott M Stark" ><[EMAIL PROTECTED]> >Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA >Date: Fri, 24 May 2002 00:41:03 -0700 > >Or perhaps I am not using the JMS resource propertly within the bean... > >Should I be able to save a QueueSession and QueueSender as fields and use >them >over multipule calls inside of a SFSB? Or do I need to recreate the >session >and sender each time? > >If that is the case it rather sucks... what a pain... > >--jason > > >On Friday 24 May 2002 12:22 am, Jason Dillon wrote: > > After thinking about this somemore, and enabling thread info in >server.log > > I realize now that the timer is not an issue, there is never an instance > > where the timer thread attempts to use the wrapper over the SFSB... the > > work completes too fast. > > > > And due to the fact that I sync'd the wrapper methods it appears that >this > > problem happens simply because the invoke happened in a seperate thread. > > > > Unfortunatly it does not really narrow the problem space to debug. The >JMS > > RA does not function with out a TX, it does not attempt to start one if > > there isn't one already... so it just fails. > > > > Is it possible that there is something a miss with the bits which setup >the > > tx for the SFSB? Or would I see other problems when the SFSB commits... >I > > think this is the case, but I am not sure. > > > > If that is true, and the SFSB does have a TX, then it must be the JMS RA >or > > JBossMQ which is at fault... and I don't really know how to isolate >which > > it is at this point. If I don't use the JMS RA, then I have to >implement > > all of the XA stuff myself, which I am sure to mess up. > > > > Any clue on how I could narrow the problem space any? > > > > I am running the same test again with trace enabled for org.jboss.mq and > > org.jboss.resource.adapter.jms. With the added log messages for the JMS >RA > > I might be able to see a problem... but who knows. > > > > --jason > > > > On Thursday 23 May 2002 08:26 pm, Scott M Stark wrote: > > > If the only cause of this can be use by multiple threads, then >updating > > > the error message to indicate incorrect usage would be good. > > > > > > > > > Scott Stark > > > Chief Technology Officer > > > JBoss Group, LLC > > > > > > - Original Message - > > > From: "Jason Dillon" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]>; "Scott M Stark" > > > <[EMAIL PROTECTED]> > > > Sent: Thursday, May 23, 2002 8:18 PM > > > Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > > > > > > Does this mean we should not try to produce more meaningful error > > > messages when this does happen... or just leave it as is? > > > > > > --jason > > > > > > On Thursday 23 May 2002 08:00 pm, Scott M Stark wrote: > > > > I don't see sufficient justification to go beyond the spec here so > > > > let's just leave it. > > > > > > > > > > > > Scott Stark > > > > Chief Technology Officer > > > > JBoss Group, LLC > > > > > > > > - Original Message - > > > > From: "Hiram Chirino" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Thursday, May 23, 2002 7:45 PM > > > > Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > > > > > > He who codes wins the vote. This issue does not bother me enough >to > > > > > > > > change > > > > > > > > > anything. > > > > > > > > > > Regards, > > > > > Hiram > > > > > > > > > > >From: David Maplesden <[EMAIL PROTECTED]> > > > > > >Reply-To: [EMAIL PROTECTED] > > > > > >To: "'[EMAIL PROTECTED]'" > > > > > ><[EMAIL PROTECTED]> > > > > > >Subject: RE: [JBoss-dev] Seein
RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
He who codes wins the vote. This issue does not bother me enough to change anything. Regards, Hiram >From: David Maplesden <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: "'[EMAIL PROTECTED]'" ><[EMAIL PROTECTED]> >Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA >Date: Fri, 24 May 2002 14:35:21 +1200 > >I understand the pros and cons, I am just saying what I feel. You can >outvote me if you wish. > >David > > > -Original Message- > > From: Hiram Chirino [mailto:[EMAIL PROTECTED]] > > Sent: Friday, May 24, 2002 2:14 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > > > > > Think about it this way... somebody creates a simple servlet > > that creates a > > unit of work by sending 2 messages and then commits the work. > > Somebody that > > does not know the spec to will might cache that session in a instance > > variable. If 2 requests come in at the same time, they will > > screw each > > other up seriously. The first request might commit his 2 > > messages and some > > of the messages the 2nd thread was creating. > > > > So the question is, should we try to make the session > > thread-safe for the > > power users out there that MIGHT know how stuff is working > > under the covers. > > Or should we make the session check conncurent access better to let > > beginer user know when he has potentialy made a semantical error. > > > > Regards, > > Hiram > > > > >From: David Maplesden <[EMAIL PROTECTED]> > > >Reply-To: [EMAIL PROTECTED] > > >To: "'[EMAIL PROTECTED]'" > > ><[EMAIL PROTECTED]> > > >Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > >Date: Fri, 24 May 2002 13:36:43 +1200 > > > > > >I hate to disagree with Scott and Hiram but I feel that just > > because the > > >spec says Sessions should only be used in 1 thread does not > > neccessarily > > >mean that we should restrict their usage as such. > > > > > >I know a Session only makes sense in the context of a single > > process, but > > >this might still entail the usage of a couple of different > > threads. I > > >don't > > >think we should place any restrictions on the usage of > > Sessions as long as > > >they work, and I believe making sendMessage() synchronized > > will do the > > >trick. > > > > > >This can be just one more area where JBoss goes "Beyond the > > Spec" but hey I > > >leave the final decision up to someone else. > > > > > >David. > > > > > >--- > > >Outgoing mail is certified Virus Free. > > >Checked by AVG anti-virus system (http://www.grisoft.com). > > >Version: 6.0.362 / Virus Database: 199 - Release Date: 5/7/2002 > > > > > > > > >___ > > > > > >Don't miss the 2002 Sprint PCS Application Developer's Conference > > >August 25-28 in Las Vegas -- >http://devcon.sprintpcs.com/adp/index.cfm > > > >___ > >Jboss-development mailing list > >[EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > >_ >MSN Photos is the easiest way to share and print your photos: >http://photos.msn.com/support/worldwide.aspx > > >___ > >Don't miss the 2002 Sprint PCS Application Developer's Conference >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.362 / Virus Database: 199 - Release Date: 5/7/2002 > > >--- >Outgoing mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.362 / Virus Database: 199 - Release Date: 5/7/2002 > > >___ > >Don't miss the 2002 Sprint PCS Application Developer's Conference >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS related; not sure if this is a problem, but it is odd...
It's ok. The message was being displayed before the message was added. >From: Jason Dillon <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: "'[EMAIL PROTECTED]'" ><[EMAIL PROTECTED]> >Subject: [JBoss-dev] JMS related; not sure if this is a problem, but it is >odd... >Date: Thu, 23 May 2002 19:10:48 -0700 > >I enabled DEBUG for org.jboss.mq, and I see logs like: > >Andy, a message just got queued in >org.jboss.mq.server.PersistentQueue@c7e8a7, >queue size is: 0 > >I have not even looked at the code, but after you add something to a queue, >the size should be > 0 right? > >--jason > >___ > >Don't miss the 2002 Sprint PCS Application Developer's Conference >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _ Send and receive Hotmail on your mobile device: http://mobile.msn.com ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
Think about it this way... somebody creates a simple servlet that creates a unit of work by sending 2 messages and then commits the work. Somebody that does not know the spec to will might cache that session in a instance variable. If 2 requests come in at the same time, they will screw each other up seriously. The first request might commit his 2 messages and some of the messages the 2nd thread was creating. So the question is, should we try to make the session thread-safe for the power users out there that MIGHT know how stuff is working under the covers. Or should we make the session check conncurent access better to let beginer user know when he has potentialy made a semantical error. Regards, Hiram >From: David Maplesden <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: "'[EMAIL PROTECTED]'" ><[EMAIL PROTECTED]> >Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA >Date: Fri, 24 May 2002 13:36:43 +1200 > >I hate to disagree with Scott and Hiram but I feel that just because the >spec says Sessions should only be used in 1 thread does not neccessarily >mean that we should restrict their usage as such. > >I know a Session only makes sense in the context of a single process, but >this might still entail the usage of a couple of different threads. I >don't >think we should place any restrictions on the usage of Sessions as long as >they work, and I believe making sendMessage() synchronized will do the >trick. > >This can be just one more area where JBoss goes "Beyond the Spec" but hey I >leave the final decision up to someone else. > >David. > >--- >Outgoing mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.362 / Virus Database: 199 - Release Date: 5/7/2002 > > >___ > >Don't miss the 2002 Sprint PCS Application Developer's Conference >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
yes. no sharing. JMS session are used to demarcate transactions. Having 2 threads demarcating transactions would not be good. Regards, Hiram >From: David Maplesden <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: "'[EMAIL PROTECTED]'" ><[EMAIL PROTECTED]> >Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA >Date: Fri, 24 May 2002 13:14:04 +1200 > >And another thing, I can't 100% remember because its been a while since I >read it but I think the JMS spec says that Sessions should not be shared >by >multiple threads. Crazy in my opinion but there you go... > > > > -Original Message- > > From: Jason Dillon [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, May 23, 2002 8:31 AM > > To: [EMAIL PROTECTED]; David Maplesden; > > '[EMAIL PROTECTED]' > > Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > > > > Nothing like a cry for help to get me interested. > > > > =) > > > > > So you either need to patch SpySession sendMessage so that it is > > > synchronized or patch the client code (the code calling the > > JBossMQ stuff) > > > so that it doesn't have threads calling commit on the > > session at the same > > > time other threads are using the queueSender.send() method. > > I must admit > > > any client where the order of these two operations is > > indeterminate is in > > > dangerous territory as they won't know which transaction > > their message > > > sends are ending up in, which probably why the bug hasn't > > shown up before. > > > I guess the client code in this case is the JMS RA stuff > > (which I know > > > nothing about) so it might need investigating. > > > > So, this does indeed get interesting... my client code is > > calling a SFSB which > > has a JMS RA, which has the SpySession. > > > > I do have a timer thread sending back periodic stats with the > > same SFSB (my > > bad) which the main thread uses... but shouldn't the SFSB > > detect this and > > throw an exception about the concurent usage? > > > > Shit, my EJB has gotten rusty... only one thread should > > beable to use a SFSB > > at a time... or really one thread per bean in general > > right... I need to read > > the latest spec again. =( > > > > I can fix my client to sync, but I am wondering if there is > > something we can > > do to make the cause of this problem more obvious for others. > > > > So, for the spec experts out there, is there something that > > should be done wrt > > the SFSB in this case? > > > > And is there any reason why SpySession.sendMessage() should NOT be > > synchronized? > > > > Thanks David. > > > > --jason > > > > > > > David. > > > > > > > -Original Message- > > > > From: Jason Dillon [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, May 23, 2002 7:37 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > > > > > > > > > I spent the last week upgrading my service to JBoss3, > > which made the > > > > configuration much easier for me to managed (no more hacks in > > > > jboss.conf for > > > > extra classpaths and such), but I am still seeing an > > > > occasional "Invalid > > > > Invalid transaction id." when using the JMS RA and JBossMQ. > > > > > > > > I changed my model so that my client (invoked inside of a > > > > NotSupported MDB) > > > > uses a SFSB with a referece to java:/JmsXA RA, mostly to > > get around > > > > serialization issues, but whatever. > > > > > > > > A test sceneraio creates 1000 request messages, each of which > > > > will send back > > > > 1+n responses, where n could vary from 2-? depending on how > > > > long the request > > > > took to process. > > > > > > > > So lets assume that for each request that there are 3 > > > > responses, so there are > > > > 5000 messages, 1000 to a request queue and 4000 to a response > > > > queue. I am > > > > seeing an occasional problem sending responses back where > > > > several responses > > > > in a row will fail with this Invalid transaction id. > > > > > > > > Each request/response(s) cyle is exactly the same... so why > > > > could some have > > > > invalid tx id's and others have valid ones? > > > > > > > > Below is a trace from one of the exceptions, though I doubt > > > > it is of much use. > > > > Any idea what might be causing this? Is this likely to be a > > > > JMS RA problem > > > > or JBossMQ problem? > > > > > > > > Any insight would be helpful, I really need to track this > > > > problem down. > > > > > > > > --jason > > > > > > > > > > > > > > > > com.boldfish.does.worker.WorkerException: failed to send > > > > message; - nested > > > > throwable is: javax.jms.JMSException: Invalid transaction id. > > > > + nested throwable: > > > > javax.jms.JMSException: Invalid transaction id. > > > > at > > > > org.jboss.mq.SpyXAResourceManager.addMessage(SpyXAResourceMana > > > > ger.java:71) > > > > at > > org.jboss.mq.SpySession.sendMessage(SpySession.java:395) > > > > at > > > >
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
>From: Jason Dillon <[EMAIL PROTECTED]> >... >And is there any reason why SpySession.sendMessage() should NOT be >synchronized? > If anything SpySession.sendMessage() should try to detect the concurrent access from 2 threads and throw an exception stating that the JMS spec is being violated by the fact that 2 threads are trying to access a single session object simulatiously. Regards, Hiram _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XDoclet and C# style metadata
Unless the getClassMetaData() loaded up the config info from a resource xml file. The XDoclet stuff would just generate the getClassMetaData() method (that just loads the data from the xml file) and the .xml that holds the class metadata. If getClassMetaData() returned a really generic object like a xml dom, then you would never have to change getClassMetaData(). Regards, Hiram >From: Dain Sundstrom <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >Subject: Re: [JBoss-dev] XDoclet and C# style metadata >Date: Fri, 17 May 2002 14:12:53 -0500 > >Ok, I'm responding to my own email. Sometimes I get to excited. > >This is technique will only be useful in some circumstances because it >requires changing your source code to change a simple configuration. In >my case this is acceptable, because I'm talking about test cases. It >would also be useful for many EJB programmers, as they use XDoclet to >set TX attributes (although they can still change the dd, they are not >editing the source of truth). > >I still think it would be very useful, but it is not as ungodly powerful >as I first thought. > >-dain > >Dain Sundstrom wrote: > >>I was just thinking how cool it would be to generically associate xml >>with a method declaration. >> >>Back story: >> >>I am working on unit test cases for JBossCMP using JUnitEJB and it would >>be really useful to mark a test method with a tx attribute. Now this >>test code is not an EJB or an XMBean, so I don't have a descriptor file >>(this is not important; I just wanted to avoid the lame "make it an ejb >>emails"). >> >>Idea (I only know a little about XDoclet an less about C#) >> >>Mark up the code with XDoclet tags that contain generic xml. Then run >>XDoclet to preprocess the java file and generate a new java file with an >>additional method getClassMetaData. This class would work like the >>getClass stuff, but would add additional methods to return the extra >>metadata specified in the class. >> >>Use: >> >>In my case, the server side tester would get the metadata, check for a >>tx tag and would start a tx if required by the tag. We could use the >>same tricks with MBeans, JBoss Enterprise Beans (JEBs), and anything. >>This is something (I think) C# has and is unbelievably powerful. >> >>What do you think? >> >>-dain >> >> >>___ >> >>Hundreds of nodes, one monster rendering program. >>Now that's a super model! Visit http://clustering.foundries.sf.net/ >>___ >>Jboss-development mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/jboss-development > > > >___ > >Hundreds of nodes, one monster rendering program. >Now thats a super model! Visit http://clustering.foundries.sf.net/ >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ Hundreds of nodes, one monster rendering program. Now thats a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [jboss-group] Fw: [JBoss-user] Does JBoss3 have Problems Deploying Similarejb-jars in Different EARs
Yes I agree it should be configurable. Regards, Hiram >From: Dain Sundstrom <[EMAIL PROTECTED]> >To: Hiram Chirino <[EMAIL PROTECTED]> >Subject: Re: [jboss-group] Fw: [JBoss-user] Does JBoss3 have Problems >Deploying Similar ejb-jars in Different EARs >Date: Fri, 17 May 2002 00:40:00 -0500 > >Then you loose optimized calls between two deployments if they contain >copies of the same classes. > >We could offer an option like we do with wars, where it could (if the user >chooses) return to the default ejb behavior. > >-dain > >Hiram Chirino wrote: > >>Marc, >> >>I've got to side with scott here. Maybe I'm being academic but you seem >>to loose the class isolation benefits just to make it easier get >>classpaths right. >> >>How hard would it be to do something like: You create a UCL Repository >>for each Deployment Unit. Make every deployment unit have an identifier. >>When a deployment unit B depends on the classes of deployment unit A, he >>just specifies that he needs to import the classes of the deployment unit >>A. Then a cross UCL Repository association would be setup so that the >>Repository of B would use Repository A to load classes also. >> >>For bonus you might even allow configuring a UCL Repository to not allow >>some classes to be exported to other UCL Repositories.. >> >>So, what do you think, have I been smoking too long tonight?? >> >>Regards, >>HIram >> >>>From: "Scott M Stark" <[EMAIL PROTECTED]> >>>Reply-To: "Scott M Stark" <[EMAIL PROTECTED]> >>>To: "JBoss Group" <[EMAIL PROTECTED]> >>>Subject: Re: [jboss-group] Fw: [JBoss-user] Does JBoss3 have Problems >>>Deploying Similar ejb-jars in Different EARs >>>Date: Thu, 16 May 2002 19:11:29 -0700 >>> >>>That's absurd. So he also has to setup a port redirector to map from the >>>well know ports such as 1099, 80 onto the individual JBoss instances. >>>This >>>in general is not possible if each client does not have a unique virtual >>>host. >>>We need more flexibility in defining repository domains. >>> >>>- Original Message - >>>From: "marc fleury" <[EMAIL PROTECTED]> >>>To: "Scott M Stark" <[EMAIL PROTECTED]>; "JBoss Group" >>><[EMAIL PROTECTED]> >>>Sent: Thursday, May 16, 2002 6:56 PM >>>Subject: RE: [jboss-group] Fw: [JBoss-user] Does JBoss3 have Problems >>>Deploying Similar ejb-jars in Different EARs >>> >>> >>> > | >>> > |So what does an ISP with 100 independent client ears who may very >>>well >>>all >>> > |be >>> > |using the same package names do? Setup 100 instances of JBoss with >>> > |each running seperate ports... >>> > >>> > yup >>> > >>> > marcf >>> > >>> > >>> > ___ >>> > jboss-group mailing list >>> > [EMAIL PROTECTED] >>> > https://secure.jboss.org/mailman/listinfo/jboss-group >>> > >>> >>>___ >>>jboss-group mailing list >>>[EMAIL PROTECTED] >>>https://secure.jboss.org/mailman/listinfo/jboss-group >> >> >> >> >> >>_ >>Chat with friends online, try MSN Messenger: http://messenger.msn.com >> >>___ >>jboss-group mailing list >>[EMAIL PROTECTED] >>https://secure.jboss.org/mailman/listinfo/jboss-group _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] HEAD & ClassCircularityError
I also saw CCE on a Sun 1.3.1 JVM on WinXP. You can make it occur by enabling the jdbc2 PM in JBossMQ and take out the element that makes it wait for the DataSource to come up. It was werid. Regards, Hiram >From: Jason Dillon <[EMAIL PROTECTED]> >To: "Sacha Labourey" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, > <[EMAIL PROTECTED]> >CC: <[EMAIL PROTECTED]> >Subject: Re: [JBoss-dev] HEAD & ClassCircularityError >Date: Wed, 15 May 2002 20:29:12 + > >I have seen this mostly on SUN's 1.4 on Linux. I have not touched >blackdown >since 1.1.7. > >--jason > > >On Wednesday 15 May 2002 07:11 am, Sacha Labourey wrote: > > well, well, well... (what was the JVM BTW?) > > > > Houston, we have a problem. > > > > As I told Marc, maybe we have a problem with our classloader in > > multithreaded situations when two threads are trying to load the same >class > > at the same time and it is not yet cached. If both of these classes have > > the same mother class (or some equivalent scenario), then the JVM may > > complain about it. I have not yet found time to do test code for this. > > > > Jason, do you know if this occurs with the Blackdown JVM? If it does, we > > could then take a look at the code of the JVM (or ask the Blackdown guys > > for some hints) > > > > Cheers, > > > > > > Sacha > > > > > -Message d'origine- > > > De : Jason Dillon [mailto:[EMAIL PROTECTED]] > > > Envoyé : mercredi, 15 mai 2002 02:24 > > > À : Sacha Labourey; [EMAIL PROTECTED]; [EMAIL PROTECTED] > > > Cc : [EMAIL PROTECTED] > > > Objet : Re: [JBoss-dev] HEAD & ClassCircularityError > > > > > > > > > And now these, after I recompiled everything from scratch: > > > > > > > > > 2002-05-14 17:22:52,321 ERROR [org.jboss.ejb.plugins.LogInterceptor] > > > TransactionRolledbackException, causedBy: > > > java.lang.ClassCircularityError: sun/reflect/MethodAccessorImpl > > > at sun.misc.Unsafe.defineClass(Native Method) > > > at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:45) > > > at > > > sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator. > > > java:381) > > > at java.security.AccessController.doPrivileged(Native Method) > > > at > > > sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerat > > > or.java:377) > > > at > > > sun.reflect.MethodAccessorGenerator.generateMethod(MethodAccessorG > > > enerator.java:59) > > > at > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorIm > > > pl.java:28) > > > at > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc > > > cessorImpl.java:25) > > > at java.lang.reflect.Method.invoke(Method.java:324) > > > at > > > org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(M > > > essageDrivenContainer.java:394) > > > at > > > org.jboss.resource.connectionmanager.CachedConnectionInterceptor.i > > > nvoke(CachedConnectionInterceptor.java:147) > > > at > > > org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(Mess > > > ageDrivenInstanceInterceptor.java:88) > > > at > > > org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxI > > > nterceptor.java:87) > > > at > > > org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInter > > > ceptorCMT.java:165) > > > at > >___ > >Have big pipes? SourceForge.net is looking for download mirrors. We supply >the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX RMI Adapter & JNDI binding
>From: "Andreas Schaefer" <[EMAIL PROTECTED]> >To: "Hiram Chirino" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, ><[EMAIL PROTECTED]> >Subject: Re: [JBoss-dev] JMX RMI Adapter & JNDI binding >Date: Mon, 13 May 2002 08:26:36 -0700 > >Hi Hiram > > > I think that you can just default it to jmx:rmi and give allow the >location > > of the bind to be configurable. > > > > So when you have 2 jmx servers using the same JNDI service, then that > > problem is solved by having second jmx server can bind to something like > > server2/jmx:rmi > >But how to you know which JVM you need ? Let us assume that it would >be possible to run more than one JBoss instances on the same box. Now >you want to deploy on a particular server. How you know which JVM/Server >you have to talk to ? > >Andy > > If the 2 JBoss instances are using different JNDI servers then the you pick the server by setting up the InitialContext correctly. If the 2 JBoss instances are using the same JNDI server, then you pick the correct server by looking up the correct JNDI key "jmx:rmi" vs. "server2/jmx:rmi" Regards, Hiram _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX RMI Adapter & JNDI binding
I think that you can just default it to jmx:rmi and give allow the location of the bind to be configurable. So when you have 2 jmx servers using the same JNDI service, then that problem is solved by having second jmx server can bind to something like server2/jmx:rmi Regards, Hiram >From: "Andreas Schaefer" <[EMAIL PROTECTED]> >To: "Jason Dillon" <[EMAIL PROTECTED]>, ><[EMAIL PROTECTED]> >Subject: Re: [JBoss-dev] JMX RMI Adapter & JNDI binding >Date: Mon, 13 May 2002 07:33:57 -0700 > >Hi Jason > > > Can someone point me to the spec where it states where in JNDI the JMX >RMI > > adapter should be bound to. > >Because otherwise no client can find the JMX RMI-Adapter except for the >local >client. > > > Currently we are binding to "jmx::rmi" which is fine when you >are > > working with the localhost, but will start to cause problems once used >in >a > > multi-host environment. > > > > For example, consider a situation where a machine has more than one >resolvable > > name (via DNS CNAMES or similar). Lets say that the localhost name is >set >to > > "myhost.mydomain.com", and there us a CNAME "www.mydomain.com". The JMX >RMI > > adapter will be bound to "jmx:myhost.mydomain.com:rmi". > > > > Now consider the deployer. scripts run from a seperate machine. >There > > is a --server option, which is the bit from >"jmx::rmi". > > This is currently only used to lookup the RMIAdapter from JNDI but not >used to > > setup the Context.URL. This means that a client could not: > > > > ./deployer.sh --server www.mydomain.com --deploy someurl > >Aggreed that is a problem. The reason to do so is that I wanted a way to >bind >multiple JMX-RMI Adaptor on the JNDI server. >The REAL problem pops up when we have two JVMs with a JMX RMI Adaptor >running !!! > > > Assuming that deployer.sh did make up a Context.URL from --server (which >it does > > not) this would not work due to a lookup failure, as there will be no > > "jmx:www.mydomain.com:rmi" bound. > >The client is supposed to look up the right JNDI name but I created a >pattern he >can easier guess the right name. > > > The point is that we can not reliably use any resolvable address. > >As I said the bigger problem is with two JVMs. > > > So, I don't know what the spec says. If the spec wants us to use the >hostname > > fine, but lets also bind the local adapter to a common name, like > > "jmx:localhost:rmi" or perhaps "jmx::rmi" or whatever I don't really >care, >as > > long as the name is not specific to the local host configuration. > >The current spec. says nothing and the current JNDI name was my idea. We >could >add a second name called "jmx:localhost:rmi" which does not help when we >have >2 JVMs. Assuming that the JNDI server is running on another box this name >has >not meaning anymore. > >Have fun - Andy > > > >___ > >Have big pipes? SourceForge.net is looking for download mirrors. We supply >the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _ Chat with friends online, try MSN Messenger: http://messenger.msn.com ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Bug: Dynamic Topic not being destroyed in all cases
Please log a bug report at http://sf.net/projects/jboss >From: mary <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >Subject: [JBoss-dev] Bug: Dynamic Topic not being destroyed in all cases >Date: Mon, 6 May 2002 17:58:43 -0500 > >What I'm seeing appears to be a bug: > >I have a message listener listening on a dynamically created topic, a MDB >publishing to that same topic, and a session bean that comes along and >deletes the topic. When the session bean tries to delete the dynamically >created topic however, the topic is only removed from JNDI and NOT >destroyed. This exception is thrown when deleting the topic fails: >"Stopping failed: javax.jms.JMSException: The destination is being used." > >Further messages in the server log say the topics been destroyed, but >listing the topics from the jmx web viewer verifies it has not been. > >I found this because I was trying to recreate the topic. JNDI lookups >failed, but createTopic() gave an InstanceAlreadyExistsException. > >Do I need to log this bug somewhere, or is this post good enough? > >Thanks, >Mary > >* * * > >View thread online: >http://jboss.org/forums/thread.jsp?forum=66&thread=14975 > >___ > >Have big pipes? SourceForge.net is looking for download mirrors. We supply >the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] getContextClassLoader() vs. Class.forName(x,y,z)
yep.. I think that's the info I needed. Thanks!
>From: Dain Sundstrom <[EMAIL PROTECTED]>
>To: Hiram Chirino <[EMAIL PROTECTED]>
>CC: [EMAIL PROTECTED]
>Subject: Re: [JBoss-dev] getContextClassLoader() vs. Class.forName(x,y,z)
>Date: Thu, 02 May 2002 23:24:53 -0500
>
>In org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCQueryMetaDataFactory I have
>a method (convertToJavaClass) that does the name to array class conversion.
> Here is the core:
>
>int arraySize = 0;
>while(name.endsWith("[]")) {
>name = name.substring(0, name.length()-2);
>arraySize++;
>}
>
>try {
>// get the base class
>Class c = entity.getClassLoader().loadClass(name);
>
>// if we have an array get the array class
>if(arraySize > 0) {
> int[] dimensions = new int[arraySize];
> for(int i=0; i dimensions[i]=1;
> }
> c = Array.newInstance(c, dimensions).getClass();
>}
>
>return c;
>} catch(ClassNotFoundException e) {
> throw new DeploymentException("Parameter class not found: " + name);
>}
>
>It that what he wanted to do?
>
>-dain
>
>Hiram Chirino wrote:
>
>>Question for you classloading feaks out there, what is the difference
>>between:
>>
>>x = "some.class.name";
>>Thread.currentThread().getContextClassLoader().loadClass(x);
>>
>>and
>>
>>x = "some.class.name";
>>Class.forName(x, false,
>> Thread.currentThread().getContextClassLoader());
>>
>>Peter Levart, submitted a patch that replaces a statment like the first
>>with a statment like the seconds. It's supposed to allow "loading
>>array class for a base class that hasn't been loaded yet."
>>
>>My thing is, it seems like they do the same thing. What's the difference?
>>
>>Regards,
>>Hiram
>>
>>_
>>Chat with friends online, try MSN Messenger: http://messenger.msn.com
>>
>>
>>___
>>
>>Have big pipes? SourceForge.net is looking for download mirrors. We supply
>>the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
>>___
>>Jboss-development mailing list
>>[EMAIL PROTECTED]
>>https://lists.sourceforge.net/lists/listinfo/jboss-development
_
Chat with friends online, try MSN Messenger: http://messenger.msn.com
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBossMQ JMX Interface change
Hi guys, I just finished commiting some major refactoring of the JBossMQ server. It just involved formaizing the interceptor pattern that peter started with the security manager addition. I also refactored some of the JMX MBeans to thier own package. So this is your notice: THE JMX INTERFACE TO JBOSSMQ CHANGED. Ok, it didn't change that much but, it changed. I hope this does not break too many things. I'll be commiting these changes to Branch_3_0 soon. Regards, Hiram _ Chat with friends online, try MSN Messenger: http://messenger.msn.com ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] dynamically adding/removing queues/topics
That feature might have been broken in the 3.0 RC1, but I know for a FACT that it is working in the CVS head now. We now have some automated junit tests the create/destroy destinations via jmx on ever testcase. Regards, Hiram >From: Joel Boehland <[EMAIL PROTECTED]> >To: JBoss Dev <[EMAIL PROTECTED]> >Subject: [JBoss-dev] dynamically adding/removing queues/topics >Date: Fri, 03 May 2002 15:39:43 -0700 > >Hi, >Someone posted a message on the old >spydermq list that looks like it belongs >on this list. I am putting the original >message and my response below. If >someone finds something wrong with the >facts in my response please correct me. >Thanks, >Joel > >*** >***Mary wrote: >*** >Hi Joel, >I have rc1 of JBoss 3.0.0 and have been >testing your interface for >topic creation/deletion both >programmaticaly and from the JMX web >interface. > >What I'm seeing is that topics are >getting created successfully, and >I can delete them successfully. If I try >to create a topic again >after having destroyed it however, I get >this exception: > >javax.jms.JMSException: This destination >has allready been added to >the server! >at >org.jboss.mq.server.JMSServer.addDestination >(JMSServer.java:830) > at >org.jboss.mq.server.TopicManager.startService >(TopicManager.java:56) > at >org.jboss.system.ServiceMBeanSupport.start >(ServiceMBeanSupport.java:162) > 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 >org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke >(ReflectedMBeanDispatcher.java:284) >... > >If I do a JNDI lookup of the topic, it >doesn't exist, and the server >log file says it was successfully >destroyed, so I think this is a >bug. >I really need this feature so I will try >to see if I can find >anything debugging in to it. Please let >me know if you've encountered >this or fixed it. And thanks by the way >for contributing this feature >to JBoss for us all! > >Thanks, >Mary > > > >My reply: > >Hi Mary, >Its been a Long time since I added >the add/destroy queue/topic methods to >the JMSServer class in the jbossmq >module. I just checked out the most >recent version from cvs, and everything >I added is gone. This is a fast moving >code-base! I believe they moved all the >functionality of those methods into the >org.jboss.mq.server.DestinationManager >class. From what I can see, it *should* >be working. The stopService method is >what I believe gets invoked >automagically when you call >destroyTopic/destroyQueue on the >JMSServer MBean. This in turn invokes >closeDestination() on the JMSServer >class, and this method removes the >topic/queue from the internal >destinations HashMap. Unfortunately, it >looks like somehow that destination >isn't really being removed from the >HashMap. > >I don't have time to debug this right >now, but I did, these are probably the >steps I would follow: >1. Using debug logging or a debugger, >trace the chain of invokers involved in >a destroyTopic/queue call. From a quick >glance, I think it goes something like >(all classes in the org.jboss.mq.server >package): >JBossMQService.destroyDestination() >-->DestinationManager.stopService() >-->JMSServer.closeDestination() > >At the end of that chain, the >topic/queue should be gone from jndi, >and removed from the destinations >HashMap in JMSServer. Maybe the end of >the closeDestination() method in >JMSServer would be a good time to >iterate thru the hashmap and print out >the names of the destinations it >contains to be sure that is the case. If >you find this isn't the case, and you >can't find the cause, It would be a good >time to post a bug report from jboss's >sourceforge project page: >(http://sourceforge.net/projects/jboss/ ) > >I will post this message to jboss-dev >(which is where you should post/follow >bugs. Spydermq on yahoo groups is pretty >much a dead list) and someone there may >have more info on this. If I get time >this weekend or later next week I may be >able to delve a little deeper into this >as well. Good luck, >Joel > > >___ > >Have big pipes? SourceForge.net is looking for download mirrors. We supply >the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _ Chat with friends online, try MSN Messenger: http://messenger.msn.com ___ H
[JBoss-dev] getContextClassLoader() vs. Class.forName(x,y,z)
Question for you classloading feaks out there, what is the difference between: x = "some.class.name"; Thread.currentThread().getContextClassLoader().loadClass(x); and x = "some.class.name"; Class.forName(x, false, Thread.currentThread().getContextClassLoader()); Peter Levart, submitted a patch that replaces a statment like the first with a statment like the seconds. It's supposed to allow "loading array class for a base class that hasn't been loaded yet." My thing is, it seems like they do the same thing. What's the difference? Regards, Hiram _ Chat with friends online, try MSN Messenger: http://messenger.msn.com ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Running testsuite twice almost works now.(Branch_3_0)
I feel like ripping that code out of the JMSContainerInvoker! It ties the JMSContainerInvoker down tightly to JBossMQ and there are other providers out there that are complaining about that. If somebody wants the auto-create feature that badly, they can implement it more elegently at the org.jboss.jms.jndi.JMSProviderAdapter level. Does anybody oppose? Regards, Hiram >From: Adrian Brock <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >Subject: Re: [JBoss-dev] Running testsuite twice almost works >now.(Branch_3_0) >Date: Thu, 2 May 2002 12:06:20 -0500 > >Yes, > >It creates the Queue if it doesn't exist. >Look in org.jboss.ejb.plugins.jms.JMSContainerInvoker >at createDestination(...) > >Regards, >Adrian > > > I've lost track of where this destination is being > > created. Is it > > automatic from the jndi lookup? > > > > david jencks > > > > > > On 2002.05.01 15:00:52 -0400 Adrian Brock wrote: > > > Well done David. > > > > > > The JBossMQ problem is because it creates a > > Destination > > > MBean directly in the ServiceController without > > > specifying any dependencies. It gets destroyed > > > with the ServiceController, after the service it > > > requires has gone. > > > > > > Anybody know what the dependency should be? > > > jboss.mq:service=server? > > > > > > Regards, > > > Adrian > > > > > > > With the changes I checked in this morning last > > night > > > > I got only 3 errors > > > > running the testsuite 6 times for Branch_3_0 > > > > > > > > 2 of these are from jrmp CustomSockets tests, so > > I > > > > think they might have > > > > the same problem the security tests with custom > > > > sockets had. > > > > > > > > The remaining failure is jsr-77 notification > > > > delivery. I think this may be > > > > broken even on a first run. > > > > > > > > jdk 1.4, linux 2.4.16. > > > > > > > > I usually get some exceptions from jbossmq stuff > > when > > > > shutting down after > > > > running the testsuite. Anyone looking into this? > > > > > > > > david jencks > > > > > > > > > * * * > > > > > > View thread online: > > http://jboss.org/forums/thread.jsp?forum=66&thread=145 > > 6 > > > > > > > > __ > > > > > > > > Have big pipes? SourceForge.net is looking for > > download mirrors. We > > > supply > > > the hardware. You get the recognition. Email Us: > > > [EMAIL PROTECTED] > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-dev > > lopment > > > > > > > > > > __ > > > > > > Have big pipes? SourceForge.net is looking for > > download mirrors. We supply > > the hardware. You get the recognition. Email Us: > > [EMAIL PROTECTED] > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-dev > > lopment > > >* * * > >View thread online: >http://jboss.org/forums/thread.jsp?forum=66&thread=14576 > >___ > >Have big pipes? SourceForge.net is looking for download mirrors. We supply >the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss Most Active this Week
Check out http://sourceforge.net right now!! JBoss is at the top of the "Most Active this Week" Regards, HIram _ Send and receive Hotmail on your mobile device: http://mobile.msn.com ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBossMQ JavaCC Problem
To all JavaCC Gurus, The javacc grammar that JBossMQ is using has a problem. It can't detect that the selector: "definitely not a message selector!" is an invalid selector. It just parses the first itentifier, "definitely" and then skips over the rest of the selector. Is there an easy way for javacc to pick up that there are some excess tokens and spit out an error??? Regards, Hiram _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
