Re: [JBoss-dev] Fwd: ASF JIRA Installation is available
Alive and kicking! I've been lurking out here, but awfully busy with a client using WL$... Marc Fleury wrote: Danch is still alive, amazing, marcf --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fwd: ASF JIRA Installation is available
you _are_ joking, right? Andrew Oliver wrote: If we forego unnecessary features from the bug tracker such as: Fields (really just a nicety) Search/filter on fields (nice to have but who needs it) History (Nice to have but you only need to know that there is a bug) Change notification for bugs (not really needed) We can then just use the nukes forums for bugs and forego the bug tracker all together. -Andy From: Bill Burke [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Thu, 15 Jan 2004 15:52:25 -0500 To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Fwd: ASF JIRA Installation is available Actually, that's a great idea. We'll write a bug tracker for nukes for 6 months, but then decide to replace it with Jira because somebody wants Wiki style bug text. Bill Andrew Oliver wrote: Maybe someone can write a bug tracker module for nukes }:-) -Andy --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss Group forks again.
Congratulations, Bill! -danch Bill Burke wrote: October 26th. 12:36 AM. Proud dad and mom doing fine. http://www.jboss.org/bill/burke/baby.jpg Bill --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
I have never heard any of the main developers talk about JBoss4 _not_ being J2EE compatible. It has always been my understanding that the AOP framework would form the underpinnings of JBoss4's EJB implementation and be available as a more-flexible, lighter weight API for people who aren't concerned with portability. Scott, Bill, Marc - can one of you clarify? thanks, danch Rahul Ganjoo wrote: but one of the goals of JBoss 4 is to make it so developers don't have to deal with all the J2EE APIs from this and the discussion in general.. Jboss4 and J2EE compliance are two entirely different roadmaps (IMHU).. i mean its important for everyone here to know what direction Jboss is going to take.. is j2EE compliance important and is Jboss going for it..or is it keeping up the Jboss4 AOP vision and hence chucking compliance? --- 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/David Vs. Sun/Goliath?
Tom Coleman wrote: Don't be too sure that there isn't a number of months of effort to pass the conformance suite. There are lots of edge cases and areas of interpretation when implementing from a spec. Unless they give the compliance testing to Bill Burke. He could probably get it done in a weekend. Personally, certification is irrelevant to me. My criteria is whether or not the product gets the job done. I think certification serves to answer that question for people who don't know how to figure it out for themselves. I'm doing an integration with a partner that uses a certified server. Their server crashes. My server doesn't. So really people use certification instead of asking if the product gets the job done. Unfortunately there are a lot of people making infrastructure decisions who are either naive enough to do that or who are hamstrung by beancounters who are. Also, in a lot of cases, a certification like that can wind up as a checklist item, and a lack of a check in that column can just force technical people to have to waste a lot of time explaining the political situation, which makes executives nervous... -danch --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Transaction propagation change
Sacha Labourey wrote: + I guess this is the whole point: current JMS transactional behaviour is fine as long as what you want is *really* to decouple the producer from the consumer, but when what you want is just transactional multithreaded, then it is no more (and by far) a good solution because you end up using JMS+MDB for *nothing* Exactly! And what you want for multithread transactions is a cleaner API that lets you just say 'this method in this class should be run in a separate thread' and let the server manage the thread pool while you manage your application code. Get rid of the JMS hullabaloo for this purpose - it's designed for a different purpose. Also, don't make the application coders worry about creating a thread, just provide an aspecty-type thing so that I can plug it all together. -danch --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Transaction propagation change
If I understand you right, you're asking to propagate transactions via JMS messages because they're not propagated via non-local EJB calls. I think that begs the question, doesn't it? Meanwhile the conversation has gone on to (basically) asynchronous EJB (really AOP) calls. Barlow, Dustin wrote: Let me simplify the example to demonstrate my real point. (and hopefully this is a better example) In the 3.x series of JBoss, there isn't a way to have one SSB with a transaction attribute of Required call another SSB with a transaction attribute of Required on a second jboss instance and have both of those beans enlist in any kind of native JBoss transaction. If you stay within one instance of JBoss, you are fine, but the moment you start to really do n-tier designs with tight transaction integration (ie XA), tight integration implies high coupling, which implies that they ought to be co-located. If the two components are loosely coupled, then you should be able to design it in the old fashioned MOM style, where transaction propagation isn't needed. that is when problems arise with this NotSerializable exception. I do know that the 3.x series only supports local transaction, but my overall point is that I just don't understand why a distributed transaction has not been a native feature of JBoss from the beginning being that it seems to me that it would be fundamental to n-tier designs. I presume there is a good reason for this. I just don't know/see what that reason would be. Distributed TX is more expensive - the JBoss TM is intended (currently) to be light-weight and quick rather than XA complete. If you have persistent JMS queues, then I would probably agree that having a distributed global transaction involved when asychronous transports are involved may not be best practice. However, if a non-persistent JMS queue is used (and i don't know why anyone wouldn't use persistence), then I can see having a distributed transaction as very beneficial to the integrity of a single unit of work. Except that you're using a very heavyweight, MOM-style API when what you wanted was just correct transaction behavior. --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Transaction propagation change
marc fleury wrote: 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. Well I think the crux of the problem is that there is no propagation of context with the JMS message. No the crux of the problem is that JMS was designed to address the needs of providers of application integration infrastructure that's used for loosely coupled interfaces between systems. If you're loosely coupled enough to use JMS, you don't want the transaction propagated. There is indeed a (weak) notion of transacting of sending and receiving but essentially your transactional scope ends at the start of async messages. Why ? Well, really it also ends at the start of 'synchronous' messages as well, if you're foolish enough to do put synchronous semantics over the top of JMS/MOM. It's all because what we're talking about just doesn't make sense in a messaging integration type use case, where JMS/MOM makes sense. You're proposing something altogether different, more akin to a one-way from CORBA land. That's great, I love it, but referring back to how JMS does it is just confusing the issue. -danch --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Transaction propagation change
Barlow, Dustin wrote: That is what I contest. Why ? So what if it is persistent/async? theoretically speaking what is the limitation here? because if you care about the transaction, JMS is the wrong tool. There's no theoretical limitation, but if what you want to to execute an asynchrounous task in the same transaction, why would you go through all of the JMS crap that's designed for a 'fire and profess apathy' sort of exchange. You want a tightly coupled transaction: why would you use an API that assumes the loosest of all possible couplings? Answer: only because marcf hadn't written the one-way spec yet! ;^}) I think the argument is that because you have persistence you are guaranteed message delivery even if the node dies. So once a message is successfully posted to the queue, stack returns to the caller (ie async) the transaction with the queue is technically done where the caller is concerned. With persistence, if the instance craters out before the message is succesfully consumed, then you should still have the message persisted and it would be picked back up and redispatched when the instance is brought back up thus protecting the original intent of the original poster's transaction. Yes! If that's not the behavior you want, you shouldn't be using persistent messaging. The originating caller can then be notified later on (if needed) once the JMS based message is consumed and processed successfully by, for example, posting back to a JMS queue on the caller's instance. Basically a workflow style system. exactly. that's what MOM systems are for. -danch --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Transaction propagation change
Dustin, Please don't take offense here, but you seem to be heading in a couple of directions where, based on my experience, I think you'll hit some problems. Apologies in advance if I've misunderstood. Barlow, Dustin wrote: My answers/comments are inline: I am sorry I went on a tangent, it is just a pet peeve of mine for the longest time (and I still have to hear about OLE, who likes these discussions ;). No need to apologize at all. I think it's an interesting topic as well. Plus you're the boss so :) In the 3.x series of JBoss, there isn't a way to have one SSB with a transaction attribute of Required call another SSB with a transaction attribute of Required on a second jboss instance and have both of those beans enlist in any kind of native JBoss transaction. Colocate! colocate! colocate! if you have a REAL reason for not colocate let's hear it. That has to do with the lack of distributed TM. Period. I am arguing for co-locating, so i take it that your challenge for reasons *not* to co-locate is not directed at me. I think you're arguing against colocating here, unless I'm missunderstanding dramatically. Load balancing is one reason *for* co-locating. Lets say I want to run multiple instances of JBoss on separate iron(s) for performance reasons. One instance that simply does all the persistence for my application with synchronous session facades (or perhaps async MDB based dispatchers) in front of entity beans. two points: 1. separating things out this way is very likely to hurt your performance. If you want performance, you should have the whole stack in the same process. If you want scalability, load-balance the whole application vertically, not horizontally. Yeah that's not what leaps to mind when they (we, speaking as one of they) say 'N-Tier', but it's what works. 2. (async base MDB dispatchers) You're not proposing doing a request/reply to an MDB, are you? That's taking an asynch. transport (NOTHING TO DO WITH TRANSACTIONS HERE!) and simulating a synchronous call over it. That tends to perform badly, you'll have some complex code to manage it, and I've found it to generally be a bad idea. The more typical need for distributed TX involves one application (A) that needs to make a request to another application (B), where A needs to know the result of the request (making synchronous the prefered invocation style) and a roll-back in either A or B needs to roll-back the both thing. The only time it makes sense to use JMS/MOM is when the requestor (A in my meta-example) doesn't really care what happens, AND where a rollback in B won't matter to A. Note that if A rolls back, the message will never be delivered. This is basically a case of A wanting to say Oh, if anybody cares, this happened. Extreme decoupling. The error handling on B's side tends to get a little hairy in these cases: it may need to intelligently recover from some errors, others can be retried at a later point, and for some errors it will wind up deffering to certain wet, grey, bio-electrical analog computers for resolution. Oh, the other time MOM makes sense is when one or more applications need to be integrated and they're entirely ignorant not only of one another, but of distributed transactions, Java, and the modern world in general. But hey, it keeps me busy! snip! Another scenario is a MDB deployed in one instance that is using a custom remote DestinationManager pointing to a JMS queue on a second JBoss instance (which currently doesn't work in 3.x .. but i'll leave that for another thread). How is the transaction handled in that scenario? The transaction is between the queue and the MDB - the ack for the message should be sent to the queue iff the MDB's transaction commits. The transaction started for the MDB's processing of the message is the only transaction in this scenario. What's the question, other than 'this doesn't work in 3.x.' It should. -danch --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ThreadPooling in JMX? Its broken
The Object pooling question was definately settled on the side of it's not worth it, but things like threads and sockets _are_ different in that the underlying OS has its own limits and imposes them on us. Starting a new thread for each operation and waiting for garbage collection will result in an event that will look an awful lot like a process table attack to most sysadmins. 'course my sensitivity here is related to my experience on Linux and Windows, where threads are either limited or expensive to create. -danch marc fleury wrote: hmmm I thought we had cleared the questions of pools of anything long time ago, meaning that modern VMs take care of that. Also bill, you and I have been badly burnt in the past by state management in reused components. My question would then be 'why would threads be different'?. The usual reason is that people say you want to limit how many threads a process creates, but that can be achieved by just monitoring the number of new threads created by the pool and listening for notifications on thread garbage collection calls. That says that you have pools who just limit the number of threads out there and block for other but associate a new thread for new invocations. marcf --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ThreadPooling in JMX? Its broken
I think his point was that all of the threads in the pool being used will become polluted with whatever crap this framework put into its thread local. At least that's what annoys me when frameworks use threadlocal stuff (IIRC, ObjectStore did this to me at one point) -danch Scott M Stark wrote: This is such nonsense I can't believe it. A framework has used ThreadLocals for whatever reason. It knows nothing about the context in which it is being used. So just because it happens to be used in the context of an RMI invocation, every thread, including the non-RMI threads that have touched the ThreadLocal should be cleared? Implement your ThreadPoolLocal construct and quit whinning. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 16, 2003 11:17 AM Subject: RE: [JBoss-dev] ThreadPooling in JMX? Its broken Each thread holds an implicit reference to its copy of a thread-local variable as long as the thread is alive and the ThreadLocal instance is accessible; after a thread goes away, all of its copies of thread-local instances are subject to garbage collection (unless other references to these copies exist). As a developer you assume the thread will die after run is complete. Or in the case of an RMI invocation, when the invocation returns. The JDK developers were too shortsighted to see that people might implement thread-pools. Otherwise there would be a way to Clear the thread locals associated with a thread. --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ThreadPooling in JMX? Its broken
It's not especially computation intensive, but it is resource intensive: it consumes a process table entry. Each user is allowed only a certain number of process table entries, and the overall system has an upper limit. Also, more threads will load the OS scheduler more. If they're idle it isn't as bad as if they're active, but it will/may consume time depending on the scheduling algorythm. Even if a 'pool' imposes an upper limit and blocks until GC happens, well, yeah that'd work, but the finalizer call is a non-deterministic event. Non-deterministic software can be entertaining, but it's not something I want to base an enterprise infrastructure on. -danch Rhett Aultman wrote: According to what I've read from various sources (http://www.kerneltrap.org, assorted Ingo Molnar interviews, etc), the cost of thread creation on Linux is comparable to that of process creation. I am not a big Linux C developer at the moment, but I was under the impression that process creation on Linux wasn't very expensive. --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ThreadPooling in JMX? Its broken
danch wrote: Sacha Labourey wrote: The Object pooling question was definately settled on the side of it's not worth it, but things like threads and sockets _are_ different in that the underlying OS has its own limits and imposes them on us. maybe for sockets, but not for threads: a JVM could have (and JRockit does) an abstraction layer between OS-threads and JVM-threads and do its own scheduling. Yeah, a JVM could have, and one does. That's hardly enough to let us assume that it's pervasive. I mean, a JVM could also (try to) multiplex sockets under the covers, reusing one 'physical' socket for all communications between our process and any IP:Port pair. If, say, the Kaffe VM had that feature, would you say that we don't have to worry about system limits on sockets? --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ThreadPooling in JMX? Its broken
Sacha Labourey wrote: The Object pooling question was definately settled on the side of it's not worth it, but things like threads and sockets _are_ different in that the underlying OS has its own limits and imposes them on us. maybe for sockets, but not for threads: a JVM could have (and JRockit does) an abstraction layer between OS-threads and JVM-threads and do its own scheduling. Yeah, a JVM could have, and one does. That's hardly enough to let us assume that it's pervasive. Sure, but your e-mail did look like you were saying that it is a limit imposed by the OS on Java, while it is not. Sure it is. JRocket just has an abstraction that loosens the limit up considerable, but the limit is still there. JRocket is basically doing your pooling for you - yeah, it's a different mechanism than pooling but the effect is the same: you can program as if you can get a thread anytime you want, even though you might have to wait anyway. To entirely get around the limit, the JVM has to completely take over the OS's scheduling role for the java application, which was what green threads did. I'd rather trust Linus, Ingo, and their hoard of contributors and testers to write a good general scheduling algorythm than anybody writing a proprietary VM. -danch --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ThreadPooling in JMX? Its broken
Sorry I'm getting argumentative here - I've been hammering code and my social graces shut down. danch wrote: Sacha Labourey wrote: The Object pooling question was definately settled on the side of it's not worth it, but things like threads and sockets _are_ different in that the underlying OS has its own limits and imposes them on us. maybe for sockets, but not for threads: a JVM could have (and JRockit does) an abstraction layer between OS-threads and JVM-threads and do its own scheduling. Yeah, a JVM could have, and one does. That's hardly enough to let us assume that it's pervasive. Sure, but your e-mail did look like you were saying that it is a limit imposed by the OS on Java, while it is not. Sure it is. JRocket just has an abstraction that loosens the limit up considerable, but the limit is still there. JRocket is basically doing your pooling for you - yeah, it's a different mechanism than pooling but the effect is the same: you can program as if you can get a thread anytime you want, even though you might have to wait anyway. To entirely get around the limit, the JVM has to completely take over the OS's scheduling role for the java application, which was what green threads did. I'd rather trust Linus, Ingo, and their hoard of contributors and testers to write a good general scheduling algorythm than anybody writing a proprietary VM. -danch --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ThreadPooling in JMX? Its broken
Adam Heath wrote: On Thu, 16 Jan 2003, danch wrote: It's not especially computation intensive, but it is resource intensive: it consumes a process table entry. Each user is allowed only a certain number of process table entries, and the overall system has an upper limit. This latter point is no longer true, in 2.4. Sure, you can change the parameter. However, at some point you will run out of some resource on the system. OK, maybe not from a practical point of view on the latest uber-box, but this conversation strayed from 'practical' into theoretical long ago...sorry about that. Also, more threads will load the OS scheduler more. If they're idle it isn't as bad as if they're active, but it will/may consume time depending on the scheduling algorythm. More runnable threads. Sleeping threads come for free. --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
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
Re: [JBoss-dev] Transaction propagation change
I think you're talking about giving people something more like asynchronous method invocations (one-way) than traditional MOM style messages, right? My MOM exists to keep me and my brothers from fighting: she takes notes one to the other, maybe 'forgets' the particularly nasty ones, makes sure there's a cooling off period, etc. The purpose of MOM is to decouple - propagating transactions with the message is a bad idea because you're using a hammer to turn a screw. An asynch. invocation on the other hand, ought to take the transaction with it, but I think you want a different programming model than the JMS overhead crap (look up three object in JNDI, call three factories, sacrifies three virgin goats...) I wouldn't care if it were implemented on the same infrastructure as JBossMQ, but I'd really want a more light-weight programming model - like an asynchronous Aspect for the target object, or something... -danch marc fleury wrote: 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 DONT 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! /water-walking 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
Re: [JBoss-dev] PHP problems
Matt Munz wrote: Marc, If you're writing tissue-paper code (write once, never modify, throw away when broken), script kiddie languages are great. If not, be prepared to eat it in the long run on man hours / maintennance. And remember that eating used tissue-paper is never a good thing. --- 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 II
When lawyers and law are involved, compromize is often impossible. If you are working on a competing product at your day job and JBoss by night, you risk infecting your employer's codebase with LGPL code, and the JBoss code by proprietary code. I'm not saying you'd intentionally do that, but it would be legally difficult to defend even incidental similarities in the code base. There probably are similarities, since both products attempt to implement the same spec. Sorry to see you go, Andy, but this is one where pragmatics point to listening to the lawers. -danch Andy wrote: Hi Oohh, the power of legal issues, you can justify nearly everything. Instead of looking for a mutual compromise to resolve this issue Marc (and others) sought a more terminal solution. Andy - Original Message - From: marc fleury [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: 'JBoss Group' [EMAIL PROTECTED] Sent: Monday, December 23, 2002 7:49 AM Subject: jRE: [JBoss-dev] Good-bye II Andy is working on a competing implementation to jboss. His own lawyers at his company have requested he not work on JBoss, he was doing so anyway under an alias. We only found out about the competing aspect a couple of days ago. To protect ourselves legally, we removed Andy's RW, we will in fact remove the code contributions. We cannot have a competitor's code in our base as it exposes us legally. It is only the second time this has happened in our history. The mail below is an expression of Andy's personal gripes and bitterness. Period. marcf --- 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 and UML?
David Jencks wrote: Personally I have found uml diagrams sometimes useful in organizing my own thinking but have never been able to communicate any useful ideas using them. As I discuss below, I find UML (or whatever modeling language you want to use) useful primarily in providing macro, analysis views of system architecture and high-level design, and in providing templates for low-level design (A.K.A. coding). For this to be useful, it must be based on a common vocabulary that is derived from the user's vocabulary. For this to be persistent, you need additional prose documentation and/or village elders who can be relied on to educate the nubies. soapbox perspective=pragmatic style=danch-rant It's absolutely ridiculous to do sequence diagrams that get anywhere near the fine grained detail of code. development models where some 'design' team grinds through and produces mountains of that nonsense that then must be ignored by herds of coders who are the lucky many who actually find out what works don't scale well, to say the least. deap-breath / /soapbox 8^}) Indeed! In fact, we can consider UML diagrams as a complement to javadoc. When a development is done, javadoc should be synchronized with it, UML diagrams should be synchronized the same way. Well, according to the dogma, you change the UML first. My personal best practice is to keep the UML at a high enough level that most code changes don't invalidate UML, and those changes that do invalidate the model tend to require using the model as a thinking tool first. Frankly, my attitude to javadoc is much the same: it should be a brief description of what is being accomplished, not a detailed description of how. And you should write it _while_ you code, not after, because 'after its done' is a time no software gets to until it's irrelavant. If you write the code for a human to read (which is the point of high-level languages), you'll need minimal commenting. UML is most useful when it is used to describe coarse-grained structures - analysis models, typical mappings from analysis to design model (both with class diagrams), and typical flows (via sequence diagrams). This makes synchronization less of an issue - if you make a change that effects things at that level, you probably _need_ to model it. Changes in implementation details fall into the 'noise' category. I think that the main thing that causes open source software to tend not to have much in the way of design documentation is that the best open source systems are built by people who have a pretty good talent for keeping a model in their heads, and for building that wetware model by reading source. When you can see it working in your head, wacking out a model isn't real stimulating compared to getting it to work in the product. soapbox Never forget that the code _is_ a design artifact, and that coding _is_ a design activity. Don't let the fact that the fabrication process is truncated in software fool you into thinking that (good) coding is an assembly line activity. Of course, that assumes that you have software engineers, not merely well trained howler monkeys. Don't do J2EE with howler monkeys. /soapbox I suggest xmi using argo/poseidon. Yes, xmi is a standard for UML diagrams. But they only are useful to those who can use them with the right tool. I think an image format could be used too for those who don't have such tool. again, argo is completely free and poseidon has a free version. They are both pretty lightweight. --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX on the client side?
Matt Munz wrote: Is this a good idea? Should we look at it for 4.0? Great idea, Dain. Once you get that far, building client container functionality should be pretty simple... It makes sense to me. The closer a client environment models the server, the better, IMO. Of course, the client should be as complex as necessary and no more, etc. Things are getting more distributed all the time... could I end up with 2 kernels in the same VM? Just a thought.. Are we still talking about client-server? I thought that by definition, the client is in a separate VM, if not a separate physical machine... I think James had more esoteric plans... -danch --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] janitorial work
So, Ben...are you hinting that your less than satisfied with the build system? That's odd, _nobody_ _ever_ complains about the build system! ;^}) yours in sympathy, danch Ben Tompkins wrote: To whom it may concern, Here is a script that ***points vaguely*** in the direction of the janitorial task that Jason outlined immediately prior to his evident leave of absence. All it does is gather (by copying - not moving) the collection of somewhat divergently named and distributed README and LICENSE files (or any set of files under a common directory you care to specify via a regular expression) into a single location for ease of review and comparison. If this isn't a complete joke, I'd appreciate some feedback, because it does seem to me to be a somewhat asinine idea - i.e. renaming, moving, and possibly ALTERING the content of README and, in particular, LICENSE. Who gives a flying ^*@ about these files anyway? Certainly not the customer. I mean, come on, no one who is too stupid to find/apprehend such files unless they are placed in a standardized location and somehow formalized is ever going to so much as **begin** to get off the ground running JBoss. The whole idea of touching these files in the first place is one that I find highly suspect, especially in light of the plethora of bugs and unresolved issues that remain outstanding, not the least of which is the glaring inadequacy of the BUILD SYSTEM, regarding which obtaining the secret combination of key ***strokes*** that is apparently required to get the *@)#! THING to build would appear to be the open source corporation's equivalent of acquiring the key to the proverbial executive lavatory, a phenomenon for which, I venture to add, the technical term repository in the present case strikes me as a decidedly lame euphemism, aside from the fact that it just happens to rhyme with suppository. --- 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] Oracle, table locks and CMP2 incompatibility
Catalin Teodorescu wrote: Check this link. http://asktom.oracle.com/pls/ask/f?p=4950:8:1513219::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:292016138754,%7Bprimary%7D%20and%20%7Bkey%7D%20and%20%7Bupdate%7D%20and%20%7Btable%7D%20and%20%7Block%7D Dan -Original Message- From: Michael Bartmann [mailto:michael.bartmann;lisytec.de] Sent: Monday, October 28, 2002 12:21 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Oracle, table locks and CMP2 incompatibility Hallo db gurus, we have for some time experienced nasty timeouts on oracle without jboss deadlock detection (or oracle deadlock detection) kicking in. We might have found the solution today, allthough this is not verified, perhaps only time will show. (...or some db guru will tell me that my following explanation is severly misguided.) The EJB locking is based on entity locks. If you have an underlying database which does locking too, it has to use row level locking, (as opposed to table level locking) or else jboss detect deadlocks on the database, as the check which detects deadlocks is based on a graph representing locks on entity (row) level. But there are circumstances, under which oracle does not use row level locking even if with row level locking configured to always. This happens when a table TableA has a dependent table TableB in a 1:n relationship (i.e. TableB has a foreign key pointing to TableA.) If a row of TableA gets updated, oracle tries to lock all entries in TableB with matching foreign key. Here comes the vital point: If there is no index on the foreign key columns of TableB, oracle does a shared lock on _table_ level. This is probably because otherwise oracle would need to do a full table scan on the fly to find the matching rows in TableB. So if you configure jboss to generate the foreign key constraints you are walking on thin ice; you have to generate indices on the foreign key columns by hand, or else this effect might hount you. Solution: 1) [workaround] disable foreign key (or their generation), and let CMP2 itself take care of the constraints or 2) implement generation of foreign key indices in jboss. (I'm not fully convinced that this would suffice; jboss deadlock detection would have to lock the same entities and avoid race conditions). Even ignoring the table-lock escalation issue, this is what should happen. In fact, I'm a little surprised that Oracle doesn't just create the indices: I believe PostgreSQL does. Does this sound reasonable to you? Regards, Michael Bartmann --- 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] Truth of statements in assertTrue clauses
Seeing a message like 42 is not equal to 48 (and should have been) would help? Jason Dillon wrote: Don't the other Assert.* methods like Assert.assertEquals(a,b) format the message at all? I would expect this to show a message like a was not equal to b (and should have been). --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Monday, July 29, 2002 3:41 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Truth of statements in assertTrue clauses I've been using the explanation of failure style, I hadn't really considered the other. I would like to switch. I've found writing the explanation of failure messages exceedingly confusing. david jencks On 2002.07.29 12:07:59 -0400 Scott M Stark wrote: In the assertTrue(String message, boolean condition) form of the junit assertion some people are using a message that reflects the expected truth of the condition while others are using a message that reflects why the AssertionFailedError is thrown. We need to be consistent on this usage. I happen to prefer that when I look at the coded statement: assertTrue(true is true, true); the message is consistent with the condition. What is the general expectation? Scott Stark Chief Technology Officer JBoss Group, LLC --- 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 --- 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] Patch #532376 / Bug #478882
Ah, there should definately be an option to turn that bloody feature off. THe important part of the preparedstatement happens on the server anyway. Oracle does its own caching of the query plans (or whatever) involved for your PreparedStatement, as does any other database where a prepared statement gives you any actual advantage. The only thing this actually pools are the java objects involved, and with modern garbage collectors that doesn't buy much. -danch Jeffrey Wescott wrote: In the newly-released JBoss 2.4.5, a patch was applied (#532376) to fix bug #478882. The patch changes the behavior of the prepared statement pool (which, I believe, is used by anyone using the XA wrapper DataSourceClass) such that when close() is called on the prepared statement, it propogates that close() call to the underlying implementation object. This patch, unfortunately, has broken things for people using JBoss / Castor / Oracle. Below is my message to the castor-dev mailing list on the topic. -8 cut here Here's the idea: In 2.4.4: 1- Castor obtains a PREPARED STATEMENT from the JBoss PREPARED STATEMENT pool. 2- Castor does work. 3- Castor calls STMT.close() to close the prepared statement. 4- JBoss returns the PREPARED STATEMENT to pool. In 2.4.5: 1- Castor obtains a PREPARED STATEMENT from the JBoss PREPARED STATEMENT pool. 2- Castor does work. 3- Castor calls STMT.close() to close the prepared statement. 4- JBoss returns the PREPARED STATEMENT to pool and closes it. I investigated this further and commenting out the lines in the close() method of the PreparedStatementInPool class make it work as it did in 2.4.4. if( impl != null ) impl.close(); It looks like this patch (#532376) was committed to fix bug #478882, but it seems to have caused another problem. For what it's worth, I'm using Oracle 8.x with classes12.zip. Any idea whether or not it does its own prepared statement pooling? Also, how do I turn OFF the pooling in JBoss to try to get this stuff to work WITHOUT changing code? -8 cut here My questions are: 1- Was there any testing done before this patch was applied? Though this fixes something for people using MSSQL, it breaks something for people using Oracle. 2- Conceptually, is it the correct thing to do? Previously, the prepared statement pool just returned the object to the pool upon a call to close(). Now it actually closes the underlying prepared statement. What good is pooling a closed prepared statement? 3- As an Oracle user, is there some other way to get stuff working without using the XA wrapper DataSourceClass? I've tried lots of combinations or the OracleXADataSource class and Oracle Xid stuff, but none with any success. Others in the JBoss forums seem to share my woes in this regard. ++jeff P.S. -- At this point, it is not an option for me to use another technology besides Castor / Oracle. ___ 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 ___ 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] JBoss Test Results from execution over HP-UX
Will it be possible to set up a CVS get + build + tests on HPUX, as Chris has done for Linux? thanks for your efforts, danch Duarte Loreto wrote: Hello! After a lot of help from Chris Kimpton (many thanks), I've setup and run the tests over JBoss Branch_3_0 on a HP-UX U 9000/800 with the B11.00 OS version and using JDK 1.3.1.02. JBoss code was from a CVS checkout from (+/-) 2002/05/13 01h00a.m. GMT. I'll try to run this tests more or less daily (during week-days) and then send the results to you. I hope this helps you finetune JBoss for this OS. Any aditional testing that you may want, please e-mail me. I'll let you know if I can or cannot do it and, if I can, when I can deliver it. It is planned a test run also for the HEAD branch, maybe starting tomorrow. Have fun! Duarte HappyGuy Loreto Don't worry, be happy! Number of tests run: 585 Successful tests: 568 Errors:16 Failures: 1 [time of test: 13 May 2002 13:11 GMT] [java.version: 1.3.1.02] [java.vendor: Hewlett-Packard Co.] [java.vm.version: 1.3.1 1.3.1.02-JPSE_1.3.1.02_20011206 PA2.0] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: HP-UX] [os.arch: PA_RISC] [os.version: B.11.00] See http://planeta.clix.pt/happyguy/jboss/ for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! _ 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 ___ 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] Automated JBoss Testsuite Results: 10-May-2002
This report says 142 errors, but the HTML report it links to says 11. What gives? The dates don't match, but is that because this email is GMT and the HTML is server time? -danch [EMAIL PROTECTED] wrote: Number of tests run: 757 Successful tests: 604 Errors:142 Failures: 11 [time of test: 10 May 2002 2:43 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1_02a-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/blackdown_jdk131_02_native for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ 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 ___ 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] testsuite in HEAD does not build
Didn't get that error there, but I did get an compile problem in the newbank stuff related to the fact that 1.4 defines a throwable 'cause' property in Exception and newbank has an exception class with an Exception cause properly. I've fixed that and will check in as soon as I confirm that it will compile under 1.3 (i don't see why it wouldn't, but...) I did just do a clean checkout because the 'most' target would build for me and I felt like it was Just Time to Do That. maybe you have an old xdoclet or an version mismatch between ant and xdoclet? -danch Francisco Reverbel wrote: Is anybody else getting this? I am using jdk1.4 on linux. Francisco - ... [xdoclet] Running deploymentDescriptor/ [xdoclet] Running jboss/ [execmodules] Running xdoclet.XDocletMain loaded by sun.misc.Launcher$AppClassLoader. Forked:true [xdoclet] Exception in thread main java.lang.NoClassDefFoundError: xdoclet/XDocletMain [execmodules] /home/reverbel/jboss-all/testsuite/build.xml:599: Java returned: 1[execmodules] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:90) [execmodules] at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:175) [execmodules] at xdoclet.DocletTask.execute(DocletTask.java:298) [execmodules] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:104) [execmodules] at org.apache.tools.ant.Task.perform(Task.java:217) ___ 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] marathon tests and banknew
I'm trying to run the marathon tests against the head. This is failing with CMP errors indicating query not found for various finders. The XDoclet tags for newbank (well Customer at any rate) have jboss-finder declarations but no ejb:finder declarations (for CMP 2) I've added one of these only to run into another. Did someone forget to check this change in or should I go ahead and fix it up, or have I gone into the weeds? thanks, danch ___ 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] marathon tests and banknew
I just finished that up. Once I figured it out, it took all of 5 minutes. For the record, it took added a 'schema' attribute to the ejb:bean tag, then adding the ejb-ql to a 'query' attribute of the ejb:finder tag. -danch Andreas Schaefer wrote: Hi Danch No, you are note into the weeds. As mentioned in the CVS message the banknew application is not working mostly because JBoss 3 uses an XDoclet version which is not officially released and therefore I don't have a docu. Can you tell me how to write the ejb:finder and I will adjust the classes and make them run ? Thanx - Andy - Original Message - From: danch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 05, 2002 1:17 PM Subject: [JBoss-dev] marathon tests and banknew I'm trying to run the marathon tests against the head. This is failing with CMP errors indicating query not found for various finders. The XDoclet tags for newbank (well Customer at any rate) have jboss-finder declarations but no ejb:finder declarations (for CMP 2) I've added one of these only to run into another. Did someone forget to check this change in or should I go ahead and fix it up, or have I gone into the weeds? thanks, danch ___ 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 ___ 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 ___ 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] [JL] Is it time for a new enterprise solution?
Andreas Schaefer wrote: Hi George The view on the configuration should be task-oriented, not file-oriented. Do you have an example for that ? I know BEA WL 5 and IBM WebSphere 3.5 and both did not provide configuration on their UI. Both now provide configuration UIs. It's so easy to understand why a GUI is necessary. And why XML is necessary. When I was working on BEA WebLogic (yes, I was) they had a usable UI but I still configured the server through the file. Mostly because the heavy configuration stuff is not added to the UI. WL 5 had a UI whereby you could change things, but did not persist the changes, IIRC. A UI makes sense to discover all the services and deployments and get statistics out of it which JSR-77 should do so. But I am convinced that configuring a server is advanced stuff and should not be made too easy otherwise it will break all the time. An application server is not a volatile system with respect to configuration. Which is a very good reason to have the configuration secured, but not necessarily a good reason to not have a GUI. Do we still provide the (unsecured) JMX web interface as default, as we did in 2.4.x? I don't necessarily see myself as being a big user of a GUI, but I do understand why people really want one - it will cut down the learning curve, and we are getting to the point where some of the people using JBoss are people who program computers for a living, not necessarily because they like it! Also, in a large organization, the people charged with management of servers are not generally programmers persay - they'll knock together a perl script, but a sysadmin who knows Java is rare. A normal sysadmin will look at the xml in JBoss configuration files and suddenly have a fond rememberance of the last time he had to 'correct' a make file for some daemon on one of his boxes. And that's on the Unix side of things - think about NT administrators! Have fun - Andy Always! danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
marc fleury wrote: Sacha, this is configuration for JBoss4.0. The fact is that for *production* the one file is good. For actually administering and configuring a server the many files is better, yes, but they are different world, the notion of locking down a server is VERY REAL. Sure. I do that by setting permissions of the config and deploy directories such that only the JBoss user can do anything (including read). What good does having one big honking file do here? I agree that it does no harm, but I don't see how it 'locks down' the server. In the admin/configuration category, the persistence of the configuration above and beyond the current xml is not done right now the fact that it is mixed with the creation is a weakness we are carrying over from the 2.0 days. Right, to really fix that will have to be a 4.0 issue. Once that works, JBoss will be administrable from whatever can use JMX - JSR 88 based tools, SNMP management tools, etc. my .02$ danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [JBoss-user] Oracle claims to be our partner
They bought Orion a while back. David Ward wrote: On a related note - I downloaded their OC4J app server (just being curious, not really straying from JBoss) in mid-March and it appears to be Orion underneath. All the xml config files are orion-this and orion-that. -- marc fleury wrote: http://www.oracle.com/corporate/press/index.html?1279885.html and we didn't even know about it! how about that... these people are incredible, I need someone like that JBoss partners with AOL and BellSouth to deliver the infrastructure of tomorrow and say it with a straight face. The world is coming to an end. marcf x Marc Fleury, Ph.D President and CEO JBoss Group, LLC x ___ 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
Re: [JBoss-dev] RE: [JBoss-user] JBOSS 3.x FINAL
We're talking about the volunteer maintained doco. Look at the site, http://www.jboss.org/online-manual/HTML/index.html The title is JBoss 3.0 documentation. The disclaimer says that it was developed early in the project and is out of date, but the date on it is Jan 15, 2002. danch marc fleury wrote: danch, get wit the program, the 10 bucks doco is 2.4 only and the book as well marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dan |Christopherson |Sent: Thursday, March 14, 2002 2:16 PM |To: David Ward |Cc: Mac Rinehart; Jboss-Development@Lists. Sourceforge. Net; |Jboss-User@Lists. Sourceforge. Net |Subject: Re: [JBoss-dev] RE: [JBoss-user] JBOSS 3.x FINAL | | |Very true - the online doc right now says it's for 3.0, but hasn't been |completely updated yet. Meanwhile it isn't right for 2.4.x anymore |either. Core team members have said that 2.4.x is going to be around for |a long time, I think it would behoove us to keep the documentation |available, at least as a download. I _believe_ it is branched (or at |least tagged) for the 2.4 branch (can't verify, sourceforge is down so I |can't browse, behind a firewall, so I can't check through CVS client), |so it shouldn't be difficult. | |-danch | |David Ward wrote: | It doesn't always lag - sometimes it's too eager! Example: I had a | gripe that 2.4 documentation started disappering off the web site, being | replaced with 3.0 documentation when 3.0 was only alpha. I think that | the 2.4 docs should stay available online - at least until 3.x |goes final. | | Mac Rinehart wrote: | | The free user documentation is only moderately useful, and | lags behind development on a number of issues. | | | | ___ | JBoss-user mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-user | | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] buglet in 2.4 JAWS. Should I fix?
OK, after one of my younger cohorts tried to create an instance of a
CMP entity whose fields were all private (at least he understands
encapsulation!) leading to a mysterious NPE, I ran across the
following code in CMPFieldMetaData:
catch (NoSuchFieldException e)
{
// we can have a private attribute, then we will use fieldName
// to find the get/set methods, but still have to set jdbcType/SQLType
// but can not yet do it sowe have to set field to null so that
// getJDBCType will not use the parent Field to find the types
field = null;
return null;
}
I've got two problems with this:
1. This violates the spec. No huge deal, in my book, but...
2. The following code in CMPFieldMetaData:
if (!isNested())
{
return getField().get(instance);
}
Blows Chow all over the place.
I'm calling this a buglet because it only sucks when you have a
non-compliant bean. But then the fact that every bloody log write
in JAWS has been made 'debug' even where they are obviously error
conditions and very few of the exceptions propogate sufficient
information (which is tough to do anyway from 'catch (Exception)')
makes it really suck when you hit it. There are a lot of error
conditions in JAWS that really suck when you hit them with DEBUG
logging off.
But. Should I fix this (and other issues) and if I fix this should I
port up to the 3.0 code? Is JAWS still used at all in 3.0, or is it
entirely replaced by Dain's CMP?
My fix for this would probably be to simply make it enforce the spec
and report a sensible DeploymentException telling the bean developer
what's wrong, but that does seem out of character for JAWS (telling
the developer what went wrong). OK, just so nobody has to remind me,
I did have a bit to do with the 2.4 JAWS, but if you can't look at
your own work from 9 months ago and bitch about it, what _can_ you
bitch about?
Opinions?
thanks all,
danch
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] 'downloads' statistic on sourceforge is broken
Sourceforge claims 0 downloads for several days now. I don't think that's quite right. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCInitCommand.java
The former. It thoughtfully switched every line end to windoze style for me. Sorry about that. danch Dain Sundstrom wrote: How is it you managed to change every line of these files? Is something wrong in your IDE, or was the file hosed to begin with (and you fixed it)? -dain Dan Christopherson wrote: User: danch Date: 02/02/25 09:18:20 Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_4 JDBCInitCommand.java Log: made 'table not created' message error rather than debug Revision ChangesPath No revision No revision 1.12.6.6 +182 -172 jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCInitCommand.java ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Deployer Message
There's a big difference in granularity between the code in the component being deployed and the component itself: do you suggest that I have a static initializer in all of my beans that logs 'hey, i've been loaded'?. Even picking an arbitrary component (from those that _do_ get their class loaded) is an ugly, ugly hack. An 'INFO' message that an application has been deployed is far better. Better yet might be a JMX notification from the deployer. At any rate, the cost of notifying on deployment is so low that there really isn't a reason for it to not be INFO (IMNSHO). danch Jason Dillon wrote: I probably changed it from info to debug, in that this information is only useful when debugging a deployer problem. Other info level messages should be provided by the component that has been deployed. --jason Hunter Hillegas wrote: Maybe this should be marked as INFO, not DEBUG: 12:11:58,396 DEBUG [MainDeployer] Done deploying someear.ear Seems like useful information that the server is done deploying the ear... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Build problem with contrib/jetty in Branch_2_4
I ran into a couple of build issues with the 2.4 branch of the jetty plugin. I had to change the build.bat/build.sh scripts to set the properties that build.xml was expecting (jboss.dist, etc.) rather than what the scripts were doing (jboss.home, etc.). If noone squawks before ~2:00 PM (GMT-6) I'll check that in. There was also an incompatibility in the build script with the version of ant that was being used. The jetty plugin in 2.4 seams to borrow ant from the tomcat plugin, and used a FixCRLF attribute that wasn't available in that version of ant. I changed this to use the older style and it worked, but I'm leary of checking that one in. Comments? danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build problem with contrib/jetty in Branch_2_4
OK, that's done. I updated the .bat and .sh, but not the xml. On a related note, how should changes in plugins or contrib modules be tagged? I just back-ported a 3.0 fix to the 2.4 branch and tagged the jetty module and the main jboss module (2.4 branch) is that sufficient, and should I also Rel tag for the script changes? thanks, danch Scott M Stark wrote: I don't use the build scripts in 2.4 to do builds. I only use Ant 1.4 and the build.xml files. If you want to update the build scripts make them compatible with this and do not change the build.xml files to work with an earlier version of Ant. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: danch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 22, 2002 8:04 AM Subject: [JBoss-dev] Build problem with contrib/jetty in Branch_2_4 I ran into a couple of build issues with the 2.4 branch of the jetty plugin. I had to change the build.bat/build.sh scripts to set the properties that build.xml was expecting (jboss.dist, etc.) rather than what the scripts were doing (jboss.home, etc.). If noone squawks before ~2:00 PM (GMT-6) I'll check that in. There was also an incompatibility in the build script with the version of ant that was being used. The jetty plugin in 2.4 seams to borrow ant from the tomcat plugin, and used a FixCRLF attribute that wasn't available in that version of ant. I changed this to use the older style and it worked, but I'm leary of checking that one in. Comments? danch ___ 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
Re: [JBoss-dev] BCEL org.jboss.proxy.compiler
I believe the one thing that the java.lang.reflect.Proxy won't do that
JBoss needs is to generate implementations of abstract classes (rather
than interfaces) this is important in a few places (EJB 2.0 CMP for one)
danch
Neale Swinnerton wrote:
I've just submitted patch 517088 to completely remove the jboss proxy compiler
and replace it with use of java.lang.reflect.Proxy.
The BCEL looks pretty good for all sorts of stuff, but the JDK Proxy class
does everything that the JBoss one does.
An 'interesting' use of the BCEL would be to post process the .class files
before deployment for production and completely remove the
if (log.isDebugEnabled()) {
...
}
code from the .class file.
I can't get too excited after the miniscule performance increase you'd get
from this (I've followed the log4j discussions on this in the past on this
list and others). but as an intellectual exercise it might be quite
interesting to do...
On Mon, Feb 11, 2002 at 08:35:44PM -0800, Jason Dillon wrote:
Any thoughts on replacing our proxy compiler with the Byte Code
Engineering Library, recently added to the list of Jakarta
sub-projects?
--jason
___
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
Re: [JBoss-dev] Oracle has bought JBoss on google
JBoss has already weathered a Slashdotting or two with no problems (according to Marc, not close to pegging CPU). Craig Johannsen wrote: Submitting a story to Slashdot is just as good as writing a script to waste Oracle's add money. People complain that when their site is mentioned on Slashdot, they get overwhelmed by huge numbers of hits on their site. Hit being webspeak for someone viewing a page at a site, not an assassination or anything violent like that. _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=7942 ___ 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
Re: [JBoss-dev] JBoss internal problem!!!
the java.lang.char issue is a JVM bug: if you have 'char' parameter the serialization stuff pukes. danch Colin Thorburn wrote: I'm using (JBoass 2.4.1 + Tomcat) reflection to have ejbCreate call an initialisation class. This class calls ejb public members having single arguments - byte, Byte, int, Integer, Character, char etc. ejbCreate complete OK, but if I have used a char argumnet to any of these funtions Method.invoke throws an InvocationTargetException - presumably refering to the proxy, since by this time my code gas completed fine (even if I do use char-s) I get a NoClassDefFoundError for - wait for it - java/lang/Char. I'm not trying to use anything of this type in my code (Which as we all know is a non existant Class anyway; Hmmm), which leaves one culprit. Here's the stack trace: Please let me know if this is genuine bug, My Apologies if it's not! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Am I a clown?
See, that's the problem with smart people; they think way too hard!
Dave Smith wrote:
Putting on his big shoes ...
HashMap is not syncnronized, possible another thread is modifing the
HashMap?
or
You are modifing the set inside the loop?
marc fleury wrote:
So I just spent 2 hours spotting the following interesting bug
HashMap deployments ...
Iterator it = deployments.keySet().iterator();
while (it.hasNext());
{
do something();
}
which would peg my CPU at 100% and never reach do something ...
man I am a clown... can you see it? 2 hours!
marcf
__
View this jboss-dev thread in the online forums:
http://jboss.org/forums/thread.jsp?forum=66thread=6868
___
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
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] use of if(debug) log.debug
The reason you might want to do that is if it costs significant processing time to build the message that's being logged (like string concatenation, or an expensive method call) -danch marc fleury wrote: ??? I have a conflict on ServiceDeployer.java the conflict is due to the inclusion of if (debug) log.debug(...) with debug being log.isDebugEnabled()... do we need to explicitely do that? I thought part of the interest is that the log4j thing would not do anything with the messages if debug was not enabled so why the explicit test? I will remove these unless something clearly says the contrary marcf Marc Fleury President JBoss Group, LLC ___ 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
Re: [JBoss-dev] use of if(debug) log.debug
Andrew Scherpbier wrote: The object reference and method call are still performed even if nothing gets logged. By using a simple test, that overhead is removed if it is not needed. This is actually a big deal. It is even better if the test can be done on a constant, because then the compiler can decide if the code needs to be included or not and there is no overhead if the constant is false. Using compile time constants to turn diagnostics on and off is something of a hot point for me - it can make it very difficult to diagnose problems in typical production environments in the companies I work with (rebuilding the app. server to get diagnostics is a no-happen) from the log4j FAQ: ... evaluating a category takes less than 1% of the time it takes to actually log a statement. There are a _few_ places in the JBoss code where I'd worry about this overhead, but not too many. Actually, in the deployer, I wouldn't bother with the test at all. marc fleury wrote: ??? I have a conflict on ServiceDeployer.java the conflict is due to the inclusion of if (debug) log.debug(...) with debug being log.isDebugEnabled()... do we need to explicitely do that? I thought part of the interest is that the log4j thing would not do anything with the messages if debug was not enabled so why the explicit test? I will remove these unless something clearly says the contrary marcf Marc Fleury President JBoss Group, LLC ___ 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Anyone mind if I rename build.bat to Build.bat?
I _think_ he's changing the case of the windows batch file only, so you should be OK. Is the shell script marked executable now? I've gotten into the habit of chmoding it after every major (CVS) update. -danch Dain Sundstrom wrote: My fingers are in the habit of typing ./build.sh so, this would really bug me. -dain -Original Message- From: Adrian Brock [mailto:[EMAIL PROTECTED]] Sent: Monday, December 10, 2001 12:22 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Anyone mind if I rename build.bat to Build.bat? David, Sounds ok to me. I use cygwin on windows. This is case-sensitive. I'll just change to ./B[tab] At the moment I have to mv build.sh xbuild.sh Regards, Adrian From: David Budworth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [JBoss-dev] Anyone mind if I rename build.bat to Build.bat? Date: Mon, 10 Dec 2001 10:05:56 -0800 Does anyone mind if I rename build.bat to Build.bat? Windows boxes aren't case sensitive, so they'll never see the change, and for unix types, we can do: ./b[TAB] to get build.sh to expand, as it is now, it stops at ./build. (because .bat and .sh are both executable). It's a little thing, but it is indeed annyoying. And you know how us unix types hate typing. :) Just wanted to check with everyone in case build.bat is REQUIRED to be lowercase for some reason. -David ___ 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 ___ 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Read-only and time-out
I _thought_ that read-only and timeout were added to implement entities that were 'read-mostly' - things that might be updated outside of the EJB container occasionially (like a product catalog, say), while keeping the caching advantage of commit option A. If I'm remembering this correctly, this would mean that the timeout would extend accross transactions - maybe overriding commit option B to some extent? However, if I am remembering correctly, then the timeout should be more like 300 seconds than 300 milliseconds. -danch Dain Sundstrom wrote: Does anyone remember who originally wrote the time-out code or know the original goal? I am working on adding read-only to relationships, and have some questions on how time-out is supposed to work. Once a read-only field is loaded in a transaction, is it supposed to be valid for the length of the transaction, or only for the amount of time in time-out (300 ms by default)? If we are in commit option A, should the time-out extend across transactions? If we have a locking-strategy enabled (select-for-update is currently the only strategy), should the time-out be ignored within a transaction (i.e., the row is locked so why reload)? Any help would be greatly appreciated. I'm just guessing right now. -dain ___ 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
Re: [JBoss-dev] JBoss 3.0 Demo App
Hicks, James wrote: From reading all the emails, I think the majority of people would benefit from several small applications that each deal with a specific feature of JBoss 3.0. Do yall ( im texan ) think it is feasible to design these small independant applications so that in the end, a wrapper application could be developed to show developers how to tie all these features together? That would fairly rock. Depending on how fancy you want to be as an architectural example, it might not be too difficult to design the components that way. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 3.0 Demo App
Tilly, Jesse wrote: I think you'd be trying to bite off too much too fast. An application that encompassed all of the extensive features of JBoss and J2EE would be very large and very complex. That's why I don't like the PetStore application. Many people look to it for development patterns with J2EE that don't fit their application very well. Or are just bad ideas - see my earlier post on the user list. I think this is a great idea, though, James. I've long believed that the J2EE specification needed examples beyond the scope of a PetStore. Or the same thing implemented the way you really would in production. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/util TestConnection.java
Why do they have to be commented out to _compile_ under 1.4? Am I
missing something?
Guillaume Boissiere wrote:
User: boissier
Date: 01/12/04 11:08:59
Modified:src/main/org/jboss/test/util TestConnection.java
Log:
* In JDK 1.4, the interface java.sql.Connection has new 12 methods.
The patch below adds those methods to TestConnection.java
to make the project compile, but keep them commented out by
default to not break anything with JDK 1.3.
Revision ChangesPath
1.2 +46 -1 jbosstest/src/main/org/jboss/test/util/TestConnection.java
Index: TestConnection.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/util/TestConnection.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TestConnection.java 2001/10/21 22:03:48 1.1
+++ TestConnection.java 2001/12/04 19:08:59 1.2
@@ -13,7 +13,7 @@
* Database connection for unit tests. Currently nothing is implemented except
* close, isClosed, isAutoCommit, setAutoCommit(true), and rollback. Everything
* else throws a SQLException.
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
* @author a href=mailto:[EMAIL PROTECTED];Aaron Mulder/a
*/
public class TestConnection implements Connection {
@@ -118,4 +118,49 @@
public void setTypeMap(Map parm1) throws java.sql.SQLException {
throw new SQLException(TEST_DB);
}
+
+
+ // Note: The following methods have been added to make the testsuite compile
+ // with JDK 1.4.
+ // These methods will need to be implemented later on.
+ // Uncomment those 12 methods to compile JBoss with JDK 1.4.
+ /*
+ public Statement createStatement(int resultSetType, int resultSetConcurrency,
int resultSetHoldability) throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public int getHoldability() throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public CallableStatement prepareCall(String sql, int resultSetType, int
resultSetConcurrency, int resultSetHoldability) throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public PreparedStatement prepareStatement(String sql, int autoGeneratedKeys)
throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public PreparedStatement prepareStatement(String sql, int resultSetType, int
resultSetConcurrency, int resultSetHoldability) throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public PreparedStatement prepareStatement(String sql, int[] columnIndexes)
throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public PreparedStatement prepareStatement(String sql, String[] columnNames)
throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public void releaseSavepoint(Savepoint savepoint) throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public void rollback(Savepoint savepoint) throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public void setHoldability(int holdability) throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public Savepoint setSavepoint() throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public Savepoint setSavepoint(String name) throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ */
+
}
___
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
Re: [JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/util TestConnection.java
I meant 1.3 8^\ Obviously, I was missing the 3 key.
danch wrote:
Why do they have to be commented out to _compile_ under 1.4? Am I
missing something?
Guillaume Boissiere wrote:
User: boissier
Date: 01/12/04 11:08:59
Modified:src/main/org/jboss/test/util TestConnection.java
Log:
* In JDK 1.4, the interface java.sql.Connection has new 12 methods.
The patch below adds those methods to TestConnection.java
to make the project compile, but keep them commented out by
default to not break anything with JDK 1.3.
Revision ChangesPath
1.2 +46 -1
jbosstest/src/main/org/jboss/test/util/TestConnection.java
Index: TestConnection.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/util/TestConnection.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TestConnection.java2001/10/21 22:03:481.1
+++ TestConnection.java2001/12/04 19:08:591.2
@@ -13,7 +13,7 @@
* Database connection for unit tests. Currently nothing is
implemented except
* close, isClosed, isAutoCommit, setAutoCommit(true), and
rollback. Everything
* else throws a SQLException.
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
* @author a href=mailto:[EMAIL PROTECTED];Aaron
Mulder/a
*/
public class TestConnection implements Connection {
@@ -118,4 +118,49 @@
public void setTypeMap(Map parm1) throws java.sql.SQLException {
throw new SQLException(TEST_DB);
}
+ + + // Note: The following methods have been added to
make the testsuite compile + // with JDK 1.4.
+ // These methods will need to be implemented later on.
+ // Uncomment those 12 methods to compile JBoss with JDK 1.4.
+ /*
+ public Statement createStatement(int resultSetType, int
resultSetConcurrency, int resultSetHoldability) throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public int getHoldability() throws SQLException { +
throw new SQLException(TEST_DB);
+ }
+ public CallableStatement prepareCall(String sql, int
resultSetType, int resultSetConcurrency, int resultSetHoldability)
throws SQLException { +throw new SQLException(TEST_DB);
+ }
+ public PreparedStatement prepareStatement(String sql, int
autoGeneratedKeys) throws SQLException { +throw new
SQLException(TEST_DB);
+ }
+ public PreparedStatement prepareStatement(String sql, int
resultSetType, int resultSetConcurrency, int resultSetHoldability)
throws SQLException { +throw new SQLException(TEST_DB);
+ }
+ public PreparedStatement prepareStatement(String sql, int[]
columnIndexes) throws SQLException { +throw new
SQLException(TEST_DB);
+ }
+ public PreparedStatement prepareStatement(String sql, String[]
columnNames) throws SQLException { +throw new
SQLException(TEST_DB);
+ }
+ public void releaseSavepoint(Savepoint savepoint) throws
SQLException { +throw new SQLException(TEST_DB);
+ }
+ public void rollback(Savepoint savepoint) throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public void setHoldability(int holdability) throws SQLException
{ +throw new SQLException(TEST_DB);
+ }
+ public Savepoint setSavepoint() throws SQLException { +
throw new SQLException(TEST_DB);
+ }
+ public Savepoint setSavepoint(String name) throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ */
+ }
___
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
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: [JBoss-user] where is CMP2.0 documentation?
Hicks, James wrote: Don't see the Apache Project selling it's docs. No. O'Reilly sells docs on Apache. The free docs that Apache has are really good reference material, but if you don't know what you're looking for you'll waste hours trying to find it. If you look at the docs for Tomcat, it gets to be a complete nightmare to figure out how to do things. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] /. - want you to tell about my fears ....
I think what a lot of people are missing is your (and Scott's) emphasis on _professional_ level documentation. () No open source project has professional level documentation for free. They have at best whatever the developer felt like spewing in something approximating English. Think of the money people shell out for books on Linux, Apache, PHP, etc. Probably one of the biggest hurdles PostgreSQL had was that the only documentation was the online, volunteer maintained stuff (until recently). Not that my opinion matters a while lot, but providing a brief guide to features (getting started, whatever it's called) for free and charging for something professional makes perfect sense. Now: when is the book out (so I can put it on the shelf and piss off the IBM weenies) -danch marc fleury wrote: | And for the most part it's a great idea - but you really odda consider | providing some decent enough docs at least for people to get started on, | otherwise I imagine you'll find alot of people never getting started at | all... I don't get it, that is what we are talking about making a getstarted stuff free and good and then the advanced stuff for a fee, did I fail to communicate this? marcf ___ 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
Re: [JBoss-dev] /. - want you to tell about my fears ....
I think what he's talking about is the whiny kids from slashdot seeing the quote below (from the doco.jsp page) and loosing control of their bowels. How much is common between the current doc (which gets dumped from CVS nightly still, right?) and the book you're preparing? My impression is that that quote puts a bit of a pessimistic spin on it. There's a lot of good info in the online version, and it _does_ get better with age. -danch Scott M Stark wrote: So if this 400 page book I have in front of me, which is undergoing author review through Sams and will be released to Flashline next week doesn't constitute active maintenance, what does? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Peter Sojan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 29, 2001 2:28 PM Subject: Re: [JBoss-dev] /. - want you to tell about my fears Sorry for posting this here, but with Slashdot raving about JBoss, once again my concers about documentation emerge. What will the slashdot masses say if they are confronted with the following message: A free volunteer maintained manual was developed in the early stages of JBoss. A more complete and updated version is the for-pay documentation. This version is now somewhat out of date as it is not being as actively maintained ... Dont forget: those folks are pampered bitches and if they dont understand, they WILL leave. I dont want them to leave, because I love JBoss and I want to see it prosper in the future. Being a fact (you can assure yourself by reading the slashdot comments) that most of the people even dont know what J2EE is, it would be a pity to let all these newbies go. Ladies and gentlemen, I think this is a big chance for JBOSS - if we can make them stay for a while some will eventually start reading. Some of those will eventually start learning what JBOSS means and eventually they will start using it. What they will learn is not J2EE primarily, but it would be JBoss! In a perfect world one year from now JBoss could be used synonymous for J2EE ... But with a statement like that above, ... I dont know! Dont get me wrong, as I said before I love JBoss and if time permits (when I finished writing my diploma thesis) I will do my best to contribute. Maybe I will do the dirty work and start with documentation, since I believe this is of UTMOST importance to JBoss. now start bashing me ... Peter ___ 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: on the use of final
Luke Taylor wrote: Dain Sundstrom wrote: There are like five hundred rules on that page. What is it specifically flagging as a bad practice? I am actually interested. I had a look at the page too (try searching for the word final :-). But it doesn't really seem say more than the obvious Helps compiler optimization and more clearly documents the use of classes ... So it can be helpful for people reading the code to know that it has no subclases, but it's not really a big deal. Together also has some QA rules relating to the use of final. One is that *all* instantiated classes should be final. Snort! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] EJB QL
Peter Levart wrote: What about using finder methods like in BMP EBs? The responsibility of a BMP finder method is to return a Collection of primary keys. That's easy to do with JDBC/SQL. There would only have to be a way to apply BMP finders to CMP beans and we'll have dynamic SQL already. Currently I'm using JDBC/SQL to retrieve primary keys and then a loop of findByPrimaryKey() for each key to obtain Local interfaces and it takes about 1-2 seconds per 30 objects. The abovementioned BMP finders would speed things up considerably since it would only take one invocation... That may still takes n+1 DB hits - remember that the BMP finder returns a set of keys - beyond that you're OK if the bean is already in cache (commit option A). If you're doing all this from a session bean (in transaction) it shouldn't be any faster with a BMP finder than what you're doing. Unless I'm missing something big. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
Rickard Öberg wrote: That's much better, assuming I know where the tmp directory is. And I don't, since the name keeps changing for each deployment. :-( Something people have been compaining about roughly forever. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
Bill Burke wrote: In our app, we don't use wars and ears, only jars for our EJBs. Our jsps run off of a directory exposed through Jetty. That way we can easily modify jsps on the fly. Can't see why anybody would use WARS and EARS unless you were shipping a product. I've worked in a lot of companies where the production environment was that separated from development - the simpler the package you can hand over the better, since the people who support production environments tend to be on a different planet. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
When we talk about 'stateless' interceptors, do we really mean stateless, or do we merely mean stateless with regard to bean instance and client? -danch Scott M Stark wrote: Any of the interceptors can be made stateless, its a question of the cost of reassociating the state from the container meta-data and having to cast from an opaque generic form to the data required by the interceptor. The current state in the security interceptors is just cached data derived from the container meta-data. In the case of the SecurityProxyInterceptor the derived data can be an expensive transformation of the container meta-data. |should not need to know or store the interceptor-specific state info for |its chain. IMHO using a catch-all (or cache-all) map is a bit of a hack. |In particular, this conflicts directly with the security proxy interceptor. But isn't the state that the security interceptor uses really meta-data about the container? Shouldn't the interceptors get all meta-data from the *container*? If that is done, you'd get very clean separation of concerns, where the interceptor act upon the meta-data, but is not responsible for the actual meta-data. To me that seems more natural. So, the point isn't that the security interceptors should be stateless. In fact, they may very well be stateful. However, they should not have state *particular to any one container* (compare with Stateless Session Beans). ___ 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
Re: [JBoss-dev] Separating JMX/EJB
Rickard Oberg wrote: Bill Burke wrote: Nope. I guess when you come from the CORBA world to EJB, everything looks powerful. The packaging, (jars, wars, ears, and with jboss, sars) is just not available in the CORBA world. That's what its all about man. Packaging, integration, configuration, and deployment. All these new frameworks year after year think they're the coolest and that they're solving all these new cool problems. When in reality they solve the same problems the last latest/greatest framework did, except, usually, the packaging, integration, configuration and deployment get more seemless. While the packaging is cool, IMHO it's more of a practical detail than a real advancement. practical details are very important in the traditional IT world. Most developers are nowhere near as dedicated and talented as those who've been taking part in this conversation. To me, personally, it's all about the meta-programming and dynamicity of building large constructs from small blocks, which is enabled by having simple blocks that fit together like lego. JBoss is like lego. In many forms and different shapes, sizes and colors, but at the same time it's all the same. It's a nice illusion though. Very cool, indeed. But don't knock practicality 8^}) -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [research] a home/remote generator
FWIW, Bluestone did this. I tried to get them to stop.
Aaron Mulder wrote:
How do you compile the client code if the home/remote exists only
in the VM of the running server?
Aaron
On Mon, 12 Nov 2001, marc fleury wrote:
I know there are many tools out there that do almost what I am going to
describe already, it is an improvement on x-doclet.
I am wondering if the generation step cannot be done at deployment time. I
think we have the bytecode generation tools stuff that generates compiled
bytecode at runtime. See the 1.2.2 proxy generation and the implementation
Dain has put of the 2.0 spec CMP stuff. I will call them bytecode
injectors.
I would like the developer to just provide the implementation class with
HelloBean, bean identifying the implementation. The code would be
public class HelloBean extends SessionBean {
public String sayHello
{ return hi;}
}
}
and that is it. We would generate the home and remote with our code
injectors, if we find overridden methods (ejbActivate) then we would use
that from the class definition itself, if not we provide an empty
implementation. We put all the public methods in the Remote, minus the
create(...) and find...(...) that need manipulation in the home. Since we
control the classes definition that are loaded in our system we would be
able to plug this one in, the HelloBean implemented by us (actually it
could be under a different name since we are on the server side), and the
client sees the generated Hello (naming convention we remove the bean)
and HelloHome. This way the client can see the classes with the remote
loading.
For more advanced tags like the transactional ones we should incorporate
some x-doclet tags in the code, but these do not result in the xml file
generation and the jar creation rather it all works in JBoss, i.e. the
metadata population is done directly from the code. In essence we say fuck
packaging, too complex.
The goal there is really simple, it is to have the developers write the
trivial HelloBean above and BE DONE WITH THE EJB LEARNING CURVE.
marcf
Marc Fleury
President
JBoss Group, LLC
___
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
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] compile error in MessageDrivenTxInterceptorBMT - 2.4 branch?
I looked at the RH version of the interceptor in question and all it seems to do is pass-through: invokeHome throws an exception (no home methods on MDBs) and invoke just calls invokeNext. Shouldn't invoke at least suspend the current transaction? I was also hoping that someone who better understood the transactional needs of the MDBs would at least tell me what to do. David Jencks wrote: I noticed this earlier this week and no one responed to my question;-) Scott changed TxManager to TransactionManager in the base class TxInterceptorBMT without doing a clean/build. I thought about reverting, but looked at the 3.0 code where a better solution was implemented. I didn't have time to backport that to 2.4, so hoped someone who understood it better could do so... What would you think about putting in depends tasks into the compile targets at least in 3.0 to make this kind of problem less likely at the cost of slightly slower builds? Thanks David Jencks On 2001.10.25 21:16:27 -0400 danch wrote: On the current CVS, I'm getting errors like the following. Method disassociateThread() not found in interface javax.transaction.TransactionManager. [javac] Transaction t1 = tm.disassociateThread(); So what am I missing? thanks all, danch ___ 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] compile error in MessageDrivenTxInterceptorBMT - 2.4 branch?
On the current CVS, I'm getting errors like the following. Method disassociateThread() not found in interface javax.transaction.TransactionManager. [javac] Transaction t1 = tm.disassociateThread(); So what am I missing? thanks all, danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBossCMP] RE: [JBoss-dev] Tuned-updates OFF?
CMP just shouldn't update primary keys. - Original Message - From: Bill Burke [EMAIL PROTECTED] To: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Cc: Jaws@Kpi. Com. Au [EMAIL PROTECTED] Sent: Thursday, October 18, 2001 11:17 AM Subject: [JBossCMP] RE: [JBoss-dev] Tuned-updates OFF? More than thatBecause of our ignorance on DB schema design back in March, we almost didn't use JBoss because tuned-updates were OFF by default which caused updates of PrimaryKeys which caused DB deadlock all over the place in our application. For CMP 2.0, I'm remember that tuned-updates are always on no matter what. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Thursday, October 18, 2001 11:50 AM To: Jboss-Development@Lists. Sourceforge. Net Cc: Jaws@Kpi. Com. Au Subject: [JBoss-dev] Tuned-updates OFF? I am looking at the new configuration files in 2.4.1 and it seems that the CMP engines come with tuned-updates turned OFF by default. Why is this? I suspect there is a reason but can't think of it off the top of my head. I strongly recommend turning this on as people will see a sharp drop in performance without these... please what is the reason these are removed... whodunit? marcf Marc Fleury President JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- This is the JBossCMP mailing list. Please send email to '[EMAIL PROTECTED]' with the command 'unsubscribe jbosscmp [email@address]' in the body of the mail to be removed from this list. Please note that after a few days of emails bouncing to your address you will be unsubscribed. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Optimized EJB calls in catalina
On Wed, Sep 19, 2001 at 06:22:18PM +0100, Ignacio Coloma wrote: Hi, I am not sure, but looking in the EJB spec (draft version), for two times it specifically forbid the optimized EJB calls made in JBoss. Citing the draft: You can turn the optimization off. Most container vendors implement this optimization. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Enhydra vs. JBoss
They're barely and only lately J2EE. THey had a lot of resistence to the whole JSP thing (based on some legitimate criticisms) and only recently Started doing EJB (via Jonas, from Bull). I haven't looked in a while, but I thought that EJB integration was only available in their 'enterprise' edition, which is available only at cost. Another thing that bothered me about the article was the apparent lack of cluefulness about what open source _is_: they didn't mention the difference in license terms or the fact that JBoss can be used by and contributed to by anyone. -danch On Wed, Aug 29, 2001 at 12:22:46PM -0400, Bill Burke wrote: From reading the IBD article, is Enhydra a competitor of JBoss? I went to their web site and it seemed that Enhydra really wasn't Open Source, but a J2EE implementation that came with the source. If they are a competitor in the Open Source arena, how can we kick their ass? Or maybe we already do? Bill ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Datasources and the java:/ namespace
Vinay Menon wrote: Hello Folks, Is there any specific reason we have the jdbc datasources bound under java:/ as opposed to java:/comp/env/jdbc/ ? The java:comp/env (note: no '/' between ':' and 'comp') is for the environment of a J2EE component. This must be set up separately for each EJB, and Web war. See the documentation on jboss.xml and jboss-web.xml for how to map the 'java:/xxx' datasource entry into the java:comp/env namespace for a component. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] URGENCY? WSDL/UDDI/ebXML
Bill Burke wrote: Man you crack me up sometimes :) We used to have a running joke about support calls for O2K. I'm sorry, but you're just too stupid to use our product. Please cd to /usr/local and rm -rf o2k. Bill I think we've _all_ wanted to say that one time or another! -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DataSourceLoader...
Ferguson, Doug wrote: Well, Alot of my datasources are loaded on the fly... I can't have the type in a password when jboss starts. Also, when there are many differnet databases... it becomes unmanagable.. d. But if you encrypt the password on disk, you need a key to decrypt it with. Unless you make a sysadmin keep a floppy in a vault with this key on it and only mount that floppy when JBoss is starting, then take it out right away, you'll have to store the key on disk on the same machine where the encrypted passwords are stored. This makes the encrypted password clear-text equivalent. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] why is NoSuchEntityException ignored?
On Fri, Aug 10, 2001 at 10:45:47AM -0400, Bill Burke wrote: What about other instances of JBoss or different applications hitting the DB, or even the DBA doing some admin work? Plus, I've just checked in some new interceptors and a MethodOnly locking mechanism to allow instance per transaction. Also, if it can never happen, why ignore it? I agree - at the very least freak out into the log, so that we know that something 'impossible' has happened. -danch (friend of Murphy) ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] how to bind 2 datasource in jboss.jcml?
still wrote: hi,everybody: i use MS Access You probably shouldn't do that. .and i have 2 tables to work with.and i successfully load the sun's jdbc:odbc database driver That's probably bad too. ODBC driver (used to, anyway, when I had to use them) be really non-threadable in a bad way. OK, that's way more flip an answer than I like to give, but damn, man, if you're gonna be cheap, be _good_ and cheap! use Interbase, postgreSQL, or something that works! ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jaws_2_4.dtd not valid
You can have only one definition of the datasource element - and that's all we need since it's the same either place (just contains CDATA). As long as it's listed as a possible contained element for both the global jaws element, and the entity-bean element, we should be fine. Unless I'm missing something. -danch Vinay Menon wrote: Mike, That is a bean level datasource and quite obviously cannot be commented out in principal! I mean if you got to have a bean level ds you got to have one! Client programs should be able to define a datasource at the file level i.e. applicable to all the beans declared in the jaws.xml and the datasource at the bean level essentially overrides it. Vinay - Original Message - From: Mike Swainston-Rainford [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 11, 2001 11:40 PM Subject: [JBoss-dev] jaws_2_4.dtd not valid the jaws dtd is no longer valid. The datasource element is defined twice. This mucks up any validating editor/parser (like XMLSpy) used to edit a jaws.xml file. Suggest the second definition at line 69 is a comment thus:- !-- The datasource at bean level. If specified the bean will use this datasource instead of the global one. Else the global one is used -- !--ELEMENT datasource (#PCDATA)-- Mike S-R ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fetch size and JBossPool and Jaws
Toby Allsopp wrote: On Tue, Jul 10, 2001 at 08:48:15AM +0200, Vincent Harcq wrote: Hi, I want to add a feature that will allow to set the FetchSize associated with Statement in Jaws/JBossPool. The default FetchSize is in fact dependant of the driver (and is not always 0, meaning get all records), that's an hazardous thing imho. 1. A bit like IsolationLevel that we can specify on the Pool setting, add a FetchSize attribute. Why not just set the fetch size on the Statement when you create it? This doesn't feel like an attribute of the connection pool to me, but of the particular query you're executing. 2. For any finder method add a fetch-size deployment descriptor in jaws. Comments ? This makes sense to me. It also fits in with my evil plot to do 'cursor' type things on finders. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-438115 ] JAWS lower-cases custom finder SQL text
Vinay Menon wrote: Dan, Oracle case sensitive as well. One of the chaps here put a finder query ... where flg='T' Obviously it didn't work cos the JDBCDefinedFinderCommand issued it to the backed as where flg=i't'. This is cos the where clause is constructed with the lower case query. Do you want me to fix it? D'Oh! That one I expect to not work - SQL is usually case sensitive with the _contents_ of columns. Go ahead and fix, if you've the time. thanks much, danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-438115 ] JAWS lower-cases custom finder SQL text
Georg Rehfeld wrote: Hi danch, Does anybody know what databases are case sensitive WRT column and table names (or even keywords). I've never run into case sensitive SQL databases before. MySQL too is case sensitive on database, table and index names on a case sensitive file system (i.e. xNIX) with some table types especially the default MyISAM table type. The reason is, that they simply use the given name to generate a file path from it. Gak! Well, Vinay's fixed that bug already. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] remove transactional
I agree with Bill - removing everything involved in the rolled-back transaction from the cache is a must. -danch Bill Burke wrote: Nope, with the old code, B would be removed from the cache when b.remove() was called even if it was invoked from within a transaction. Also, all beans involved with a transaction would be removed from the cache on a rollback within InstanceSynchronization. I think that is the safe and correct approach to remove any bean from the cache that is part of a rollback. Otherwise you may have corrupted data. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Tuesday, July 03, 2001 2:57 PM To: Jboss-Development@Lists. Sourceforge. Net Subject: [JBoss-dev] remove transactional as I wrap up the stuff, sanity check bean a and bean b a starts transaction and calls b.remove() and then rolls back b is still there in cache right? marcf _ Marc Fleury, Ph.D [EMAIL PROTECTED] _ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build problem with CVS HEAD
For the record, I didn't literally checkout the HEAD branch - this was just a default checkout (no tag specified). The only difference I can think of between my system and those who report it working is that I'm running on a reiserfs filesystem - the jar files could get sent back to Ant in an unusual order? Just guessing. -danch Bordet, Simone wrote: Yo, I'm back to real life ! I'd suggest not to use HEAD tag, it's used by CVS and does not reflect the most recent code on the main trunk. If I remember well, just deleted files have HEAD tag, so you will checkout them even if they're not part of the most recent code. Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-438115 ] JAWS lower-cases custom finder SQL text
Does anybody know what databases are case sensitive WRT column and table
names (or even keywords). I've never run into case sensitive SQL
databases before.
[EMAIL PROTECTED] wrote:
Bugs item #438115, was opened at 2001-07-02 19:50
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=438115group_id=22866
Category: JBossCMP
Group: v2.4 BETA (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Jara (mjara)
Assigned to: Nobody/Anonymous (nobody)
Summary: JAWS lower-cases custom finder SQL text
Initial Comment:
JAWS is now lower-casing all custom finder SQL text
specified in jaws.xml. Most database drivers seem to
ignore case, but some (such as JConnect5.2/SybaseASE)
do not.
For example, if I have this in my jaws.xml file:
entity
ejb-nameEventDescription/ejb-name
finder
namefindByEventType/name
query, TypeDescriptionPair,
EventType WHERE EventType.description={0} AND
EventType.enumerationIndex=TypeDescriptionPair.eventTyp
eKey AND
TypeDescriptionPair.eventDescriptionKey=EventDescriptio
n.enumerationIndex/query
orderEventDescription.description/order
/finder
/entity
All table and field names are lower-cased on
execution. This is the trace logged in Beta 2.4:
2001-07-02 20:39:22,195 [RMI TCP Connection(8)-
161.218.184.161] DEBUG JAWS - findByEventType command
executing: SELECT EventDescription.enumerationIndex,
EventDescription.description FROM EventDescription,
typedescriptionpair, eventtype where
eventtype.description=? and
eventtype.enumerationindex=typedescriptionpair.eventtyp
ekey and
typedescriptionpair.eventdescriptionkey=eventdescriptio
n.enumerationindex ORDER BY
EventDescription.description
2001-07-02 20:39:22,195 [RMI TCP Connection(8)-
161.218.184.161] DEBUG JAWS - Set parameter: idx=1,
jdbcType=VARCHAR, value=Construction
2001-07-02 20:39:22,285 [RMI TCP Connection(8)-
161.218.184.161] DEBUG JAWS -
com.sybase.jdbc2.jdbc.SybSQLException: The column
prefix 'eventdescription' does not match with a table
name or alias name used in the query. Either the table
is not specified in the FROM clause or it has a
correlation name which must be used instead.
This DOES work properly in release 2.2 (maintaining
case as entered in jaws.xml.)
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=438115group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosspool/src/main/org/jboss/pool/jdbc/xa XAPoolDataSource.java
User: danch
Date: 01/07/01 20:20:08
Modified:src/main/org/jboss/pool/jdbc/xa XAPoolDataSource.java
Log:
Added timeout parameter for blocking
Revision ChangesPath
1.2 +6 -0 jbosspool/src/main/org/jboss/pool/jdbc/xa/XAPoolDataSource.java
Index: XAPoolDataSource.java
===
RCS file:
/cvsroot/jboss/jbosspool/src/main/org/jboss/pool/jdbc/xa/XAPoolDataSource.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- XAPoolDataSource.java 2001/05/15 07:58:24 1.1
+++ XAPoolDataSource.java 2001/07/02 03:20:08 1.2
@@ -22,6 +22,10 @@
* @see org.jboss.pool.factories.XAConnectionFactory
*
* @author Aaron Mulder ([EMAIL PROTECTED])
+ * @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson)/a
+ *
+ * Revision:
+ * 20010701 danch added code for timeout in blocking.
*/
public class XAPoolDataSource implements DataSource, Referenceable, ObjectFactory {
private static HashMap sources = new HashMap();
@@ -103,6 +107,8 @@
public int getMaxSize() {return pool.getMaxSize();}
public void setBlocking(boolean blocking) {pool.setBlocking(blocking);}
public boolean isBlocking() {return pool.isBlocking();}
+public void setBlockingTimeout(int blockingTimeout)
{pool.setBlockingTimeout(blockingTimeout);}
+public int getBlockingTimeout() {return pool.getBlockingTimeout();}
public void setIdleTimeoutEnabled(boolean allowShrinking)
{pool.setIdleTimeoutEnabled(allowShrinking);}
public boolean isIdleTimeoutEnabled() {return pool.isIdleTimeoutEnabled();}
public void setGCEnabled(boolean allowGC) {pool.setGCEnabled(allowGC);}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib jbosspool.jar
User: danch Date: 01/07/01 20:29:14 Modified:src/lib jbosspool.jar Log: allow specification of a timeout in JDBC connection pools when blocking is enabled Revision ChangesPath 1.2 +356 -359 jboss/src/lib/jbosspool.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] FW: [JBoss-user] Strange Behavior When DataSource goes down.
I tend to agree with Doug on this. Also, I think it's reasonable that the pools be able to tell the difference between inability to create a new object (connection, in this case) and simple pool exhaustion - there's no reason to block startup of the whole server just because one datasource is bad - you could be taking 20 applications down just because 1 has a database that went down. This like inability to connect should also be logged at error level. If nobody objects, I'll take this on and add this feature for 3.0. -danch. Ferguson, Doug wrote: Hi, This is a thread that I think needs to move to DEV... Basically I feel that it is a royal pain that jboss hangs whenever I try to startup jboss when a datbase is down and I've set the mbean to blocking. I would like to see a timeout feature to where I can setup the mbean with a timeout parameter for the blocking. I would also be nice to have a default timeout. Other people brought up interesting issues... Please check the thread. Thanks, d. -Original Message- From: Kaseman, Mark T To: '[EMAIL PROTECTED]' Sent: 6/29/2001 11:40 AM Subject: RE: [JBoss-user] Strange Behavior When DataSource goes down. Number 2 is a big issue for me and OS/390 DB2. DB2 has an idle thread time out parameter, that causes the datasource to become unusable once DB2 kills the inactive connection/thread. I then must reboot JBOSS. Orion server recovers the connection with no problem. -Original Message- From: danch (Dan Christopherson) [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 12:11 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Strange Behavior When DataSource goes down. In this case, no query has been executed. What I'd change: 1. In the pools, object factory create methods should throw an exception when they can't create an object - this way we can tell pool exhaustion from inability to create a pooled resource. 2. The pools should have an ability to test connections to determine if they're still good (configurable, of course). This is for those whose database thwacks them on the head after some period of time (and no ability to turn that behavior off) others? -danch David Jencks wrote: Well, I kind of agree, however I don't know how to distinguish between the db crashing and executing a query whose first results are available in 3 hours...and you're willing to wait. I think if the driver can distinguish and throw an exception, you get to see the exception. Otherwise, what do you do? Some kind of time awareness such as jini leases would be nice, however there certainly isn't any support for them in jdbc. Any ideas? david jencks On 2001.06.28 15:32:20 -0400 Richard Kasperowski wrote: David Jencks wrote: Hi, I find it hard to understand what you want. jboss does try out connections from configured datasources on startup, and hangs if they can't connect. I don't see how this is a severe problem: if your datasource isn't working, neither will your app. When a datasource becomes unavailable after startup, it might be desirable for the application to tell the user, sorry, the database is unavailable.? A user might find that more satisfactory than being denied service. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where is everyone today?
The first implementation of the read-ahead messed around with the caches before I decided that I didn't like it and took that out. -danch Dain Sundstrom wrote: Jay, Great point. Up until I started on this code, no part of JBossCMP worked with the other container objects (cache, invoker etc); JBossCMP was executed by the container via the persistence store interface. I'm going to have to think about this. Thanks for helping to clarify my bad feeling, -dain -Original Message- From: Jay Walters [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 2:01 PM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] Where is everyone today? I would think you'd want to be out of the guts too, that just seems a bit too closely coupled with JBoss for the persistence manager. Shouldn't the CMP persistence manager be some type of layer on top (well almost on top) with a well defined interface? This should clearly tie in to take advantage of what the container can provide. I am definitely on the outside of JBoss though, so marc et al are the people to listen to. Cheers -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 2:53 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Where is everyone today? Yo Dain, I know absolutely nothing about CMP 2.x Relationships, but it makes me really worried that you are working directly with EntityEnterpriseContexts from the container.cache. Why aren't you going through the HOME interfaces to access related beans? Remember, each entity type can have entirely different datastores, caching mechanisms, locking mechanisms, synchronization mechanisms, and pooling mechanisms. You shouldn't really be circumventing how to access a bean. If I'm totally out of my league here, I'll just apologize and shut up. Let me know, but in the meantime, I'll try to review the CMP 2.x Relationships. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Friday, June 29, 2001 2:22 PM To: '[EMAIL PROTECTED]' Subject: [JBoss-dev] Where is everyone today? Is everyone on vacation? Is the list working? What-ever, doesn't really matter. If any one is around today, and can reply to my message, I would greatly appreciate it. I kind of need some guidance on the decision to create an interceptor or not. I'm going to continue along the line that I don't need an interceptor (I can always add it later). If you all are on vacation, have a great time. -dain -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 28, 2001 11:48 PM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation marc, Do you mean that I should be setting invoked, or something else? I got the bi-directional one-to-one (enforced integrity) working using the entity cache, but it gives me a bad feeling. In the this case, there may be up to 4 beans that need to be stored: before: a1--b1 a2--b2 a1.setB(b2) after: a1\ b1 a2 \b2 So, I hold onto up to three other contexts. When my store is called, I write my state and then store the other contexts (with their respective mangers). This won't cause extraneous writes as 'tuned updates' is always on. What is giving me the bad feeling is I have just cut out all of the work that is being done in the interceptors, specifically EntitySynchronizationInterceptor. For example, do I need to remove the context from the cache at the end of the transaction? Do I need to lock the context? What if one of the beans is removed? (the new remove procedure for relationships may handle this, but haven't implemented it yet) As you can tell this has given me a lot of concern. If this is stuff I shouldn't worry about, good. If I should worry, will it be better to create the new interceptor, thus reusing the code in the other interceptors, or will it be easier to handle the few special cases in the persistence store? -dain -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 28, 2001 9:53 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation also be sure to report right here is you touch any of the information in the ctx (using setters) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dain |Sundstrom |Sent: Thursday, June 28, 2001 9:45 PM |To: '[EMAIL PROTECTED]' |Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation | | | | The only way I can find to get a ctx for a pk | |is from EntityInstanceInterceptor, and the only way to get to the | |EntityInstanceInterceptor is container.invoke(mi). | | no no no it's in the cache, | | container.cache.get(id) (or something like that) | | marcf | | |YES! Thanks so much. I didn't want to write the interceptor. |This is going |to be way easier. I'm going to go code now. | |-dain
Re: [JBoss-dev] Where is everyone today?
Dain Sundstrom wrote: Bill, Thanks for the reply. I really need other people thinking about this, because I don't understand the rest of the container. Here's the deal. I delegate the actual storage of the other updated contexts to the their respective persistence storage managers, so they get stored by correct data source. I also get references to the other beans through their container's cache. Errr. I was nervous enough about the persistence manager messing with its own bean's cache, let along messing with other bean's caches. I think the biggest problem with this implementation is that my persistence store is directly calling store on other persistence stores, thus by passing all of the code that is supposed know the right way to do this. Ya, this makes me nervous too - there's too much that can go wrong. Really to get the store going you should be hooking into the transaction (which is the job of the EntitySynchronizationInterceptor) What about Bill's suggestion to go through the homes? That may not be the best performance, but then you know that all the Right Things are happening, even if (when) the definition of Right Thing changes. Short circuiting the interceptor chain is bad, IMHO. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead/interfaces - New directory
User: danch Date: 01/06/29 21:32:32 jbosstest/src/main/org/jboss/test/readahead/interfaces - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/readahead - New directory
User: danch Date: 01/06/29 21:33:31 jbosstest/src/resources/readahead - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/readahead/META-INF - New directory
User: danch Date: 01/06/29 21:34:16 jbosstest/src/resources/readahead/META-INF - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/build/subprojects build-readahead.xml
User: danch
Date: 01/06/29 21:38:05
Added: src/build/subprojects build-readahead.xml
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.1 jbosstest/src/build/subprojects/build-readahead.xml
Index: build-readahead.xml
===
?xml version=1.0?
!-- The JBossTest CMP read-ahead testsuite build file --
project name=JBossTest-ReadAhead default=jar
!-- === --
!-- Compiles the source code--
!-- === --
target name=compile
mkdir dir=${build.classes.dir}/
javac srcdir=${src.dir}
destdir=${build.classes.dir}
classpath=${classpath}
debug=on
deprecation=on
optimize=off
includes=org/jboss/test/readahead/**
/
/target
!-- === --
!-- Creates the JBossTest bank ejb-jar file --
!-- === --
target name=jar depends=compile
delete dir=${build.classes.dir}/META-INF/
copy todir=${build.classes.dir}
fileset dir=${src.resources}/readahead/
/copy
jar jarfile=${build.lib.dir}/readaheadtest.jar
basedir=${build.classes.dir}
manifest=${etc.dir}/manifest.mf
includes=org/jboss/test/readahead/interfaces/**,org/jboss/test/readahead/test/**,*.*
/
jar jarfile=${build.deploy.dir}/readahead.jar
basedir=${build.classes.dir}
includes=org/jboss/test/util/ejb/**,org/jboss/test/readahead/interfaces/**,org/jboss/test/readahead/ejb/**,**/*.xml
/
/target
/project
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/build build.xml
User: danch Date: 01/06/29 21:38:05 Modified:src/build build.xml Log: Added tests for readahead functionality. Note that this only checks to see if they work: it doesn't verify that it's actually performing well Revision ChangesPath 1.37 +7 -2 jbosstest/src/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosstest/src/build/build.xml,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- build.xml 2001/06/26 01:08:49 1.36 +++ build.xml 2001/06/30 04:38:05 1.37 @@ -148,7 +148,8 @@ antcall target=web-subproject / antcall target=jmsra-subproject / antcall target=logging-subproject / - antcall target=threading-subproject / +antcall target=threading-subproject / +antcall target=readahead-subproject / /target target name=bank-subproject depends=prepare @@ -227,7 +228,11 @@ !-- Log4j logging tests -- ant antfile=src/build/subprojects/build-logging.xml / /target - target name=threading-subproject depends=prepare +target name=readahead-subproject depends=prepare +!-- CMP finder readahead tests -- +ant antfile=src/build/subprojects/build-readahead.xml / +/target +target name=threading-subproject depends=prepare !-- threading tests -- ant antfile=src/build/subprojects/build-threading.xml / /target ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead/interfaces AddressHome.java AddressPK.java AddressRemote.java CMPFindTestEntityHome.java CMPFindTestEntityRemote.java CMPFindTestSessionHome.java CMPFindTestSessionRemote.java
User: danch
Date: 01/06/29 21:38:06
Added: src/main/org/jboss/test/readahead/interfaces
AddressHome.java AddressPK.java AddressRemote.java
CMPFindTestEntityHome.java
CMPFindTestEntityRemote.java
CMPFindTestSessionHome.java
CMPFindTestSessionRemote.java
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.1
jbosstest/src/main/org/jboss/test/readahead/interfaces/AddressHome.java
Index: AddressHome.java
===
package org.jboss.test.readahead.interfaces;
import java.util.Collection;
import java.rmi.RemoteException;
import javax.ejb.EJBHome;
import javax.ejb.CreateException;
import javax.ejb.FinderException;
/**
* Home interface for one of the entities used in read-ahead finder tests
*
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
* @version $Id: AddressHome.java,v 1.1 2001/06/30 04:38:05 danch Exp $
*
* Revision:
*/
public interface AddressHome extends EJBHome {
public AddressRemote create(String key, String addressId, String address,
String city, String state, String zip) throws
RemoteException, CreateException;
public AddressRemote findByPrimaryKey(AddressPK primaryKey) throws
RemoteException, FinderException;
public Collection findByKey(String key) throws RemoteException, FinderException;
public Collection findByCity(String city) throws RemoteException, FinderException;
}
1.1
jbosstest/src/main/org/jboss/test/readahead/interfaces/AddressPK.java
Index: AddressPK.java
===
package org.jboss.test.readahead.interfaces;
import java.io.Serializable;
/**
* Primary key class for one of the entities used in read-ahead finder tests.
*
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
* @version $Id: AddressPK.java,v 1.1 2001/06/30 04:38:05 danch Exp $
*
* Revision:
*/
public class AddressPK implements Serializable {
public String key = ;
public String addressId = ;
public AddressPK() {
}
public AddressPK(String key, String addressId) {
this.key = key;
this.addressId = addressId;
}
public boolean equals(Object obj) {
if (this.getClass().equals(obj.getClass())) {
AddressPK that = (AddressPK) obj;
return this.key.equals(that.key) this.addressId.equals(that.addressId);
}
return false;
}
public int hashCode() {
return key.hashCode()+addressId.hashCode();
}
}
1.1
jbosstest/src/main/org/jboss/test/readahead/interfaces/AddressRemote.java
Index: AddressRemote.java
===
package org.jboss.test.readahead.interfaces;
import java.rmi.RemoteException;
import javax.ejb.EJBObject;
/**
* Remote interface for one of the entities used in read-ahead finder tests
*
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
* @version $Id: AddressRemote.java,v 1.1 2001/06/30 04:38:05 danch Exp $
*
* Revision:
*/
public interface AddressRemote extends EJBObject {
public java.lang.String getZip() throws RemoteException;
public void setZip(java.lang.String newZip) throws RemoteException;
public java.lang.String getState() throws RemoteException;
public void setState(java.lang.String newState) throws RemoteException;
public java.lang.String getCity() throws RemoteException;
public void setCity(java.lang.String newCity) throws RemoteException;
public void setAddress(java.lang.String newAddress) throws RemoteException;
public java.lang.String getAddress() throws RemoteException;
public java.lang.String getAddressId() throws RemoteException;
public java.lang.String getKey() throws RemoteException;
public void setAddressId(java.lang.String newAddressId) throws RemoteException;
}
1.1
jbosstest/src/main/org/jboss/test/readahead/interfaces/CMPFindTestEntityHome.java
Index: CMPFindTestEntityHome.java
===
package org.jboss.test.readahead.interfaces;
import java.util.Collection;
import java.rmi.RemoteException;
import javax.ejb.EJBHome;
import javax.ejb.CreateException;
import javax.ejb.FinderException;
/**
* Home interface for one of the entities used in read-ahead finder tests.
*
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
* @version $Id
[JBoss-dev] CVS update: jbosstest/src/resources/readahead client.policy jndi.properties
User: danch
Date: 01/06/29 21:38:06
Added: src/resources/readahead client.policy jndi.properties
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.1 jbosstest/src/resources/readahead/client.policy
Index: client.policy
===
grant {
// Allow everything for now
permission java.security.AllPermission;
};
1.1 jbosstest/src/resources/readahead/jndi.properties
Index: jndi.properties
===
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jnp.interfaces
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/readahead/META-INF ejb-jar.xml jaws.xml
User: danch
Date: 01/06/29 21:38:06
Added: src/resources/readahead/META-INF ejb-jar.xml jaws.xml
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.1 jbosstest/src/resources/readahead/META-INF/ejb-jar.xml
Index: ejb-jar.xml
===
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans
1.1//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd'
ejb-jar
enterprise-beans
entity
ejb-nameCMPFindTestEntity/ejb-name
homeorg.jboss.test.readahead.interfaces.CMPFindTestEntityHome/home
remoteorg.jboss.test.readahead.interfaces.CMPFindTestEntityRemote/remote
ejb-classorg.jboss.test.readahead.ejb.CMPFindTestEntity/ejb-class
persistence-typeContainer/persistence-type
prim-key-classjava.lang.String/prim-key-class
reentrantFalse/reentrant
cmp-field
field-namekey/field-name
/cmp-field
cmp-field
field-namename/field-name
/cmp-field
cmp-field
field-namerank/field-name
/cmp-field
cmp-field
field-nameserialNumber/field-name
/cmp-field
primkey-fieldkey/primkey-field
/entity
session
ejb-nameCMPFindTestSession/ejb-name
homeorg.jboss.test.readahead.interfaces.CMPFindTestSessionHome/home
remoteorg.jboss.test.readahead.interfaces.CMPFindTestSessionRemote/remote
ejb-classorg.jboss.test.readahead.ejb.CMPFindTestSession/ejb-class
session-typeStateless/session-type
transaction-typeContainer/transaction-type
/session
entity
ejb-nameAddress/ejb-name
homeorg.jboss.test.readahead.interfaces.AddressHome/home
remoteorg.jboss.test.readahead.interfaces.AddressRemote/remote
ejb-classorg.jboss.test.readahead.ejb.Address/ejb-class
persistence-typeContainer/persistence-type
prim-key-classorg.jboss.test.readahead.interfaces.AddressPK/prim-key-class
reentrantFalse/reentrant
cmp-field
field-namekey/field-name
/cmp-field
cmp-field
field-nameaddressId/field-name
/cmp-field
cmp-field
field-nameaddress/field-name
/cmp-field
cmp-field
field-namecity/field-name
/cmp-field
cmp-field
field-namestate/field-name
/cmp-field
cmp-field
field-namezip/field-name
/cmp-field
/entity
/enterprise-beans
/ejb-jar
1.1 jbosstest/src/resources/readahead/META-INF/jaws.xml
Index: jaws.xml
===
jaws
enterprise-beans
entity
ejb-nameCMPFindTestEntity/ejb-name
tuned-updatestrue/tuned-updates
pk-constrainttrue/pk-constraint
finder
namefindAll/name
query /
order /
read-aheadtrue/read-ahead
/finder
finder
namefindByCity/name
query, address where CMPFindTestEntity.key = address.key AND
address.city = {0}/query
order /
read-aheadtrue/read-ahead
/finder
/entity
entity
ejb-nameAddress/ejb-name
tuned-updatestrue/tuned-updates
pk-constrainttrue/pk-constraint
finder
namefindByCity/name
queryaddress.city = {0}/query
order /
read-aheadtrue/read-ahead
/finder
/entity
/enterprise-beans
/jaws
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/bin readaheadtest.bat readaheadtest.sh
User: danch Date: 01/06/29 21:38:05 Added: src/bin readaheadtest.bat readaheadtest.sh Log: Added tests for readahead functionality. Note that this only checks to see if they work: it doesn't verify that it's actually performing well Revision ChangesPath 1.1 jbosstest/src/bin/readaheadtest.bat Index: readaheadtest.bat === java -Djava.security.policy=jar:file:../lib/readaheadtest.jar!/client.policy -Djava.security.manager -classpath ../lib/readaheadtest.jar junit.swingui.TestRunner org.jboss.test.readahead.test.Main 1.1 jbosstest/src/bin/readaheadtest.sh Index: readaheadtest.sh === #!/bin/sh java -Djava.security.policy=jar:file:../lib/readaheadtest.jar!/client.policy -Djava.security.manager -classpath ../lib/readaheadtest.jar junit.swingui.TestRunner org.jboss.test.readahead.test.Main ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead/test Main.java
User: danch
Date: 01/06/29 21:38:06
Added: src/main/org/jboss/test/readahead/test Main.java
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.1 jbosstest/src/main/org/jboss/test/readahead/test/Main.java
Index: Main.java
===
package org.jboss.test.readahead.test;
import javax.naming.Context;
import javax.naming.InitialContext;
import org.jboss.test.readahead.interfaces.CMPFindTestSessionHome;
import org.jboss.test.readahead.interfaces.CMPFindTestSessionRemote;
import junit.framework.TestCase;
import junit.framework.Test;
import junit.framework.TestSuite;
/**
* TestCase driver for the readahead finder tests
*
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
* @version $Id: Main.java,v 1.1 2001/06/30 04:38:06 danch Exp $
*
* Revision:
*/
public class Main extends TestCase {
CMPFindTestSessionRemote rem = null;
public Main(String name) {
super(name);
}
public static Test suite() {
return new TestSuite(Main.class);
}
protected void tearDown() throws Exception {
if (rem != null) {
System.out.println(Removing test data);
rem.removeTestData();
rem.remove();
rem = null;
}
}
protected void setUp()
throws Exception
{
if (rem != null)
return;
System.out.println(Deploying);
new org.jboss.jmx.client.Deployer().deploy(../deploy/readahead.jar);
System.out.println(Creating test data);
Context ctx = new InitialContext();
CMPFindTestSessionHome home =
(CMPFindTestSessionHome)ctx.lookup(CMPFindTestSession);
rem = home.create();
rem.createTestData();
}
public void testFindAll() throws Exception {
rem.testFinder();
}
public void testFindByCity() throws Exception {
rem.testByCity();
}
public void testAddressByCity() throws Exception {
rem.addressByCity();
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead - New directory
User: danch Date: 01/06/29 21:32:14 jbosstest/src/main/org/jboss/test/readahead - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Dain Sundstrom wrote: I don't know if you wanted with user configurable, but for now it will allow you to play with different levels. I can make it static later. static? ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Fw: [JBoss-dev] Shouldn't expose transaction-isolation within CMP
Dain Sundstrom wrote: I think I understand now. Here is some text I found the J2EE tutorial: You cannot modify the isolation level of a entity beans with container-managed persistence. These beans use the default isolation level of the DBMS, which is usually READ_COMMITTED. I don't remember the spec saying that the container had to use the database default isolation level. Is this remark more about the RI than what containers in general should do, or did I miss something? Do not change the isolation level in the middle of a transaction. Usually, such a change causes the DBMS software to issue an implicit commit. D'Oh! I'd expected an exception in that case. --- So the code I added probably causes an implicit commit, which is bad. From my very JDBC centric perspective, this should be set in Minerva (JBossPool?) and user configurable. I don't know much about the connector architecture, so maybe Minerva is the wrong place. Any way, I think I should roll back my change. I'd agree. If you agree marc, just say so and it is done. But I'm not marc. I don't know any thing about Minerva, so if you want that changed, someone else would be better suited. If no one wants to do it, I'll look at it. -dain -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
David Jencks wrote: Read on - the problem with this occured to a few of us already. Although none of us mentioned putting it in the container-transaction - that's interesting. But what if a method at iso 'read-uncommitted' calls a method in an iso 'serializable' transaction? thanks, danch Hi, Forgive me if I am talking nonsense, but doesn't it only make sense to have transaction isolation per transaction I very much doubt you will find a db that can support several transaction isolation levels within one transaction. I can't quite figure out what it would mean, either. So I say, put it with the transaction requirements for methods - Requires, Requires New, etc. Then you can set the isolation each time you start a new transaction, based on this specification. david jencks On 2001.06.26 14:48:00 -0400 Dain Sundstrom wrote: |I added transaction isolation to the new cmp plugin. You can set it by |adding the transaction-isolation element after the datasource element. |Valid levels are: |transaction-none |transaction-read-committed |transaction-read-uncommitted |transaction-repeatable-read |transaction-serializable | |Give me 10 minutes and I'll add it to JAWS... ok but these will be leveraged by new caches in JBoss 3.0 so I would imagine that each application can set its own datasource isolation level, (different kinds of bean). So it IS user configurable right??? Also how does it play with the datasources, if the datasource is shared across applications and different tables support different locking policies (say one table is RO the other RW) can the driver support sequential setIsolationLevel that only applies to the record and or table touched? marcf Right now this the jaws and jbosscmp code only support datasource per application. When we implement datasource per bean, we can have isolation level per bean. This leads to the intresting situation with EJB-QL queries that thouch multiput beans. May be we need to specify an isolation lever for each query. Havn't thought about it much. Right now you can only set it for the entire ejb-jar. Just tell me when you get the cache stuff figgured out and I can update jaws and jbosscmp to support what ever you want. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
