Re: [JBoss-dev] Why is new ObjectName() so slow?
Juha-P Lindfors wrote: On Sun, 28 Apr 2002, marc fleury wrote: Juha for example. By spec must we have Domain1:name1=value1;name2=value2 == Domain1:name2=value2;name1=value1 ??? I would imagine so, yes and this is the problem for performance -- Juha I've been following this discussion and I'd like to throw in my $.02: Can the implementation override its hashCode() method and compute it in a different way; and use the hashCode() as an initial part of the equals() method? I'm thinking doing something simple like scanning the input string and resetting the hash computation counter ever time a ';' is seen. IOW, compute a unique hashcode for each name=value pair and simply XOR them together to get the final hashcode for the ObjectName. This way, a hash comparison can be done without sorting anything. It will at least reduce time when the two objects are not equal. The scanning can be done lazily: only when the equals() or hashCode() methods are called. Disadvantages: * Breaks spec since only the constuctor is supposed to check syntax. This can be fixed by doing the hashcode computation in the constructor. * Still O(n) where n is the length of the initial string. * Can't use this to search for a specific name=value pair. Advantages: * Should be faster than parsing the input into a hash table and then sorting in order to do a comparison. However, the sort comparison should still be done once a hashCode() match is found, unfortunately! * Reduces memory requirements by delaying the creation of a hashtable until it is actually required. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Demo
How about deployables in the root of the distribution tree. Also, to follow up on Peter's message in a different thread about using a default.war to document things... I really like that idea. It can be extended to dynamically show what services can be deployed by looking in the deployables directory and parsing the *-service.xml files for information. If those files contain the documentation for the service they provide, then there is only one place to update if things change. (Would adding a description element to the *-service.xml files break anything?) The cool part of this is that the documentation could automatically show the dependecies as well. At another level, this whole interface could be extended to be a web based configuration thingy which can create configurations with the services you want. Maybe this should be part of the new JMX web interface. Are there any JSR's related to this? I haven't been keeping up on those. I am willing to work on something like this (for 3.1, not 3.0!!!) if there is any interest. --Andrew Hiram Chirino wrote: I like the idea. But what would be a good intuative directory name to put deployable services that are not actually deployed??? I got a feeling this could also cause some confusion. Regards, Hiram From: Andrew Scherpbier [EMAIL PROTECTED] To: Jason Dillon [EMAIL PROTECTED] CC: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Demo Date: Tue, 09 Apr 2002 18:39:21 -0700 I see your point about a minimal configuration. But what about the idea of a directory that has all the deployable stuff. This could be a good solution to the problem of people asking (or having to search for) database *-service.xml files. And as I said earlier, it would allow people to pick the web container they want (if any). By building a completely self-contained package that requires minimal external stuff to be installed, the user's experience will be that much better! ;-) --Andrew Jason Dillon wrote: Sure, though then perhaps an additional minimal configuration is in order, so that the default brings up most of the needed functionality. Or perhaps not... this is hard, because the minimum required is on that there be a jboss-service.xml, you don't need to configure any other beans... but this configuration is not very useful. I would support a minimal configuration, though I am not sure what functionality that would contain. I would also support documenting this somewhere, as minimal to you might not be minimal to me and so on. I expect 70% of the users who download this release to uppack it, startup with the defaults, copy there .ear or .war and then load a webpage in there broweser for confirmation that it all worked. I understand that you want to be clear about what is requried and what is optional, but perhaps there is a better way to get this information across than with a seperate configuration? --jason Andrew Scherpbier wrote: I have a suggestion on a related subject... From my current point of view (as a user of jboss 3) I would actually prefer a clear description of whatall goes into the deploy directory and why, and let me be the judge what gets deployed. This would mean creating the simplest deploy directory that has at least the ability to deploy a simple (no war) ear file that contains EJBs. In a separate directory, put all the crap that *can* be put into the deploy directory (and these need to be clearly described since the names may refer to things the user doesn't know about (yet)). The motivation for this is that as a deployer of JBoss, I want to make sure I only include the stuff that is actually used/required to deploy my user's applications. So, in other words, instead of making an example deploy directories from which a user might not know what to delete, provide the minimal config plus a clear description on what can be deployed. This might also be a nice way to include both Jetty and Catalina in the binary distribution. Let the user pick what they want. Am I making any sense to anyone? [trimmed for your protection] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Demo
Peter Fagerlund wrote: on 10-04-2 18.50, Andrew Scherpbier at [EMAIL PROTECTED] wrote: How about deployables in the root of the distribution tree. close but ... but what? Maybe available-services or possible-services Also, to follow up on Peter's message in a different thread about using a default.war to document things... I really like that idea. It can be extended to dynamically show what services can be deployed by looking in the deployables directory and parsing the *-service.xml files for information. If those files contain the documentation for the service they provide, then there is only one place to update if things change. (Would adding a description element to the *-service.xml files break anything?) The cool part of this is that the documentation could automatically show the dependecies as well. At another level, this whole interface could be extended to be a web based configuration thingy which can create configurations with the services you want. Maybe this should be part of the new JMX web interface. fucking beautiful At yet another level (higher baby, go higher!) it might be much easier to not rely on the autodeployer at all for this stuff. Instead, use the web interface to create a meta deployment descriptor that tells a new type of deployer what to deploy and in what order. That way, all possible service, sar, and jar files can be put in one place and left there. The only problem with this approach that I can see is that some of the *-service.xml files need customization (the database ones come to mind). Any bright ideas on how to deal with that? Don't get me wrong, I absolutely love the autodeployer for development, but from a user point of view, it can be quite confusing. Providing a clean, web-based configuration interface will make the barrier to entry for jboss deployers much lower. This idea might actually work really well in a clustered environment as well. -- Andrew Scherpbier, CTO ([EMAIL PROTECTED]) BlackBall Music (http://www.blackballmusic.com/) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Demo
I see your point about a minimal configuration. But what about the idea of a directory that has all the deployable stuff. This could be a good solution to the problem of people asking (or having to search for) database *-service.xml files. And as I said earlier, it would allow people to pick the web container they want (if any). By building a completely self-contained package that requires minimal external stuff to be installed, the user's experience will be that much better! ;-) --Andrew Jason Dillon wrote: Sure, though then perhaps an additional minimal configuration is in order, so that the default brings up most of the needed functionality. Or perhaps not... this is hard, because the minimum required is on that there be a jboss-service.xml, you don't need to configure any other beans... but this configuration is not very useful. I would support a minimal configuration, though I am not sure what functionality that would contain. I would also support documenting this somewhere, as minimal to you might not be minimal to me and so on. I expect 70% of the users who download this release to uppack it, startup with the defaults, copy there .ear or .war and then load a webpage in there broweser for confirmation that it all worked. I understand that you want to be clear about what is requried and what is optional, but perhaps there is a better way to get this information across than with a seperate configuration? --jason Andrew Scherpbier wrote: I have a suggestion on a related subject... From my current point of view (as a user of jboss 3) I would actually prefer a clear description of whatall goes into the deploy directory and why, and let me be the judge what gets deployed. This would mean creating the simplest deploy directory that has at least the ability to deploy a simple (no war) ear file that contains EJBs. In a separate directory, put all the crap that *can* be put into the deploy directory (and these need to be clearly described since the names may refer to things the user doesn't know about (yet)). The motivation for this is that as a deployer of JBoss, I want to make sure I only include the stuff that is actually used/required to deploy my user's applications. So, in other words, instead of making an example deploy directories from which a user might not know what to delete, provide the minimal config plus a clear description on what can be deployed. This might also be a nice way to include both Jetty and Catalina in the binary distribution. Let the user pick what they want. Am I making any sense to anyone? Jason Dillon wrote: I would prefer to keep any additional configurations that ship with the release to a minimum. I think that three configs: default, advanced and example will cover what we need and won't add much extra confusion. I expect that clustering would go into the advanced configuration. --jason Peter Fagerlund wrote: on 11-04-2 01.21, Jason Dillon at [EMAIL PROTECTED] wrote: Do you mean a demo or example configuration for the server? I think that a demo module under jboss-all is not appropriate, but a demo or example configuration under server/ is certainly do able. There was talk awhile ago about how to best organize this. I have not implemented anything since there was not a final decision. I suggest we add a advanced and example config directory under server, probably copying default for a base. exactly ++ also maybe a folder for cluster and the like called extended ? ... The deployer would need to be aware and ant triggable ...Yes - We talked about it some while ago and the concencus was - cool ;-) if that is not final . then . Ahhh ... /peter_f --jason Peter Fagerlund wrote: Are We ready to make a Demo folder in jboss-all/ that BM would copy into output/*/* where I could with an ant build.xml file build and copy to deploy ... and once in deployed in deploy as a webapp I could edit some source - save - *bong* - cool ... /peter_f ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Andrew Scherpbier, CTO ([EMAIL PROTECTED]) BlackBall Music (http://www.blackballmusic.com/) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBOSS @ JAVAONE TSHIRT CONTEST
I'll apologize up front if these have already been mentioned. If they have, they get my vote! :-) JBoss: Just Because Other Systems Suck JBoss: JBoss Beats Other Server Software -- Andrew Scherpbier, CTO ([EMAIL PROTECTED]) BlackBall Music (http://www.blackballmusic.com/) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] use of if(debug) log.debug
The object reference and method call are still performed even if nothing gets logged. By using a simple test, that overhead is removed if it is not needed. This is actually a big deal. It is even better if the test can be done on a constant, because then the compiler can decide if the code needs to be included or not and there is no overhead if the constant is false. marc fleury wrote: ??? I have a conflict on ServiceDeployer.java the conflict is due to the inclusion of if (debug) log.debug(...) with debug being log.isDebugEnabled()... do we need to explicitely do that? I thought part of the interest is that the log4j thing would not do anything with the messages if debug was not enabled so why the explicit test? I will remove these unless something clearly says the contrary marcf Marc Fleury President JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] use of if(debug) log.debug
Lemme correct myself... This stuff is a big deal *if* it is in code that gets called a lot. Andrew Scherpbier wrote: The object reference and method call are still performed even if nothing gets logged. By using a simple test, that overhead is removed if it is not needed. This is actually a big deal. It is even better if the test can be done on a constant, because then the compiler can decide if the code needs to be included or not and there is no overhead if the constant is false. marc fleury wrote: ??? I have a conflict on ServiceDeployer.java the conflict is due to the inclusion of if (debug) log.debug(...) with debug being log.isDebugEnabled()... do we need to explicitely do that? I thought part of the interest is that the log4j thing would not do anything with the messages if debug was not enabled so why the explicit test? I will remove these unless something clearly says the contrary marcf Marc Fleury President JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Versioning? (Was: current mbean structure confusing)
Some food for thought on the mbean system: (Just tell me to shutup and crawl back into my cubicle if you want!) While reading the thread current mbean structure confusing I was thinking about some other issues with mbeans, specifically versioning. In the special purpose app server we developed at my previous company we ran into a problem with upgrades. Our complete system consisted of something similar to mbeans (we developed this before the JMX stuff was around...) running in a simple container. (Sounds familiar? :-)) When we sent a new version of our software to a client (our clients included our own IT) we needed a way for the software to recognize that newer versions of some of the components were available. So we extended our component system to make it aware of its own version number and allowed a special method to perform upgrade tasks (it got the old version number, so it could perform the correct upgrade) I see this type of thing as a very useful extension to the current JMX stuff. Any thoughts on this? Does JMX 1.1 address this? If there is interest, I am willing to seriously look at implementing something like this. Also, since we always upgraded the complete system all at once, we didn't have any need for explicit version checking when computing dependencies, but with a generic server like JBoss, this might be of interest as well. This plays into the whole classloader thing as well, because you could conceivably have two different version of the same mbean that are used by other mbeans. This is probably too complicated, but it *could* be useful. Again, thoughts? --Andrew ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
Rickard Öberg wrote: David Jencks wrote: How would this help in the least? My understanding is that if you use a directory, the dd is checked for time changes For the auto-deployer, yes. I think I'd actually prefer to not use the auto-deployer, and instead make an Ant task that does the deploy command explicitly. Then there's no need to watch dd's or anything. I ran into the same problem and solved it by running Tomcat 4.0 as a separate process during development. Since tomcat works just fine with an already unpacked tree for my webapp, I simply modify my JSPs directly (I have a symbolic link from my webapp development tree to tomcat's webapps directory.) My ant rule to compile servlets and EJB remote/home interfaces is followed by a simple request to tomcat to reload the app: wget --http-user=foo --http-passwd=bar http://localhost:8080/manager/reload?path=/myapp I found this to be much easier than having to put the webapp in the ear for jboss. -- Andrew Scherpbier ( [EMAIL PROTECTED]) CTO, BlackBall Music ( http://www.blackballmusic.com/) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] IBM AS/400 (tm), it seems to be running right. kick webshmere ass
Ernst, Before you attempt to do what you suggest, I would suggest you first do some analysis of your environment. There are some things that you need to be aware of. The first thing you need to do is determine if there is a performance problem. What are your performance goals? What makes you think that JBoss is the problem? How did you test this? Can any performance problems be solved by throwing more hardware at the problem? Are there alternative J2EE app servers that will meet your performance goals? Also, keep in mind that the speed of JBoss is determined more by I/O (disk, network, database, etc.) and context switching speed of the underlying OS than by the JVM (Java Virtual Machine). Since you claim to be a Java newby, I have to point out some things about Java you probably didn't know: I assume that the JVM on the AS400 has a JIT (Just In Time compiler). Knowing IBM, this JIT will be of excellent quality. My (pretty extensive) experience with long running systems like JBoss is that running the java program with a JIT will be close to the speed or sometimes *faster* than running a native version (java compiled into native code). (At least Sun's Hotspot JIT in server mode outperforms anything I've tried, including optimized C++ code, when it comes to memory allocation/deallocation.) In short, don't underestimate the power of java and the JVM. :-) So, my advise is: don't even think about doing a project like this unless you know absolutely need to. Evalutate the cost of your effort compared to the performance gain that you may or may not get. Ernst Bekker wrote: I unzipped 2.4.1 on our as400 v5r1 at work. The server runs without any complaints. Unfortunately I am a java newby. (don't stop reading now). The as400 can compile java classes into native as400 byte code that runs like lightning. What I would like to contribute is as/400 CL and RPG code to make JBOSS the obvious choice for as400. So please help me out here. I can compile a .class and .jar files with a command (CRTJVAPGM), and then run them with (RUNJVAPGM). If you can give me an idea of how all the files fit together I am sure I can write some software to automate an optimal as400 server. TIA Ernst Bekker -- Andrew Scherpbier, CTO ([EMAIL PROTECTED]) BlackBall Music (http://www.blackballmusic.com/) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: LONG: RE: [JBoss-dev] can't build jboss from cvs
engineer Software. You acknowledge that Software is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility. Sun disclaims any express or implied warranty of fitness for such uses. No right, title or interest in or to any trademark, service mark, logo or trade name of Sun or its licensors is granted under this Agreement. This section states that .. you may not make copies .. other than .. for archival purposes. Also, decompile is not defined, and could be implied to mean unjaring of the embedded jaxp.jar. 7. Export Regulations. All Software and technical data delivered under this Agreement are subject to US export control laws and may be subject to export or import regulations in other countries. You agree to comply strictly with all such laws and regulations and acknowledge that you have the responsibility to obtain such licenses to export, re-export, or import as may be required after delivery to you. This could have ramifications if someone in an export controlled regulated country downloads JBoss, and, by extension, jaxp. In the supplemental license for jaxp, there are additional items to be concerned about. 1. Software Internal Use and Development License Grant. Subject to the terms and conditions of this Agreement, including, but not limited to Section 3 (Java(TM) Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce internally and use internally the binary form of the Software, complete and unmodified, for the sole purpose of designing, developing and testing your Java applets and applications (Programs). This section is just a long winded version of the first section 1. 2. License to Distribute Software. In addition to the license granted in Section 1 (Software Internal Use and Development License Grant) of these Supplemental Terms, subject to the terms and conditions of this Agreement, including but not limited to Section 3 (Java Technology Restrictions), Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software in binary form, provided that you (i) distribute the Software complete and unmodified and only bundled as part of your Programs, (ii) do not distribute additional software intended to replace any component(s) of the Software, (iii) do not remove or alter any proprietary legends or notices contained in the Software, (iv) only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (v) agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. Again, non-transferable is listed here. This means that since JBoss downloaded jaxp, accepted the license, and then bundled it, that JBoss is ok in doing so. However, if JBoss is uploaded to Debian, then it would mean that a transfer has taken place, and this is not allowed. (i) states that the software must be distributed unmodified. However, unmodified is not defined, and could be taken to mean the actual file that is fetched from sun's website, and NOT the embedded jaxp.jar inside the zip. (ii) means that there can not be 2 different jaxp implementations, which can be switched at build/compile time. This isn't so bad, as if there was a free jaxp implementation, the non-free jaxp from sun would just be dropped. (iv) is problematic as well, as I do not see reference to jaxp in documentation for JBoss. (v) could be quite costly for JBoss. If, sun wants to enforce this aggreement, and finds JBoss breaking this agreement, then JBoss is responsible for payment of damages and other associated costs. In some situations, JBoss doesn't even have to break this agreement, for these costs to occur. 1: http://www.debian.org/social_contract 2: http://www.debian.org/social_contract#guidelines 3: http://java.sun.com/xml/jaxp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Andrew Scherpbier, CTO ([EMAIL PROTECTED]) BlackBall Music (http://www.blackballmusic.com/) ___ Jboss-development mailing list [EMAIL PROTECTED] https
[JBoss-dev] EJB 2.0?
Hi all, First off, I have to warn you that I am fairly new to EJB and JBoss. After developing an app under JBoss-2.4.3-Tomcat, I figured I would make a try at playing with Rabbit Hole. I got everything checked out (HEAD), compiled, and running. (A little bit more documentation on this would be useful, but that is a different story...) My EJB 1.1 app runs just fine under the new setup. But now I want to start using some EJB 2.0 features. (Specifically, the CMR stuff) Any attempts at providing my setup with EJB 2.0 beans produce lots of errors during deployment. So what gives? What do I have to do to make JBoss accept EJB 2.0 beans? If this simply isn't implemented yet, what EJB 2.0 features can I use and more importantly, how can I use them. TIA! -- Andrew Scherpbier, CTO ([EMAIL PROTECTED]) BlackBall Music (http://www.blackballmusic.com/) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
