RE: [JBoss-dev] Suggested interface change for org.jboss.jms.server.MessageStore
Wow, people are actually looking at the code! I must admit that currently, the MessageStore is somewhat nebulous in my mind. The idea of course is to delegate all message storage to implementations of MessageStore allowing them to store messages as they see fit (in memory, database, file, etc.) not unlike the JBossMQ PersistanceManager. One difference, however, is that it is the MessageStore's job to expire messages as well--this may or may not be a good thing. Anyway, I appreciate your suggestion about Iterator vs. Collection. Frankly, I've seen people use them interchangeable and I've never developed a preference from one over the other. But your point is well taken. I choose to return a list because that is how I was storing the messages in the SimpleMessageStore. A MessageStore that stores messages in a db would be dealing with a different underlying data structure, so your point is well taken. I'll give this some more thought, but I think you are likely right--in fact in a small sort of way using List destroys the abstraction that MessageStore is trying to create... Thanks, Nathan JMS/JBoss Lead JBoss Group, L.L.C. -Original Message- From: Michael Barker [mailto:[EMAIL PROTECTED] Sent: Sunday, July 20, 2003 4:19 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Suggested interface change for org.jboss.jms.server.MessageStore Hi, I am currently looking at the MessageStore part of the new JMS implementation. I would like to propose the addition of the following method to MessageStore interface: Iterator getSavedMessagesIterator() The reason being that the MessageStore implementation may not want to store all of the MessageReferences in memory to improve scalability. Implementing an Iterator interface to handle this will be a lot simpler than implementing a List interface. This will also give the caller more control as to the resource usage by the system (e.g. the caller can load the messages into a list if it so desires). This should also be the preferred method for getting at all of the messages in the store, almost to the point where I would suggest deprecating or removing List getSavedMessages(). Regards, Mike. -- Michael Barker [EMAIL PROTECTED] --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
I prefer it be commit on a branch. Thanks, Nathan -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, July 11, 2003 4:32 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Jeremy Boynes Subject: 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 --- 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
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 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. 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 * 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 --- 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] JBossMQ rewrite
JBossMQthe current code basewill continue to ship with JBoss 3.2 which is, and will remain for some time, the production version. Therefore, making changes to the current code base IS NOT worthless. However, I am working on a brand new implementation with assistance from Adrian, Bela, Bill, Tom Elrod, and Troy Daley. The framework code has recently been checked in to the jboss-jms module in CVS. It is early, but a start. In addition to the traditional client-server oriented JMS we're working on, at Bela's suggestion, I was able to implement a pure p2p implementation of the JMS topic messaging domain that does non-durable subscribers over JavaGroups. At Bill's request, we're going to get this code out there quickly (July). To my knowledge this will be the first pure p2p (server-less) JMS implementation in open source and it will provide very fast in-firewall publish and subscribe over multicast. Thanks, Nathan Phelps JMS/JBoss (Reloaded) Project Lead JBoss Group, L.L.C. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, June 13, 2003 4:45 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] JBossMQ rewrite Can anyone give me some informations about the current state of the announced rewrite of JBossMQ for JBoss 4 ? Does it still make sense to implement needed features on the current JBossMQ implementation ? I don't want to spend time on something that gets nuked in short time :-) Regards Ulf --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] ServiceController Invalid transition from...
Title: ServiceController Invalid transition from... Are these messages new? What do they mean? They are all over the place in JB4 and I dont recall seeing them before. 2003-05-27 20:45:21,328 DEBUG [org.jboss.system.ServiceController] Creating service jboss:service=EJBTimerService 2003-05-27 20:45:21,328 INFO [org.jboss.system.ServiceController] returning from create for service jboss:service=EJBTimerService, invalid transition from CREATED 2003-05-27 20:45:21,859 DEBUG [org.jboss.system.ServiceController] starting service jboss:service=EJBTimerService 2003-05-27 20:45:21,859 INFO [org.jboss.system.ServiceController] Returning from start request for service: jboss:service=EJBTimerService, invalid transition from state RUNNING 2003-05-27 20:45:22,109 DEBUG [org.jboss.system.ServiceController] starting service jboss.admin:service=PluginManager 2003-05-27 20:45:22,109 INFO [org.jboss.system.ServiceController] Returning from start request for service: jboss.admin:service=PluginManager, invalid transition from state CONFIGURED 2003-05-27 20:45:22,109 DEBUG [org.jboss.system.ServiceController] starting service jboss.admin:service=PluginManager 2003-05-27 20:45:22,109 INFO [org.jboss.system.ServiceController] Returning from start request for service: jboss.admin:service=PluginManager, invalid transition from state CONFIGURED 2003-05-27 20:45:22,109 DEBUG [org.jboss.system.ServiceController] starting service jboss.admin:service=PluginManager 2003-05-27 20:45:22,109 INFO [org.jboss.system.ServiceController] Returning from start request for service: jboss.admin:service=PluginManager, invalid transition from state CONFIGURED 2003-05-27 20:45:23,640 DEBUG [org.jboss.system.ServiceController] starting service jboss.jca:service=BaseWorkManager 2003-05-27 20:45:23,640 INFO [org.jboss.system.ServiceController] Returning from start request for service: jboss.jca:service=BaseWorkManager, invalid transition from state CONFIGURED etc. 2003-05-27 20:45:48,750 DEBUG [org.jboss.system.ServiceController] Creating service jboss.j2ee:jndiName=ejb/jmx/ejb/Adaptor,service=EJB 2003-05-27 20:45:48,750 INFO [org.jboss.system.ServiceController] returning from create for service jboss.j2ee:jndiName=ejb/jmx/ejb/Adaptor,service=EJB, invalid transition from CREATED Thanks, Nathan
RE: [JBoss-dev] JBoss remoting callbacks [was JB4DR1 Deadline MAY 26]
I question if A JMSServerInvocationHandler is even necessary (along with the JMS Subsystem) if Bill exposes the callbacks via the AOP remoting framework. Frankly, I have the same thought about all the subsystems as I know EJB for instance will also being using the AOP framework and therefore the AOPServerInvocationHandler. I know you guys have a JMX subsystem which you have used to implement JMX remoting, but if you decide to refactor that to use the AOP framework that subsystem wouldn't be necessary either as far as I understand it. What I'm getting at is that it is my understanding that the future of J2EE flavored services on JBoss will be built on top of the AOP framework, and therefore AOP remoting is going to be the only InvocationHandler used because it is what gives us the modern interceptor stack. Bill, am I correct? Thanks, Nathan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Elrod Sent: Friday, April 04, 2003 1:05 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss remoting callbacks [was JB4DR1 Deadline MAY 26] Guess Jeff beat me to it ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tom Elrod Sent: Friday, April 04, 2003 1:49 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss remoting callbacks [was JB4DR1 Deadline MAY 26] Jeff made the fix last night and I have not looked at the code yet (he still has it local while we are testing that and some other fixes out). However, my understanding from Jeff is that the invoker client passes its locator to the invoker server if it wishes to receive callbacks. The invoker server will then use that for establishing the connection back to the client to send notifications (callbacks). Given this, it will be pretty easy to make it so the calling code can give the client invoker the locator to use for callbacks, which it then gives the invoker server (and will use its own by default as is now). I can put this in this weekend (if Jeff doesn't beat me to it). It sounds like there won't be enough time to include JMS as one of the invoker transport before the deadline. However, I would personally be interested in working with you on it. Depending on how soon you will have time to start on it, might be wise to make a branch just for the JMS transport, until JB4DR1. -Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Nathan Phelps Sent: Thursday, April 03, 2003 11:44 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 Did you guys end up doing it in such a way so that you can use one protocol one way and another protocol the other way like you had mentioned? Secondly, what is really going to be cool when we expose this via AOP remoting... Bill, what are your plans for that? Thanks, Nathan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Haynie Sent: Thursday, April 03, 2003 8:21 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 Jboss Remoting callbacks are in - I wil commit in the next day or so when tom and I finish testing. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Thursday, April 03, 2003 6:06 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 I'm ok with JMS. I didn't think you could rewrite in such short of time. Especially with Remoting and AOP just now becoming stable. I think this email thread is good because it will allow us to determine whether or not we can release. I still think there is enough functionality. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Nathan Phelps Sent: Thursday, April 03, 2003 5:48 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 I agree that there is some great stuff in there already. However, being that the AOP transaction, security, remoting, etc. was only recently released in its first iteration, and the fact that JBoss remoting doesn't yet support true callbacks (Jeff says it is coming) there is simply no way I can deliver the new JMS implementation BUILT ON TOP of these services by May 5th! And I'm going to be out basically two weeks between now and then with customers as I know others will be as well. Since the whole point of the JMS rewrite is to take advantage of the core JBoss AOP services, I haven't really had that much time to do so since the services have only recently been released. Therefore, I expect that a May 26th release will ONLY INCLUDE THE OLD JMS CODE which is currently in HEAD. It is the only option with a May 5th deadline in my opinion. If everyone
RE: [JBoss-dev] JB4DR1 Deadline MAY 26
I agree that there is some great stuff in there already. However, being that the AOP transaction, security, remoting, etc. was only recently released in its first iteration, and the fact that JBoss remoting doesn't yet support true callbacks (Jeff says it is coming) there is simply no way I can deliver the new JMS implementation BUILT ON TOP of these services by May 5th! And I'm going to be out basically two weeks between now and then with customers as I know others will be as well. Since the whole point of the JMS rewrite is to take advantage of the core JBoss AOP services, I haven't really had that much time to do so since the services have only recently been released. Therefore, I expect that a May 26th release will ONLY INCLUDE THE OLD JMS CODE which is currently in HEAD. It is the only option with a May 5th deadline in my opinion. If everyone is OK with this and we're committed to that date, then I am must immediately shift my attention from the development of the new code build on top of the AOP framework to the old code currently in HEAD to start working on ensuring JMS 1.1 compliance, stability, etc. as well as applying the HTTP IL code currently only in Branch_3_2 to HEAD. Then, after the May 26th release, I'll continue working on the new JMS code which is build on top of the AOP framework. Comments? Thanks, Nathan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Thursday, April 03, 2003 3:22 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 There's already a lot we can release. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dain Sundstrom Sent: Thursday, April 03, 2003 4:01 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JB4DR1 Deadline MAY 26 I think you are delusional if you think JB4 will be ready for JavaOne. -dain On Thursday, April 3, 2003, at 02:47 PM, marc fleury wrote: Guys, We are thinking a lot about the forthcoming JB4 release. It is a truly exciting step for us as we believe we will bring a programming style, whose time has come, to a mass audience. AOP as Bill says is a clear wave for system level services on par with OOP. On top of it and also as a proof of how powerful the approach is we still develop a full J2EE server. Meaning that you can choose to live in the J2EE world work on JBoss J2EE and access all the prepackaged AOP goodies as you have been doing since JBoss2.0. There seems to be a lot of fear at SUN from what I can tell in the press, that we will abandon J2EE. We love J2EE. When really we will support J2EE for the forthcoming future. Never do we talk about abandoning J2EE, we just let the user access core functionality in the open server and think at the AOP level. A more fundamental construct of the framework. The reason we are almost there is that it is also a very old implementation in JBoss. We have been doing it for a long time but never talked/packaged it this way. We make it easy for you to leverage the AOP layer. The implementation is old the way you interact with JBoss is new. It can also be old if you decide to stay at the J2EE level which will be fully supported. But you are now invited to roam in the core JBoss system, in fact you may find it very cozy as you port POJO based applications to JBoss. There will be a stabilization period though. We are making an aggressive push to release JB4 by JavaONE with all our resources dedicated to implementing the final AOP system aspects and porting some of the existing code to that. We're making an aggressive push to release JBoss 4.0 by JavaOne. We're targeting May 26th. That leaves us 2 month from now. I REPEAT TARGET FOR JBOSS4.0 DR1 MAY 26TH To meet this aggressive deadline, we need to set some dates. There will be a functionality freeze, Monday, May 5th. All new functionality commits after May 5th must be approved by either Scott Stark, or Bill Burke. We will not branch May 5th, but instead make the month of May, JBoss 4.0 stability en route to a Developpers Release 1 (DR1). Please think long and hard and fast about your modules. Many of you are involved in core modules that need to move fast in the coming weeks. Don't be afraid to talk and say who needs help etc. PLgC marcf xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- 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]
RE: [JBoss-dev] Oswego util.concurrent jar updated
Any chance they'll ever update the package name to get rid of the capital EDU... drives me crazy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Thursday, April 03, 2003 4:02 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Oswego util.concurrent jar updated I updated the Oswego util.concurrent jar in 3.0+ from the rather ancient 1.3.0 version to 1.3.2 as we found some serious concurrency failures in the ConcurrentHashMap and ConcurrentReaderHashMap classes in looking into some JMS load test failures. A bit ironic that the concurrent package was messing up concurrency. Scott Stark Chief Technology Officer JBoss Group, LLC --- 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 --- 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] JB4DR1 Deadline MAY 26
Did you guys end up doing it in such a way so that you can use one protocol one way and another protocol the other way like you had mentioned? Secondly, what is really going to be cool when we expose this via AOP remoting... Bill, what are your plans for that? Thanks, Nathan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Haynie Sent: Thursday, April 03, 2003 8:21 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 Jboss Remoting callbacks are in - I wil commit in the next day or so when tom and I finish testing. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Thursday, April 03, 2003 6:06 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 I'm ok with JMS. I didn't think you could rewrite in such short of time. Especially with Remoting and AOP just now becoming stable. I think this email thread is good because it will allow us to determine whether or not we can release. I still think there is enough functionality. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Nathan Phelps Sent: Thursday, April 03, 2003 5:48 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 I agree that there is some great stuff in there already. However, being that the AOP transaction, security, remoting, etc. was only recently released in its first iteration, and the fact that JBoss remoting doesn't yet support true callbacks (Jeff says it is coming) there is simply no way I can deliver the new JMS implementation BUILT ON TOP of these services by May 5th! And I'm going to be out basically two weeks between now and then with customers as I know others will be as well. Since the whole point of the JMS rewrite is to take advantage of the core JBoss AOP services, I haven't really had that much time to do so since the services have only recently been released. Therefore, I expect that a May 26th release will ONLY INCLUDE THE OLD JMS CODE which is currently in HEAD. It is the only option with a May 5th deadline in my opinion. If everyone is OK with this and we're committed to that date, then I am must immediately shift my attention from the development of the new code build on top of the AOP framework to the old code currently in HEAD to start working on ensuring JMS 1.1 compliance, stability, etc. as well as applying the HTTP IL code currently only in Branch_3_2 to HEAD. Then, after the May 26th release, I'll continue working on the new JMS code which is build on top of the AOP framework. Comments? Thanks, Nathan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Thursday, April 03, 2003 3:22 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 There's already a lot we can release. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dain Sundstrom Sent: Thursday, April 03, 2003 4:01 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JB4DR1 Deadline MAY 26 I think you are delusional if you think JB4 will be ready for JavaOne. -dain On Thursday, April 3, 2003, at 02:47 PM, marc fleury wrote: Guys, We are thinking a lot about the forthcoming JB4 release. It is a truly exciting step for us as we believe we will bring a programming style, whose time has come, to a mass audience. AOP as Bill says is a clear wave for system level services on par with OOP. On top of it and also as a proof of how powerful the approach is we still develop a full J2EE server. Meaning that you can choose to live in the J2EE world work on JBoss J2EE and access all the prepackaged AOP goodies as you have been doing since JBoss2.0. There seems to be a lot of fear at SUN from what I can tell in the press, that we will abandon J2EE. We love J2EE. When really we will support J2EE for the forthcoming future. Never do we talk about abandoning J2EE, we just let the user access core functionality in the open server and think at the AOP level. A more fundamental construct of the framework. The reason we are almost there is that it is also a very old implementation in JBoss. We have been doing it for a long time but never talked/packaged it this way. We make it easy for you to leverage the AOP layer. The implementation is old the way you interact with JBoss is new. It can also be old if you decide to stay at the J2EE level which will be fully supported. But you are now invited to roam in the core JBoss system, in fact you may find it very cozy as you port POJO based applications to JBoss. There will be a stabilization period though. We are making an aggressive push to release JB4 by JavaONE with all our
RE: Re[2]: [JBoss-dev] JBoss-3.2 build issues
I've never been able to find documentation for what the -z3 switch does. What is it for? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Tuesday, March 18, 2003 10:37 AM To: [EMAIL PROTECTED] Subject: Re: Re[2]: [JBoss-dev] JBoss-3.2 build issues You have to specify the branch as well. I don't know how you ever could have gotten this to compile either. Use cvs -z3 -d:ext:[EMAIL PROTECTED]:/cvsroot/jboss co -r Branch_3_2 jboss-3.2 Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Alex Loubyansky [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Sent: Tuesday, March 18, 2003 7:22 AM Subject: Re[2]: [JBoss-dev] JBoss-3.2 build issues Amazing... I wonder how it got mixed. I should have used cvs -z3 -d:ext:[EMAIL PROTECTED]:/cvsroot/jboss co jboss-3.2 Is it correct? Should I specify branch version in addition? I never did it and had no problems. Thank you, alex --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Branch_3_2 build failing... again.
Title: Branch_3_2 build failing... again. I just checked out a clean copy of Branch_3_2 and the build is failing with the following error: C:\Checkout\jboss-3.2\cluster\src\main\org\jboss\ejb\plugins\StatefulHASessionInstanceCache.java:58: cannot resolve symbol symbol : method unschedulePassivation (java.lang.Object) location: class org.jboss.ejb.plugins.StatefulHASessionInstanceCache unschedulePassivation(id); ^ C:\Checkout\jboss-3.2\cluster\src\main\org\jboss\ejb\plugins\StatefulHASessionInstanceCache.java:87: cannot resolve symbol symbol : method unschedulePassivation (java.lang.Object) location: class org.jboss.ejb.plugins.StatefulHASessionInstanceCache ctx = unschedulePassivation(id); What is up? Thanks, Nathan
RE: [JBoss-dev] Is JDK 1.4 required to build
Make that 4 cheers! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Elrod Sent: Thursday, March 06, 2003 11:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Is JDK 1.4 required to build 3 cheers for Scott! --- 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] Proposal for jboss-wide interceptor framework
I agree. As I begin the development of JMS/JBoss 4.0, I'm, frankly, confused as to which direction to go concerning the interceptor framework--which project is THE project? There is some great work being done right now by a variety of people on this problem, but I have no idea how it all fits together--if it fits together. I wish we could settle this problem, agree on which direction we are going, and then get the code base stabilized so those of us building services that will use THE framework can have the confidence that we're working with the right one and that it works as advertised. Thanks, Nathan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Sunday, March 02, 2003 1:37 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Proposal for jboss-wide interceptor framework Woa, before we have a full fledged interceptor war show up in main what is the status of the various JMX, AOP, etc interceptors and associated frameworks? It seems like several people are running around writing this without demonstrating how it applies to the existing services. A simple example is how do I expose the existing JNDI naming service via RMI/JRMP and RMI/HTTP with that ability to introduce security and persistence? Scott Stark Chief Technology Officer 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
RE: [JBoss-dev] Eclipse is so amazing...
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=162thread=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
RE: [JBoss-dev] Eclipse is so amazing...
Are you using the internal extssh client? I can certainly check out the source on the command line then connect the checked out source project by project. However, I was sort of hoping to be able to checkout a whole branch from within Eclipse AS a project. In other words, I was really hoping to do: 1.) Open the CVS Repository Explorer 2.) Right-click on a project Branch (having already set up the branch stuff) and choose Check out as Project 3.) Switch to the Java Project and start working. As it stands right now, this simply doesn't work (especially with Branch_3_2). Thanks, Nathan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Wednesday, February 26, 2003 2:26 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Eclipse is so amazing... Any reason not to set it up as multiple projects? I have had nothing but success when connecting Eclipse projects to a checked out jboss-head. --jason On Thursday, February 27, 2003, at 02:42 AM, Nathan Phelps 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=162thread=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 --- 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
[JBoss-dev] 3.2 branch build failing
I just check out a fresh copy of jboss-3.2 from CVS (CVS co -r Branch_3_2 jboss-3.2) and tried to build it. I keep getting this error which is causing the build to fail. C:\source\jboss-3.2\management\src\main\org\jboss\management\j2ee\factor y\RARModuleFactory.java:12: package org.jboss.resource does not exist import org.jboss.resource.RARMetaData; Anyone know what is up? Thanks, Nathan --- 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
[JBoss-dev] Base64 encoder in client libs?
I'm putting the finishing touches on the JBossMQ HTTPIL, and one of the requirements is supporting Basic auth. To support this, I'll need a Base64 encoder in the client libs. Do we currently have one we use already? If not, any suggestions? I hate to add a whole JAR just to support Base64 encoding... Thanks, Nathan --- 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
[JBoss-dev] HttpProxyServlet?
I'm currently working with a client who uses IIS/ServletExec due to legacy issues. IIS is bound to port 80 and 443 on the PC's one IP. The firewall is only open on port 80 and 443 for the machine's one IP. Some requests need to be serviced by IIS/ServletExec, while others need to be serviced by Web/JBoss (Jetty). Therefore, we need to set up IIS/ServletExec to act as a proxy to Web/JBoss running on the same machine on port 8080, taking requests on port 80 or 443, reissuing them Web/JBoss (Jetty) on port 8080 and returning the response to the client. I.E. HttpProxyServlet? I started writing one for my very specific use case, but figured it may be a more useful addition if it were more generalized and could handle *any* HTTP or HTTPS requests. Has anyone got something like this? Thanks, Nathan --- 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] AWT plug-in ClassNotFoundException
Anyone run into this problem before? There is a JAR file which is an AWT plug-in (i.e. used by the core system AWT classes), and AWT is throwing a ClassNotFoundException because it can't find the classes in this dependant JAR. We tried putting this JAR in every directory we can think of JRE/lib/ext, the server lib directory, the deploy directory, etc. with no luck. Has anyone dealt with this problem before? Thanks, Nathan --- 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] JNuke dev
I would think that we'd want to make this a J2EE application so it can run on ANY J2EE application server. Therefore, I would elect to go down a pure J2EE route instead of a JBoss only JMX route. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ben Sabrin Sent: Tuesday, January 14, 2003 1:04 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev Are we developing this for the PHP community or the Java community? Or more important for the JBoss community? To me it seems that it would depend on who you are targeting for your user base. If you want to target the PHP users to bring them to JBoss, then Bill could be right. If we do not care about the PHP community, we go down the JMX way. I think the PHP community will never want to do anything with JSP. They believe they have what they need to be successful and will continue to innovate in their own circle. For most of the PHP community, what they have built is scalable to their needs. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Bill Burke Sent: Tuesday, January 14, 2003 1:51 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev The only negative comment I have in using JMX is that the PHP community may have a tough time switching over to Nukes on JBoss if you have to have a package structure like a SAR or a WAR. I hate to say it, but does it need to be dumbed-down for the PHP community? This type of community needs to be able to edit a JSP and immediately see the change on the webserver. Is it possible to be all JSP based for themes, modules and blocks? You could use a URL fragement and JSP:Include to decide what theme to use. Just a thought. Maybe JMX and such is the way to go. Just want to give you something to think about. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of julien viet Sent: Tuesday, January 14, 2003 11:31 AM To: SourceForge.net Subject: [JBoss-dev] JNuke dev hi folks, JNuke adventure has started. After analysis of PostNuke I've began the development, still early though. I keep everything that's good in PostNuke and throw all the shit away : modules, blocks, permissions system, url system and themes. JMX is used for PostNuke components : themes, modules and blocks are all JMX mbeans. Here are my reasons : A : general 1.we need a component structure, why not JMX ? after all another forum say that's lightweight. 2.theses components do not have to scale, i.e the number of modules, blocks and themes is very small. B : for modules 1.Ability to deploy/undeploy when application is running. 2.It's easy to deploy additional modules as a separate deployment and have them register in the same registry. 3.PostNuke is all about invoking module functions. Url like index.php?module=Userop=register means that the PN must call the method register on module User. For me that means that the servlet retrieves the mbean under the name jnuke:publicmodules:name=User and invokes the operation register(). 4.When a module is installed and configured it plug block mbeans in the JMX. C : for blocks, same reasons as above except 3 and 4 as invocation is typed for 3. D : for themes, same reasons as above except 3 and 4 as invocation is typed for 3. EJB are used for the model : UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will be CMP 2.0 beans. We'll use local invocations and same trick as in forum to make them faster. Plus more beans. Each module is made of : 1.ModuleMBean : is the module itself, does not provide fucntionnalities, it's used to manager the PublicModule. Main operations are lifecycle (initialize, activate, unactivate, uninitialize) 2.PublicModuleMBean : is created when ModuleMBean activates and is responsible for serving requests. The MBean is dynamic and operations with no arguments and no returns are served. It's up to the module to do as he wants : if he wants MVC it can, it it wants to mix HTML and code, it can. First modules won't be MVC as they simply don't need. It's up to the model to have the persistence mecanisms it wants. First modules will use EJB. With lifecycle operations, each module can install itself, for instance : a ModuleMBean is plugged : 1.module configuration, setup of variables 2.initialize : module can creates table, deploy EJB, plugs block. 3.activate : module then go to block admin and creates instances of blocks (if module use blocks), display them on the page. Each block is made of : 1.BlockMBean : manages BlockInstanceMBean. 2.BlockInstanceMBean : is a block instance, it contains a title and a position on web page + 3 operations : display(), edit(),
RE: [JBoss-dev] sun's j2ee-cas-com-bridge
On the J2EE CAS Bridge forum there are several messages which state that Sun is providing the source of the bridge to J2EE licensees. The Sun version of the bridge will never be released as 1.0. Despite some lobbying on my part, they refuse to open source the bridge as well. Anyway, this looks like another case where JBoss will be discriminated against because it is open source and thus not a J2EE licensee. -Original Message- From: Alexey Yudichev [mailto:[EMAIL PROTECTED]] Sent: Monday, January 21, 2002 1:30 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] sun's j2ee-cas-com-bridge As you know, sun released Java 2 Platform, Enterprise Edition Client Access Services (J2EETM CAS) COM Bridge 1.0 Early Access (http://developer.java.sun.com/developer/earlyAccess/j2eecas/download-com-br idge.html). They only support 4 or 5 leading EJB servers. They provide EJB server connectivity with some kind of win32 connector. They wrote such connectors for 5 servers mentioned above. Can anybody write such a connector for jboss? It will extend jBoss usage area to Windows COM clients. For now we have only 3rd-party jintegra (http://www.intrinsyc.com/products/bridging/jintegra.asp) bridge which costs a lot. Best wishes, Alexei Yudichev mailto:[EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
