[JBoss-dev] Optimizing MarshalledObject, or variants thereof
Hey I just found out a way to optimize the use of MarshalledObject, if it's used to send stuff over the network (JBoss has it's own version, but it has the same basic code). The MO serializes the data into a ByteArrayOutputStream, which then is toByteArray'ed in order to get the data. This is bad, since the data is then copied into a new array of the same length. This may not mean much, but if you're doing it all the time it makes a difference. There's a trick to get around this: simply store the BAOS in an instance variable of the MO, and call out.write(BAOS.size());BAOS.writeTo(out); during serialization. This will avoid the copy. Read the data during deserialization, and the rest is the same. This simple trick will hence reduce the number of byte arrays created by 50%. You'll probably want to introduce this fix into MarshalledValue, and any other place where MO's are used. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code1 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Optimizing MarshalledObject, or variants thereof
marc fleury wrote: thanks marcf PS: want to get your RW back? do you still have it? No, I'm cool without it. I just happened to do this optimization in some code I wrote for my new AOP framework, and remembered that MO's were being used quite heavily for calls in JBoss. That's all. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code1 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Miracles do happen :-)
http://developer.java.sun.com/developer/bugParade/bugs/4388666.html Finally. -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Will grand unification of CL solve this?
Anatoly Akkerman wrote: I've been seeing the following problem and have been wondering how to solve it or whether the grand unification will solve it. I am writing an EJB application that processes XML descriptors using Castor. Now, Castor is loaded by the SL and is available to the application but when an EJB invokes Castor, it has to be able to instantiate certain classes from the application. It seems in 3.0alpha this is not possible. The only way I can get rid of this problem is by removing castor from lib/ext and deploying it as an application library. This is, obviously not a good solution. In general, is there a way to deal with such issues? This is really a known bug of Castor. It, like a ton of other flawed libraries, does not use Thread.currentThread().getContextClassLoader().loadClass() to get classes. Instead it uses Class.forName(), which doesn't work properly. If this is changed in Castor, your code will work just fine. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
marc fleury wrote: |It's not fixed. Marc, do you remember when we were at J1 and talked to |your french friend that said something about it being a security hole if |it was fixed. Or something like that. Are you sure it is not fixed? as in you verified or as in you took what this guy said at face value (name is jc collet btw), I wouldn't trust everything he said :) you know we were friends and all but... Haven't checked, but can't imagine that it's been fixed... still, would be nice with a solution that works on 1.3 too. |I've been thinking about this problem though. Wouldn't it be possible to |make a custom URL handler that returns a connection wrapper that we can |drop under the covers. I.e. even if the URLClassLoader hangs onto it, we |can still close the file under the covers. I think that would make it |work, and wouldn't be *that* intrusive in the code. sure, that is an idea and it would simplify the code a lot. The problem I see is that I suspect they keep the connection opened for classloading reasons, i.e. the VM asks for loading classes at random times. Reopening the connection seems slow (the security hole would be the capability to change the jar we look up???). That's irrelevant. It's ok that they hold on to the connection. It's not ok that there's no way to flush that cache. What our custom URL handler would buy us is that we can close the underlying connections explicitly as needed. If there's another call on the connection we would reopen it, but during the time it is closed we can replace the underlying JAR. I guess the way this works is you would put a time out on the URL or something, you need to make guesses as to when the vm will be done loading from this puppy which is never in the case of JMX and SL CL architectures. Nope, just an explicit way of closing the connections and thus disregarding how the URLClassLoader connection cache does things. A problem will be slow classloading in the JMX/SL base (it will affect 2.4 and 3.0) as you will ask CL to look for classes in connections that are closed... h we are going to need smart CLs... at least with indexing, yes... indexing of cl contents to allow for fast clusterwide lookups h me likes... do you see these? is there a way to create a default jar tvf (t being the important one here) and allowing for indexing PER Cl, that would dramaticaly improve the speed of our superservers as well as solve the above problem. blah blah blah... nonsense. Not a problem, see above. The only thing that's important is that we can *close* them when *we* want to. Other than that its fine that the URLCL hangs onto open connections. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
marc fleury wrote: following my own mantra of communicate simple, go right ahead and create a URLConnection that closes the connection after some time or every time, maybe even every time is enough. See previous email. No guessing is needed. All the connection needs is that when we explicitly say close() goddammit it will close the underlying connection, so that we can remove the file that it was pointing to. The discussion I have below only affects loading times when new classes are deployed and we can always measure that and deal with it. So KISS the URL. There would be no loading time problems. See previous descriptions. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
marc fleury wrote: not that I know, the original deployer was a piece of crap anyway, fix this if you want. BTW is the URL caching thing FIXED in 1.4 JDK or not? if so we could require the 1.4 VM for proper behavior of the deployer I think it would greatly simplify the design as we wouldn't need to copy the files over. It's not fixed. Marc, do you remember when we were at J1 and talked to your french friend that said something about it being a security hole if it was fixed. Or something like that. I've been thinking about this problem though. Wouldn't it be possible to make a custom URL handler that returns a connection wrapper that we can drop under the covers. I.e. even if the URLClassLoader hangs onto it, we can still close the file under the covers. I think that would make it work, and wouldn't be *that* intrusive in the code. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
marc fleury wrote: I understand what you proposed what I don't understand is the above, see below :) Ah, sorry, now I understand. We're talking about slightly different things. Question: can you overwrite the jar if the vm holds a open connection to it and thus a lock to it in windows (file in usage)? No. If no which is my assumption for this discussion then you don't know when ANT is going to replace that file from JBoss, or when the user wants to drag and drop, it is an asynchronous operation that happens without your knowledge (won't happen in this case) I was thinking about the same case as now, where there is one original copy (in /deploy) and one copy being actually used. The original copy would never be locked, but currently the copy being used is. *That* is what this solution would fix. You'd still need two copies. For the other case, you'd simply not use auto deployment. Introduce an Ant target that does JBoss Deploy and which does undeploy-copy-deploy directly to the server. Then you can work with the original file without problems. Personally I'd prefer this explicit way of doing deploy, since auto deployment seems a little funky right now (we get dual deployments quite often). |6. At this point there are no open connections to the JAR, so it can be |replaced with a new file or removed. no see above, you don't know *when* someone is going to replace the file so you can't be open most of the time. Do we agree here? We were talking about different files, that was the problem. almost, some googoo on my glasses still (or is it yours?) As above, we talked about different things. We were both right :-) /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
David Jencks wrote: So this requires an explicit undeploy of the old jar: it cannot work via an autodeployer watching for changed timestamps, because you have to undeploy the file first before you can change it. Correct, I was mainly thinking about the locking of the copied file, which is a pain right now (it doesn't get cleaned up). You sure this is better than copying? Copying would still be used, but at least the copy can have the same name, and always be removed on undeploy. With explicit deployment (described in previous reply to Marc) there would be no locking. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Developing with JBoss
Hey Developing with JBoss used to be very good due to hot deploy features. Now that our app is growing rapidly (mostly LOADS of JSP's) we're seeing that it's not so nice, because we have to package the app as an EAR file before deployment. If JBoss could work from a directory, that would cut down the dev cycle by a lot. Looking at the J2EE deployer it seems as though it can take a directory as input. However, if that is the case, then it gets packaged into a JAR anyway! Thus, the overhead we skipped by not packaging it into an EAR file in the first place is added anyway. Is this really necessary, and would it be possible to change it? As it is, we have a redeploy cycle of about a minute, which is not nice... /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Julian Gosnell wrote: 2. Non-compliant - only requests for system classes are passed upwards. FWIW, Tomcat4 does the same thing, which means that you have to bundle in jaxp.jar in your webapp, or you're going to get strange class-cast exceptions and class-not-found exceptions. The solution is to bundle all libraries with your app. This strategy resolves the problems listed against (1) but causes the isAssignableFrom() test mentioned above to fail. What appears to happen is that JBoss passes ClassLoader A to the EJB container which loads class X then on to Jetty which creates it's WebApp ClassLoader, B, as a child of A, then asks B to load class X. B does not delegate to A, but loads class A for a second time. So you need to put all classes in the EAR scope instead of in the webapp scope to make things work. Right? /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Julian Gosnell wrote: So, Are you saying that we should simply support both - but not a third strategy which somehow supports sandboxing AND optimised intra-container calls ? Well, I believe the real fix is to make the EJB-loader use the non Java2 class-loading style as well, i.e. force people to bundle in JAR's that the app is going to use. That is the ultimate way to get things portable, and to be able to allow different running apps use different versions of, say, JAXP. I think, after a good 5 mins deep consideration, that the App server should provide the following classes to a SANDBOXED application. 1. J2SE x.x 2. J2EE y.y 3. Common local infrastructure What goes into 3? 1 and 2, yes. That must be available from the classloader. Since the app is sandboxed, it should be able to override these with it's own version. I guess if you want your own version of JAXP then you should probably have to include your own implementation as well. Absolutely. And that is indeed the case, or you'll get funky classcast exceptions (we had those a couple of days ago and had muchos fun trying to figure out what happened). Should the app-server not try, even in this situation, to optimise intra-container calls ? Well, what is the need to optimize them anymore, really? I mean, use local interfaces and that's it. The proxies don't have to do the check, since it will be implied from what type of proxies that are used. Hey, it's portable too. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Julian Gosnell wrote: What goes into 3? Your site's e.g. Logging classes etc.. which every app uses. You figure it's cheaper to load them once into the apps parent CL, than many times, into every app. Ok, good point. I believe Tomcat handles this by using a common directory that contains libraries that should be available to webapps and server alike. If they are not optimised, RH currently throws an exception and the test fails. So this needs fixing. Ah. Point taken. I have heard of, but know nothing about, local interfaces. I would have thought though, that they must still be constrained by the basic laws of Class assignability - i.e. if the way the ClassLoaders is arranged means that instances of a Class cannot be passed directly from one ClassLoader to the other, without serialisation, then your call is going to be slower than if they were. Wether you are using local interfaces or not. Am I wrong ? Well, if you want to use local interfaces, then yes, you have to be careful with how you package classes. They need to be in the EAR. Anyway, JBoss attempts to implement optimised intra-container calls through the standard interface. Are you suggesting we should throw all this code away now? It would save me a lot of effort. I'm torn. The optimization was introduced because there was no standard way to do it, but now that it does... well.. what's the point? Backward compatibility with people who have written apps that takes advantage of it, yes, but that should be it. All new apps should use local interfaces if you want local behaviour. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Scott M Stark wrote: That is correct. The packaging required to run under a 2.2 servlet container is inconsistent with that required to run under a 2.3 container due to the change in the web container class loader behavior. I see this with Tomcat 3.2.3 vs Tomcat 4.0. Really, the only time this shows up is for JSP pages trying to access EJBs. Well, *all* access from the web container to EJB's (i.e. servlets too) need to be aware of these changes. We ran into this the other day, and the fix was to bundle crimson.jar into our app too (i.e. not rely on it being available). Now, because of all this bundling going on, the EAR quickly grows HUGE, which means that for development you want hot-deploy on exploded EAR files. Unfortunately JBoss does not currently support that, so the cycling time becomes somewhat excessive. :-( /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Optimised Servlet-EJB calls.../ Local Interfaces
Julian Gosnell wrote: Is it being suggested that I should use these for servlet/jsp-ejb communication ? I would :-) If so, then something is wrong. Do I really have to decide the architecture of my AppServer before I write my App? It should be transparent. You can write your app so that these issues are transparent, but then you need to take alays care of the worst case, which is remote behaviour. If not, then you are guilty of having believed in the Seven Fallacies of Network Computing (http://wwwtec.informatik.uni-rostock.de/IuK/gk/thm/devdef/Vortrag1/tsld008.htm) Architecture is rarely transparent, although it is often quite possible to *localize* the impact of it to some degree. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Greg Wilkins wrote: What class does it fail for? Can't you remove that class/jar from the webapplication, so that it can only be loaded from the EJB classloader? It should be loaded by the EAR loader methinks. -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
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. and if it changes the whole app is undeployed and redeployed. Unless you can put your app in independently deployable chunks, you will need to undeploy and redeploy the entire application anyway. What I want to avoid is the copying and packaging that goes on. Do you have any idea of the time it takes to package 1500 JSP's into a JAR, and then have that 3-4Mb file copied and exploded into a tmp dir, and this for every time you make a change in a single JSP? Forever I can tell you. It adds up to *a lot* of time each day for just redeployment. Why can't you use the Scoped Classloader, which puts several ears into the same classloader and application? Could work, but I'd rather do something portable. Plus, it's non-trivial to break up our app (it's rather monolithic). Plus, several EAR's - several web deployments - several web contexts - no session sharing - no good. Also if the problem is with jsps I thought I saw somewhere that you could change the copied, deployed, unpacked jsp files while the app was running and they would get picked up and recompiled. Haven't tried this though. No good. So, I change a file, and get it to work. I then change a class and rebuild. Poof, my changed JSP file is gone. No, it needs to be clean, or there's just no point. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] How would RDF help us, Rickard?
David Jencks wrote: I tried looking into rdf a little bit since Rickard has been pushing it for mbean configuration, but as far as I have read (not very far) I don't see the point. Is there an example of using rdf for something remotely resembling component configuration that might convince me quickly that this is a good idea? AFAIK there are no good reasons to use RDF at all, apart from giving you that feel-good feeling and a voice in the back of your head saying you're gonna be glad for this some day. RDF is not an easy sell if you're always looking at single examples. It's when you get more stuff into RDF that you can do interesting things, since a large part of it revolves around semantic deductions. Oh yeah, now I remember, Mozilla uses RDF for all of their stuff. I believe they have a couple of this is how it went docs as well at their site (mozilla.org). I'm gonna try and use RDF for as much as possible in my future projects. At some point critical mass is reached and you can do all sorts of funky stuff. Hey, it's only XML anyway, so no loss if nothing good comes out of it. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls ClassLoaders
Scott M Stark wrote: Really, what was the package structure that caused the exception? I thought I had tested a number of variations and hadn't seen any issues with normalized ears. We had to include jaxp.jar and crimson.jar in our EAR to get XML parsing to work. With only jaxp.jar you get a LinkError (or something like that) because you'll get jaxp.jar from the app and the parser from the server, and the interfaces the parser implements is not the same as that in jaxp.jar (=classloader hell). Regardless, I'm going to work on the deployment layer to clean it up and add support unarchived ears. That would be sooo appreciated. It would save us so much time it aint funny... /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
Luke Taylor wrote: It's not just about the time for the deployment, which is minimal - if you're working on frontend stuff and just essentially modifying web pages, then you lose your whole session state. If you have a complicated web application with security, shopping carts etc, and you're working on the checkout pages, then you have to go through the whole use-case procedure every time you redeploy. If a web container can be configured to pick up the jsp's directly then you only have to reload the page to see a change. One solution is to use a template engine such as Velocity instead of JSP. Then there's no problem whatsoever: just have it pick up changed templates from your /src dev directory. That is, if you have a choice in the first place. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
David Jencks wrote: Could work, but I'd rather do something portable. Plus, it's non-trivial to break up our app (it's rather monolithic). Plus, several EAR's - several web deployments - several web contexts - no session sharing - no good. You're talking about a non-portable development environment anyway aren't you? Putting pieces of your 1500 jsps in different files might not be so hard??? Yes, I am talking about non-portable development environment. When I'm done, I package an EAR anyway. And no, again, splitting the app into multiple WAR's is Not An Option. ??? Are you proposing to change a copy of the source for the jsp rather than the source?? That's what I thought *you* meant... which would be dumb.. Cmon, you change your jsp in src, deployment of change consists of copying changed file to temp deployment directory?? That's much better, assuming I know where the tmp directory is. And I don't, since the name keeps changing for each deployment. :-( You rebuild from source, you pick up the changes. Only problem I see is automatically finding the correct tmp deploy directory again after redeployment of the whole ear. Exactly. Paaain.. /R -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Ignorance
Sacha Labourey wrote: In RMI's Bible, hum, I mean Rickard's book, Hehe, I was just reading the bible, I mean.. uhm, anyway.. to be sure. It's always a good idea to do this, especially in such a controlled environment as we have, with little need for allowing upgrades in the system over time. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] suggest changing log4j layout patterns
[EMAIL PROTECTED] wrote: Has there been any thought as to making the log4j component a configurable MBean like the rest of the system? It would be nice to be able to configure the logging properties via some administration interface on the fly via jmx. Right now it looks as if there is only a thin wrapper around starting log4j and pointing at its configuration file. I've begun doing a simple log4j console in the WebWork project (sf.net/projects/webwork) which will allow you to see the categories and set debug levels and stuff like that, and also get log output. I'm not doing it as MBean's though, but as a WAR file. The app just hooks directly into log4j without going through JMX. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Separating JMX/EJB
marc fleury wrote: |I intend to write a whitey on it some day too, but basically it goes |something like this: |* Meta-programming is good, but not inherent to EJB true, but a sophism You are intelligent, but intelligence is not inherent to Rickard Oberg (I am intelligent as well), does that make Rickard Oberg dumb? What an utterly stupid remark. What I meant was: MP is good, EJB has it, but it's not the only way to get MP. |* The EJB programming model in general is flawed. (See EJB-INTEREST for |lots of conflicting answers to common questions. If experts can't figure |it out, how are mortals supposed to?!) could it be because experts are donkey-dick-sucking-monkeys that don't know their ass from their tinny winny pinuses? I think so. Anyway when you really make your points, make sure to be specific about the model in general :) that's not going to cut it. What utterly stupid remarks. Marc, Marc, time to return to reality, yoh, we're over hree |* In particular, dynamic (re)configuration of EJB is not possible, and |it should be (compare with JMX/Jini) false Because..? 1) Bean A uses bean B. B dies, but C that implements the same interface is still alive. Now what's A supposed to do? How will it be notified that B is dead, and how is it supposed to find C? (with hardcoding these dependencies in of course) 2) Bean A stores files in a particular directory. The name of the directory changes. A needs to be alerted of this. How? Change the XML file with environment settings and redeploy? Gee.. great... |* The EJB persistence model is flawed, compared with JDO. true boloney, sliced thick, with peanuts in the middle, will end up as chunky 2c toilet wisdom Thanks for your input, you really helped show why EJB is good, or rather, why my reasons to not use EJB are false. Thanks again. Now back to our regular programming. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
marc fleury wrote: h you have been pushing this RDF thingy for the past months, if it does indeed allow for a one file admin, it might be worth it. Right now we are going exactly the opposite way with the full file split across many little files, possibly in sars... interesting Well, namespaces can be used with or without RDF. It's just a very nice way to get multiple aspects of a particular element into one XML file without element name clashes. Simple too. |Do take time to look into Aspect Oriented Programming if you have time. |Volume 44/Issue 10 of Communications of the ACM |(http://portal.acm.org/toc.cfm?id=383845type=issuecoll=portaldl= |ACMidx=J79part=magazineWantType=Magazinestitle=CACM) |have lots of great articles on the subject, and there are lots of |parallels with how JBoss works already. Yes, Aspect programming is the compilation heavy approach by PARC to meta-programming. To be precise, AspectJ is the compilation heavy approach. Aspect Oriented Programmin in general is more of a philosophy that can be implemented in numerous ways, the interceptor architecture of JBoss being one of them. The interceptors in JBoss fit really well with the notion of aspects in AOP. If you read this carefully you see that scripting is probably the middle ground between compilation heavy PARC and XML light EJB. Research but there is really no reason why intercepting mbeans wouldn't be close to it. Yes, scripting will make it easier to insert aspect join points. Good point. To me it seems like AspectJ has this scripting aspect to it, although it uses pre-runtime compilation to get it into bytecode. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
danch wrote: When we talk about 'stateless' interceptors, do we really mean stateless, or do we merely mean stateless with regard to bean instance and client? Bean instance, container, and client. Yes. It may only hold state that is relevant for the particular work it is doing, such how to do it. For example, an invocation monitor sending messages to JMS might have an instance variable with the name of the topic to send messages to. That name is not client specific, it is not instance specific, and it is not container specific, but it is nevertheless state. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Separating JMX/EJB
marc fleury wrote: |What an utterly stupid remark. Laaa laa la laa laaa laa ! ( I am not listening ) Hehe.. you're so screwed... awhh.. why do I even bother.. :-) |Because..? |1) Bean A uses bean B. B dies, but C that implements the same interface |is still alive. Now what's A supposed to do? How will it be notified |that B is dead, and how is it supposed to find C? (with hardcoding these |dependencies in of course) Rickard you are talking of dependencies. The EJB spec defines dependencies in XML (soft) the proxies can implement failover, if you need notification (say to restart) you can be notified through many other frameworks including JMX and jini. Well, EJB's can't use Jini (can't hold on to a ServiceDiscoveryManager for example). If you want the proxies to do the failover, which would be entirely possible, you need to be able to let them point to many various instances of possibly different implementations. I guess the EJB interface/spec in itself would allow for this, but it would require quite a lof of the EJB container, as opposed to a rather simple hack in JMX/Jini. Alright, you may have a point, but it's not really valid until it gets implemented *well*. |2) Bean A stores files in a particular directory. The name of the |directory changes. A needs to be alerted of this. How? Change the XML |file with environment settings and redeploy? Gee.. great... A notification of state change can be achieved by other means. A simple reset of context in most cases would do that. Rickard these are truly minor points that can be solved for the price of a callback on the bean. They are by no means show stoppers that invalidate the model (which really doesn't worry itself with these). We can do it simply in JBoss by offering an MBean in the EJB, you can certainly push for it in spec commitee (if you are in the commitee). Heck! require an MBean for the properties (pointers and what not), and you are done. So you'd need to go outside EJB for such a common requirement as runtime reconfiguration? Is that good? Sorry, but it's still bad. However, one of the key reasons why I don't like EJB, is because it's overused. People use it for things they shouldn't use it for, especially for web applications where the web client and EJB's are in the same JVM. And you still need to go through the remote interface, thus introducing a whole bunch of heavyweight patterns such as Data Transfer Objects. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
David Jencks wrote: Whether you put the state in the interceptor instance or the head of the chain, you need the same state info. If you put it in the head of the chain, you either have to put instance variables specific to the interceptors that will be in the chain if you want any compiler type checking help or use an untyped map and hope for the best if you want it generic. Seems logical to put the MBeanInfo object of the container in the thingy that gets passed on. The interceptors can the extract whatever metadata about the container they want from that. If you put the state info in the interceptor instance, you can have all the compiler type checking you can stand, you keep the state info needed for the interceptor encapsulated in the interceptor (where, I will say, it belongs), and the interceptor becomes much more self contained. What if two interceptors are interested in the same metadata? The only feature the stateless approach gets not easily available with the statefull approach is the ability to change which interceptors are called during the chain traversal. I don't see any use for this meta-meta programming at this time. Also, a stateless interceptor can be used for any container. If you want to just have tx's, you'd go find a tx-interceptor, and put it in the invocation chain. The interceptor will extract the metadata it needs about the container using the MBeanInfo, and do its work. If it is stateful, how will the interceptor get its metadata? I hope it won't load it itself... that would make it dependent on the type of object the interceptor chain is being used on (since it may be used on things that are not EJB containers). /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CacheKey copy semantics and speed
Bill Burke wrote: Also remember why I added the copying to the CacheKey in the first place. What I was doing in my application code was reusing a fat-primary key so I didn't have to reallocate one. Thus the entity cache was getting corrupted because I kept on changing the shared primary key instance. I guess if you're stupid enough to re-use an instance of a primary key, you deserve to spend days trying to track down this problem. So, if you're going to get rid of the MarshalledObject and all the copying, why not just get rid of CacheKey all together? Hehe... if it is removed I have only one thing to say: told you so... :-) /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CacheKey copy semantics and speed
Bordet, Simone wrote: eee, man this guy seem to *always* be right. Ah well, pure alien category. Rickard, ehrm, who will win the football league this year ? :-)) I *could* tell, but that'd spoil the fun ;-) /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Separating JMX/EJB
marc fleury wrote: we agree on the metaprogramming, we are going to make it dynamic too, some other day I will publish a white paper :) Let Rickard fire first I intend to write a whitey on it some day too, but basically it goes something like this: * Meta-programming is good, but not inherent to EJB * The EJB programming model in general is flawed. (See EJB-INTEREST for lots of conflicting answers to common questions. If experts can't figure it out, how are mortals supposed to?!) * In particular, dynamic (re)configuration of EJB is not possible, and it should be (compare with JMX/Jini) * The EJB persistence model is flawed, compared with JDO. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Class loading with JMX vs 3.0
Hey One of the primary goals of JBoss 3 is to accomplish reloading of services through the use of advanced classloader relationships (implemented in URLClassLoader and ServiceLibraries AFAICT). To me it seems as though this is a direct replica of MLet+DefaultLoaderRepository in JMX, since (AFAICT) they work the same way. Is there a particular reason why the JMX way is not used? Are there any limitations in using the MLet+DLR combo that drove the decision to implement a custom solution instead? /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] is there (911)
David Budworth wrote: Adding one would be trivial (in fact, it's as easy as adding a single string to the log4j properties) The problem, is the log would never be a valid XML doc untill the app server is shut down. Not the actual log file, but that's why XML has entities :-) Just put this into a file: !DOCTYPE log PUBLIC log logfile.dtd [ !ENTITY introduction SYSTEM logfile.xml ] log logfile; /log -- Then *that* file will read as valid XML. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX service architecture: next gen++
on earth that is using JMX EVEN TODAY as the base like you did rickard. They all use it for management. Good point. WTF! bunch of impostors... bunch of bozos. Working in isolation of your peers leads to decay of the mind and decay of the work. I don't buy for A SECOND that the second grade developers at these companies can come up with the same. It is stealing but we know better. We're all proffessional thieves, in some sense. :-) It's how good you are at putting different things together in different dimensions that makes it interesting or not. :-) man I feel better it has been on my mind for quite some time now. Love, to the ones who deserve it. To the rest... we will bury you -- Krutchev? -- You're a blanwhite kinda guy ;-) Glad I'm on the right side of the fence. PLgC /R -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX service architecture: next gen++
marc fleury wrote: We would create the interceptors independently of each other. And then creating a stack is nothing more than instructing incoming gates (.net, rmi, whatever) that the messages requesting EJB-style fielding should go through this stack of ObjectName interceptors. standardjboss.xml needs to map one on one there. Well, the only thing the incoming gates would have to know is to immediately delegate to the stack configuration MBean. After that it can take care of the stack config. *But this will only work if the interceptor/config interleaving is done as outlined in previous post*. Otherwise it will be an MBean explosion... The stack of state machines, the movie seen by the MI, is a random access stack from the point of view of the admin. Then updating the flow means talking to that route mapper at the gates. Which, as discussed, need to be hand-holding the MI as it travels along the stack. /R -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[Fwd: [JBoss-dev] JMX service architecture: next gen++]
Wrong reply-to.. here it is. ---BeginMessage--- marc fleury wrote: |I'll rephrase myself. Interceptors could be done as a series of JMX |MBeans implementing DynamicMBean, i.e. they don't do anything with the |call except delegate to other DynamicMBeans, with the last one actually |doing something. This would work, and it would make it simple to |configure each interceptor separately, since they're MBeans. The problem Yes this would indeed be the prefered way to work on the interceptors at run time. Ok, gotcha. |is that for each MBean requiring a specific set of interceptors there |would be a bunch of additional MBeans (i.e. the interceptors |themselves). You would hence get loads and loads of MBeans who play the |interceptor game. Not sure if that's a good idea. However, if you put Not necessarily. Take for example the transaction interceptor in JBoss. It is essentially a purely stateless component so that many threads can go through it at once. In clear even just ONE instance of the component (Tx interceptor EJB semantic) is probably enough to take the full load of the server. I don't know enough about compiler technology to know if this is true or not. It should be. So then you will instead have n number of Tx-EJB-style MBeans for each configuration of it that you want to be able to use. There is a stacking problem here though. If each interceptor is supposed to know which interceptor comes next in the chain, then you will need one instance per *chain configuration*. I.e. if you have two MBeans being served by the same chain, and then want to modify the chain for one of the MBeans, you'll have to duplicate the chain and make the modification. It would be messy. The only way I can see to get around that is to have the interceptor chain interleaved with a configuration interceptor. Example: MBean XYZ wants the interceptor chain A,B,C (where C handles the call). Somehow this config info is given. An interceptor stack management MBean (MGMT) knows this, and for each incoming call the actual runtime chain of invocations looks like this: 1. Connector.invoke (incoming call) 2. MGMT.invoke (MGMT is delegated to, and in turn delegates to first in chain) 3. A.invoke (do the A stuff, delegate back to MGMT) 4. MGMT.invoke (determine that the chain has progressed past A, delegate to B) 5. B.invoke (similar as 3) 6. MGMT.invoke (same as 4) 7. C.invoke (similar as 3, delegate to XYZ through reflection) 8. XYZ.invoke 9. return through interceptors 10. Connector.invoke return result This is the only way you can get away with having a finite amount of interceptor MBean instances. If each interceptor is aware of the next in the chain, as in JBoss2 EJB, then you will have the config explosion problem (i.e. each interceptor will have the state config+chain knowledge instead of just config). See what I mean? To get this to work the interceptor chain needs the following meta-info in the MI: 1. Final MBean to invoke (XYZ in above case. this identifies the chain to use) 2. Point in chain (0,1,2,3 in above case. this identifies which interceptor in the chain to delegate to next) 3. method 4. arguments 5. custom meta-data(?) This way you can take maximum advantage of the fact that interceptors are largely stateless (and thread-safe), hence reusable for multiple concurrent calls. Each interceptor is a state machine that works on stateless sequence of symbols (the MI coming through) and modify the symbols based on contextual information (tag declaration in tx for example). Yes, true. As in above, the point-in-chain is very important though in order to externalize the actual chain from the interceptors. Agree? I didn't think about that before, but if you are right and we can indeed use the ONE dynamic MBean instead of custom stacks per bean, the we could very well have the mbean be the interceptors. It would require the above to work I think, but it's definitely doable. /R -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ---End Message---
Re: [JBoss-dev] JMX service architecture: next gen++
marc fleury wrote: |Well, the only thing the incoming gates would have to know is to |immediately delegate to the stack configuration MBean. After that it can |take care of the stack config. | |*But this will only work if the interceptor/config interleaving is done |as outlined in previous post*. Otherwise it will be an MBean explosion... 4 hours of sleep and I need coffee but no I think that you don't have explosion as we now know that you can use stateless interceptor which enables you to have ONE instance per node as well as at the beginning mapping that the MI sees coming in, no need to go through the config interceptor every call. Do you agree? Let's see if I understand this right. Do you send the list of interceptors as part of the MI? I.e. the list contains the MI and an index, and each interceptor just increases the index and delegates to the next? Or how is the stack controlled? What is the driver of the interceptor delegation? /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [Fwd: [JBoss-dev] JMX service architecture: next gen++]
(Seems like the lists need to change the reply-to. it's to the sender and not the list) Hiram Chirino wrote: Since it seems like the configuration would define a static stack of interceptors, MGMT could build a java.util.Stack containing the interceptors and pass that down. Avoiding the delegation back to it. Yes, pass it down along with the MI. That'd work. Didn't figure that one out initially. That would indeed be much better. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX service architecture: next gen++
marc fleury wrote:
a stack of ObjectNames and in each message interceptor mbean there is a
ObjectName name = message.getNextInterceptorInStack();
server.invoke(name, mi) // equivalent dynamic invocation
...
whatever there are tons of ways to do that (maybe self contained in MI)
Good point. I had missed the send stack along in invoke option. That
is indeed superior. Very lightweight and simple.
The stack could indeed done as:
class InterceptorStack
{
List interceptors;
int idx = 0;
InterceptorStack(List aList)
{
interceptors=aList;
}
ObjectName getNextInterceptor()
{
return (ObjectName)interceptors.get(idx++);
}
}
---
So many MI's would be sharing the same list, but with different indices
into it.
Updating the list would be to simply replace it at the gates. MI's
already in progress using the old version get to finish with that old
version.
Nice.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of Mastering RMI
Email: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX service architecture: next gen++
marc fleury wrote: |So many MI's would be sharing the same list, but with different indices |into it. right that is even better the only state that is in the MI is the index and a (static) reference to the type of flow he will see (ejb), pretty cool rickard. It is indeed (and I would not want to get credit for this idea. You already said it, you just didn't know it :-). |Updating the list would be to simply replace it at the gates. MI's |already in progress using the old version get to finish with that old |version. yes, once you send something in it uses that stack. Do you foresee a problem with this? Only if the change of the stack is due to MBeans in it becoming unavailable. Then the MI's that are in progress may try to use MBeans that are no longer running. You get around this by using dependencies. If the stack mgr declares itself as depending on the interceptor MBeans, then it should get STOPPING events before the interceptors have actually stopped, and can then a) wait until any current MI's using that MBean have finished b) hold any incoming MI's wanting to use stacks with that MBean Of course that won't work if the reason for stopping the interceptor is a fatal error (i.e. no way to halt the stop procedure, even temporarily). But then you're screwed anyway. We do have a centralized intelligence, the distributed JMX bus (you indirect in JMX at every point) Yup. It will be more of an interesting configuration problem, than a programming/design problem. How do you get this to work without getting config files the size of the planet? :-) /R -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX service architecture: next gen++
Vinay Menon wrote: What if an interceptor in the stack has a call back to a previous interceptor that was removed as a result of the update? Maintain multiple version of the stack until all old references complete? I think the point is that you never change a stack. Only replace them. So, if an MI has a particular stack it won't change, even if the config changes. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX service architecture: next gen++
|Implementation model | |Let's start with the basics. The JMX MBeans in JBoss are all based upon |the Standard MBean model. This has worked well, and is especially a very |lightweight and simple way to make components manageable. The downside |is that you can't add very interesting metadata and custom call |interception (such as per component security checks) without going I agree with the first one not the second one... but that is a minor point. You just mean that invoke() is a more natural way to String together detyped services but you could argue that for the price of putting the Dynamic Proxies right behind the standard MBean interface you can generate the same invoke() call and thus string a stack behind it. You can only do that if you are in control over the MBean instantiation and registration. If you want to make generic MBeans that do not depend on the JBoss infrastructure this does not hold. It is not very standard-ish. |through hoops. I've decided to use a different model that uses all three |types of MBeans, but which makes use of the benefits of all while still |being easy to use. uh oh... sounds like an excercise de style hmmm let's see if I can use all of the beans of the specification It just means that all three models have pros and cons, and the cons of each model is being fixed by one or a combination of the other two. I didn't start out with let's see if I can use all three models, humdidum. So the DynamicMBean implements the invoke() interface and the invoke() interface is then delegated to an instance of RMM which has instances of a class provided by the programmer. Correct. The mapping of the invoke() to the POJO... is a bit obscure at this point. This is done by the Model MBean. That is one of the big points of Model MBeans. To map invoke()'s to POJO's. Read the spec please. |Note that the POJO case in this model does not have to know *anything* |about JMX. All of the JMX-ery can be dealt with by the ServiceSupport |subclass. Anyway, so this makes use of all three models and retains the Instrumenting without JMX knowledge is good but if that is the goal (which I doubt) One of the goals is indeed to make the MBeans, or services, as JMX-ignorant as possible in order to make them easy to write and also to make things about managing the MBean as reusable as possible. then there are other easier ways to achieve this (see upcoming Juha's Book ;-) by extending even the *binary* itself. What do you mean by extending the binary? |* The easy-to-use mapping between dynamic calls and reflection |invocations on the service object of ModelMBean's. That I don't see What is obscure? Mapping dynamic calls to reflective invokes is the most important task of the Model MBean model. |* The easy-to-implement style of Standard MBeans. sure. Listen kid, using all the features of the spec is pretty cool, but is it really necessary. No, nothing is necessary. But doing it makes it as easy to use as possible. |* Need to map dynamic invokes of Dynamic MBean to reflective calls - |solved by ModelMBean model I see so the MM calls his POJO by reflection and you build the adaptor in there. The MM *is* the adaptor. Do you know what ModelMBeans are about at all?? |* Need to implement dynamic invokes of Dynamic MBean - solved by |Standard MBeans in conjunction with ModelMBeans model dynamic invokes of Dynamic MBean ;-) huh you are going to have to explain that one Rickard it sounds kind of silly as I read it. If the MBean that is registered in the MBeanServer is a DynamicMBean you will be getting invoke() calls from the server. What do you do with that? Simple: delegate to a Model MBean instance that converts that invoke() to a reflective call on the Standard MBean that contains the actual implementation. It is really really basic stuff here Marc |Configuration |= |The way configuration works in this scheme is a little different from |how it works in JBoss. In JBoss the Configuration MBean is pretty much |dictatorial in that all MBeans must be configured through it. This is |not how the JMX spec intended it to work. The Persistent MBean interface |is there so that load() and store() can be called, and *if* the MBean Does that remind you of anything? come on... What are you referring to here? I've browsed through the new ServiceController/ServiceConfigurator stuff, and it still seems to be the way it used to be, i.e. it mandates that MBeans are configured through the XML mechanism. Am I missing something? Is JBoss indeed calling PersistentMBean.load/store somewhere? I couldn't see it anyway... |wants to it can ask a central Configuration MBean, but it can also do |whatever config reading it wants instead or additionally. The |configuration MBean in my implementation still reads services.xml files |and creates beans, but then it only calls load() which allow the MBean Not exactly. The load() store() is there to allow the component itself to
Re: [JBoss-dev] JMX service architecture: next gen++
|You just mean that invoke() is a more natural way to String together |detyped services but you could argue that for the price of putting the |Dynamic Proxies right behind the standard MBean interface you can generate |the same invoke() call and thus string a stack behind it. | |You can only do that if you are in control over the MBean instantiation and |registration. If you want to make generic MBeans that do not depend on the |JBoss infrastructure this does not hold. It is not very standard-ish. Either that or you control the JMX infrastructure, a JMX server that includes the externalization of stacks of JBoss would do just that. That's true. So, you want to replace the RI then? | then there are other easier ways to achieve this (see upcoming Juha's |Book ;-) by extending even the *binary* itself. | |What do you mean by extending the binary? read the book Ah, ok. Very informative answer. Does this mean there's no one-liner reply, that you don't think it's worth the effort to answer properly, or that you don't know? |Sure, that could work. Still, I don't see in current JBoss 3 code |where this |is left to the individual MBean to decide. It seems like JBoss mandates the |configuration to come through the SAR stuff. The stuff that does that is the XMBeans of Juha's upcoming book. .. which is similar to what I have described, right? |It seems like what I have done is very similar to what he has done |(based on |his descriptions anyway). Which makes it kind of interesting why you're |dizzing what I'm saying, since you're on the other hand praising the very |same approach. I never did understand you dude... well relax... I am not dizzying you. I am praising the load and store in both approaches. The important thing is the beans dealing with their configuration semantics. Which is not how JBoss 2/3 works today. I was critizing the rest of the praise, in my mind the real pro here is the localized semantics. Yes, that MBeans can deal with their own configuration semantics. Right? *Which is what I said*geeezz... |wants to be able to start without a dependency having been resolved it can |mark it as not-required in the XML configuration. If an MBean is do you hold a bean until you get an event in case you don't have the bean yet? Not quite sure what you're asking about. Example: MBean A has a not-required dependency on MBean B, which is coupled to the attribute b. A can start without B being available or started, i.e. calling getB on A can yield null. When B is started the dependency is resolved, and setB is called with a proxy to B as argument. A may then use B. This means that A has to check whether B is set or not before it tries to use it. This is the semantics of not-required dependencies. |started and a required dependency becomes unavailable it will stop, unless it can find |another MBean matching the same ObjectName-pattern (this is the poor mans |failover part). hmmm interesting is this during run-time? Of course. so how does this work you recieve an event e.g. MBean A receives the event MBean B state is now STOPPING, i.e. B is becoming unavailable for A to use. and you stop the mbean e.g. A is stopped due to a dependency to B is becoming unresolved. and you control the reference inside the object (must be exposed) and you set it to the new MBean name... the reference of inter-bean is what? this is not clear. Do you call the bean directly do you call the server? You are talking about stateless stuff here obviously. These sentences make no sense to me. I have no idea what you're asking about. Can you be more specific. An example perhaps? Yes but that is inferior to rerouting on the server. Reread my mail. In my case the client is another server, i.e. I'm referring to MBean2MBean communication where the MBeans can reside on different servers. How is it inferior? |On the server side, yes, but that is worse because then the client is never |given the option of using another provider of the service. You are That is not correct. The client knows about different JMX node invokers. But you are then assuming that the client has to know about the concept of invokers in the first place. In my scenario the client MBeans only sees other MBeans and does not have to know about the underlying stuff, which could indeed be based on what you describe. Either you do it there or you do it in the bean, either way you need a way to describe the stack of interceptor to the bean (that would create it) or to the JBoss-like deployer. Correct. And if you do it in the server the MBeans that makes use of it are tied to the JBoss server, i.e. they are not portable to other servers. By placing the logic in the MBeans instead, i.e. in between the invoke() and the actual call handling, the MBeans become more self-contained. I prefer self-contained, unless there is a big win with putting it in the server itself. I am not following you. You keep talking about clients on the web with RMI
Re: [JBoss-dev] JMX service architecture: next gen++
not. The thing that is even more JUICE in there is that you now have a way to manage the stacks through the server *and dynamically*. For example imagine you want to add a metadata interceptor to a given bean. The thing that is interesting is that you can for example add a valve interceptor that gets in the chain somewhere (say beginning) and freezes the invocations and then you can put a new interceptor that does advanced security and defreeze the invocation and *remove* the interceptor. All through the servers infrastructure. That's important for the five nines, indeed. Or six or seven or how many nines you want. ahw wtf, nine nines.. that'd be something :-) Maybe one thing that is missing in the descriptions is that I view the invoke() of the beans not only as administration operations but really for ALL operations invoked in components residing in the server. +1. What we both like then is that the stringing of stacks together in front of the target bean is a task that can be taken care of in a generic fashion in the server (JMX/JBoss base).As an application example, putting together an EJB is no different that putting together any type of bean and essentially means, put the following stacks in front (the role of the container factory today). Meaning that any MBean can take advantage of the tx and security stacks. NOW WE'RE TALKING. Because the EJB model, as some of the listeners are aware of (Hi Sean), does have some serious flaws as a *practical programming model*. Can you say over engineering. Knew you could... If you can make the EJB interceptors - which is really what is the real deal with EJB - available as a generic MBean stack that will be very useful. (understatement of the day) More straightforwardly, making the MBeans more self-contained ranks a 2 (on a 10 scale) on my good idea for administration list. We could use the MBeanInfo to describe the stack but the mechanisms to do it gain enormously by being in the JMX base. Don't you agree? I think I'm still leaning more towards doing what you describe as MBean Adaptors, but the problem with that is that you'll practically flood the MBeanServer with interceptor stack Adaptor MBeans. Which is not good. Hm we agree then. Using jini as a server side watchdog, might be a nice thing as it automates the lifecycle - event generation plumbing. Precisely. I will take a look at it in this frame of mind. As a way to expose services to the wider world I think it absolutely sucks (I could be wrong). 100% agree. It wouldn't scale. |For the *end-user client* stuff your invokers et al becomes much more |interesting. Absolutely. Refine this... it is interesting even on the server side, where you can for example schedule asynchronous shuttle-bundles between nodes for messaging. Meaning there are a lot of optimizations that you can do at the communication level with a DETACHED/ABSTRACTED invocation layer inter-JMX nodes. What I meant was that for the end-user client your stuff is interesting, and it's interesting for server2server talk *too* :-) The Jinification I talked about is just one method of intercepting, one possible stack, and not a replacement for you describe. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] when updating jboss/manual
marc fleury wrote: jason, to be very honest I don't think it is a good idea i mean updating the website and each time going through the xdoc generation is a pain. Yup, that is a bit of a pain. Have you guys tried Mozilla lately? It has a demo where they use an XML file that is rendered directly in Mozilla using CSS, i.e. there's no need for an HTML generation step. Just point Mozilla at it, and there it is. Pretty neat. I know this won't work for public docs for awhile, since not everyone will have Mozilla or an other browser with similar capabilities, but it should be very useful for in-house documentation using DocBook. /Rickard ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Off-Topic: Mangement of Java Classes through SNMP
Hi! This looks very interesting!!! Have you tested it with JBoss though? I browsed in the docs and couldn't find anything about JMX. /R Jason Dillon wrote: http://www.opennms.org --jason On Tue, 25 Sep 2001, Andreas Schaefer wrote: Hi Geeks I am looking for information how Java Classes can be managed through SNMP (I know this sounds ugly). Does anyone has some info or a link about this ? Andy ___ 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 -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Optimized EJB calls in catalina
Scott M Stark wrote: I looked at integrating the catalina final release with integrated security and JNDI and I find that everything works except for optimized EJB calls. Did you use the updated Catalina support that I've added? /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JSR/SAR (Jetty) Undeployment...
David Maplesden wrote: Ahh, this is a bug I came across about two weeks ago when developing my own mbean. It is actually a bug in the MBeanServerImpl when working with mbeans that use the default domain in the object name (i.e. :service=Jetty instead of SomeDomain:service=Jetty). It fails to find the mbean when it tries to unregister it, even though the call to isRegistered(mbean) returns true. Put a domain name in your object name the problem goes away. Or use MBeanServer.getDefaultDomain() to get the name to use as domain name. Recommended workaround. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Tomcat4 integration
Hey I just got the Tomcat4 integration to work. I have updated the Catalina sources in the contrib CVS module. Build the tomcatservice target and put the embedded.jar file in /lib/ext. You can now deploy EAR files with WAR's that get deployed to Tomcat4. Use the instructions in the readme for setup. I have not yet looked at security, EJB JNDI-reference, or jboss-web.xml integration. But at least it works now. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JINI - JavaGroups - Whatever: real issue?
Peter Antman wrote: Hi Jason, have you personally used JINI? Have you set up a working network with JINI nodes? Ok, I am not expert on JINI, but I do know that when I was trying to read into it I several times stumbled on to the following type of informations: - Yes, JINI is verry cool, but we have never gotten it to work. Which has more to do with sucky tutorials and hard-to-use implementation rather than Jini. I've made Jini to work; wasn't trivial, but wasn't that difficult either. - Hey, my hello app does not work. Mine does. See the chapter in Mastering RMI on Jini. Help on how to set it up is included. - Well, have you patched your linix kernels, have you spoken to the router people to put on broadcast. We're talking clustering, so for most cases I'm assuming that this will be used for single subnets only, i.e. no router changes needed. However, if you really want to use it over subnets, no problemo, either use Unicast, or set up a bridge. Yes, that type of stuff: If this is still true, that you have to go around an put in broadcas support in all your nodes and routers, then a think JINI, or any technology based on special os configuration needs, is a good choice. This is pure FUD. Just drop it. Or has things changed? Am I just naive and uninformed? Yup, that seems like the case. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JINI - JavaGroups - Whatever: real issue?
Jason Dillon wrote: What are the exact licensing issues with JINI? Can anyone explain them to me in non-lawyer speak? The only issue is with redistributing the Jini binary. That can be fixed by getting a commercial licensee agreement with Sun (no fee involved, just papers), something that The JBoss Group can easily get. If that's not done, then users have to download Jini binaries separately. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JINI - JavaGroups - Whatever: real issue?
Peter Antman wrote: Otherwise multicast/broadcast won't work, and that there is no difference in that regars between using JavaGroup and JINI? Not really, except Jini can use Unicast as well. Multicast is bonus, but not required. I don't know about JG on this point. /R -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JINI - JavaGroups - Whatever: real issue?
Hi! Jason Dillon wrote: Otherwise multicast/broadcast won't work, and that there is no difference in that regars between using JavaGroup and JINI? Not really, except Jini can use Unicast as well. Multicast is bonus, but not required. I don't know about JG on this point. But unicast does not help with clustering, we want multicast. Well, you still get the leasing support, it's just that you need more admin to get it going (pointing out all nodes, etc.). Using multicast is more admin-free, but it's not much more than that. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JINI - JavaGroups - Whatever: real issue?
Sacha Labourey wrote: Nevertheless, as you probably know, when doing clustering we also need some advanced communication semantics. We need to be able to know which message has been received by which member in which order (for example). A cluster where invocations cannot be received in the same order by each node, when you do not know which node has received which message, ... is not a very usefull cluster IMHO. You are making way too many assumptions about how to implement the cluster here. There is no inherent need for what you describe. And this is JavaGroups job. JG provides memberhip protocol, state transfer protocol, group views, group communication, ... JG also provides a kind of discovery ;) : you create a group with a particular name, and you then are able to use extended communication semantic in the group, get state transfer events, membership events, ... There is a lot of complexity inherent in what you describe above. I doubt that most of that will be useful. And I'm assuming we're talking about clustering the EJB container here. For the JMS stuff the above will be more interesting. KISS. (because we do need this communication semantic). Can you explain why and where this is needed? It seems like this depends on a particular implementation strategy. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup andJBossMQ)
But you really don't know what you are talking about when you talk about transactions? Is this a question or sarcasm? I just can't tell... /Rickard ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup and JBossMQ)
Andreas Schaefer wrote: Forgive me when I am wrong but JINI and JMX have some similarities but mostly they are quite different. Exactly. JINI allows to create a dynamic community where services can appear or disappear and the services get notified dynamically. You can also search for a service w/o knowing the implementation like you want a color printer but you don't care which one. JMX allows you either to offer a management interface or to use the offered management interface to manage the components. BUT JMX works locally and have no notion of a network. You can add an Adaptor and/or Connector to manage remotely but there is not further description on the spec. (and most people mix up the Adaptor and Connector as well). One similarity is that you can search for a component according to its properties, of course, only when the properties are set well. Yup, that's it. JINI would allows JBoss to create a dynamic community of J2EE servers and JMX would allow us to manage the components. Precisely. This leads me back to my proposal of generating a collective of servers (yeah, your right, the BORG collective, because each server should know the whole configuration allowing the collective to work even when a member dies or is temporary unavailable IN CONTRAST to the community of specialized servers like Master/Slave model) where JINI build up the collective and JMX is the communication channel. Which is very similar to what I proposed I guess it was a year ago when I started rambling about Jini for clustering. I'm all with Andy on this one. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup andJBossMQ)
Jason Dillon wrote: David Jencks wrote: I still don't understand how jini and jmx can relate. They seem to me to be unrelated and non-interoperable implementations of to a large extent the same functionality (as far as finding stuff, not failure recovery in a distributed environment). JMX handle the internal interface of a service (configuration, lifecycle) whereas Jini handle the external (providing API, finding other services' API's). Complementary. Also, some things in JMX can be implemented using Jini, such as adaptors. What about events? Same thing. I'd use JMX events for things related to lifecycle things, but Jini events for implementing actual functionality provided by the service. MBean, which is mostly a local concept, whereas the API is/may be a distributed thing. JMX could be used more like a Jini system too. The MBeanProxy stuff is a great example of that. The only difference is that JMX needs a name, dynamic proxy needs an interface. Well, there's more to it than that, since Jini has better support for the services behind the proxy going down at any time. The leasing system is very very powerful. Handling this in JMX takes more thinking I believe. The network is the computer, the computer is the network, who cares... java lets you do cool things. Admins across the planet (perhaps beyond) will be greatful for millenia to come. Assuming we can get of the planet before the sun goes red giant =) Assuming that there will be a need in the first place to get off the planet if the Sun goes red giant.. but that's another issue ;-) JMX provides a local namespace and flexibility for integration. Jini provides a network, global or rather grouped namespace. Jini is to packages, as JMX is to classes. I believe that's an ok analogy, yes. The way I see it the services themselves are packaged as JMX MBeans and use JMX for internal stuff, such as configuration and lifecycle. Things that relate to the service as being a service. The Jini stuff is more for what the service actually *does*. The service API's it provides. Because of this I don't really see a vs relationship between JMX or Jini, although I guess you could adopt that standpoint if you wanted to. How does a JMX serivce interact? Throgh JMX api's or Jini API's. In other words, if service0 depends on service1 and service2, does it access them through the MBeanServer or by looking up the service interface ala jini, then use RMI semantics to process any reqests? I'd prefer Jini lookups. Note that what you get from the lookup service *does not have to be an RMI object*. Heck, it can just be a Plain Old Java Object (POJO, tm Martin Fowler) that implements all of the stuff locally. That's the beauty of Jini: it *can* be distributed, but doesn't have to be. Having a method throw RemoteException only means that the method *may* be remote, but it doesn't have to be. What about leasing? or events? What about them? How could we replace the JMX event/notification fluff with something backed up by a topic? We could link JBossMQ instances via there group namespace, then configure links between groups and provide a routing mechanism. Now we have a distrubuted event system which we can use to provide os level services to the nodes in the cluster (configuration notices, node activation or rather when a node accepting client connections). Yes, that could work. You could even use JBossMQ as the backbone for a Jini event handler. Would work quite nicely I believe. How does Jini make JBoss a better platform for writing applications? Because it makes servers aware of other servers more easily, and services aware of other services more easily. Plus, another very important question is: how does JBoss make writing applications in Jini better? Looking at the Jini community, and having talked to Jini folks on this topic recently, it is now very easy to write clients and services in Jini, but it's still pretty awkward to actually run the damn critters. Enter JBoss, which can provide all the gory stuff (conf, lifecycle) that they need. Package the Jini services as MBeans and off you go. Very very nice. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Deployment Dependencies (was RE: [JBoss-dev] RH startupandJBossMQ)
Peter Fagerlund wrote: How does Jini make JBoss a better platform for writing applications? Because it makes servers aware of other servers more easily, and services aware of other services more easily. JINI is broadcast so is JavaGroups - one is licenced one is open ! Oh please. Jini is also open: you get the code, you can distribute your apps, you can distribute the Jini binary, etc. Please read the Jini FAQ or licensing stuff before making these kinds of comments. No FUD please. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup andJBossMQ)
Jason Dillon wrote: It can simply be a serializable? Yes. Any object is ok. An RMI stub *happens* to be one such case, and most people seem to assume that this is what it *has* to be. Not so. How about resource control? I guess you would implement that at the stub level? If I want a machine0 to allow 10 clients to use it's service0 and no more... what do you do? Implement a semaphore in my service. Trivial. This could even be done once as a proxy service. Hm.. cool... What about leasing? or events? What about them? Wondering if you had anything to say about it. Likes, dislikes, ideas, improvements, prodding you to drop some knowledge =) Leasing is what makes it all work. The fault tolerant in Jini == Leasing. It's brilliant. Events are cool too, but they're not very fancy in their design, by design, so you may want to use JMX for the implementation if you want particular high-end features. Plus, another very important question is: how does JBoss make writing applications in Jini better? Looking at the Jini community, and having I was a bit taken by the whole rmid thing Another misconception. You don't *need* rmid, it's just that every freakin tutorial uses it. Argh...insanity seems to be contagious.. it just starts and spirals us down into confusion la la land... , the install the service, Enter SAR's. leave it. Perhaps I am old fashioned but I like to start with a clean slate every time and remind the server what it should be running. Me too. Never use RMID myself. How does activation fit into this scheme? Does it? Well, you can use it if you want to, but I just found it awkward to use. If you want long lived service identities, fine, but otherwise I'd go with plain service rediscovery. talked to Jini folks on this topic recently, it is now very easy to write clients and services in Jini, but it's still pretty awkward to actually run the damn critters. Enter JBoss, which can provide all the gory stuff (conf, lifecycle) that they need. Package the Jini services as MBeans and off you go. Very very nice. In your opinion; What needs to be done to make this happen? Hope and promise are prevalent, but there must be order to take an idea and turn it into a reality. When the service deployment stuff in JBoss3 stabilizes that should be pretty much it. MBean wrappers for core Jini services such as the LUS and transaction service would be nice. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup andJBossMQ)
Jason Dillon wrote: FYI I am not against JavaGroups. I have read up on Jini, found it quite meaningful. How does Sun expect it to take off with a restrictive license. What is restrictive in the license? What are the differences between JavaGroups and Jini? Jini is this: * Discovery * Lookup * Events * Transactions * Leasing * Very nice helper tools to make it all easy to use All of those are core pieces in getting fault tolerance going. Does JG have all of that? Toasters have nothing todo with it; that is just plain silly. The toaster hype is harmful to the education of the public. If not for the simple fact that toasters et al won't be able to run Java VM's. Boy what a marketing blunder that was. /R -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Deployment Dependencies (was RE: [JBoss-dev] RHstartupandJBossMQ)
Peter Fagerlund wrote: Oh please. Jini is also open: you get the code, you can distribute your apps, you can distribute the Jini binary, etc. Then maybe We could buy a copy of JDMK and use SNMP ? ... JDMK also gives You the code - you can distribute your apps - you can distribute the JDMK binary ... You don't have to buy Jini. What's your point re: JDMK?? Please read the Jini FAQ or licensing stuff before making these kinds of comments. I read the FAQ ++ - and was impressed by the copy - but - since I was then looking at a way to have self-discovery over geo spatial boundaries, I ditched JINI ... becouse of its bradcast nature ... If you want Jini discovery over large distances (=multiple subnets), simply use a bridge. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup and JBossMQ)
marc fleury wrote: | ?xml version=1.0 encoding=UTF-8? | server | | dependsJBOSS-SYSTEM:service=Naming/depends | dependsJBOSS-SYSTEM:service=AnotherService/depends | | classpath archives=jbossmq.jar/ | | mbean code=org.jboss.mq.server.JBossMQService |name=JBossMQ:service=Server/ | | *snip*snip* | | /server Sometime in a bright future this, and the actual service config stuff, really should be in RDF (http://www.w3.org/RDF/). It would be very very cool as it wouldn't then be XML-dependent, i.e. you could store it in the-whatever-store (e.g. LDAP, e.g. RDBMS). Thanks that is an easy solution. You will create a graph of dependencies in the service controller. It was needed for the longest time. If I remember correctly someone coded that long time ago and you might find a trace of the dependency manager somewhere in the attic. I implemented this in my XS server (google on it to find it :-), and it was one of the things I've been missing in JBoss. Should've been done properly ages ago. My own vote on my own suggestion at this point is thumbs down for the simple reason that the explicit MBean dependency is simpler for us to code. So go ahead with your idea, XP. Yes, explicit is probably better. It is simpler than ClassLoader dependency graphs that a certain Rickard Oberg was advocating ehrm.. wouldn't say advocating, more like mentioned as a possibility. Aaanyway. for administrators to build, but it is still MBean dependencies built by administrators when we could do away with it. I don't see a problem with requiring that administrators be aware of what services depend on what services. It seems like a natural task, jason? I'd like to pop in a thought from the Jini-line of thinking: in Jini you don't specify what services you want, instead you say I want something that looks like this. Of course, if you specify enough you will end up with saying exactly which service you want, but that's not the standard case. The J2EE way, or rather the JNDI way, is to say I want the object named X, so there's no flexibility. You know what you want, and that's that. It's rather uninspired IMnsHO. So, one could adopt the Jini way and let the developer of the MBean, not the administrator of the server, say This MBean depends on the availability of other MBeans looking like this and this. That could be expressed either in code, or in XML. The key point is that this shouldn't really have to be done in the configuration of the service/server, because it involves knowledge that the admin really *shouldn't have to have*. Also, one could argue whether to put this in the MBean itself or in a separate MBean. Inside the MBean would mean that the MBean itself could be put into any other server and still function, whereas in a separate MBean would then require that this extra MBean is also deployed in the server (which may be != JBoss). Actually, one could have the same argument about the configuration persistence. Currently the JBoss server pushes config to the MBean, whereas it is much more portable to let the MBean pull. And I believe the JMX spec actually promotes this way of doing it (look at the PersistentMBean/ModelMBean interface). That said, the actual MBean could still be using get/set methods, it's just that the MBean itself uses some util code to get the config and call these methods by using reflection on itself. The result is a more self-contained MBean that can live in a more core JMX environment. Wouldn't that be just cool. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup and JBossMQ)
David Jencks wrote: Maybe it's my lack of imagination, but I'm having a hard time seeing how to combine JINI discovery/lookup with jmx mbean calls. I do wonder how much of what you are thinking of can be done with disciplined use of object names and mbean queries? Probably most. It's just levels of flexibility and dependency: either you say the exact service *instances* you need, or you specify the service *types* you need. For most cases the explicit way will probably work well, whereas it is possibly more selfmaintaining to only be dependent on service types. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is mail return acting peculiar?
Scott M Stark wrote: I haven't changed anything. Perhaps the sourceforge defaults have changed. Looking at the list admin page the default, and in sourceforge words strongly recommended, is to reply to the poster. All SF lists have been screwed up lately (all other SF projects I'm running too anyway). Use the mail admin to set back to list reply. Reply-to-poster is just annoying :-) /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] The Rabbit is out of the bag
*CHEERS* *APPLAUSE* *HOORAY!* Absolutely fabulous! Now I don't need EJB's anymore, just plain jane MBeans and JDO will do the trick :-) Maybe a twinkle of Jini just for fun. And it's...ahhh.. manageable... :-) /R -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] The Rabbit is out of the bag
Jason Dillon wrote: don't need EJB's anymore, just plain jane MBeans and JDO will do the trick :-) What deals with transactions? Either do JDO transactions manually, or make a simple generic proxy that deals with it by calling JDO transactions or JTA. Do you think you have lost anything? Nope. EntityBeans - JDO, stateless session beans - POJO's (Plain Old Java Objects). Stateful session bean stuff is done in web session. I've gained a lot though, since MBeans are inherently more manageable (how do you manage/configure beans at runtime? you don't!), and there's no distribution which means I can drop all the value object nonsense. Maybe a twinkle of Jini just for fun. And it's...ahhh.. manageable... :-) Jini sounds like an ideal way to group together JMX Agents. As well as building a fault tolerant distributed event system. It is indeed so. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] The Rabbit is out of the bag
Jason Dillon wrote: Hrm... not sure how to to that really. Wouldn't the client still be required to manage references to tx mgr, to add objects that will be managed? All of that is done by MBeans, i.e. the client does not have to know anything about JDO or tx's or anything. Perhaps if there was a thin proxy layer which automated this. Correct. What about the configuration of a given deployment? EJB lets you write components which are not directly assocated and link them together via deployment descriptors. In reality you have to write a factory object to access them anyway, so that factory can take care of any such configuration management. I guess with the new deployable services system, a similar linking scheme could be employed. But still let that configuration and linkage be changed (or specified) at runtime. Exactly. I have not done much JDO. Do you provide the jdbc/sql or is there a subsystem that simply takes your object and persists it? This depends on what you use as JDO store. JDO may work with JDBC/SQL, but that's just one option. In my case I will persist it as RDF in XML files, and in LDAP. The JDO RI has pluggable state managers (but the license is still bad though, so it's a wee bit in the future right now). /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: How about a JBoss-2.6 release?
marc fleury wrote: sure thing! why don't you submit that :) you are about to lose your rw passwd for inactivity in JBoss, you know we have the 3mo rules of contribution for active developers. I know, and it would be kinda sad to loose the rw 8-) /R -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss and Catalina
Hey I have managed to get JBoss working with Catalina. The Catalina code is terribly hard to read though, since it uses its own SAX-handling framework, which doesn't work too well. The formatting is not very nice either. Are the authors of that code still here (Roberto?)? Otherwise I'd suggest a refactoring of that code somehow. Anyway, I do have JBoss 2.4 working with Tomcat 4.0b7. Should this be bundled up somehow as a binary? I think more people will be interested in it. regards, Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss and Catalina
Nick Betteridge wrote: Sounds good - I'm certainly interested. Did you manage to set up JAAS/JNDI etc to work with jboss? Nope, just basic deployment. That was frustrating enough. One step at a time. /R -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: How about a JBoss-2.6 release?
marc fleury wrote: 2.4 is going to be the stable one but 3.0 is 2.4 with new features (IIOP, qualityMQ, CMP, cluster, Microkernel, http based install) Does this include what we loosely called .sar deployment (i.e. Jar file with MBeans and jboss.cfml/services.xml in it)? That would be so cool. :-) BTW, in my current project we have dropped EJB's in favor of MBeans + Jini. So, the EAR hot deployment is not so interesting, but .sar hot deployment would be :-) /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: How about a JBoss-2.6 release?
marc fleury wrote: |Does this include what we loosely called .sar deployment (i.e. Jar file |with MBeans and jboss.cfml/services.xml in it)? That would be so cool. |:-) yep. If you do, please look at the Service provider API in the JAR specification: http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Service%20Provider Not quite sure how to use it, but something like calling the file META-INF/services.xml would probably be a good idea. You took the infrastructure so far with the MLet but making the stuff really hot deploy is really a pain, the MLets don't work. I now understand why you took the december argument on our research so personally, you had in fact ran into these problems during the JMX design. You should have corrected me when I said we would not use this EVER in our codebase ;-) it's the building block. I should have known, research is never intellectual curiosity but almost always finds implementations in places we expect it least. Ah well, it's on track now at least :-) You will see, I will try to commit very very soon (I know I have been saying so for the past 2 weeks) but the MLet stuff is replaced by a ServiceClassLoader tightly coupled with the MBean/url approach... I think you will like it, if you understood Dr Jung's work (did you?) Sounds very very nice :-) A simple work. I take what you had pionneered to its real final form and its logical conclusion. The microkernel stuff is real and solid imho, even if it doesn't look like much, it is, I like to believe, ground breaking work. Yes, agree. Now, couple that with a Jini-based deploy interface and you have something really interesting. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: How about a JBoss-2.6 release?
marc fleury wrote: |Now, couple that with a Jini-based deploy interface and you have |something really interesting. what do you mean, expand Well, it's how the actual deployment step is done, i.e. getting the JAR to the server. With Jini there are two ways: 1. Use pull: each server has a Jini service that listens for available JAR's from a central repository, which is found form the LUS (Jini LookUpService, similar to JNDI but more dynamic). When a JAR is added, it is downloaded and deployed. 2. Use push: each server has a Jini service that one can call deploy(URL) on. The deployer tool can find the servers by looking them up in the LUS. 1. is good because you just say here are the JAR's to be used for this cluster, i.e. put them in the central repository and let the servers find them by looking them up. Whenever you start a new server it will load them automatically, i.e. you don't have to deploy them manually. 2. is good because you get immediate response whether the deployment succeeded or failed, and you have more control over when the actual deployment is done. Both are useful, and they're not exclusive, i.e. both can be used at the same time. More clear? /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] A new user interface for JBoss
Peter Fagerlund wrote: On Wed, 8 Aug 2001, Schaefer, Andreas wrote: When you want to reanimate EJX please do so but keep in mind that this is a big job and we need someone dedicated to it. on 1-08-10 09.16, Holger Engels at [EMAIL PROTECTED] wrote: BTW, where are the sources for the EjbJar ResourceManager? I only found jBossEjbJar and decompiled the ejxejb.jar Some of the EJX parts is closed source ... EJX is OpenSource, BSD license. What parts do you think are closed source? /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] A new user interface for JBoss
Peter Fagerlund wrote: some dreambean stuff - or that was my understanding : 1) becouse it is mentioned on this list (old JBossGUI = closed source) That's a lie. It's BSD. Download source from http://dreambean.com/ejx.html 2) when i looked at the distro could not find source - lot of barfing - had to add some obscure .jar So, does this reasoning apply to all .jar files in JBoss that do not have their source in JBoss CVS??? Come on... /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] A new user interface for JBoss
Peter Fagerlund wrote: I was refering to : Re: [JBoss-dev] EJX and XML on 1-06-25 19.30, marc fleury at [EMAIL PROTECTED] wrote: yes EJX doesn't really belong here anymore. Also rickard is not supporting it, it doesn't really work, and finally they are com.dreambean classes not JBoss open sourced. From memory I must have confused not JBoss open sourced with it not being open sourced - and at the time I did not se any reference to Download source from http://dreambean.com/ejx.html - my mistake - sorry ... Yes, I can see how it is possible to interpret it that way. No problemo. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss+Tomcat 4
Hi! Since Tomcat 4 is now vastly better than Tomcat 3.2, I think it is time to make a binary with JBoss+Catalina. There's a lot of goodies in Catalina (newer spec compliance and performance) that would be nice to rely on in my web app framework WebWork, but without a binary distribution of JBoss+Cataline it's not very interesting since people will find it too difficult to set up on their own. How hard would it be to add this to the binaries? /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss+Tomcat 4
Dan - Blue Lotus Software wrote: Has anyone integrated them yet? Or are you suggesting a 2 VM implementation of JBoss+Catalina? Well, there is a Catalina plugin in the contrib module. I have no idea about its status though. If it is good, then go! :-) It might be outdated though. Starting from scratch using the Tomcat 3.2 plugin as base might be a better idea. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ditch entity locking in favor of select-for-update
The recents questions posted by James Cook got me thinking. Maybe we should ditch the current entity locking scheme in favor of using select-for-update. It would greatly simplify the entity/cache locking mechanism, thus probably making it much more robust than it currently is. Of course, we'd have to improve select-for-update so that it worked across a greater range of databases and keep the old entity/cache locking for databases that didn't. Also, what about BMP? Does the spec allow for the container to pass on synchronization responsibities to the Bean Developer? I'll have to check. Note that not all Entities are backed by DBMS's. In the app I'm working on currently they almost never are. Instead, I'm using XML files as the backing store, so using select-for-update is not an option. /Rickard ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why doesn't Container implment ContainerInvokerContainer?
Scott M Stark wrote: Another issue is why doesn't the Container class implement ContainerInvokerContainer? This is the assumed behavior as evidenced by the prevelance of unsafe downcasts scattered throughout the container invoker code: The reason for the separation is(was at least) that MDB's aren't ContainerInvoker-invokable, i.e. they have no remote interface and such. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why doesn't Container implment ContainerInvokerContainer?
Hi! Scott M Stark wrote: That makes sense, but the current MessageDrivenContainer is the one that does implement the ContainerInvokerContainer interface and then decides to void the contract by throwing Errors. That is one way to do it to. If you let MessageDrivenContainer implement CIC, then there is no need for the CIC interface. Then remove it, but instead of using Error's it might be a better idea to use the java.lang.UnsupportedOperationException. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] new Threads.java (cache bug tests) is incomplete.
marc fleury wrote: |For objects that do a lot of stuff in set*Context, yes. Common |operations are lookup of home objects, and to create data structures. In |those cases pooling is essential. it is the ***reuse*** that really fucks us up. We can prefab some instances and keep pools at a minimum level but no reuse. So you would say that a pool has a minimum of 10 instances in there and a thread would create the instance and replenish the pool, maybe a static thread in the class could do the trick. That could work, yes. If you do on demand it's back to wait-on-init-land, but replenishing in background could be ok. /R -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] new Threads.java (cache bug tests) is incomplete.
Bill Burke wrote: Yeah, I guess it's cool now that you removed InstancePooling. God, pooling just fucked everything up and caused a lot of complexity. I wonder if pooling actually had any effect on performance anyways? For objects that do a lot of stuff in set*Context, yes. Common operations are lookup of home objects, and to create data structures. In those cases pooling is essential. I assume that pooling is still optional, for those cases that need it, yes? /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ONLINE FORUMS
marc fleury wrote: go try it out... it is working really well, go post questions there... http://www.jboss.org:8081/jive It would be cool if it eventually used WebWork based skins. :-) Maurice Parker has been working on that, and it's very easy to customize AFAICT. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] EJX and XML
On Mon, 25 Jun 2001, Rickard Öberg wrote: AFAICT the only problem in integrating with Tomcat is the whole ClassLoader architecture. AFAIK no it isn't. That was nailed ages ago. Works great. What doesn't work great is Tomcat. It's dead slow. Do some benchmarks and be disturbed. /R ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] EJX and XML
There, I said it, it pisses me off. The J2EE stack is a dream but nothing more unless Tomcat is fixed. Which is why Jules has been busy getting Jetty working. Let me be more specific then: unless Jasper is fixed (which Jetty uses too). There is work underway to correct this, but it'll take some while before it is done. And until then performance is not exactly stellar. /Rickard ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] EJX and XML
On Mon, 25 Jun 2001, Rickard Öberg wrote: AFAICT the only problem in integrating with Tomcat is the whole ClassLoader architecture. AFAIK no it isn't. That was nailed ages ago. Works great. Except that Jasper has different behavior when it compiles JSPs than when they're run. (the classes in ejb-jars in the ear are available at run time, but not when Jasper is compiling.) Ah, good point. Since I'm only using tag libraries I'm not affected by this, which is why I missed it. Tag libraries rule, as a concept, but the current Jasper implementation of it is not very good. /Rickard ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX in jBoss, Clustering, Monitoring, Failover, better bootstrapp ing via pluggable XMLet
Very very nice :-) Well done Stacy! /Rickard -- Rickard berg Software Development Specialist xlurc - Xpedio Linkping Ubiquitous Research Center Author of "Mastering RMI" Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [JBoss-user] The Weblogic to JBoss/Jetty experience.
Bill Burke wrote:
JBoss:
- We found that we needed to declare ejb-refs for referenced beans in
our jboss.xml and ejb-jar.xml files for JBoss to work with our Jars. We
did not need to do this with Weblogic. Maybe this isn't a problem in
JBoss 2.1?
The jboss.xml one is only necessary if you have several JAR's. Otherwise
it works with just ejb-jar.xml. Using several JAR's in an EAR should
work too (IIRC).
- For EntityBeans, we did not know that the EJB spec states that each
persistent data member of your bean class needs to be initialized in the
ejbCreate methods. We were depending on the initial values being set in
the declaration of the member variable . (i.e. class fooBean { int
m_SomeVariable = 25; }). This is not a problem with Weblogic 5.1
Because they don't use pooling. Simply set the pool size to 0 in
standard-jboss.xml for the same behaviour. If you need pooling, then the
WL 5.1 behaviour is gonna kill your performance.
- This problem almost caused us to ditch JBoss and buy Weblogic,
although it was an RTFM error. We're using JAWS and CMP and the default
for tuned-updates is false. When tuned-updates is false, every field
in the bean is updated in the database including the primary keys! When
you update a primary key you must obtain a write-lock on the index for
the table. This was causing deadlock in our application because we were
having one thread that was inserting into a table causing a lock on the
index and another thread that was trying to update a primary key that
was trying to get a lock on the index. The moral of the story is ALWAYS
HAVE tuned-updates set to TRUE! IMHO, tuned-updates should be removed
as a configuration parameter, or at least, primary keys should not be
updated if they have not changed if tuned-updates is set to false.
Otherwise, you're going to have dumbasses like me thinking JBoss is a
piece of shit, when it is plain user error.
PK values should not be updated, true.
- Another deadlock problem we had was that the default trans-attribute
for Weblogic is "Supports" for stateless beans, and for JBoss it is
"Required". Since some of our Stateless Beans where using entity beans
and we were assuming "Supports", we were getting deadlock everywhere.
It is not clearly stated in the JBoss documentation that the default
trans-attribute is Supports.
True, that should be documented better.
Jetty:
- With the Weblogic 5.1 JSP engine you can do jsp:includes and then do
a jsp:forward or a redirect. With Jetty and probably Tomcat, since
they both use the apache Jasper engine, jsp:include causes a flush of
the output buffer and commits the request. Thus you can't do a
jsp:forward or a redirect.
The Jasper engine is flawed in many ways, true. This is one of them. (It
sucks performance-wise too).
- errorPage will not work if you have already have had a jsp:include
since the buffer get's flushed.
- To get the Jetty/Jboss integrated VM to work you must load your
application's non-ejb-jars and classes through the ClassPathExtensions
in jboss.conf. Don't have your application's jars/classes in the System
classpath
True, this is a common problem. I remember that we had a discussion
about whether to include CLASSPATH or not. I personally preferred not to
use it because it's error-prone, but it was decided to keep it (can't
remember why right now).
BTW, this story has a happy ending. We have successfully ported or
application from Weblogic 5.1 to JBoss/Jetty and are happy so far with
the move.
Well, it's nice to have it end good, but it's sad that you had such a
bumpy road. Hopefully some of the sillier items on the list will improve
as we go along.
regards,
Rickard
--
Rickard berg
Software Development Specialist
xlurc - Xpedio Linkping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
