Re: [JBoss-dev] JMX on the client side?
On 2002.11.08 23:33:50 -0500 Matt Munz wrote: > David, > > > Hard to know. We do have the minimal jboss configuration, which is a > good > > starting place: as I recall basically all it can do is deploy .sars. > AFAIK > > I'm thinking of a minimal that is perhaps smaller than that. I think > that > the MBean API + proxies should be sufficient for many clients. Currently setting up the sar deployer is done in the jboss startup code, and the "minimal" jboss-service.xml is then read in. Without this, how do you propose to efficiently deploy and configure mbeans? > > > It's a lot easier for me to think about the container starting first, > and > I > > think it will provide less surprising performance, but I'm not sure we > can > > Isn't Dain's method just lazy instantiation (by definition harder to > measure > performance-wise)? I imagine a client proxy factory that 1) checks for > an > mbean server, creates it if necessary, and then 2) checks if required > client-side MBeans are loaded and then loads them if necessary, before > returning the proxy. Agreed. On the other hand, it might be useful to make everything be loaded by one of our classloaders. I seem to recall that in java 1.4 one can specify the system classloader on startup. Could we use this to force our classloader to set up an mbean server to manage itself? This would be a fairly transparent way to get the mbean server started immediately. > > Either way, this all sounds good. Too bad I don't have a real use for it > yet ;) > Just wait till its written :-) david jencks > - Matt > > > > --- > 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 > > --- 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
[JBoss-dev] confirm 158923
Title: confirm 158923
RE: [JBoss-dev] JMX on the client side?
David, > Hard to know. We do have the minimal jboss configuration, which is a good > starting place: as I recall basically all it can do is deploy .sars. AFAIK I'm thinking of a minimal that is perhaps smaller than that. I think that the MBean API + proxies should be sufficient for many clients. > It's a lot easier for me to think about the container starting first, and I > think it will provide less surprising performance, but I'm not sure we can Isn't Dain's method just lazy instantiation (by definition harder to measure performance-wise)? I imagine a client proxy factory that 1) checks for an mbean server, creates it if necessary, and then 2) checks if required client-side MBeans are loaded and then loads them if necessary, before returning the proxy. Either way, this all sounds good. Too bad I don't have a real use for it yet ;) - Matt --- 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
[JBoss-dev] Never Pay INCOME TAX Again!! 9049jQFK8-937lFne381-19
It costs you about one fifth of everything you earn; every Monday, in effect, you're a slave to the Federal Government. But with our PROVEN method, NEVER AGAIN! Here's what you stand to gain: - FREEDOM FROM INCOME TAX, FOR EVER! That means $8,000 every year, to the average earner. Over 30 years, that's a saving of $240,000. Then in addition, - FREEDOM FROM STATE INCOME TAX too, for most of those who work in a State that tries to tax income. For that same average earner, another $50,000 or so. - FREEDOM FROM "SOCIAL SECURITY" TAX, for self-employed users of this method. About another $180,000, free to spend on (eg) REAL retirement and health insurance. - FREEDOM FROM SWEATING THAT 1040 Form every year, lest you miss a deduction or risk penalties for errors. Instead, it will take you ten minutes or less. - FREEDOM FROM SPYING into your private affairs by the IRS, which Congressman Ron Paul has rightly called "The world's largest terrorist organization." - FREEDOM FROM BULLYING by those bureaucrats, to make you obey their every arrogant whim. - FREEDOM FROM PAYING FOR OBJECTIVES YOU OPPOSE but which the politicians spend your money on anyway. - INCREASED SELF-ESTEEM that comes only from knowing that you have taken back control of YOUR life, from some distant pimp of a politician and his thugs. How? By LEARNING HOW TO USE A WELL-PROVEN METHOD to take advantage of the remarkable fact that in the USA, *** ***NO LAW EXISTS TO TAX EARNINGS! *** *** That's right; for nearly 90 years, the "income tax" has been collected only by fraud and extortion - by politicians, lawyers and bureaucrats; three of the lowest forms of human life. It's by far the biggest swindle in history. As the late Senator Henry Bellman said: "In a recent conversation with an official of the IRS, I was amazed when he told me that 'If the taxpayers of this country ever discover that the Internal Revenue Service operates on 90 percent bluff, the entire system will collapse.'" He was lying about the 90% (it's actually 100%) but we have made that discovery, and found how to take advantage of it. Many thousands of us are legally doing so. Nobody has been prosecuted. Nobody has lost his home. Yet nobody pays a dime of income tax. Now, you can learn to use it too; we have developed an ON-LINE SCHOOL with in-person help, to teach you how. You will recover its cost from a very few weeks of "income tax" savings. Then for the rest of your working life, all those savings will be yours. Reply to learn more; it will be my pleasure. Please put "NO MORE TAX" in the subject line. CLICK HERE: Best Regards, Jim D. PS: If you'd like to talk at once, just include your phone # and the best time(s) for me to call you. You are receiving this offer because you have provided permission to receive email promotions and special offers. If you feel you have received this in error or wish to be removed from out contact list, just put "Remove" in subject line and click below. Sorry for the inconvenience. Click Here: 8151hiWP0-826VJob2368l20 --- 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] JMX on the client side?
On 2002.11.08 17:35:42 -0500 Matt Munz wrote: > > > Imagine a world where jboss is installed everywhere - client and > server. > ;) > > You're talking about (more evenly) distributed systems (a.k.a. P2P)? I > think you're still going to need a delineation of roles -- some nodes are > going to be thicker than others. You don't want to start up an entire > JBoss > stack just to run JNotepad (fictional). Likewise, I'd imagine you don't > want all of your client side applications running in the same JVM. It > seems > to me that a measure of fault tolerance is worth the extra memory use (by > starting up separate VMs) in this case (although I'm interested in > arguments > to the contrary). > > It seems to me that when you're designing a node in a distributed system, > you start out by defining the role/functionality. Then take the most > minimal JBoss kernel. Then start stacking on functionality until you > have > what you want. > > What makes this better than client-server, IMO, is that all nodes > (should) > share a common architecture. That way, server-side code can easily be > pushed to the client for added performance. So JNotepad uses a > Web-service > based remote spellchecker. You like it? OK, download spellchecker.sar, > and > any "server" modules that it depends on. > > What makes this worse than client-server is that it doesn't exist yet, > AFAIK Hard to know. We do have the minimal jboss configuration, which is a good starting place: as I recall basically all it can do is deploy .sars. AFAIK however none of our clients are adapted well to live in this environment and make use of it (although I have some plans in this direction for transaction propagation). I think the difference between what Dain is proposing and the j2ee client container is that the j2ee client container is expected to start first, before your app, whereas my understanding of Dain's proposal is that the jmx/container services start when you first look something up in jndi. It's a lot easier for me to think about the container starting first, and I think it will provide less surprising performance, but I'm not sure we can require or enforce it in any practical way. Did I get Dain's idea right? Any other ideas? thanks david jencks > :) ... > > - Matt > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of James > Higginbotham > Sent: Friday, November 08, 2002 4:42 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JMX on the client side? > > > > I think James had more esoteric plans... > > > > -danch > > > > Right.. I'm not talking about Jboss proper, I'm speaking of a rich > client platform that uses jboss as its service arch kernel. Imagine a > world where jboss is installed everywhere - client and server. ;) > > James > > > --- > 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 > > > > --- > 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 > > --- 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] JMX on the client side?
> JBoss Unlimited. > JBoss Unleashed. > Infinite JBoss. > > This is the kind of thing that makes suits giddy with joy. Right! Or: JBoss Web Service Platform JBoss: Web Service Edition JBossXML In fact, if you change the tagline from WebOS to WebServiceOS, you can charge more consulting bucks on your engagements! ;) Have a great weekend everyone! --- 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] JMX on the client side?
On Fri, 8 Nov 2002, James Higginbotham wrote: > Right.. I'm not talking about Jboss proper, I'm speaking of a rich > client platform that uses jboss as its service arch kernel. Imagine a > world where jboss is installed everywhere - client and server. ;) JBoss Unlimited. JBoss Unleashed. Infinite JBoss. This is the kind of thing that makes suits giddy with joy. --- 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] JMX on the client side?
this is great and an old standing vision, if we make it real I believe it should be a standalone distribution marc f > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net] On > Behalf Of James Higginbotham > Sent: Friday, November 08, 2002 4:42 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JMX on the client side? > > > > I think James had more esoteric plans... > > > > -danch > > > > Right.. I'm not talking about Jboss proper, I'm speaking of a > rich client platform that uses jboss as its service arch > kernel. Imagine a world where jboss is installed everywhere - > client and server. ;) > > James > > > --- > 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 --- 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] [OT] JMX on the client side?
Well, I'm not really talking that, though I did address that in a JXTA product I architected around May of 2001 - we never went public with it, as we decided not to try for funding after Sept 11th - customers for it would be few and far between with R&D budgets gone.. I'm speaking more of using Jboss and its JMX capabilities to design what I would call J2DE - Desktop edition. Something that encompasses a service-oriented architecture, with things similar to EJBs or Jboss JMX services that are plugged in to extend the capability of a rich client. No, not swing from an mbean on a server (re: a past post), but the inverse. Kinda like the BeanContext API sun packaged but never really explored fully.. A service component that has a context to its gui container and the services to which it may have access to. So, yes, some services may be a lightweight proxy to a web service, with the option of installing the .sar locally if you tend to use it a lot. Make sense? Sorry for this on the jboss-dev list. We can take this offline for anyone else interested in this further. Dain's email got me thinking that his idea of a JMX container on the calling client could be cool, but could also introduce some technical issues for what I was thinking. My apologies for taking jboss-dev's time on this one.. James > -Original Message- > From: Matt Munz [mailto:mmunz@;apelon.com] > Sent: Friday, November 08, 2002 4:36 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JMX on the client side? > > > > > Imagine a world where jboss is installed everywhere - client and > > server. > ;) > > You're talking about (more evenly) distributed systems > (a.k.a. P2P)? I think you're still going to need a > delineation of roles -- some nodes are going to be thicker > than others. You don't want to start up an entire JBoss > stack just to run JNotepad (fictional). Likewise, I'd > imagine you don't want all of your client side applications > running in the same JVM. It seems to me that a measure of > fault tolerance is worth the extra memory use (by starting up > separate VMs) in this case (although I'm interested in > arguments to the contrary). > > It seems to me that when you're designing a node in a > distributed system, you start out by defining the > role/functionality. Then take the most minimal JBoss kernel. > Then start stacking on functionality until you have what you want. > > What makes this better than client-server, IMO, is that all > nodes (should) share a common architecture. That way, > server-side code can easily be pushed to the client for added > performance. So JNotepad uses a Web-service based remote > spellchecker. You like it? OK, download spellchecker.sar, > and any "server" modules that it depends on. > > What makes this worse than client-server is that it doesn't > exist yet, AFAIK > :) ... > > - Matt > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On > Behalf Of James Higginbotham > Sent: Friday, November 08, 2002 4:42 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JMX on the client side? > > > > I think James had more esoteric plans... > > > > -danch > > > > Right.. I'm not talking about Jboss proper, I'm speaking of a > rich client platform that uses jboss as its service arch > kernel. Imagine a world where jboss is installed everywhere - > client and server. ;) > > James > > > --- > 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 --- 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 --- 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] JMX on the client side?
> Imagine a world where jboss is installed everywhere - client and server. ;) You're talking about (more evenly) distributed systems (a.k.a. P2P)? I think you're still going to need a delineation of roles -- some nodes are going to be thicker than others. You don't want to start up an entire JBoss stack just to run JNotepad (fictional). Likewise, I'd imagine you don't want all of your client side applications running in the same JVM. It seems to me that a measure of fault tolerance is worth the extra memory use (by starting up separate VMs) in this case (although I'm interested in arguments to the contrary). It seems to me that when you're designing a node in a distributed system, you start out by defining the role/functionality. Then take the most minimal JBoss kernel. Then start stacking on functionality until you have what you want. What makes this better than client-server, IMO, is that all nodes (should) share a common architecture. That way, server-side code can easily be pushed to the client for added performance. So JNotepad uses a Web-service based remote spellchecker. You like it? OK, download spellchecker.sar, and any "server" modules that it depends on. What makes this worse than client-server is that it doesn't exist yet, AFAIK :) ... - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of James Higginbotham Sent: Friday, November 08, 2002 4:42 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JMX on the client side? > I think James had more esoteric plans... > > -danch > Right.. I'm not talking about Jboss proper, I'm speaking of a rich client platform that uses jboss as its service arch kernel. Imagine a world where jboss is installed everywhere - client and server. ;) James --- 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 --- 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
[JBoss-dev] [ jboss-Bugs-630665 ] CMR within one transaction
Bugs item #630665, was opened at 2002-10-29 13:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=630665&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Leon Doud (ldoud) Assigned to: Nobody/Anonymous (nobody) Summary: CMR within one transaction Initial Comment: When two objects are created in the same transaction setting a relation between these objects fails. There is no exception given, but the foreign key is NULL. The test case submitted uses one session bean with two almost identical methods. The only difference is that one method has the transaction type of "Required" and the other has a type of "NotSupported". The test case for the required transaction fails, while the other test case passes. This test only covers one-to-many bidirectional relationships. It was tested against the latest CVS code for Branch_3_0, using Windows 2000 and JDK 1.4.0. -- >Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-08 16:20 Message: Logged In: YES user_id=251431 A primitive int is not allowed for a primary key. The spec requires an Object, as the primary key is returned from a method that returns an Object. The verifier should have thrown an error. Did you turn off the verifier? If not, this is a verifier bug. -- Comment By: Alexey Loubyansky (loubyansky) Date: 2002-11-08 15:50 Message: Logged In: YES user_id=543482 I don't understand why it works for NotSupported. The problem is that, you are using 'int' for primary key with zero value. Currently, foreign keys can't be 'NOT NULL'. On the other hand, 'int' can't be null, so null equivalent is 0. Thus, relationships are not set. Try the following: 1. use int for pk but non-zero values; 2. use java.lang.Integer instead of int. alex -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=630665&group_id=22866 --- 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
[JBoss-dev] [ jboss-Bugs-619969 ] SQL Server substring syntax is wrong
Bugs item #619969, was opened at 2002-10-08 01:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=619969&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Vinh Nguyen (softwaremasters) Assigned to: Nobody/Anonymous (nobody) Summary: SQL Server substring syntax is wrong Initial Comment: The function mapping for substring for SQL Server (both 7 and 2K) in standardjbosscmp-jdbc.xml is currently: substring(?1 FROM ?2 FOR ?3) This is incorrect. The correct syntax for the substring function is: substring(?1, ?2, ?3) -- Comment By: Stephen Coy (scoy) Date: 2002-11-01 01:43 Message: Logged In: YES user_id=463096 This is fixed in HEAD, Branch_3_2 and Branch_3_0. It can be closed. For prosperity, the previously mentioned URL is: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=619969&; group_id=22866 -- Comment By: Stephen Coy (scoy) Date: 2002-10-31 09:48 Message: Logged In: YES user_id=463096 Jeremy Boynes just sent us a URL confirming the bug. I'll fix it and check it in in the next day or so, -- Comment By: Stephen Coy (scoy) Date: 2002-10-31 09:02 Message: Logged In: YES user_id=463096 My reference "SQL in a Nutshell" (O'Reilly) says otherwise. Can you provide some other documentary evidence of this? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=619969&group_id=22866 --- 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] Customizing JBoss server configurations
I checked in four files: build/etc/lego/lego.xml build/etc/lego/lego.properties server/src/etc/conf/default/jboss-server.lego messaging/src/etc/server/default/deploy/jbossmq-service.lego As I said, lego.xml is supposed to define a bunch of targets for different pluggable features, like "transaction-manager", "jbossmq" and so on. Each of targets "knows" what other features it depends on, what files are required and what configuration files has to be altered to enable the feature. After that you can define specialized server configuration by enumeration required features. For example, I've defined "ssb-mdb-xaoracle" server that supports SSB's, MDB's (with jbossmq) and oracle xa datasource. PS: if it looks like complete waste of time and effort, let me know and I delete it. Igor Fedorenko wrote: I meant to say ant's *buildfile*. Sorry for confusion. Igor Fedorenko wrote: It's an *ant* script. Nothing fancy, though, just a bunch of targets that move stuff from "all" to your new config and modify *-sevice.xml files if needed using ant's "replace" task. I'll check it in today. Bill Burke wrote: Yes that is a great idea. What kind of script? sh, perl, python, java, ?? I've done the same for the CD subscription but using InstallAnywhere. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Igor Fedorenko Sent: Wednesday, November 06, 2002 5:07 PM To: jboss-development Subject: [JBoss-dev] Customizing JBoss server configurations Hi, I've created an ant script that allows easy creation of custom jboss server configurations (other then all, default and minimal). Basically, it defines a bunch of targets like "jbossmq", "transaction-manager" and alike from which you can assemble your own unique server. I am using this script to reduce amount of resource used by jboss by removing services that are not used to my app but I can see other usages as well. Of course, this script is far from being complete but if it sounds like a good idea I can put it somewhere so people can start using/improving it. Thoughts? -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- 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
[JBoss-dev] [ jboss-Bugs-630665 ] CMR within one transaction
Bugs item #630665, was opened at 2002-10-29 21:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=630665&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Leon Doud (ldoud) Assigned to: Nobody/Anonymous (nobody) Summary: CMR within one transaction Initial Comment: When two objects are created in the same transaction setting a relation between these objects fails. There is no exception given, but the foreign key is NULL. The test case submitted uses one session bean with two almost identical methods. The only difference is that one method has the transaction type of "Required" and the other has a type of "NotSupported". The test case for the required transaction fails, while the other test case passes. This test only covers one-to-many bidirectional relationships. It was tested against the latest CVS code for Branch_3_0, using Windows 2000 and JDK 1.4.0. -- >Comment By: Alexey Loubyansky (loubyansky) Date: 2002-11-08 23:50 Message: Logged In: YES user_id=543482 I don't understand why it works for NotSupported. The problem is that, you are using 'int' for primary key with zero value. Currently, foreign keys can't be 'NOT NULL'. On the other hand, 'int' can't be null, so null equivalent is 0. Thus, relationships are not set. Try the following: 1. use int for pk but non-zero values; 2. use java.lang.Integer instead of int. alex -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=630665&group_id=22866 --- 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] JMX on the client side?
> I think James had more esoteric plans... > > -danch > Right.. I'm not talking about Jboss proper, I'm speaking of a rich client platform that uses jboss as its service arch kernel. Imagine a world where jboss is installed everywhere - client and server. ;) James --- 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] 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
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 8-November-2002
Number of tests run: 991
Successful tests: 985
Errors:5
Failures: 1
[time of test: 8 November 2002 12:55 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1_03-69]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.2.1]
See http://lubega.com/testarchive/${build.uid} 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!
---
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] JMX on the client side?
In my company we have the requirement for client pcs doing accounting in production environments. They could sample their data to a local jboss server with a hypersonic db and an message driven data synchronization mechanism. Some months ago somebody posted on jboss-dev about his success starting even the swing dialogs as mbeans under 3.0. I think that even a normal swing gui client is as ressource consuming as a small jboss server installation "out of the box", so this should not be a problem for most of our use cases. Isn't "a jboss for every client" the ultimate HA environment? Regards, Michael Bartmann www.4production.de Dain Sundstrom wrote: Yep, these are the technical issues. We should be able to code around them, but it may be challenging. I am really interested in what everyone else thinks. Is this a good idea? Should we look at it for 4.0? -dain James Higginbotham wrote: That would be interesting. I've really wanted to put together a rich client framework using jboss as the kernel for adding services and hotdeploying client functionality, but haven't had the time. Just something to think about: what happens if you do this and I want my app to start a kernel - what sort of classloader implications are there - could I end up with 2 kernels in the same VM? Just a thought.. This would rock! James -Original Message- From: Dain Sundstrom [mailto:dain@;daingroup.com] Sent: Friday, November 08, 2002 11:25 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMX on the client side? Yes that is exactly what I am suggesting. When you first contact the JBoss server we start an MBeanServer if non is available. I think we may have problems if we use features specific to the JBoss JMX code (like not having huge bugs), but that is a discussion for another day. -dain James Higginbotham wrote: Interesting.. Are you guys talking about a small JMX container on the client invoker side? Or something else? -Original Message- From: David Jencks [mailto:davidjencks@;directvinternet.com] Sent: Thursday, November 07, 2002 10:12 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMX on the client side? +1000 This will greatly simplify many things, such as the trunk invoker client. I'd like to suggest that we also consider basing UserTransaction on a transaction manager instance on the client: this would allow UserTransaction to use the same propagation mechanism as distributed transactions (shipping xids). Again, this would be easy with jmx on the client. Setting everything up without jmx would be considerably more difficult. david jencks On 2002.11.07 22:33:57 -0500 Dain Sundstrom wrote: Why don't we require jmx on the client side? I bet it takes almost no memory and it has a small jar size. If do require it on the client side, we can reuse all the services we are building on the server, like a jcache mbean. It would also simply server to client messages, which will be used for cache invalidations and jms messages. This is because we can reuse the invoker architecture. There will still be a problem with socket back channels to clients on the other side of a firewall, but we would get a ton of reuse and simplification. -dain --- 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 --- 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 --- 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 -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- 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 --- This sf.net email
RE: [JBoss-dev] JMX on the client side?
> Is this a good idea? Should we look at it for 4.0? 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... - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Friday, November 08, 2002 3:29 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMX on the client side? Yep, these are the technical issues. We should be able to code around them, but it may be challenging. I am really interested in what everyone else thinks. Is this a good idea? Should we look at it for 4.0? -dain James Higginbotham wrote: > That would be interesting. I've really wanted to put together a rich > client framework using jboss as the kernel for adding services and > hotdeploying client functionality, but haven't had the time. Just > something to think about: what happens if you do this and I want my app > to start a kernel - what sort of classloader implications are there - > could I end up with 2 kernels in the same VM? Just a thought.. > > This would rock! > James > > >>-Original Message- >>From: Dain Sundstrom [mailto:dain@;daingroup.com] >>Sent: Friday, November 08, 2002 11:25 AM >>To: [EMAIL PROTECTED] >>Subject: Re: [JBoss-dev] JMX on the client side? >> >> >>Yes that is exactly what I am suggesting. When you first contact the >>JBoss server we start an MBeanServer if non is available. I think we >>may have problems if we use features specific to the JBoss JMX code >>(like not having huge bugs), but that is a discussion for another day. >> >>-dain >> >>James Higginbotham wrote: >> >>>Interesting.. Are you guys talking about a small JMX >> >>container on the >> >>>client invoker side? Or something else? >>> >>> >>> -Original Message- From: David Jencks [mailto:davidjencks@;directvinternet.com] Sent: Thursday, November 07, 2002 10:12 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMX on the client side? +1000 This will greatly simplify many things, such as the trunk invoker client. I'd like to suggest that we also consider basing UserTransaction on a transaction manager instance on the client: this would allow UserTransaction to use the same propagation mechanism as distributed transactions (shipping xids). Again, this would be easy with jmx on the client. Setting everything up without jmx would be considerably more difficult. david jencks On 2002.11.07 22:33:57 -0500 Dain Sundstrom wrote: >Why don't we require jmx on the client side? > >I bet it takes almost no memory and it has a small jar >>size. If do >> >require it on the client side, we can reuse all the >>services we are >> >building on the server, like a jcache mbean. It would also simply >server to client messages, which will be used for cache invalidations >and jms messages. This is because we can reuse the invoker >architecture. There will still be a problem with socket back channels >to clients on the other side of a firewall, but we would get a ton of >reuse and simplification. > >-dain > > > >--- >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 > > --- 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 >>> >>> >>>--- >>>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 >> >> >>-- >> >>Dain Sundstrom >>Chief Architect JBossCMP >>JBoss Group, LLC
Re: [JBoss-dev] JMX on the client side?
Yep, these are the technical issues. We should be able to code around them, but it may be challenging. I am really interested in what everyone else thinks. Is this a good idea? Should we look at it for 4.0? -dain James Higginbotham wrote: That would be interesting. I've really wanted to put together a rich client framework using jboss as the kernel for adding services and hotdeploying client functionality, but haven't had the time. Just something to think about: what happens if you do this and I want my app to start a kernel - what sort of classloader implications are there - could I end up with 2 kernels in the same VM? Just a thought.. This would rock! James -Original Message- From: Dain Sundstrom [mailto:dain@;daingroup.com] Sent: Friday, November 08, 2002 11:25 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMX on the client side? Yes that is exactly what I am suggesting. When you first contact the JBoss server we start an MBeanServer if non is available. I think we may have problems if we use features specific to the JBoss JMX code (like not having huge bugs), but that is a discussion for another day. -dain James Higginbotham wrote: Interesting.. Are you guys talking about a small JMX container on the client invoker side? Or something else? -Original Message- From: David Jencks [mailto:davidjencks@;directvinternet.com] Sent: Thursday, November 07, 2002 10:12 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMX on the client side? +1000 This will greatly simplify many things, such as the trunk invoker client. I'd like to suggest that we also consider basing UserTransaction on a transaction manager instance on the client: this would allow UserTransaction to use the same propagation mechanism as distributed transactions (shipping xids). Again, this would be easy with jmx on the client. Setting everything up without jmx would be considerably more difficult. david jencks On 2002.11.07 22:33:57 -0500 Dain Sundstrom wrote: Why don't we require jmx on the client side? I bet it takes almost no memory and it has a small jar size. If do require it on the client side, we can reuse all the services we are building on the server, like a jcache mbean. It would also simply server to client messages, which will be used for cache invalidations and jms messages. This is because we can reuse the invoker architecture. There will still be a problem with socket back channels to clients on the other side of a firewall, but we would get a ton of reuse and simplification. -dain --- 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 --- 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 --- 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 -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- 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 --- 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 -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- 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-dev] Off topic: Never use Expedia
I just thought I would warn everyone. At the JBoss Group we do a lot of travel, and most of it we book through expedia.com. Recently expedia changed their site to prepaid hotels. They make that claim that they give you a special rate, but the rate is not special. The problem is if you need to change your travel plans and leave early, they will not refund any un used days. This only cost me $100, but it could have been more. I talked with expedia and they refused to refund that $100 so I will never be using them again, and I suggest you don't. The manager at the hotel I stayed at recommends hotels.com as it is easy to change reservations, and I will be checking them out next time. Ok, I'm done ranting now. -dain --- 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] JMX on the client side?
That would be interesting. I've really wanted to put together a rich client framework using jboss as the kernel for adding services and hotdeploying client functionality, but haven't had the time. Just something to think about: what happens if you do this and I want my app to start a kernel - what sort of classloader implications are there - could I end up with 2 kernels in the same VM? Just a thought.. This would rock! James > -Original Message- > From: Dain Sundstrom [mailto:dain@;daingroup.com] > Sent: Friday, November 08, 2002 11:25 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JMX on the client side? > > > Yes that is exactly what I am suggesting. When you first contact the > JBoss server we start an MBeanServer if non is available. I think we > may have problems if we use features specific to the JBoss JMX code > (like not having huge bugs), but that is a discussion for another day. > > -dain > > James Higginbotham wrote: > > Interesting.. Are you guys talking about a small JMX > container on the > > client invoker side? Or something else? > > > > > >>-Original Message- > >>From: David Jencks [mailto:davidjencks@;directvinternet.com] > >>Sent: Thursday, November 07, 2002 10:12 PM > >>To: [EMAIL PROTECTED] > >>Subject: Re: [JBoss-dev] JMX on the client side? > >> > >> > >>+1000 > >> > >>This will greatly simplify many things, such as the trunk > >>invoker client. > >> > >>I'd like to suggest that we also consider basing > >>UserTransaction on a transaction manager instance on the > >>client: this would allow UserTransaction to use the same > >>propagation mechanism as distributed transactions (shipping > >>xids). Again, this would be easy with jmx on the client. > >>Setting everything up without jmx would be considerably more > >>difficult. > >> > >>david jencks > >> > >>On 2002.11.07 22:33:57 -0500 Dain Sundstrom wrote: > >> > >>>Why don't we require jmx on the client side? > >>> > >>>I bet it takes almost no memory and it has a small jar > size. If do > >>>require it on the client side, we can reuse all the > services we are > >>>building on the server, like a jcache mbean. It would also simply > >>>server to client messages, which will be used for cache > >> > >>invalidations > >> > >>>and jms messages. This is because we can reuse the invoker > >>>architecture. There will still be a problem with socket > >> > >>back channels > >> > >>>to clients on the other side of a firewall, but we would > >> > >>get a ton of > >> > >>>reuse and simplification. > >>> > >>>-dain > >>> > >>> > >>> > >>>--- > >>>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 > >>> > >>> > >> > >> > >>--- > >>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 > > > > > > --- > > 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 > > > -- > > Dain Sundstrom > Chief Architect JBossCMP > JBoss Group, LLC > > > > > --- > 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 > --- 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] JMS Starup Behavior
Add the check. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Aaron Lindsey" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, November 08, 2002 8:36 AM Subject: [JBoss-dev] JMS Starup Behavior > Hello everyone, > I think there's a bug in the jdbc2 PersistenceManager, but I want to verify > that it's not a feature before fixing it. At startup, if you already have > the database tables present, and have not set the CREATE_TABLES_ON_STARTUP > property to false, an exception is thrown (on Postgres at least). From a > clean install, you basically have to start jboss, stop jboss, add the flag > and set it to false and then restart. After that everything is okay. So, > does anybody have a problem with me putting in checks at startup to see if > tables already exist before creating them? > > Aaron > > > --- > 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 > --- 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] JBoss.net and performance tuning
CGJ,
> Discuss this when I come back, ok? It´s crucial and your measures should
> help a lot in that respect.
Sure. Enjoy your time off :) . FWIW, I am not seeing a significant
improvment w/ Axis + Tomcat (no JBoss) either, so I am guessing that axis
itself is the primary bottleneck...
- Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Jung
, Dr. Christoph
Sent: Friday, November 08, 2002 12:54 PM
To: '[EMAIL PROTECTED]'
Subject: AW: [JBoss-dev] JBoss.net and performance tuning
Matt,
Currently we just do prototyping with the stuff, no profiling at all. I´m
away three weeks for holiday. Let us
Discuss this when I come back, ok? It´s crucial and your measures should
help a lot in that respect.
CGJ
-Ursprüngliche Nachricht-
Von: Matt Munz [mailto:mmunz@;apelon.com]
Gesendet: Freitag, 1. November 2002 18:14
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] JBoss.net and performance tuning
hi again,
Anybody out there working on or using JBoss.net?
Attached are some files I'm using to test, in a very simplistic way, the
performance of jmx.net.
My current timing so far is on average .3 seconds to complete the simplest
possible transaction (as far as I can tell) -- returning a very short string
object.
Does this number sound reasonable? If so, what are you using JBoss.Net
for? Perhaps I have the wrong idea...
Not included in the archive is the class JmxNetProxy, which is a delegate
for the mechanism used in the JBoss.Net test cases. Here's the relevant
method from that class.
public Object invoke(String webServiceName, String mbeanServiceName,
String methodName,
Object[] arguments, Class[] classes)
throws Exception
{
...
MBeanInvocationHandler handler;
handler = createMBeanInvocationHandler(target);
return handler.invoke(mbeanServiceName,
methodName,
arguments,
classes); // classes
}
Any comment would be greatly appreciated.
- Matt ([EMAIL PROTECTED])
-Original Message-
From: [EMAIL PROTECTED]
[mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Matt Munz
Sent: Thursday, October 31, 2002 11:17 AM
To: JBoss Developers Group
Subject: [JBoss-dev] JBoss.net and performance tuning
CGJ and JBoss.net guys,
My fledgeling JBoss.net enabled application is growing up and it needs
some performance enhancements. Particularly, Marshalling/Unmarshalling
appears to take significantly longer than expected.
Here's my setup.
1) I'm using the JMX.net proxy classes used in the test cases.
2) I am working with short, frequent transactions.
3) I am using the bean serializer to send simple custom objects across the
wire.
4) On the server side, an MBean is the recipient of the request.
RE: #1 -- Would WSDL2Java be any faster? Is MBean to wsdl generation
working yet?
RE: #2 -- I know, course-grained transactions are preferred, but are they
required? My objects are small, almost tiny. How fast can a transaction
be? If I can get it under .05 seconds, this should suffice for the moment.
RE: #3 -- Any tips / tricks here? Would switiching to primitives and
Strings be markedly faster?
Any help would be greatly appreciated. Links to benchmarks / performance
tests would help too.
- Matt
---
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
###
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/
---
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
---
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
[JBoss-dev] JMS Starup Behavior
Hello everyone, I think there's a bug in the jdbc2 PersistenceManager, but I want to verify that it's not a feature before fixing it. At startup, if you already have the database tables present, and have not set the CREATE_TABLES_ON_STARTUP property to false, an exception is thrown (on Postgres at least). From a clean install, you basically have to start jboss, stop jboss, add the flag and set it to false and then restart. After that everything is okay. So, does anybody have a problem with me putting in checks at startup to see if tables already exist before creating them? Aaron --- 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
AW: [JBoss-dev] jboss.net status
Title: Nachricht 3.0 is still a beta version 3.2 should be rc1 head will be release 1 when I manage to checkin the stuff over the weekend. I´m going on holidays for the next three weeks, so no promise on that. But I´ll try. CGJ -Ursprüngliche Nachricht-Von: Finn, Michael [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 31. Oktober 2002 15:55An: Jboss-Development-List (E-mail)Betreff: [JBoss-dev] jboss.net status Guys, Quick question - what is the status of jboss.net WRT Axis 1.0 in: - 3.0 branch? - 3.2 branch? - HEAD? Is Axis 1.0 GA supported anywhere yet? TIA, Mike ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/
AW: [JBoss-dev] JBoss.net and performance tuning
Matt,
Currently we just do prototyping with the stuff, no profiling at all. I´m
away three weeks for holiday. Let us
Discuss this when I come back, ok? It´s crucial and your measures should
help a lot in that respect.
CGJ
-Ursprüngliche Nachricht-
Von: Matt Munz [mailto:mmunz@;apelon.com]
Gesendet: Freitag, 1. November 2002 18:14
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] JBoss.net and performance tuning
hi again,
Anybody out there working on or using JBoss.net?
Attached are some files I'm using to test, in a very simplistic way, the
performance of jmx.net.
My current timing so far is on average .3 seconds to complete the simplest
possible transaction (as far as I can tell) -- returning a very short string
object.
Does this number sound reasonable? If so, what are you using JBoss.Net
for? Perhaps I have the wrong idea...
Not included in the archive is the class JmxNetProxy, which is a delegate
for the mechanism used in the JBoss.Net test cases. Here's the relevant
method from that class.
public Object invoke(String webServiceName, String mbeanServiceName,
String methodName,
Object[] arguments, Class[] classes)
throws Exception
{
...
MBeanInvocationHandler handler;
handler = createMBeanInvocationHandler(target);
return handler.invoke(mbeanServiceName,
methodName,
arguments,
classes); // classes
}
Any comment would be greatly appreciated.
- Matt ([EMAIL PROTECTED])
-Original Message-
From: [EMAIL PROTECTED]
[mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Matt Munz
Sent: Thursday, October 31, 2002 11:17 AM
To: JBoss Developers Group
Subject: [JBoss-dev] JBoss.net and performance tuning
CGJ and JBoss.net guys,
My fledgeling JBoss.net enabled application is growing up and it needs
some performance enhancements. Particularly, Marshalling/Unmarshalling
appears to take significantly longer than expected.
Here's my setup.
1) I'm using the JMX.net proxy classes used in the test cases.
2) I am working with short, frequent transactions.
3) I am using the bean serializer to send simple custom objects across the
wire.
4) On the server side, an MBean is the recipient of the request.
RE: #1 -- Would WSDL2Java be any faster? Is MBean to wsdl generation
working yet?
RE: #2 -- I know, course-grained transactions are preferred, but are they
required? My objects are small, almost tiny. How fast can a transaction
be? If I can get it under .05 seconds, this should suffice for the moment.
RE: #3 -- Any tips / tricks here? Would switiching to primitives and
Strings be markedly faster?
Any help would be greatly appreciated. Links to benchmarks / performance
tests would help too.
- Matt
---
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
###
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/
---
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] JMX on the client side?
Yes that is exactly what I am suggesting. When you first contact the JBoss server we start an MBeanServer if non is available. I think we may have problems if we use features specific to the JBoss JMX code (like not having huge bugs), but that is a discussion for another day. -dain James Higginbotham wrote: Interesting.. Are you guys talking about a small JMX container on the client invoker side? Or something else? -Original Message- From: David Jencks [mailto:davidjencks@;directvinternet.com] Sent: Thursday, November 07, 2002 10:12 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMX on the client side? +1000 This will greatly simplify many things, such as the trunk invoker client. I'd like to suggest that we also consider basing UserTransaction on a transaction manager instance on the client: this would allow UserTransaction to use the same propagation mechanism as distributed transactions (shipping xids). Again, this would be easy with jmx on the client. Setting everything up without jmx would be considerably more difficult. david jencks On 2002.11.07 22:33:57 -0500 Dain Sundstrom wrote: Why don't we require jmx on the client side? I bet it takes almost no memory and it has a small jar size. If do require it on the client side, we can reuse all the services we are building on the server, like a jcache mbean. It would also simply server to client messages, which will be used for cache invalidations and jms messages. This is because we can reuse the invoker architecture. There will still be a problem with socket back channels to clients on the other side of a firewall, but we would get a ton of reuse and simplification. -dain --- 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 --- 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 --- 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 -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- 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
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version "1.3.1_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01) Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE Generating output for 'org.jboss.deployment.scanner.URLDirectoryScanner' using template file 'jar:file:/disk/orig/home/lubega/jbossro/jboss-all/thirdparty/xdoclet-xdoclet/lib/xdoclet-jmx-module.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. Generating output for 'org.jboss.deployment.XSLSubDeployer' using template file 'jar:file:/disk/orig/home/lubega/jbossro/jboss-all/thirdparty/xdoclet-xdoclet/lib/xdoclet-jmx-module.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. Generating output for 'org.jboss.system.component.Component' using template file 'jar:file:/disk/orig/home/lubega/jbossro/jboss-all/thirdparty/xdoclet-xdoclet/lib/xdoclet-jmx-module.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. Generating output for 'org.jboss.system.server.ServerConfigImpl' using template file 'jar:file:/disk/orig/home/lubega/jbossro/jboss-all/thirdparty/xdoclet-xdoclet/lib/xdoclet-jmx-module.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. INFO:Some classes refer to other classes that were not found among the sources or on the classpath. (Perhaps the referred class doesn't exist? Hasn't been generated yet?) The referring classes do not import any fully qualified classes matching these classes. However, since no packages are imported, xjavadoc has assumed that the referred classes belong to the same package as the referring class. The classes are: org.jboss.deployment.ClasspathExtension --> ClasspathExtensionMBean qualified to ClasspathExtensionMBean org.jboss.deployment.DeploymentInfo --> DeploymentInfoMBean qualified to DeploymentInfoMBean org.jboss.deployment.DeploymentInfoDocumentURIResolver --> DeploymentInfoDocumentURIResolverMBean qualified to DeploymentInfoDocumentURIResolverMBean org.jboss.deployment.JARDeployer --> JARDeployerMBean qualified to JARDeployerMBean org.jboss.deployment.SubDeployerSupport --> SubDeployerMBean qualified to SubDeployerMBean org.jboss.deployment.MainDeployer --> MainDeployerMBean qualified to MainDeployerMBean org.jboss.deployment.SARDeployer --> SARDeployerMBean qualified to SARDeployerMBean org.jboss.deployment.XSLSubDeployer --> XSLSubDeployerMBean qualified to XSLSubDeployerMBean org.jboss.deployment.cache.DeploymentCache --> DeploymentCacheMBean qualified to DeploymentCacheMBean org.jboss.deployment.cache.FileDeploymentStore --> FileDeploymentStoreMBean qualified to FileDeploymentStoreMBean org.jboss.deployment.scanner.AbstractDeploymentScanner --> DeploymentScannerMBean qualified to DeploymentScannerMBean org.jboss.deployment.scanner.HttpURLDeploymentScanner --> HttpURLDeploymentScannerMBean qualified to HttpURLDeploymentScannerMBean org.jboss.deployment.scanner.URLDeploymentScanner --> URLDeploymentScannerMBean qualified to URLDeploymentScannerMBean org.jboss.deployment.scanner.URLDirectoryScanner --> URLDirectoryScannerMBean qualified to URLDirectoryScannerMBean org.jboss.system.ServiceController --> ServiceControllerMBean qualified to ServiceControllerMBean org.jboss.system.component.Component --> ComponentMBean qualified to ComponentMBean org.jboss.system.component.Container --> ContainerMBean qualified to ContainerMBean org.jboss.system.server.ServerConfigImpl --> ServerConfigImplMBean qualified to ServerConfigImplMBean org.jboss.system.server.ServerImpl --> ServerImplMBean qualified to ServerImplMBean org.jboss.system.server.ServerInfo --> ServerInfoMBean qualified to ServerInfoMBean _default:compile-classes: [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/system/output/classes [depend] Deleted 0 out of date files in 0 seconds [javac] Compiling 76 source files to /disk/orig/home/lubega/jbossro/jboss-all/system/output/classes /disk/orig/home/lubega/jbossro/jboss-all/system/src/main/org/jboss/deployment/NetBootHelper.java:145: encode(java.lang.String) in java.net.URLEncoder cannot be applied to (java.lang.String,java.lang.String) return listUrl + "dir=" + java.net.URLEncoder.encode (directory, "UTF-8"); ^ /disk/orig/home/lubega/jbossro/jboss-all/system/src/main/org/jboss/system/ORBSingleton.java:160: warning: create_recursive_sequence_tc(int,int) in org.omg.CORBA.ORB has been deprecated public TypeCode create_recursive_sequence_tc(int bound, int offset) ^ /disk/orig/home/lubega/jbossro/jboss-all/system/src/main/org/jboss/system/ORBSingleton.java:273: warning: get_current() in org.omg.CORBA.ORB has been deprecated publi
RE: [JBoss-dev] JMX on the client side?
Interesting.. Are you guys talking about a small JMX container on the client invoker side? Or something else? > -Original Message- > From: David Jencks [mailto:davidjencks@;directvinternet.com] > Sent: Thursday, November 07, 2002 10:12 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JMX on the client side? > > > +1000 > > This will greatly simplify many things, such as the trunk > invoker client. > > I'd like to suggest that we also consider basing > UserTransaction on a transaction manager instance on the > client: this would allow UserTransaction to use the same > propagation mechanism as distributed transactions (shipping > xids). Again, this would be easy with jmx on the client. > Setting everything up without jmx would be considerably more > difficult. > > david jencks > > On 2002.11.07 22:33:57 -0500 Dain Sundstrom wrote: > > Why don't we require jmx on the client side? > > > > I bet it takes almost no memory and it has a small jar size. If do > > require it on the client side, we can reuse all the services we are > > building on the server, like a jcache mbean. It would also simply > > server to client messages, which will be used for cache > invalidations > > and jms messages. This is because we can reuse the invoker > > architecture. There will still be a problem with socket > back channels > > to clients on the other side of a firewall, but we would > get a ton of > > reuse and simplification. > > > > -dain > > > > > > > > --- > > 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 > > > > > > > --- > 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 --- 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] Files looked on my fs from clean co
fredagen den 8 november 2002 kl 15.07 skrev Chris Kimpton: What is "looked" lock'ed --- 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] Files looked on my fs from clean co
Hi, Sorry - don't quite understand - "come as looked" ? What is "looked"? Chris --- Peter Fagerlund <[EMAIL PROTECTED]> wrote: > when I cvs co jboss-head they come as looked ? is this a cvs thingy > ? > > /peter_f > > > > --- > 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 = __ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 --- 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
[JBoss-dev] Files looked on my fs from clean co
when I cvs co jboss-head they come as looked ? is this a cvs thingy ? /peter_f --- 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
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
org.jboss.varia.counter.CounterInterceptor --> AbstractInterceptor qualified to
AbstractInterceptor
_default:compile-classes:
[mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/varia/output/classes
[depend] Deleted 0 out of date files in 0 seconds
[javac] Compiling 86 source files to
/disk/orig/home/lubega/jbossro/jboss-all/varia/output/classes
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_ServerConnection.java:89:
cannot resolve symbol
symbol : class Channel
location: class org.hsqldb.Embedded_ServerConnection
private Channel init() {
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_DatabaseManager.java:438:
work(java.lang.String[]) in org.hsqldb.util.Transfer cannot be applied to ()
Transfer.work();
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_DatabaseManager.java:440:
warning: setLogStream(java.io.PrintStream) in java.sql.DriverManager has been
deprecated
DriverManager.setLogStream(System.out);
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_DatabaseManager.java:442:
warning: setLogStream(java.io.PrintStream) in java.sql.DriverManager has been
deprecated
DriverManager.setLogStream(null);
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_Server.java:130:
cannot resolve symbol
symbol : variable DEFAULT_HSQL_PORT
location: class org.hsqldb.jdbcConnection
port = jdbcConnection.DEFAULT_HSQL_PORT;
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_Server.java:140:
warning: setLogStream(java.io.PrintStream) in java.sql.DriverManager has been
deprecated
DriverManager.setLogStream(System.out);
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_ServerConnection.java:100:
cannot resolve symbol
symbol : class Channel
location: class org.hsqldb.Embedded_ServerConnection
Channel c;
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_ServerConnection.java:107:
cannot resolve symbol
symbol : constructor Result (java.lang.String)
location: class org.hsqldb.Result
write(new Result(e.getMessage()).getBytes());
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_ServerConnection.java:119:
cannot resolve symbol
symbol : class Channel
location: class org.hsqldb.Embedded_ServerConnection
Channel c = init();
^
6 errors
3 warnings
BUILD FAILED
file:/disk/orig/home/lubega/jbossro/jboss-all/varia/../tools/etc/buildfragments/targets.ent:45:
Compile failed; see the compiler error output for details.
Total time: 4 minutes 35 seconds
---
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] [AUTOMATED] (HEAD) JBoss compilation failed
okey - I did not manage to rename/remove some files yesterday fixing now
fredagen den 8 november 2002 kl 11.19 skrev [EMAIL PROTECTED]:
=
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR
DETAILS=
=
JAVA VERSION DETAILS
java version "1.3.1_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01)
Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode)
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
org.jboss.varia.counter.CounterInterceptor --> AbstractInterceptor
qualified to AbstractInterceptor
_default:compile-classes:
[mkdir] Created dir:
/home/jboss/jbossci/jboss-all/varia/output/classes
[depend] Deleted 0 out of date files in 0 seconds
[javac] Compiling 86 source files to
/home/jboss/jbossci/jboss-all/varia/output/classes
/home/jboss/jbossci/jboss-all/varia/src/main/org/hsqldb/1.6.1/
Embedded_ServerConnection.java:89: cannot resolve symbol
symbol : class Channel
location: class org.hsqldb.Embedded_ServerConnection
private Channel init() {
^
/home/jboss/jbossci/jboss-all/varia/src/main/org/hsqldb/1.6.1/
Embedded_DatabaseManager.java:438: work(java.lang.String[]) in
org.hsqldb.util.Transfer cannot be applied to ()
Transfer.work();
^
/home/jboss/jbossci/jboss-all/varia/src/main/org/hsqldb/1.6.1/
Embedded_DatabaseManager.java:440: warning:
setLogStream(java.io.PrintStream) in java.sql.DriverManager has been
deprecated
DriverManager.setLogStream(System.out);
^
/home/jboss/jbossci/jboss-all/varia/src/main/org/hsqldb/1.6.1/
Embedded_DatabaseManager.java:442: warning:
setLogStream(java.io.PrintStream) in java.sql.DriverManager has been
deprecated
DriverManager.setLogStream(null);
^
/home/jboss/jbossci/jboss-all/varia/src/main/org/hsqldb/1.6.1/
Embedded_Server.java:130: cannot resolve symbol
symbol : variable DEFAULT_HSQL_PORT
location: class org.hsqldb.jdbcConnection
port = jdbcConnection.DEFAULT_HSQL_PORT;
^
/home/jboss/jbossci/jboss-all/varia/src/main/org/hsqldb/1.6.1/
Embedded_Server.java:140: warning: setLogStream(java.io.PrintStream)
in java.sql.DriverManager has been deprecated
DriverManager.setLogStream(System.out);
^
/home/jboss/jbossci/jboss-all/varia/src/main/org/hsqldb/1.6.1/
Embedded_ServerConnection.java:100: cannot resolve symbol
symbol : class Channel
location: class org.hsqldb.Embedded_ServerConnection
Channel c;
^
/home/jboss/jbossci/jboss-all/varia/src/main/org/hsqldb/1.6.1/
Embedded_ServerConnection.java:107: cannot resolve symbol
symbol : constructor Result (java.lang.String)
location: class org.hsqldb.Result
write(new Result(e.getMessage()).getBytes());
^
/home/jboss/jbossci/jboss-all/varia/src/main/org/hsqldb/1.6.1/
Embedded_ServerConnection.java:119: cannot resolve symbol
symbol : class Channel
location: class org.hsqldb.Embedded_ServerConnection
Channel c = init();
^
6 errors
3 warnings
BUILD FAILED
file:/home/jboss/jbossci/jboss-all/varia/../tools/etc/buildfragments/
targets.ent:45: Compile failed; see the compiler error output for
details.
Total time: 2 minutes 18 seconds
---
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
---
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
[JBoss-dev] [ jboss-Change Notes-635435 ] hsqldb 1.7.1 issues
Change Notes item #635435, was opened at 2002-11-08 11:42
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=381174&aid=635435&group_id=22866
Category: JBossServer
Group: v4.0
Status: Open
Priority: 5
Submitted By: Peter Fagerlund (peter_f)
Assigned to: Nobody/Anonymous (nobody)
Summary: hsqldb 1.7.1 issues
Initial Comment:
The new hsqldb.jar is vanilla distro with a commented out //
System.exit() in method windowClosing() in file
org.hsqldb.util.DatabaseManagerSwing
Configuration changes includes 2 new fields in our MBean
definition as can be seen for ex. in the hsqldb-ds.xml file.
true
Is 1.7.x configuration property for embedding
true
Is a new flag with default set to true together with jdbc:hsqldb:hsql://localhost:1710
meaning We will start an instance of the org.hsqldb.Server class
in a thread as usual. If set to false together with
jdbc:hsqldb:hsql:. We will run hsqldb without the
server instance above, and We will not be persistent over
invocations. Set to false means running without Sockets so
hsqldb are only visible for other components inside the VM, also
hsqldb are not writing out to a *.script file. In short persist == false
means We are running without a threaded hsqldb server instance,
no sockets and no files, therefore no persistence over
invocations. Great when testing ...
"~Well~" that is what is supposed to happen in teori, in practise
there is some issues running with persist false mentioned in the
hsqldb documentation.
*** Start hsqldb docu
In-Memory
URL format: jdbc:hsqldb:.
No persistence. An applet, for example, could have his very own
database running in his memory. There is no daemon. Database
uses no network resources.
For some reason, with in-memory database ".", sometimes you
get default data and sometimes you don't. You get the data with
QueryTool on the command-line, and with DatabaseManager from
Applet. Otherwise you get an empty database. file:/path/
to.file.html)
*** End hsqldb docu
huh ...
So now when running as persist == false We end up with the *
.script file in {JBOSS_HOME_DISTRO}/bin instead, and We do
persist over invocations ... hmmm ... very confusing ... hehe ... let
me get back to You after I asked for advise from the hsqldb team.
/peter_f
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=381174&aid=635435&group_id=22866
---
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
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
=
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS=
=
JAVA VERSION DETAILS
java version "1.3.1_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01)
Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode)
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
org.jboss.varia.counter.CounterInterceptor --> AbstractInterceptor qualified to
AbstractInterceptor
_default:compile-classes:
[mkdir] Created dir: /home/jboss/jbossci/jboss-all/varia/output/classes
[depend] Deleted 0 out of date files in 0 seconds
[javac] Compiling 86 source files to
/home/jboss/jbossci/jboss-all/varia/output/classes
/home/jboss/jbossci/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_ServerConnection.java:89:
cannot resolve symbol
symbol : class Channel
location: class org.hsqldb.Embedded_ServerConnection
private Channel init() {
^
/home/jboss/jbossci/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_DatabaseManager.java:438:
work(java.lang.String[]) in org.hsqldb.util.Transfer cannot be applied to ()
Transfer.work();
^
/home/jboss/jbossci/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_DatabaseManager.java:440:
warning: setLogStream(java.io.PrintStream) in java.sql.DriverManager has been
deprecated
DriverManager.setLogStream(System.out);
^
/home/jboss/jbossci/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_DatabaseManager.java:442:
warning: setLogStream(java.io.PrintStream) in java.sql.DriverManager has been
deprecated
DriverManager.setLogStream(null);
^
/home/jboss/jbossci/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_Server.java:130:
cannot resolve symbol
symbol : variable DEFAULT_HSQL_PORT
location: class org.hsqldb.jdbcConnection
port = jdbcConnection.DEFAULT_HSQL_PORT;
^
/home/jboss/jbossci/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_Server.java:140:
warning: setLogStream(java.io.PrintStream) in java.sql.DriverManager has been
deprecated
DriverManager.setLogStream(System.out);
^
/home/jboss/jbossci/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_ServerConnection.java:100:
cannot resolve symbol
symbol : class Channel
location: class org.hsqldb.Embedded_ServerConnection
Channel c;
^
/home/jboss/jbossci/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_ServerConnection.java:107:
cannot resolve symbol
symbol : constructor Result (java.lang.String)
location: class org.hsqldb.Result
write(new Result(e.getMessage()).getBytes());
^
/home/jboss/jbossci/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_ServerConnection.java:119:
cannot resolve symbol
symbol : class Channel
location: class org.hsqldb.Embedded_ServerConnection
Channel c = init();
^
6 errors
3 warnings
BUILD FAILED
file:/home/jboss/jbossci/jboss-all/varia/../tools/etc/buildfragments/targets.ent:45:
Compile failed; see the compiler error output for details.
Total time: 2 minutes 18 seconds
---
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
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version "1.3.1_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01)
Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode)
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
org.jboss.varia.counter.CounterInterceptor --> AbstractInterceptor qualified to
AbstractInterceptor
_default:compile-classes:
[mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/varia/output/classes
[depend] Deleted 0 out of date files in 0 seconds
[javac] Compiling 86 source files to
/disk/orig/home/lubega/jbossro/jboss-all/varia/output/classes
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_ServerConnection.java:89:
cannot resolve symbol
symbol : class Channel
location: class org.hsqldb.Embedded_ServerConnection
private Channel init() {
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_DatabaseManager.java:438:
work(java.lang.String[]) in org.hsqldb.util.Transfer cannot be applied to ()
Transfer.work();
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_DatabaseManager.java:440:
warning: setLogStream(java.io.PrintStream) in java.sql.DriverManager has been
deprecated
DriverManager.setLogStream(System.out);
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_DatabaseManager.java:442:
warning: setLogStream(java.io.PrintStream) in java.sql.DriverManager has been
deprecated
DriverManager.setLogStream(null);
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_Server.java:130:
cannot resolve symbol
symbol : variable DEFAULT_HSQL_PORT
location: class org.hsqldb.jdbcConnection
port = jdbcConnection.DEFAULT_HSQL_PORT;
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_Server.java:140:
warning: setLogStream(java.io.PrintStream) in java.sql.DriverManager has been
deprecated
DriverManager.setLogStream(System.out);
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_ServerConnection.java:100:
cannot resolve symbol
symbol : class Channel
location: class org.hsqldb.Embedded_ServerConnection
Channel c;
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_ServerConnection.java:107:
cannot resolve symbol
symbol : constructor Result (java.lang.String)
location: class org.hsqldb.Result
write(new Result(e.getMessage()).getBytes());
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_ServerConnection.java:119:
cannot resolve symbol
symbol : class Channel
location: class org.hsqldb.Embedded_ServerConnection
Channel c = init();
^
6 errors
3 warnings
BUILD FAILED
file:/disk/orig/home/lubega/jbossro/jboss-all/varia/../tools/etc/buildfragments/targets.ent:45:
Compile failed; see the compiler error output for details.
Total time: 4 minutes 37 seconds
---
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] [AUTOMATED] (HEAD) JBoss compilation failed
hehe ... just pushed the button for a clean checkout at lubega and it
even answers. Hopefully this will take care of it !
***
The next jboss rebuild will do a full cvs checkout - cool!
TIME NOW: Fri Nov 8 08:57:55 GMT 2002
fredagen den 8 november 2002 kl 09.19 skrev [EMAIL PROTECTED]:
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version "1.3.1_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01)
Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode)
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
org.jboss.varia.counter.CounterInterceptor --> AbstractInterceptor
qualified to AbstractInterceptor
_default:compile-classes:
[mkdir] Created dir:
/disk/orig/home/lubega/jbossro/jboss-all/varia/output/classes
[depend] Deleted 0 out of date files in 0 seconds
[javac] Compiling 86 source files to
/disk/orig/home/lubega/jbossro/jboss-all/varia/output/classes
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/
1.6.1/Embedded_ServerConnection.java:89: cannot resolve symbol
symbol : class Channel
location: class org.hsqldb.Embedded_ServerConnection
private Channel init() {
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/
1.6.1/Embedded_DatabaseManager.java:438: work(java.lang.String[]) in
org.hsqldb.util.Transfer cannot be applied to ()
Transfer.work();
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/
1.6.1/Embedded_DatabaseManager.java:440: warning:
setLogStream(java.io.PrintStream) in java.sql.DriverManager has been
deprecated
DriverManager.setLogStream(System.out);
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/
1.6.1/Embedded_DatabaseManager.java:442: warning:
setLogStream(java.io.PrintStream) in java.sql.DriverManager has been
deprecated
DriverManager.setLogStream(null);
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/
1.6.1/Embedded_Server.java:130: cannot resolve symbol
symbol : variable DEFAULT_HSQL_PORT
location: class org.hsqldb.jdbcConnection
port = jdbcConnection.DEFAULT_HSQL_PORT;
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/
1.6.1/Embedded_Server.java:140: warning:
setLogStream(java.io.PrintStream) in java.sql.DriverManager has been
deprecated
DriverManager.setLogStream(System.out);
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/
1.6.1/Embedded_ServerConnection.java:100: cannot resolve symbol
symbol : class Channel
location: class org.hsqldb.Embedded_ServerConnection
Channel c;
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/
1.6.1/Embedded_ServerConnection.java:107: cannot resolve symbol
symbol : constructor Result (java.lang.String)
location: class org.hsqldb.Result
write(new Result(e.getMessage()).getBytes());
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/
1.6.1/Embedded_ServerConnection.java:119: cannot resolve symbol
symbol : class Channel
location: class org.hsqldb.Embedded_ServerConnection
Channel c = init();
^
6 errors
3 warnings
BUILD FAILED
file:/disk/orig/home/lubega/jbossro/jboss-all/varia/../tools/etc/
buildfragments/targets.ent:45: Compile failed; see the compiler error
output for details.
Total time: 4 minutes 41 seconds
---
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
---
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
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version "1.3.1_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01)
Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode)
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
org.jboss.varia.counter.CounterInterceptor --> AbstractInterceptor qualified to
AbstractInterceptor
_default:compile-classes:
[mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/varia/output/classes
[depend] Deleted 0 out of date files in 0 seconds
[javac] Compiling 86 source files to
/disk/orig/home/lubega/jbossro/jboss-all/varia/output/classes
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_ServerConnection.java:89:
cannot resolve symbol
symbol : class Channel
location: class org.hsqldb.Embedded_ServerConnection
private Channel init() {
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_DatabaseManager.java:438:
work(java.lang.String[]) in org.hsqldb.util.Transfer cannot be applied to ()
Transfer.work();
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_DatabaseManager.java:440:
warning: setLogStream(java.io.PrintStream) in java.sql.DriverManager has been
deprecated
DriverManager.setLogStream(System.out);
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_DatabaseManager.java:442:
warning: setLogStream(java.io.PrintStream) in java.sql.DriverManager has been
deprecated
DriverManager.setLogStream(null);
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_Server.java:130:
cannot resolve symbol
symbol : variable DEFAULT_HSQL_PORT
location: class org.hsqldb.jdbcConnection
port = jdbcConnection.DEFAULT_HSQL_PORT;
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_Server.java:140:
warning: setLogStream(java.io.PrintStream) in java.sql.DriverManager has been
deprecated
DriverManager.setLogStream(System.out);
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_ServerConnection.java:100:
cannot resolve symbol
symbol : class Channel
location: class org.hsqldb.Embedded_ServerConnection
Channel c;
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_ServerConnection.java:107:
cannot resolve symbol
symbol : constructor Result (java.lang.String)
location: class org.hsqldb.Result
write(new Result(e.getMessage()).getBytes());
^
/disk/orig/home/lubega/jbossro/jboss-all/varia/src/main/org/hsqldb/1.6.1/Embedded_ServerConnection.java:119:
cannot resolve symbol
symbol : class Channel
location: class org.hsqldb.Embedded_ServerConnection
Channel c = init();
^
6 errors
3 warnings
BUILD FAILED
file:/disk/orig/home/lubega/jbossro/jboss-all/varia/../tools/etc/buildfragments/targets.ent:45:
Compile failed; see the compiler error output for details.
Total time: 4 minutes 41 seconds
---
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
