Re: [JBoss-dev] [Fwd: [JBoss-user] Read-Ahead Cache Supports]
Alexey, Did you make this change or was it me? Either way, I think it is my fault as I was the one that re-enabled running with out a transaction and didn't add any integration tests. -dain On Friday, June 27, 2003, at 02:07 AM, Alexey Loubyansky wrote: That was me. I agree, we shouldn't force finders to run under active transaction. The reason for the change was a bug in cleaning ReadAheadCache. I'll look at it. alex Friday, June 27, 2003, 3:11:02 AM, Scott Stark wrote: SMS So why was this change made? There is a difference between yelling at SMS the user for running under a scenario with potentially n^2 related SMS performance degradation and breaking a working app. -- Scott Stark Chief Technology Officer JBoss Group, LLC Original Message Subject: [JBoss-user] Read-Ahead Cache Supports Date: Thu, 26 Jun 2003 15:47:23 -0700 From: Gavin Matthews [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] CC: Gavin Matthews [EMAIL PROTECTED] All, I'm upgrading from 3.2.0 to 3.2.2(RC1) and I hit an incompatibility with the new(?) ReadAheadCache implementation and the finder transaction type. Basically if I have a finder with transaction-type=Supports and use read-ahead-strategy=on-find then I get the following exception if I'm outside of a transaction: 14:43:55,968 ERROR [LogInterceptor] RuntimeException: java.lang.IllegalStateException: There is no tranaction associated with the current thread at org.jboss.ejb.plugins.cmp.jdbc.TransactionLocal.getTransaction(Transact ionLo cal.java:206) at org.jboss.ejb.plugins.cmp.jdbc.TransactionLocal.get(TransactionLocal.ja va:11 8) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache$ListCache.getCache(ReadAh eadCa che.java:624) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache$ListCache.add(ReadAheadCa che.j ava:570) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache.addFinderResults(ReadAhea dCach e.java:114) at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(JDBCAbs tract QueryCommand.java:207) at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(JDBCAbs tract QueryCommand.java:91) at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntitiesCommand.execute(JDBCFind Entit iesCommand.java:40) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntities(JDBCStoreM anage r.java:599) at org.jboss.ejb.plugins.CMPPersistenceManager.findEntities(CMPPersistence Manag er.java:324) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEn titie s(CachedConnectionInterceptor.java:323) at org.jboss.ejb.EntityContainer.findLocal(EntityContainer.java:604) The fix for me is trivial, I can switch to transaction-type=Required without any issues but I think there is a bug here, the ReadAheadCache should only be used if you're already in a transaction (the read-ahead cache strategy is forcing the transaction-type decision which seems wrong to me). thanks, gavin --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development /* * Dain Sundstrom * Partner * Core Developers Network */ --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
On Tuesday, June 17, 2003, at 12:58 AM, Bill Burke wrote: Not sure I like this idea. Tell me why we need to support 3.2 and 3.0 descriptors in 4.0? I'd much rather a 3.2 component crap out gracefully in 4.0 than have to maintain 3 separate configuration mechanisms. I wish we could get rid of the old stuff, but it is a requirement of the EJB 2.1 specification that we support 2.0 and 1.1 deployment descriptors. Also, one of the common complaints of the JBoss project is the changing of deployment descriptors and the lack backward compatibility. With XSL we can build the code to support on version and use style sheets to up convert old stuff. I do like the idea of having a metamodel separate from XML parsing. BUT STILL, it is quite easy to navigate the current metadata/XML marriage that now exists in current configuration. Are you sure we're actually gaining any maintainability by changing the status quo? I thought one of Scott's requirements was to remove reliance on XML in the metadata model for 4.0. Scott? -dain --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
On Tuesday, June 17, 2003, at 12:36 AM, Bill Burke wrote: Why? Because everybody is very familiar with them. Why? because its simple and easy to maintain and modify. Yes, the XML parsing needs to be moved to a separate module, but the classes themselves have held up fine. I will not allow you to add anything overly complex like the mess you did with datasources. David, you have never ever built a piece of software for JBoss that was even remotely intuitive to configure. Configuration is not your strength so please STAY AWAY from it. I'm warning you. If I see an XSLT translation anywhere within EJB land I will roll it back. Can we please dial back the personal and emotional issues and return to objective discussions of the technology? -dain --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Core Developers Network Announces Public Launch
Core Developers Network(TM) Announces Public Launch We are pleased to announce the foundation of Core Developers Network, a new services company supporting enterprise open source Java software. Core Developers Network is a partnership of peers with the guiding principles of integrity, openness, and fairness. Its charter is to provide a commercial infrastructure to enable open source contributors to deliver their professional expertise to the marketplace, independent of their contributions to open source projects. Many of our partners are core developers with cvs commit privileges on the JBoss project, and this enables us to offer a wide range of services geared towards the JBoss server, including professional documentation, training and expert support. The focus of Core Developers Network, however, is wider than just JBoss, and we have partners with cvs commit privileges on other projects including Jetty, Apache Jakarta, and XDoclet. Direct support is available today for these projects, as well as 3rd party support for several other Core Technologies (see www.coredevelopers.net for a full listing). We are committed to having the same level of involvement in our current projects that we have had in the past. This means that we will continue to work on the JBoss project itself. In addition, we will continue to support the JBoss project via the jboss-development and jboss-users mailing lists maintained by SourceForge.net, as well as any other open public forum. Unfortunately, the forums on jboss.org are a commercial venue for the JBoss Group LLC, and therefore we will not be participating in them. A few of our partners have offered support through the JBoss Group LLC in the past, but for various reasons have concluded that their professional aspirations would be better served outside of the JBoss Group LLC. In order to ensure that customers previously supported by our partners continue to receive the same level of high quality support, Core Developers Network is offering these customers a limited amount of free support during this transition period. We want to emphasize that our partners will continue to provide the same responsive, high-quality technical support as we have always done. The founding of Core Developers Network simply signals the natural emergence of competition in the marketplace. We hope that broadening the range of service options for open source projects will raise the level of support available and lead to even greater adoption of these Core Technologies. Please look for us at JavaOne booth 1705! Core Developers Network www.coredevelopers.net Jan Bartel Jeremy Boynes Remigio Chirino Jules Gosnell David Jencks James Stracham Dain Sundstrom Greg Wilkins --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Core Developers Network Announces Public Launch
Core Developers Network(TM) Announces Public Launch We are pleased to announce the foundation of Core Developers Network, a new services company supporting enterprise open source Java software. Core Developers Network is a partnership of peers with the guiding principles of integrity, openness, and fairness. Its charter is to provide a commercial infrastructure to enable open source contributors to deliver their professional expertise to the marketplace, independent of their contributions to open source projects. Many of our partners are core developers with cvs commit privileges on the JBoss project, and this enables us to offer a wide range of services geared towards the JBoss server, including professional documentation, training and expert support. The focus of Core Developers Network, however, is wider than just JBoss, and we have partners with cvs commit privileges on other projects including Jetty, Apache Jakarta, and XDoclet. Direct support is available today for these projects, as well as 3rd party support for several other Core Technologies (see www.coredevelopers.net for a full listing). We are committed to having the same level of involvement in our current projects that we have had in the past. This means that we will continue to work on the JBoss project itself. In addition, we will continue to support the JBoss project via the jboss-development and jboss-users mailing lists maintained by SourceForge.net, as well as any other open public forum. Unfortunately, the forums on jboss.org are a commercial venue for the JBoss Group LLC, and therefore we will not be participating in them. A few of our partners have offered support through the JBoss Group LLC in the past, but for various reasons have concluded that their professional aspirations would be better served outside of the JBoss Group LLC. In order to ensure that customers previously supported by our partners continue to receive the same level of high quality support, Core Developers Network is offering these customers a limited amount of free support during this transition period. We want to emphasize that our partners will continue to provide the same responsive, high-quality technical support as we have always done. The founding of Core Developers Network simply signals the natural emergence of competition in the marketplace. We hope that broadening the range of service options for open source projects will raise the level of support available and lead to even greater adoption of these Core Technologies. Please look for us at JavaOne booth 1705! Core Developers Network www.coredevelopers.net Jan Bartel Jeremy Boynes Remigio Chirino Jules Gosnell David Jencks James Stracham Dain Sundstrom Greg Wilkins --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Does clustering work on OS X?
I commented out that code. Can you try HEAD on that box? The way I got it to hang was to start all, run tests-unit (which worked great), and when the test completed, I just pressed ctrl^C in the console. -dain On Friday, April 4, 2003, at 12:04 AM, Scott M Stark wrote: 3.2 works fine on the same box/JDK. I'm clustering web sessions just fine. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 03, 2003 1:13 PM Subject: Re: [JBoss-dev] Does clustering work on OS X? Hey that is my code Is it not even starting for you? I can remove the ObjectCopier service until I figure out why it is hanging? I don't see why this would effect shutdown. Does this happen when you run the default configuration. Is it a problem to reference awt classes like Color from the server? I can remove all awt references from these classes. I was just trying to support copying of all data objects included in the JDK. -dain --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Does clustering work on OS X?
I'm just running 'all', and am not connecting to anything. -dain On Thursday, April 3, 2003, at 01:12 AM, Stephen Coy wrote: As in just running the all config, or are you actually clustering with something else? Running all certainly works in 3.2 - I've not tried HEAD in a while. In fact, I've run all on a Mac and linux box together without problems using JDK 1.4.1. Steve Coy On Thursday, April 3, 2003, at 04:32 PM, Dain Sundstrom wrote: Does clustering in jboss-head work for anyone on OS X? Whenever I try to shutdown jboss-head on my powerbook the entire os locks up until I unplug my wireless access point and 'killall -9 java'. This can take like 30 minutes to get my laptop responsive again. [12:27:50] dain$ java -version java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-39) Java HotSpot(TM) Client VM (build 1.4.1_01-14, mixed mode) -dain --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JB4DR1 Deadline MAY 26
I think you are delusional if you think JB4 will be ready for JavaOne. -dain On Thursday, April 3, 2003, at 02:47 PM, marc fleury wrote: Guys, We are thinking a lot about the forthcoming JB4 release. It is a truly exciting step for us as we believe we will bring a programming style, whose time has come, to a mass audience. AOP as Bill says is a clear wave for system level services on par with OOP. On top of it and also as a proof of how powerful the approach is we still develop a full J2EE server. Meaning that you can choose to live in the J2EE world work on JBoss J2EE and access all the prepackaged AOP goodies as you have been doing since JBoss2.0. There seems to be a lot of fear at SUN from what I can tell in the press, that we will abandon J2EE. We love J2EE. When really we will support J2EE for the forthcoming future. Never do we talk about abandoning J2EE, we just let the user access core functionality in the open server and think at the AOP level. A more fundamental construct of the framework. The reason we are almost there is that it is also a very old implementation in JBoss. We have been doing it for a long time but never talked/packaged it this way. We make it easy for you to leverage the AOP layer. The implementation is old the way you interact with JBoss is new. It can also be old if you decide to stay at the J2EE level which will be fully supported. But you are now invited to roam in the core JBoss system, in fact you may find it very cozy as you port POJO based applications to JBoss. There will be a stabilization period though. We are making an aggressive push to release JB4 by JavaONE with all our resources dedicated to implementing the final AOP system aspects and porting some of the existing code to that. We're making an aggressive push to release JBoss 4.0 by JavaOne. We're targeting May 26th. That leaves us 2 month from now. I REPEAT TARGET FOR JBOSS4.0 DR1 MAY 26TH To meet this aggressive deadline, we need to set some dates. There will be a functionality freeze, Monday, May 5th. All new functionality commits after May 5th must be approved by either Scott Stark, or Bill Burke. We will not branch May 5th, but instead make the month of May, JBoss 4.0 stability en route to a Developpers Release 1 (DR1). Please think long and hard and fast about your modules. Many of you are involved in core modules that need to move fast in the coming weeks. Don't be afraid to talk and say who needs help etc. PLgC marcf xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Does clustering work on OS X?
va:72) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:45) at org.jboss.mx.server.Invocation.invoke(Invocation.java:70) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.ja va:155) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:544) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControlle r.java:1002) at $Proxy1.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:390) - locked 0x67792c90 (a org.jboss.system.ServiceController) at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso rImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.ja va:72) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:45) at org.jboss.mx.server.Invocation.invoke(Invocation.java:70) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.ja va:155) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:544) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:776) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:574) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:538) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:522) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja va:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso rImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.ja va:72) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:45) at org.jboss.mx.server.Invocation.invoke(Invocation.java:70) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.ja va:155) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:544) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:172) at $Proxy7.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:330) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:238) at org.jboss.Main.boot(Main.java:165) at org.jboss.Main$1.run(Main.java:403) at java.lang.Thread.run(Thread.java:554) Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 03, 2003 7:51 AM Subject: Re: [JBoss-dev] Does clustering work on OS X? I wish I could. I can't even move windows. It just goes into la-la-land. My guess is it is some funk networking thing on OS X with the new VM. -dain --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JB4DR1 Deadline MAY 26
Ok then there are 4 weeks to get the new stuff done? Marc, Bill, sure we could do a release but what difference would it make if the new features are not in it. Is this a release just to show off AOP? What about any of the other new stuff? Just give the users a solid 3.2 and they will be happy. -dain On Thursday, April 3, 2003, at 03:30 PM, Bill Burke wrote: It will be ready and stable. Functionality freeze is May 5th. What functionality doesn't make it by then will be left out of the release. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dain Sundstrom Sent: Thursday, April 03, 2003 4:01 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JB4DR1 Deadline MAY 26 I think you are delusional if you think JB4 will be ready for JavaOne. -dain On Thursday, April 3, 2003, at 02:47 PM, marc fleury wrote: Guys, We are thinking a lot about the forthcoming JB4 release. It is a truly exciting step for us as we believe we will bring a programming style, whose time has come, to a mass audience. AOP as Bill says is a clear wave for system level services on par with OOP. On top of it and also as a proof of how powerful the approach is we still develop a full J2EE server. Meaning that you can choose to live in the J2EE world work on JBoss J2EE and access all the prepackaged AOP goodies as you have been doing since JBoss2.0. There seems to be a lot of fear at SUN from what I can tell in the press, that we will abandon J2EE. We love J2EE. When really we will support J2EE for the forthcoming future. Never do we talk about abandoning J2EE, we just let the user access core functionality in the open server and think at the AOP level. A more fundamental construct of the framework. The reason we are almost there is that it is also a very old implementation in JBoss. We have been doing it for a long time but never talked/packaged it this way. We make it easy for you to leverage the AOP layer. The implementation is old the way you interact with JBoss is new. It can also be old if you decide to stay at the J2EE level which will be fully supported. But you are now invited to roam in the core JBoss system, in fact you may find it very cozy as you port POJO based applications to JBoss. There will be a stabilization period though. We are making an aggressive push to release JB4 by JavaONE with all our resources dedicated to implementing the final AOP system aspects and porting some of the existing code to that. We're making an aggressive push to release JBoss 4.0 by JavaOne. We're targeting May 26th. That leaves us 2 month from now. I REPEAT TARGET FOR JBOSS4.0 DR1 MAY 26TH To meet this aggressive deadline, we need to set some dates. There will be a functionality freeze, Monday, May 5th. All new functionality commits after May 5th must be approved by either Scott Stark, or Bill Burke. We will not branch May 5th, but instead make the month of May, JBoss 4.0 stability en route to a Developpers Release 1 (DR1). Please think long and hard and fast about your modules. Many of you are involved in core modules that need to move fast in the coming weeks. Don't be afraid to talk and say who needs help etc. PLgC marcf xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01
Re: [JBoss-dev] Does clustering work on OS X?
I'll comment out the AWT stuff. All the copiers are hard coded right now, but when I add the configuration code, I'll just have the AWT stuff commented out and if someone wants them they can turn them on. I'm still not sure that you are seeing the same problem I am, because the server boots and works fine for me. When I shutdown the entire thing hangs. (again I am not actually clustering, just running the all configuration). -dain On Thursday, April 3, 2003, at 03:49 PM, Scott M Stark wrote: Those Apple guys are just too big of GUI freaks I guess. This is even over an ssh session so it was not even like I was on the console. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Stefan Reich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 03, 2003 1:18 PM Subject: Re: [JBoss-dev] Does clustering work on OS X? I've seen the hang sometimes on UFS filesystems, but why the heck is java.awt.Color being loaded in the first place!? --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Does clustering work on OS X?
It is supposed to work fine on JDK 1.4 which is required for JB4. Anyway, I have commented out support for copying them. -dain On Thursday, April 3, 2003, at 04:28 PM, Stefan Reich wrote: Please remember that using AWT/Swing classes will load a whole bunch of native libraries on most platforms, which increases the memory footprint. It might also not work on headless machines or on regular machines when nobody is logged in, depending on the OS. On Thursday, Apr 3, 2003, at 14:07 US/Pacific, Dain Sundstrom wrote: I'll comment out the AWT stuff. All the copiers are hard coded right now, but when I add the configuration code, I'll just have the AWT stuff commented out and if someone wants them they can turn them on. I'm still not sure that you are seeing the same problem I am, because the server boots and works fine for me. When I shutdown the entire thing hangs. (again I am not actually clustering, just running the all configuration). -dain On Thursday, April 3, 2003, at 03:49 PM, Scott M Stark wrote: Those Apple guys are just too big of GUI freaks I guess. This is even over an ssh session so it was not even like I was on the console. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Stefan Reich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 03, 2003 1:18 PM Subject: Re: [JBoss-dev] Does clustering work on OS X? I've seen the hang sometimes on UFS filesystems, but why the heck is java.awt.Color being loaded in the first place!? --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JB4DR1 Deadline MAY 26
I don't think we can support J2EE 1.4 for the DR1 release unless someone gets in and makes whatever changes are required to get our metadata classes to support the XML schemas used in J2EE 1.4. Besides meta data are there other big things in J2EE 1.4 that we haven't addressed yet? -dain On Thursday, April 3, 2003, at 04:30 PM, Igor Fedorenko wrote: What J2EE specification version are you planning to support in JBoss 4.0? J2EE 1.4 is not final as far as I know... -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED] Sent: Thursday, April 03, 2003 3:47 PM To: [EMAIL PROTECTED] Sourceforge. Net Subject: [JBoss-dev] JB4DR1 Deadline MAY 26 Guys, We are thinking a lot about the forthcoming JB4 release. It is a truly exciting step for us as we believe we will bring a programming style, whose time has come, to a mass audience. AOP as Bill says is a clear wave for system level services on par with OOP. On top of it and also as a proof of how powerful the approach is we still develop a full J2EE server. Meaning that you can choose to live in the J2EE world work on JBoss J2EE and access all the prepackaged AOP goodies as you have been doing since JBoss2.0. There seems to be a lot of fear at SUN from what I can tell in the press, that we will abandon J2EE. We love J2EE. When really we will support J2EE for the forthcoming future. Never do we talk about abandoning J2EE, we just let the user access core functionality in the open server and think at the AOP level. A more fundamental construct of the framework. The reason we are almost there is that it is also a very old implementation in JBoss. We have been doing it for a long time but never talked/packaged it this way. We make it easy for you to leverage the AOP layer. The implementation is old the way you interact with JBoss is new. It can also be old if you decide to stay at the J2EE level which will be fully supported. But you are now invited to roam in the core JBoss system, in fact you may find it very cozy as you port POJO based applications to JBoss. There will be a stabilization period though. We are making an aggressive push to release JB4 by JavaONE with all our resources dedicated to implementing the final AOP system aspects and porting some of the existing code to that. We're making an aggressive push to release JBoss 4.0 by JavaOne. We're targeting May 26th. That leaves us 2 month from now. I REPEAT TARGET FOR JBOSS4.0 DR1 MAY 26TH To meet this aggressive deadline, we need to set some dates. There will be a functionality freeze, Monday, May 5th. All new functionality commits after May 5th must be approved by either Scott Stark, or Bill Burke. We will not branch May 5th, but instead make the month of May, JBoss 4.0 stability en route to a Developpers Release 1 (DR1). Please think long and hard and fast about your modules. Many of you are involved in core modules that need to move fast in the coming weeks. Don't be afraid to talk and say who needs help etc. PLgC marcf --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JB4DR1 Deadline MAY 26
Persistence will not be done. -dain On Thursday, April 3, 2003, at 04:27 PM, Bill Burke wrote: JBoss Remoting AOP + tx, security, versioning, remoting, clustering, txlock, caching DTM (waiting on David's response) EMB (Enterprise Media Beans) JUDDI integration If I can get it done: AOP + EJB (packaged extensions to EJB) and don't forget Nukes! Anybody got anything to add to this list? Who doesn't think they'll be done by May 5th? Who thinks they'll be cutting it close? Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dain Sundstrom Sent: Thursday, April 03, 2003 4:48 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JB4DR1 Deadline MAY 26 Ok then there are 4 weeks to get the new stuff done? Marc, Bill, sure we could do a release but what difference would it make if the new features are not in it. Is this a release just to show off AOP? What about any of the other new stuff? Just give the users a solid 3.2 and they will be happy. -dain On Thursday, April 3, 2003, at 03:30 PM, Bill Burke wrote: It will be ready and stable. Functionality freeze is May 5th. What functionality doesn't make it by then will be left out of the release. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dain Sundstrom Sent: Thursday, April 03, 2003 4:01 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JB4DR1 Deadline MAY 26 I think you are delusional if you think JB4 will be ready for JavaOne. -dain On Thursday, April 3, 2003, at 02:47 PM, marc fleury wrote: Guys, We are thinking a lot about the forthcoming JB4 release. It is a truly exciting step for us as we believe we will bring a programming style, whose time has come, to a mass audience. AOP as Bill says is a clear wave for system level services on par with OOP. On top of it and also as a proof of how powerful the approach is we still develop a full J2EE server. Meaning that you can choose to live in the J2EE world work on JBoss J2EE and access all the prepackaged AOP goodies as you have been doing since JBoss2.0. There seems to be a lot of fear at SUN from what I can tell in the press, that we will abandon J2EE. We love J2EE. When really we will support J2EE for the forthcoming future. Never do we talk about abandoning J2EE, we just let the user access core functionality in the open server and think at the AOP level. A more fundamental construct of the framework. The reason we are almost there is that it is also a very old implementation in JBoss. We have been doing it for a long time but never talked/packaged it this way. We make it easy for you to leverage the AOP layer. The implementation is old the way you interact with JBoss is new. It can also be old if you decide to stay at the J2EE level which will be fully supported. But you are now invited to roam in the core JBoss system, in fact you may find it very cozy as you port POJO based applications to JBoss. There will be a stabilization period though. We are making an aggressive push to release JB4 by JavaONE with all our resources dedicated to implementing the final AOP system aspects and porting some of the existing code to that. We're making an aggressive push to release JBoss 4.0 by JavaOne. We're targeting May 26th. That leaves us 2 month from now. I REPEAT TARGET FOR JBOSS4.0 DR1 MAY 26TH To meet this aggressive deadline, we need to set some dates. There will be a functionality freeze, Monday, May 5th. All new functionality commits after May 5th must be approved by either Scott Stark, or Bill Burke. We will not branch May 5th, but instead make the month of May, JBoss 4.0 stability en route to a Developpers Release 1 (DR1). Please think long and hard and fast about your modules. Many of you are involved in core modules that need to move fast in the coming weeks. Don't be afraid to talk and say who needs help etc. PLgC marcf xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JB4DR1 Deadline MAY 26
On Thursday, April 3, 2003, at 05:26 PM, Bela Ban wrote: 3. [Jeremy, Dain] Integration of the cache into the PersistenceManager. The first version will have the PersistenceManager use the Cache as a replicated in-memory cache. Our use case will initially be shared DB, so all nodes use the Our need for caching is very different from what the other two, so I don't think that it can be done in parallel as it requires some very things in the implementation. I'm still not convinced that we don't need a completely different cache from what the rest of the server will use. Of course we will use the same low level APIs, but I think the rest will need to be custom. I know you and Jeremy have been working these issues out, so I'll have to wait and see what happens. same database. At a later stage (probably not JB4) we will provide unshared DBs. This involves some more efforts, e.g. retrieving full DB state for new nodes (from existing nodes). I think this is a third system that will be very different from the other two. I am concerned that if we try to support all of these different requirements we will end up difficult to use and maintain code, but you are a coding Jedi. Anyway, my point is I don't think they can be done in parallel. -dain --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Does clustering work on OS X?
Does clustering in jboss-head work for anyone on OS X? Whenever I try to shutdown jboss-head on my powerbook the entire os locks up until I unplug my wireless access point and 'killall -9 java'. This can take like 30 minutes to get my laptop responsive again. [12:27:50] dain$ java -version java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-39) Java HotSpot(TM) Client VM (build 1.4.1_01-14, mixed mode) -dain --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Re[6]: [JBoss-dev] php5 is coming
On Tuesday, April 1, 2003, at 04:39 AM, julien viet wrote:
I dont't want to reinvent a scripting language, but JSP are
not adapted to nukes at all. I think the nicest feature of
JSP is the possibility to embed true java code whithin text :
TABLETR
% for (int i = 0;i 5;i++) { %
TD%= i %/TD
% } %
/TR
/TABLE
I love scriptlets also, because they make the page code to easy read
and understand. Even the most entry level html writer can write the
basic java code, and it sure beats the following
table
c:forEach var=product items=${products}
tr
tdc:out value=${product.name}//td
tdc:out value=${product.price}//td
/tr
/c:forEach
/table
See what I mean. Tags are just overhead when you can use scriptlets.
-dain
BTW, yes that was sarcasm.
---
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] php5 is coming
I forwarded the contact info at the 2 java compiler projects onto Julien. Both support passing in a class loader from which classes will be obtained. One of the projects has a licensing issue (GPL), but they may be willing to change. The other project does not full implement the language spec, but may have enough for JSP. -dain On Tuesday, April 1, 2003, at 01:29 PM, Scott M Stark wrote: So get another compiler. We don't need no stinking JSR. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 11:13 AM Subject: Re: [JBoss-dev] php5 is coming Scott M Stark wrote: We really have not looked into tweaking the jsp compiler layer to see if the filesystem requirement can be replaced by an input stream or byte[] view of classes as far as I know. Its something to look into as another optimization/benefit of embedding the web container into JBoss. I don't see how you can do that. The problem is the Java compiler (there's already a JSR for that already, ETA is for Tiger). I recommed using JSP compilation to just get rid of the compilation crap at runtime. I think we should eventually recommend in the docs that people do that during the deployment process of the webapp. Remy --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Re[2]: [JBoss-dev] php5 is coming
I talked with 2 compiler projects after JBoss boot camp and both were interested in being integrated, but I dropped the ball and got busy on some other stuff. If anyone is interested in this I can send you the contact info. -dain On Sunday, March 30, 2003, at 10:37 AM, julien viet wrote: Hello Marcel, Sunday, March 30, 2003, 6:23:38 PM, you wrote: MA julien viet wrote ([EMAIL PROTECTED]) JD Though now that I think about it I would prefer that Java was more like JD PHP in the sense of a light weight web application development language JD with its rich extensions and apis. we discussed with Dain at boot camp and we wished having a way to dynamic compile a class, I mean with a java compiler written in java and taking class def from a classloader. That would enable a compilation service in jboss. Would be great for nukes. Kopi compiler is written in 100% java and could be modified to achieve such results though I don't know about its license. MA I did this for the PizzaCompiler as part of getting Cocoon to work MA without a JDK (only a JRE needed). For Pizza this is relatively MA easy as it has pluggable resource-loaders (.class files are resources MA to the compiler). The pizza compiler can be found at: cool, it could help for module or block scripting in Nukes, i.e get code class - fully generate class - compile it - generate xmbeam - deploy it pluggable resource loader is very helpfull, I don't know if we can have bytes of class through unified classloaders but that would help. MA http://pizzacompiler.sourceforge.net/ MA I placed the sources for the pizza-loader and some wrapper and extension MA classes needed to use it at: http://www.artefact.nl/pizza-loader.zip MA I stripped of some extra's and commented out some lines to keep it MA simple and self hosting. MA Hope this helps. MA Regards, MA Marcel Ammerlaan -- Best regards, julienmailto:[EMAIL PROTECTED] --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] AOP versioned ACID objects 1st iteration
On Thursday, March 27, 2003, at 09:57 AM, Bill Burke wrote: Yes, its a deep copy which is why I require Serializable. new MarshalledObject(obj).get(); Maybe there is a better way to make copies? Yes. I wrote an object copier service for just this type for situation. In CMP the spec requires us to return copies of CMP-fields and up until now we just ignored that requirement. The object copier is currently broken, but I expect to have it fixed sometime this weekend. I'll send you some sample code later. -dain --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Verify primary key implements equals and hashCode
After some email with Bill, it looks like we can use
Class.getDeclaredMethods to find which method the class implements (you
learn something new every day). It specifically excludes inherited
methods, so we can use it to verify if a primary key has actually
implemented hashCode and equals.
Since equals equals is not really inheritable (see Effective Java), I
think we should throw a verifier error if a pk does not directly
implement it. HashCode on the other hand can be inherited (and still
be valid), so I think we should only print a warning if they don't
directly. We could check the parents until we get to Object to see if
they left the default implementation.
Who maintains the verifier?
-dain
Here is the code I wrote in to test this:
public static boolean definesEquals(Class clazz)
{
Method[] method = clazz.getDeclaredMethods();
for(int i=0; imethod.length; i++)
{
if(method[i].getName().equals(equals)
method[i].getParameterTypes().length == 1
method[i].getParameterTypes()[0] == Object.class
method[i].getReturnType() == Boolean.TYPE)
{
return true;
}
}
return false;
}
public static boolean definesHashCode(Class clazz)
{
Method[] method = clazz.getDeclaredMethods();
for(int i=0; imethod.length; i++)
{
if(method[i].getName().equals(hashCode)
method[i].getParameterTypes().length == 0
method[i].getReturnType() == Integer.TYPE)
{
return true;
}
}
return false;
}
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Verify primary key implements equals and hashCode
On Wednesday, March 26, 2003, at 09:29 PM, Victor Langelo wrote:
Dain Sundstrom wrote:
After some email with Bill, it looks like we can use
Class.getDeclaredMethods to find which method the class implements
(you learn something new every day). It specifically excludes
inherited methods, so we can use it to verify if a primary key has
actually implemented hashCode and equals.
Class.getDeclaredMethod(equals, new Class[] { Object.class }) should
also do the trick and won't return inherited methods.
I dumb; I missed that one.
Since equals equals is not really inheritable (see Effective Java), I
think we should throw a verifier error if a pk does not directly
implement it.
I haven't read Effective Java, but this won't work for us. We
intentionally create derived primary key classes for each entity.
These are derived from generic pk classes when the primary key data is
a simple primative type. The super class implements equals, compareTo
and hashCode. I don't see any reason these would need to be
reimplemented in each derived class.
The purpose of the derived classes is primarly for type safety.
I loaned my copy of Effective Java to a friend so I can't quote. The
basic idea is that if a.equals(b) is true b.equals(a) must also be
true. This means you must test for the exact type of the related
compare to object. You must have code that looks something like this.
public boolean equals(object o)
{
if(o instanceof MyType)
{
return value.equals((MyType).value);
}
return false;
}
The important part is the instance of check. I suppose you could do
this check with reflection... something like this
if(getClass() == o.getClass())
So I guess you are right, but we know that if one of the super classes
(other then Object) we know that the implementation is wrong.
public static boolean definesEquals(Class clazz)
{
Class[] params = new Class[] { Object.class };
while (clazz != null !clazz.equals(Object.class)) {
try {
Method m = clazz.getDeclaredMethod(equals, params);
if (m.getReturnType() == Integer.TYPE)
return true;
} catch (NoSuchMethodException) {
}
clazz = clazz.getSuperclass();
}
return false;
}
That should work.
-dain
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
Being compliant and the AOP features are not mutually exclusive. We will do both. To Brian Wallis, even if Jboss were to get certified, it would not make your J2EE compliant applications portable. Why? There are may important things considered outside the specification. For example, all database mappings for CMP are outside the spec, even using a database for CMP is outside the spec. Then you get into things like exception recovery and tuning, and you are way outside the spec. Unless you have a very simple application it will not be portable without multiple configuration files and possibly a portably a portability layer. Having the TDK would be nice to help identify new bugs, and eliminate the of the minor differences between the platforms, but I doubt it will seriously help you with making a cross platform application. -dain On Monday, March 24, 2003, at 07:52 AM, danch wrote: I have never heard any of the main developers talk about JBoss4 _not_ being J2EE compatible. It has always been my understanding that the AOP framework would form the underpinnings of JBoss4's EJB implementation and be available as a more-flexible, lighter weight API for people who aren't concerned with portability. Scott, Bill, Marc - can one of you clarify? thanks, danch Rahul Ganjoo wrote: but one of the goals of JBoss 4 is to make it so developers don't have to deal with all the J2EE APIs from this and the discussion in general.. Jboss4 and J2EE compliance are two entirely different roadmaps (IMHU).. i mean its important for everyone here to know what direction Jboss is going to take.. is j2EE compliance important and is Jboss going for it..or is it keeping up the Jboss4 AOP vision and hence chucking compliance? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Use of InMemory and File persistent manager?
Do any of you use or know of a user of the CMPInMemoryPersistenceManager or CMPFilePersistenceManager? I would like to get rid of them, to make the integration of the new persistence engine easier. We will eventually have file and in memory stores under the new persistence engine, but we don't right now. Is this a problem for anyone? -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Use of InMemory and File persistent manager?
Where is the code that uses it? -dain On Monday, March 24, 2003, at 06:12 PM, Bill Burke wrote: Don't! InMemory is used by clustering for HTTP Session replication. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dain Sundstrom Sent: Monday, March 24, 2003 9:59 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Use of InMemory and File persistent manager? Do any of you use or know of a user of the CMPInMemoryPersistenceManager or CMPFilePersistenceManager? I would like to get rid of them, to make the integration of the new persistence engine easier. We will eventually have file and in memory stores under the new persistence engine, but we don't right now. Is this a problem for anyone? -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
On Sunday, March 23, 2003, at 04:19 PM, Stefan Arentz wrote: On Saturday, Mar 22, 2003, at 23:03 Europe/Amsterdam, Tom Coleman wrote: Personally, certification is irrelevant to me. My criteria is whether or not the product gets the job done. I think certification serves to answer that question for people who don't know how to figure it out for themselves. I have a different view on that. I think certification is important because by running all those tests we will find a lot of new bugs in JBoss. Certification will make it a better product because *all* parts of the specification will be touched instead of just what people are using. I agree that certification is not that important to sell the product, but from a development / testing perspective it is *very* useful. The more tests we have the better we will be, but I doubt that sun will let us check the TDK into CVS, so it will be worthless to everyone but the few JBoss employees that get access. -dain --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
On Sunday, March 23, 2003, at 07:30 PM, Dave Neuer wrote: --- Dain Sundstrom [EMAIL PROTECTED] wrote: The more tests we have the better we will be, but I doubt that sun will let us check the TDK into CVS, so it will be worthless to everyone but the few JBoss employees that get access. -dain Is a condition of the TDK license that you can't use the information about your source tree that it reveals to improve the product? Does it specifically bar you from writing JUnit test cases which test for a bug which just happens to be a bug regarding spec compliance? Got me. Where did you find the license to the J2EE TDK license? -dain --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
What is the deal with this? It builds perfectly for me. -dain On Saturday, March 15, 2003, at 10:38 AM, [EMAIL PROTECTED] wrote: = ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01) Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE getTransaction(), relatedId, myCtx.getId()); ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/ejb/plugins/ cmp/jdbc/bridge/JDBCCMRFieldBridge.java:1226: cannot resolve symbol symbol : variable container location: class org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge TransactionManager tm = container.getTransactionManager(); ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/invocation/ http/interfaces/Util.java:63: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated if( conn instanceof com.sun.net.ssl.HttpsURLConnection ) ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/invocation/ http/interfaces/Util.java:68: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated com.sun.net.ssl.HttpsURLConnection sconn = (com.sun.net.ssl.HttpsURLConnection) conn; ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/invocation/ http/interfaces/Util.java:68: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated com.sun.net.ssl.HttpsURLConnection sconn = (com.sun.net.ssl.HttpsURLConnection) conn; ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/jmx/ connector/rmi/RMIConnectorImpl.java:592: warning: deserialize(java.lang.String,javax.management.ObjectName,byte[]) in javax.management.MBeanServer has been deprecated public ObjectInputStream deserialize(String className, ObjectName loaderName, byte[] data) ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/jmx/ connector/rmi/RMIConnectorImpl.java:581: warning: deserialize(java.lang.String,byte[]) in javax.management.MBeanServer has been deprecated public ObjectInputStream deserialize(String className, byte[] data) ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/jmx/ connector/rmi/RMIConnectorImpl.java:570: warning: deserialize(javax.management.ObjectName,byte[]) in javax.management.MBeanServer has been deprecated public ObjectInputStream deserialize(ObjectName name, byte[] data) ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/jmx/ connector/ejb/EJBConnector.java:56: warning: deserialize(java.lang.String,javax.management.ObjectName,byte[]) in javax.management.MBeanServer has been deprecated public class EJBConnector ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/jmx/ connector/ejb/EJBConnector.java:56: warning: deserialize(java.lang.String,byte[]) in javax.management.MBeanServer has been deprecated public class EJBConnector ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/jmx/ connector/ejb/EJBConnector.java:56: warning: deserialize(javax.management.ObjectName,byte[]) in javax.management.MBeanServer has been deprecated public class EJBConnector ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/jmx/ connector/ejb/EJBConnector.java:56: warning: deserialize(java.lang.String,javax.management.ObjectName,byte[]) in javax.management.MBeanServer has been deprecated public class EJBConnector ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/jmx/ connector/ejb/EJBConnector.java:56: warning: deserialize(java.lang.String,byte[]) in javax.management.MBeanServer has been deprecated public class EJBConnector ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/jmx/ connector/ejb/EJBConnector.java:56: warning: deserialize(javax.management.ObjectName,byte[]) in javax.management.MBeanServer has been deprecated public class EJBConnector ^ 6 errors 22 warnings BUILD FAILED file:/home/jboss/jbossci/jboss-head/server/build.xml:291: Compile failed; see the compiler error output for details. Total time: 1 minute 55 seconds --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
Re: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
I'm dumb, dumb, dumb. I checked this in in one sandbox and tested it in another. -dain On Saturday, March 15, 2003, at 11:04 AM, Dain Sundstrom wrote: What is the deal with this? It builds perfectly for me. -dain On Saturday, March 15, 2003, at 10:38 AM, [EMAIL PROTECTED] wrote: = ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01) Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE getTransaction(), relatedId, myCtx.getId()); ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/ejb/plugins/ cmp/jdbc/bridge/JDBCCMRFieldBridge.java:1226: cannot resolve symbol symbol : variable container location: class org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge TransactionManager tm = container.getTransactionManager(); ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/invocation/ http/interfaces/Util.java:63: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated if( conn instanceof com.sun.net.ssl.HttpsURLConnection ) ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/invocation/ http/interfaces/Util.java:68: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated com.sun.net.ssl.HttpsURLConnection sconn = (com.sun.net.ssl.HttpsURLConnection) conn; ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/invocation/ http/interfaces/Util.java:68: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated com.sun.net.ssl.HttpsURLConnection sconn = (com.sun.net.ssl.HttpsURLConnection) conn; ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/jmx/ connector/rmi/RMIConnectorImpl.java:592: warning: deserialize(java.lang.String,javax.management.ObjectName,byte[]) in javax.management.MBeanServer has been deprecated public ObjectInputStream deserialize(String className, ObjectName loaderName, byte[] data) ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/jmx/ connector/rmi/RMIConnectorImpl.java:581: warning: deserialize(java.lang.String,byte[]) in javax.management.MBeanServer has been deprecated public ObjectInputStream deserialize(String className, byte[] data) ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/jmx/ connector/rmi/RMIConnectorImpl.java:570: warning: deserialize(javax.management.ObjectName,byte[]) in javax.management.MBeanServer has been deprecated public ObjectInputStream deserialize(ObjectName name, byte[] data) ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/jmx/ connector/ejb/EJBConnector.java:56: warning: deserialize(java.lang.String,javax.management.ObjectName,byte[]) in javax.management.MBeanServer has been deprecated public class EJBConnector ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/jmx/ connector/ejb/EJBConnector.java:56: warning: deserialize(java.lang.String,byte[]) in javax.management.MBeanServer has been deprecated public class EJBConnector ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/jmx/ connector/ejb/EJBConnector.java:56: warning: deserialize(javax.management.ObjectName,byte[]) in javax.management.MBeanServer has been deprecated public class EJBConnector ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/jmx/ connector/ejb/EJBConnector.java:56: warning: deserialize(java.lang.String,javax.management.ObjectName,byte[]) in javax.management.MBeanServer has been deprecated public class EJBConnector ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/jmx/ connector/ejb/EJBConnector.java:56: warning: deserialize(java.lang.String,byte[]) in javax.management.MBeanServer has been deprecated public class EJBConnector ^ /home/jboss/jbossci/jboss-head/server/src/main/org/jboss/jmx/ connector/ejb/EJBConnector.java:56: warning: deserialize(javax.management.ObjectName,byte[]) in javax.management.MBeanServer has been deprecated public class EJBConnector ^ 6 errors 22 warnings BUILD FAILED file:/home/jboss/jbossci/jboss-head/server/build.xml:291: Compile failed; see the compiler error output for details. Total time: 1 minute 55 seconds --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here
Re: [JBoss-dev] Going ahead with EJB module refactor
So how is it coming? -dain On Wednesday, March 12, 2003, at 06:02 PM, Stephen Coy wrote: The fix certainly allows xdoclet to build itself, whereas it was failing with the same problem we have in JBoss HEAD. I can't check against JBoss HEAD until I get home tonight (its AM here), but I'm a happy camper for my dev work now. Steve Coy On Thursday, March 13, 2003, at 04:15 AM, David Jencks wrote: There's a patch on their bugtracker that is supposed to fix this: http://opensource.atlassian.com/projects/xdoclet/secure/ ViewIssue.jspa?key=XDT-376 They want feedback. I need to keep working so I haven't up(?)graded my 1.4.1 copy yet. david jencks On 2003.03.12 04:53 Jason Dillon wrote: Actually now that I think about it I have to wait until i can actually build the source tree again... Any word from the XDoclet folks on what the problem is? --jason On Wednesday, March 12, 2003, at 03:30 PM, Jason Dillon wrote: Tonight I will be working on the EJB module re-factoring. Will probably have something ready to check in tomorrow. If you have EJB related bits to commit in system please do so now. --jason --- This SF.net email is sponsored by:Crypto Challenge is now open!Get cracking and register here for some mind boggling fun andthe chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Can't build on linux either
I guess my machine is hosed. I have my env setup just like this, and it doesn't work. I even remove everything from my .bashrc file and set the variables by hand... [EMAIL PROTECTED] build]$ export JAVA_HOME=/usr/java/jdk1.4.1_02 [EMAIL PROTECTED] build]$ export PATH=$JAVA_HOME/bin:$PATH [EMAIL PROTECTED] build]$ ./build.sh build.sh: Executing: /home/dain/work/jboss/jboss-head/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger Buildfile: build.xml ... generate-parsers: [jjtree] Exception in thread main java.lang.NoClassDefFoundError: COM/sun/labs/jjtree/Main BUILD FAILED file:/home/dain/work/jboss/jboss-head/server/build.xml:168: JJTree failed. I'm going to go do some other things until Jason gets the XDoclet patch applied for OS X. -dain On Tuesday, March 11, 2003, at 11:31 PM, Scott M Stark wrote: A clean co of head is building for me on a RedHat 8 box with the same JDK. I believe you have to set both the JAVA_HOME and PATH to get JavaCC to work as it seems to use the PATH for something. [EMAIL PROTECTED] starksm]$ export JAVA_HOME=~/Java/j2sdk1.4.1_02 [EMAIL PROTECTED] starksm]$ PATH=$JAVA_HOME/bin:$PATH [EMAIL PROTECTED] build]$ ./build.sh build.sh: Executing: /home/starksm/JBoss/jboss-head/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger Buildfile: build.xml ... BUILD SUCCESSFUL Total time: 7 minutes 5 seconds Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 8:08 PM Subject: [JBoss-dev] Can't build on linux either Because OSX is hosed I decided to move my development to my linux box, but it doesn't build either. It looks like the build isn't picking up the JavaCC.zip file. Jason is this working for you... Here is what I get java version 1.4.1_02 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) [EMAIL PROTECTED] build]$ ./build.sh build.sh: *WARNING* Ignoring environment value for $ANT_HOME build.sh: Executing: /home/dain/work/jboss/jboss-head/tools/bin/ant -logger org. apache.tools.ant.NoBannerLogger Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property snip/ == == == Executing 'most' in module 'server'... == == generate-parsers: [jjtree] Exception in thread main java.lang.NoClassDefFoundError: COM/sun/labs/jjtree/Main BUILD FAILED file:/home/dain/work/jboss/jboss-head/server/build.xml:168: JJTree failed. --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Going ahead with EJB module refactor
Did it work? I'm dead in the water as my linux box won't build either. -dain On Wednesday, March 12, 2003, at 11:30 AM, Jason Dillon wrote: Heh, I sorta wish I could uninstall it... perhaps I can, but I am not really sure how. I will have a look unless someone beats me to it. --jason On Thursday, March 13, 2003, at 12:15 AM, David Jencks wrote: There's a patch on their bugtracker that is supposed to fix this: http://opensource.atlassian.com/projects/xdoclet/secure/ ViewIssue.jspa?key=XDT-376 They want feedback. I need to keep working so I haven't up(?)graded my 1.4.1 copy yet. david jencks On 2003.03.12 04:53 Jason Dillon wrote: Actually now that I think about it I have to wait until i can actually build the source tree again... Any word from the XDoclet folks on what the problem is? --jason On Wednesday, March 12, 2003, at 03:30 PM, Jason Dillon wrote: Tonight I will be working on the EJB module re-factoring. Will probably have something ready to check in tomorrow. If you have EJB related bits to commit in system please do so now. --jason --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by:Crypto Challenge is now open!Get cracking and register here for some mind boggling fun andthe chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JDK 1.4.1 on OS X out and breaks build
Well this sucks. I hope the XDoclet guys fix this quick. -dain On Tuesday, March 11, 2003, at 05:43 AM, Jason Dillon wrote: Um but it looks like HEAD will only build with 1.4+ so I will shut up now. --jason On Tuesday, March 11, 2003, at 06:19 PM, Jason Dillon wrote: FYI, export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/ Home or if you like csh pain: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home And you can build again. --jason On Tuesday, March 11, 2003, at 01:13 PM, Dain Sundstrom wrote: I just upgraded to 1.4.1 on OS X and now the build won't work. I tried a fresh checkout, but that didn't help. Jason is this working on your mac. -dain bash-2.05a$ java -version java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-39) Java HotSpot(TM) Client VM (build 1.4.1_01-14, mixed mode) bash-2.05a$ ./build.sh build.sh: Executing: /Users/dain/work/jboss/x/jboss-head/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property _buildmagic:init:local-properties: [copy] Copying 1 file to /Users/dain/work/jboss/x/jboss-head/build configure-project: [echo] groups: default [echo] modules: common,naming,remoting,jmx,system,aop,cache,j2ee,management,transacti on,persistence,server,blocks,console,security,messaging,connector,var ia,cluster,jetty,jboss.net,iiop _buildmagic:modules:most: == == == Executing 'most' in module 'common'... == == compile-mbean-sources: [mkdir] Created dir: /Users/dain/work/jboss/x/jboss-head/common/output/gen/classes [execmodules] Running mbeaninterface/ [execmodules] Generating output for 'org.jboss.util.property.jmx.SystemPropertyClassValue' using template file 'jar:file:/Users/dain/work/jboss/x/jboss-head/thirdparty/xdoclet- xdoclet/lib/xdoclet-jmx-module-jb4.jar!/xdoclet/modules/jmx/ resources/mbean.xdt'. [execmodules] (XDocletMain.start 51 ) Running XDoclet failed. [execmodules] (XDocletMain.start 52 ) Running XDoclet failed. [execmodules] xdoclet.template.TemplateException: Error in template file: corresponding /XDtClass:classOf not found, line=8 of template file: jar:file:/Users/dain/work/jboss/x/jboss-head/thirdparty/xdoclet- xdoclet/lib/xdoclet-jmx-module-jb4.jar!/xdoclet/modules/jmx/ resources/mbean.xdt [execmodules] at xdoclet.template.TemplateEngine.handleBlockTag(TemplateEngine.java:82 4) [execmodules] at xdoclet.template.TemplateEngine.handleTag(TemplateEngine.java:425) [execmodules] at xdoclet.template.TemplateEngine.generate(TemplateEngine.java:324) [execmodules] at xdoclet.template.TemplateEngine.start(TemplateEngine.java:373) [execmodules] at xdoclet.TemplateSubTask.startEngine(TemplateSubTask.java:559) [execmodules] at xdoclet.TemplateSubTask.generateForClass(TemplateSubTask.java:765) And so on... --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Can't build on linux either
Because OSX is hosed I decided to move my development to my linux box, but it doesn't build either. It looks like the build isn't picking up the JavaCC.zip file. Jason is this working for you... Here is what I get java version 1.4.1_02 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) [EMAIL PROTECTED] build]$ ./build.sh build.sh: *WARNING* Ignoring environment value for $ANT_HOME build.sh: Executing: /home/dain/work/jboss/jboss-head/tools/bin/ant -logger org. apache.tools.ant.NoBannerLogger Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property snip/ == == == Executing 'most' in module 'server'... == == generate-parsers: [jjtree] Exception in thread main java.lang.NoClassDefFoundError: COM/sun/labs/jjtree/Main BUILD FAILED file:/home/dain/work/jboss/jboss-head/server/build.xml:168: JJTree failed. --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Move MarshalledValue* to common module?
I would like to move the org.jboss.invocation.MarshalledValue* to the commons package, so it can be used by non-ejb dependent code. Does any have an issue with this? Does this create a problem for client jars? -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Move MarshalledValue* to common module?
I have another issue now... should have checked before sending this email. I have a written new basic service ObjectCopier, which is an MBean that knows how to *efficiently* deep copy objects. This means that I track metadata so we can avoid serialize/ deserialize. Anyway, I wanted add this to the common module, because it is a generic service that will be used by several modules (CMP and Cache for now). The problem is common does not build after system, so I can't use ServiceMBeanSupport. Should we add a new module for common services or move the ServiceMBeanSupport stuff to common or something else or should I put my code server? -dain On Monday, March 10, 2003, at 08:15 PM, Dain Sundstrom wrote: I would like to move the org.jboss.invocation.MarshalledValue* to the commons package, so it can be used by non-ejb dependent code. Does any have an issue with this? Does this create a problem for client jars? -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JDK 1.4.1 on OS X out and breaks build
I just upgraded to 1.4.1 on OS X and now the build won't work. I tried a fresh checkout, but that didn't help. Jason is this working on your mac. -dain bash-2.05a$ java -version java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-39) Java HotSpot(TM) Client VM (build 1.4.1_01-14, mixed mode) bash-2.05a$ ./build.sh build.sh: Executing: /Users/dain/work/jboss/x/jboss-head/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property _buildmagic:init:local-properties: [copy] Copying 1 file to /Users/dain/work/jboss/x/jboss-head/build configure-project: [echo] groups: default [echo] modules: common,naming,remoting,jmx,system,aop,cache,j2ee,management,transaction, persistence,server,blocks,console,security,messaging,connector,varia,clu ster,jetty,jboss.net,iiop _buildmagic:modules:most: == == == Executing 'most' in module 'common'... == == compile-mbean-sources: [mkdir] Created dir: /Users/dain/work/jboss/x/jboss-head/common/output/gen/classes [execmodules] Running mbeaninterface/ [execmodules] Generating output for 'org.jboss.util.property.jmx.SystemPropertyClassValue' using template file 'jar:file:/Users/dain/work/jboss/x/jboss-head/thirdparty/xdoclet- xdoclet/lib/xdoclet-jmx-module-jb4.jar!/xdoclet/modules/jmx/resources/ mbean.xdt'. [execmodules] (XDocletMain.start 51 ) Running XDoclet failed. [execmodules] (XDocletMain.start 52 ) Running XDoclet failed. [execmodules] xdoclet.template.TemplateException: Error in template file: corresponding /XDtClass:classOf not found, line=8 of template file: jar:file:/Users/dain/work/jboss/x/jboss-head/thirdparty/xdoclet- xdoclet/lib/xdoclet-jmx-module-jb4.jar!/xdoclet/modules/jmx/resources/ mbean.xdt [execmodules] at xdoclet.template.TemplateEngine.handleBlockTag(TemplateEngine.java:824) [execmodules] at xdoclet.template.TemplateEngine.handleTag(TemplateEngine.java:425) [execmodules] at xdoclet.template.TemplateEngine.generate(TemplateEngine.java:324) [execmodules] at xdoclet.template.TemplateEngine.start(TemplateEngine.java:373) [execmodules] at xdoclet.TemplateSubTask.startEngine(TemplateSubTask.java:559) [execmodules] at xdoclet.TemplateSubTask.generateForClass(TemplateSubTask.java:765) And so on... --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Move MarshalledValue* to common module?
I don't need to move it anymore, because I'm going to put my new code in server. I think this will need to be moved when we get more of the persistence engine moved, because we use MarshalledValue for BLOBs. -dain On Tuesday, March 11, 2003, at 12:57 AM, Jason Dillon wrote: Why not add it to system? --jason On Tuesday, March 11, 2003, at 09:32 AM, Dain Sundstrom wrote: I have another issue now... should have checked before sending this email. I have a written new basic service ObjectCopier, which is an MBean that knows how to *efficiently* deep copy objects. This means that I track metadata so we can avoid serialize/ deserialize. Anyway, I wanted add this to the common module, because it is a generic service that will be used by several modules (CMP and Cache for now). The problem is common does not build after system, so I can't use ServiceMBeanSupport. Should we add a new module for common services or move the ServiceMBeanSupport stuff to common or something else or should I put my code server? -dain On Monday, March 10, 2003, at 08:15 PM, Dain Sundstrom wrote: I would like to move the org.jboss.invocation.MarshalledValue* to the commons package, so it can be used by non-ejb dependent code. Does any have an issue with this? Does this create a problem for client jars? -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Naming a core module?
On Sunday, March 9, 2003, at 10:35 AM, Jeff Haynie wrote: If different protocols are desired beyond that and we support them, you can just add the dependent JARs and they become available. I think this is what you want ... I think this is a bad idea. If I want a specific connector available on my server, I will explicitly deploy it. I may want SOAP for something other then JMX remoting and I don't want it to implicitly available as a JMX connector just because I have some jars in my classpath. -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MarshalledValue
I'll take a look at 3.2. I think the problem is we keep both the
ByteArrayOutputStream and the byte[] in the class, which ends up with
two copies of the byte array in memory. I'll see what I can do.
-dain
On Sunday, March 9, 2003, at 10:34 AM, Scott M Stark wrote:
I didn't make this change so I don't know why it was done. This is not
how MarshalledValue
is coded in 3.2 so change it to the 3.2 version which still has the
serializedForm setup
in the ctor.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Dain Sundstrom [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, March 08, 2003 4:53 PM
Subject: Re: [JBoss-dev] MarshalledValue
Scott what is the deal with this? Can I make this change?
-dain
On Monday, March 3, 2003, at 04:16 AM, Alex Loubyansky wrote:
MarshalledValue's constructor is
public MarshalledValue(Object obj) throws IOException
{
baos = new ByteArrayOutputStream();
MarshalledValueOutputStream mvos = new
MarshalledValueOutputStream(baos);
mvos.writeObject(obj);
mvos.flush();
isHashComputed = false;
}
Here is get():
public Object get() throws IOException, ClassNotFoundException
{
if (serializedForm == null)
return null;
ByteArrayInputStream bais = new
ByteArrayInputStream(serializedForm);
MarshalledValueInputStream mvis = new
MarshalledValueInputStream(bais);
return mvis.readObject();
}
Should the constructor include the line
serializedForm = baos.toByteArray(); ?
searializedForm is initialized only in readExternal(). Thus, for
instances constructed with 'new MarshalledValue(obj)' all the methods
except for readExternal/writeExternal are broken.
Or am I missing something?
PS: this is for all MarshalledValue's in invocation.*, aop.* and
interception.*.
Thanks,
alex
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The
debugger
for complex code. Debugging C/C++ programs can leave you feeling lost
and
disoriented. TotalView can help you find your way. Available on major
UNIX
and Linux platforms. Try it free. www.etnus.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The
debugger
for complex code. Debugging C/C++ programs can leave you feeling lost
and
disoriented. TotalView can help you find your way. Available on major
UNIX
and Linux platforms. Try it free. www.etnus.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MarshalledValue
Scott what is the deal with this? Can I make this change?
-dain
On Monday, March 3, 2003, at 04:16 AM, Alex Loubyansky wrote:
MarshalledValue's constructor is
public MarshalledValue(Object obj) throws IOException
{
baos = new ByteArrayOutputStream();
MarshalledValueOutputStream mvos = new
MarshalledValueOutputStream(baos);
mvos.writeObject(obj);
mvos.flush();
isHashComputed = false;
}
Here is get():
public Object get() throws IOException, ClassNotFoundException
{
if (serializedForm == null)
return null;
ByteArrayInputStream bais = new
ByteArrayInputStream(serializedForm);
MarshalledValueInputStream mvis = new
MarshalledValueInputStream(bais);
return mvis.readObject();
}
Should the constructor include the line
serializedForm = baos.toByteArray(); ?
searializedForm is initialized only in readExternal(). Thus, for
instances constructed with 'new MarshalledValue(obj)' all the methods
except for readExternal/writeExternal are broken.
Or am I missing something?
PS: this is for all MarshalledValue's in invocation.*, aop.* and
interception.*.
Thanks,
alex
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DTD hell
Is this for 4.0? I thought we were switching to XML schema for 4.0. We could switch to schemas for 3.2 also. -dain On Friday, March 7, 2003, at 11:50 AM, Scott M Stark wrote: I am working on adding the ability to specify a loader repository to all of the deployment types, and this adds a loader-repository element that needs a mixed content type with a loader-repository-config element with an ANY content type. This is needed because the loader-repository-config depends on the particular loader-repository class implementation. The problem is that if I add the following to the existing deployment dtds they become non-validatible because any elements that show up in an ANY content model element still must be declared, and this is the part that makes no sense to me. Is there a way to avoid this? !-- The loader-repository specifies the name of the UnifiedLoaderRepository MBean to use for the ear to provide ear level scoping of classes deployed in the ear. It is a unique JMX ObjectName string. Examples: loader-repositoryjboss.test:loader=cts-cmp2v1-sar.ear/loader- repository loader-repository jboss.test:loader=cts-cmp2v1-sar.ear loader-repository-config HeirarchicalLoaderRepository3 java2ParentDelegaton='true' / /loader-repository-config /loader-repository -- !ELEMENT loader-repository (#PCDATA | loader-repository-config)* !-- The loaderRepositoryClass attribute gives the classname loader-repository implementation. -- !ATTLIST loader-repository loaderRepositoryClass CDATA #IMPLIED !-- The loader-repository-config element specifies any arbitrary configuration fragment for use in configuring the loader-repository instance. The actual content of this element is specific to the loaderRepositoryClass and the code parsing the element. -- !ELEMENT loader-repository-config (ANY) Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is JDK 1.4 required to build
So when can I start to check in code into HEAD that will only build 1.4? What parts of the server must run on 1.3? After spending an entire day writing a lame IdentityHashMap (and I haven't even begun to test it) I am leaning to requiring 1.4 for the new persistence framework. I think David's DTM logging and recovery stuff will require NIO in 1.4. -dain On Friday, March 7, 2003, at 01:12 AM, Scott M Stark wrote: Agreed. I don't want that management headache propagated to 4.0. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 06, 2003 9:51 PM Subject: Re: [JBoss-dev] Is JDK 1.4 required to build I got no problem making 99% of CMP working on 1.3 (basicially anything that does not require JDBC3). It is just the #ifdef stuff I hate. -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Is JDK 1.4 required to build
Is JDK 1.4 now required to build? If not when are we going to add this requirement? I need an IdentityHashMap for the ObjectCopier and would like to encapsulate and delegate to IdentityHashMap for JDK 1.4 (because of speed) and for JDK 1.3 I will just is an IdentityKey wrapper. This code will be way easier to write if I can assume that we are compiling in 1.4. For now I will just write the 1.3 version. -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Unified interceptors?
On Thursday, March 6, 2003, at 04:08 PM, Jason Dillon wrote: What is left over is: org.jboss.cmp (I am guessing this is some of the new cmp framework) This is our new generic persistence code. Jason can you add a new empty module 'persistence' for us and we'll move the stuff over. org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil (required by org.jboss.cmp, does not depend on org.jboss.ejb) I'll move this stuff to org.jboss.util in the common package. I still believe that making the EJB-specific components of JBoss separate from the core system services is a very, very good idea. It will help keep JBoss a generic framework by forcing developers to keep service and system classes and components separate. It will also help promote the fact that JBoss is not just an EJB container, or rather isn't an EJB container at all... just a generic framework which happens to also provide EJB/J2EE services. +1 I feel that for the most part, the rest of the server is quite well organized into logical chunks of functionality. It is just this module which is the kitchen sink which has been bothering me for quite some time. I do not believe it is just a style issue either. Separation of functionality makes for better software engineering by isolation of similar components, which promotes simpler builds as well as unit and integration testing. +1 the server module is junk drawer especially org.jboss.ejb.plugins So, I think we should make the change, but I think it will be best to wait until the unified interceptor work has been completed. Hopefully that will be done by middle of next week, after which I can redo this separation, now that I have discovered all of the interaction points. Once that has been completed and proves functional via the testsuite I think we should move the cmp2 bits to its own home. We will as soon as we have a persistence module. Well the non EJB specific stuff will be moved to persistence, but a small number of classes will be put in org.jboss.ejb.entity.cmp. -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is JDK 1.4 required to build
I got no problem making 99% of CMP working on 1.3 (basicially anything that does not require JDBC3). It is just the #ifdef stuff I hate. -dain On Thursday, March 6, 2003, at 10:49 PM, Scott M Stark wrote: Originally I said I thought we needed to keep 4.0 buildable by JDK 1.3, but I'm starting to think otherwise. I'm about to give in to this demand. If users cannot switch to JDK 1.4 then I'm willing to say they cannot make use of the full set of features in 4.0. The remaining question I had was can the core services remain binary compatible with JDK 1.3, meaning JMX, AOP, deployers, etc. required to have a highly functional microkernel for building on top of. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 06, 2003 9:59 AM Subject: [JBoss-dev] Is JDK 1.4 required to build Is JDK 1.4 now required to build? If not when are we going to add this requirement? I need an IdentityHashMap for the ObjectCopier and would like to encapsulate and delegate to IdentityHashMap for JDK 1.4 (because of speed) and for JDK 1.3 I will just is an IdentityKey wrapper. This code will be way easier to write if I can assume that we are compiling in 1.4. For now I will just write the 1.3 version. -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] please notify before large scale changes to EJB land.
On Wednesday, March 5, 2003, at 11:56 AM, Jason Dillon wrote: EJB specific: ./org/jboss/security ? ./org/jboss/security/plugins ? ./org/jboss/monitor ? ./org/jboss/monitor/client ? ./org/jboss/verifier/strategy ? ./org/jboss/jmx/adaptor/ejb ./org/jboss/jmx/connector/ejb ./org/jboss/metadata ./org/jboss/proxy/ejb ./org/jboss/proxy/ejb/handle ./org/jboss/cmp/ejb ./org/jboss/cmp/ejb/ejbql ./org/jboss/deployment If the above stuff is truly EJB specific I think we should put them under the org.jboss.ejb package. If it is not then, we should move them to their respective modules (we will move the cmp stuff). I think we need a clear delineation between EJB specific stuff and general behaviors that can be reused by other distributed object frameworks like AOP. How does everyone feel about that? -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] UnifiedClassLoader notifications?
Can I register with a UnifiedClassLoader for a notification when the class loader is dereferenced by JBoss? I'm writing an object copier service for the new persistence engine and cache, so I'm holding on to some metadata for each class that can be copied. -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Re[2]: [JBoss-dev] New module for cmp? What about the ejb module?
I was just thinking about this the other day... I like just persistence and I would love to have the EJB related stuff moved to an EJB module. I'd also like to get rid of the org.jboss.ejb.plugins as it is just a junk drawer. -dain On Monday, March 3, 2003, at 12:07 AM, Alex Loubyansky wrote: Sunday, March 02, 2003, 9:15:33 PM, Jason Dillon wrote: JD I think it might be better to use a different name non-ejb related... JD but whatever... what about just persistence? I like just persistence too. alex JD --jason JD On Monday, March 3, 2003, at 01:45 AM, Jeremy Boynes wrote: I think so. Is 'cmp' OK for the new module name, or is that too strongly associated with EJBs? Maybe 'persistence'? Jeremy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Jencks Sent: Sunday, March 02, 2003 10:10 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] New module for cmp? What about the ejb module? Would it be appropriate to put the new cmp framework in its own module since it is not particularly dependent on ejbs? Are we going to move the ejb support into the currently empty ejb module? david jencks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBOSS and SQL Server 2000
On Thursday, February 27, 2003, at 02:49 PM, Brian Repko wrote: And to the JBoss-dev list - jeez - way to shut down a newbie. Here is someone in a Microsoft shop bringing in J2EE and JBoss and not one message was helpful and a couple were downright mean. No you are wrong and don't post here. But you'll talk about eclipse all day long and that is appropriate? I agree about the eclipse discussion, but it does actually have a point for development of the jboss server. It is always a pain to get any IDE to like our directory layout. -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Directory layout (was Re: [JBoss-dev] JBOSS and SQL Server 2000)
The reason for all the modules is dependancies. This is why you can run different deployments of JBoss. If everything were in a single source tree, it would be almost impossible to run without everything. -dain On Thursday, February 27, 2003, at 04:00 PM, Dave Neuer wrote: --- Dain Sundstrom [EMAIL PROTECTED] wrote: snip I agree about the eclipse discussion, but it does actually have a point for development of the jboss server. It is always a pain to get any IDE to like our directory layout. -dain I would go so far as to say that it is a pain to get a potential new developer to like the directory layout as well, and that only with a tool like Eclipse is does it even begin to feel feasable to a new developer to navigate the hierarchy of widely dispersed directories (and identically named classes in different packages). Especially assuming that that developer is used to the conventional single package/directory hierarchy used in most Java development shops/projects. While I can see an advantage for the current layout in terms of facilitating working on one small piece of the system, I also think that it adds a great deal of overhead to grasping the JBoss architecture and makes finding other source files/packages that might be relevant more difficult (i.e., find ../../../ -type d 'org/jboss/management' -print). Is there some other advantage that the current layout provides as well? Ant can certainly handle building and packaging up discreet files from a single hierarchy so it's not really a build/packaging issue, right? I could see how one might argue that it makes concurrent experimental development easier (a la Bill-AOP/Hiram-AOP) except that that's what CVS branches are for, right? Sorry if this has been covered on the lists or the forums ad nauseum or if there's consensus that the current layout is the right way. Dave Neuer __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
I've had only two customers ask about CORBA support, but only as an interim solution until the clients can be rewritten. Fortunately both decided to just port the clients at the same time. -dain On Thursday, February 27, 2003, at 05:04 PM, Luke Taylor wrote: David Jencks wrote: Maybe we're confusing 2 issues here: 1. writing a maintainable usable jboss dtm 2. supporting corba etc. Does anyone actually use CORBA clients agains JBoss - from Java even, never mind C++. I can understand the desire to use CORBA the other way - i.e. calling out to access a legacy system, but is there any reason why anone would choos to use CORBA clients. Maybe supporting them isn't really so important. At one point CORBA was intended to support interceptors (client and server side) in a standard way, but I've no idea if the spec. was ever completed - they always seemed to be arguing about it and that was years ago. If it was, you could probably supply a set of JBoss CORBA interceptors which did the same job as the custom Java ones. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Eclipse is so amazing...
Ya, for like 5 minutes. All I really want out of an ide is an editor, syntax highlighting and ant. I can get that from vim, bash and ant. Am I missing some amazing feature. -dain On Wednesday, February 26, 2003, at 02:24 PM, Jason Dillon wrote: Ahh, but have you tried Eclipse? --jason On Thursday, February 27, 2003, at 02:02 AM, Dain Sundstrom wrote: vim -dain --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
Bill, Where is you design? David's design looks totally obvious to me. It is well understood, and based on our existing real-world experiences. To me it looks like you are the one invent the perfect design/API. So can you present you invocation chain as did and show us the error in our logic? -dain On Monday, February 24, 2003, at 09:39 AM, Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Saturday, February 22, 2003 11:48 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread This is really boring and unpleasant, bill. We don't seem to I am sorry I am boring you. Summarized, my major concern with the TX refactor is that it will not work for clients that cannot have interceptor chains (i.e. non-Java), but support Tx propagation (CORBA) for all trans-attributes (specifically, NotSupported, and RequiresNew). I thought Marc's vision for creating these generic, transport specific invokers was to isolate the EJB Container from the transport layer, and I see this refactor as breaking this vision. The only way I see this working is if we have separate transport-specific interceptor chains on the server to support non-Java clients. I wanted to avoid this because this is what has happened when I put in support for multiple invokers. Client-side interceptor configuration became bloated. All this to avoid creating and passing over a TxId. See my point now? === As far as AOP goes, I'm hoping that as we implement services on top of the Framework and apply the framework to JMX and remoting, the requirements and API will be fleshed out as we iterate. I'd like the design of AOP to be driven by real-world requirements and applications rather than what we might think as the perfect (and probably bloated) design/API might be currently. I'm not afraid of throwing code out or having to modify huge amounts of code to iterate. Iteration is key. Allows us to get to market quick and to quickly notice bad designs. Didn't somebody say Release early, release often? Bill have a shared understanding of how interceptors ought to work with local and remote calls. Most of your comments make no sense to me, and I think contrariwise. I'll try to explain my view one more time, and I'll write an interceptor framework that satisfies my understanding of what is needed for mbeans, ejbs, remoting, and aop (which I don't understand all that well). If you don't like it and I can't understand your objections, I'll let you indulge your previously expressed wish to write a transaction manager. You might also get that wish fulfilled if you say the following is obvious. I thought it was, but I don't think we have agreed on it. I'm writing it down to try to form a basis for discussion, which is currently missing. == Dave's mental model for invocations. Lets assume first you already have something representing the object you are interested in (such as an ejb Remote interface object, mbean thingy, aop-ized object, or some kind of proxy). Items marked with a * might be removed for non-remotable objects. Key to symbols: \/ interceptor chain invokeNext() calls. \/ || method/field access/... calls whose nature may vary depending on the application and that are not part of the interceptor/invocation framework. \/ \/ calls between segments. These are of the form invoke(invocation) on a particular object found by the current interceptor. .. sequence of interceptors in a chain. || || transport mechanism. For a remote object, this is the boundary between client and server. === Some program does something on the object \/ || The Object \/ || Something that knows about interceptor chains and metadata. It looks at the method (or field access, ...) call and its environment and determines what interceptor chain to use. It constructs an Invocation object that includes an iterator over the selected chain, the method call data, and some metadata. Then it starts the invocation down the chain. I will call this a Container. I believe it corresponds to your aop Advisor(s). \/ Several interceptors (client side interceptors specific to the object/class you are calling) . \/ * Transport selector interceptor. This examines the metadata and picks a transport endpoint. It calls invoke(invocation) on the selected transport endpoint. It does not call invocation.invokeNext(), so this may be the end of the use of the original interceptor iterator. \/ \/ * Transport endpoint. If this is a local do nothing transport, it may simply call invocation.invokeNext(). Otherwise, it replaces the interceptor iterator with one for the client side transport interceptor stack. \/ * Several interceptors (client side interceptors
[JBoss-dev] Verifier problems
I'm working on fixing the exception tests and I have run into a problem with the verifier. I am getting the following warning that is causing the deployment to fail: Bean : ExceptionTesterEJB Method : public abstract void ejbExceptionInStore() throws Exception Section: 7.10.7 Warning: The methods in the local interface must not include java.rmi.RemoteException in their throws clause. I don't think they wanted to exclude 'throws Exception' from a declaration. This is really a grey area of the spec. Who is maintaining this code? What do you think? -dain --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TxInterceptor split is really really bad
Jeff, Don't let these guys push you around. Bill's just in a pissy mood today. -dain On Friday, February 21, 2003, at 06:01 PM, Jeff Haynie wrote: Oh, I buy into it - and I'm neither for OR against what David is saying. I'm merely saying you should separate the concerns - but it seems like that is obvious and redudant (although not so apparent with all the back in forth) to you. As you know, I don't work for Jboss Group. I'm just merely trying to help out on my own *free time* and try and help make this a better product with what little value I can add. Sorry I stepped into the flames. I was hoping to enlighten a little bit to the fact that you could push some of this stuff into the remoting stuff that tom and I worked on. Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Haynie Sent: Friday, February 21, 2003 6:15 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad Yes - but you guys don't seem to buy into it otherwise you won't be talking about where and how tx or remoting should go into AOP. Maybe I'm missing something. I'm not understanding you. I certainly buy into it and am implementing stuff (albeit slowly). Whether you and David buy into it is irrelevent. The vision is set. THis is where we're going. The whole point is isolation and being able to dynamically remote or not remote with any protocol you want. IMHO, Davids implementation for tx right now doesn't allow for this isolation. He disagrees. So what? We disagree. Eventually it will all flush out and either David and/or I will end up rewriting everything. My bet David gets there first since I've got A.D.D. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Friday, February 21, 2003 6:09 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I personally don't think AOP should have anything related to transactions, remoting, etc. I think that should be pushed up into the functional areas that apply those specific semantics to the subsystems since they are quite different depending on the subsystem (JMS, EJB, etc) and location (local,remote). Where have you been? Marc has been talking about creating an AOP framework and services on top of this framework since the fall. The whole point is to break ourselves away from EJB and isolate and abstract out distribution infrastructure even more from a coding perspective. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February
Re: [JBoss-dev] jbosscx rfe 677512
On Monday, February 17, 2003, at 05:21 PM, Timothy Barreto wrote:
try { ...
} finally {
try { rs.close(); rs=null;
stmt.close(); stmt=null;
} catch (Exception e){}
}
You need to put rs.close() and stmt.close() in different try blocks.
If rs.close() throws an exception stmt.close() may never get called.
In the CMP engine I have a utility class that contains a bunch of
helper methods for closing db resources. Here is a snippet.
public final class JDBCUtil
{
private static Logger log =
Logger.getLogger(JDBCUtil.class.getName());
public static void safeClose(Connection con)
{
if(con != null)
{
try
{
con.close();
} catch(SQLException e)
{
log.error(SQL error, e);
}
}
}
...
}
I have a safeClose method for each resource type. This makes the
cleanup code very easy to write as you don't have to check for nulls.
For example:
try{
// whatever
} finally {
JDBCUtil.safeClose(rs);
JDBCUtil.safeClose(stmt);
}
-dain
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why are we using this bogus construct
This seems backwards to me. I usually do something like this:
class X
{
HashMap clients = new HashMap();
public void someMethod()
{
synchronized(clients)
{
m.put(dc, cq);
}
...
}
public void someOtherMethod()
{
HashMap clientsCopy = null;
synchronized(clients)
{
clientsCopy = new HashMap(clients);
}
Iterator i = clientsCopy.keySet().iterator();
while( i.hasNext() )
{
...
}
}
}
For the insert, you only get a quick synchronized around the add, and
on iteration you get a single copy in the synchronize. If the
iteration very small and quick, I sometimes put the entire iteration in
the synchronized block, but you need to be careful about open calls.
-dain
On Thursday, February 13, 2003, at 11:20 AM, Scott M Stark wrote:
I have seen this usage construct in a few places in the code and it
makes
no sense to me:
class X
{
HashMap clients = new HashMap();
public void someMethod()
{
synchronized(clients)
{
HashMap m = new HashMap(clients);
m.put(dc, cq);
clients=m;
}
...
}
public void someOtherMethod()
{
Iterator i = clients.keySet().iterator();
while( i.hasNext() )
{
...
}
}
}
The unsynchronized clients HashMap is synchronized and copied when
modified and accessed without synchronization in other contexts. This
is
not thread safe for the accesses and makes for very expensive updates.
Why isn't the HashMap simply synchronized and used without copying?
Scott Stark
Chief Technology Officer
JBoss Group, LLC
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why are we using this bogus construct
Hiram,
This type of construct creates some trick code. You iterate over the
keys, and I assume somewhere in the code you do clients.get(key). Well
there is no guarantee the the key is associated. I bet there are a ton
of other issues as your iterator in the read phase drifts from reality
of changing clients HashMap. Anyway, I hope you documented this
heavily.
-dain
On Thursday, February 13, 2003, at 12:28 PM, Hiram Chirino wrote:
Yep.. your way is valid too but you take a
synchronization hit on every read. The otherway, the
performace hit is on the write. As I said previously,
if you read the map ALLOT more than you write to it,
then it makes sense to do it backwards.
Regards,
Hiram
--- Dain Sundstrom [EMAIL PROTECTED] wrote:
This seems backwards to me. I usually do something
like this:
class X
{
HashMap clients = new HashMap();
public void someMethod()
{
synchronized(clients)
{
m.put(dc, cq);
}
...
}
public void someOtherMethod()
{
HashMap clientsCopy = null;
synchronized(clients)
{
clientsCopy = new HashMap(clients);
}
Iterator i =
clientsCopy.keySet().iterator();
while( i.hasNext() )
{
...
}
}
}
For the insert, you only get a quick synchronized
around the add, and
on iteration you get a single copy in the
synchronize. If the
iteration very small and quick, I sometimes put the
entire iteration in
the synchronized block, but you need to be careful
about open calls.
-dain
On Thursday, February 13, 2003, at 11:20 AM, Scott M
Stark wrote:
I have seen this usage construct in a few places
in the code and it
makes
no sense to me:
class X
{
HashMap clients = new HashMap();
public void someMethod()
{
synchronized(clients)
{
HashMap m = new HashMap(clients);
m.put(dc, cq);
clients=m;
}
...
}
public void someOtherMethod()
{
Iterator i = clients.keySet().iterator();
while( i.hasNext() )
{
...
}
}
}
The unsynchronized clients HashMap is synchronized
and copied when
modified and accessed without synchronization in
other contexts. This
is
not thread safe for the accesses and makes for
very expensive updates.
Why isn't the HashMap simply synchronized and used
without copying?
Scott Stark
Chief Technology Officer
JBoss Group, LLC
---
This SF.NET email is sponsored by: FREE SSL Guide
from Thawte
are you planning your Web Server Security? Click
here to get a FREE
Thawte SSL guide and find the answers to all your
SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by: FREE SSL Guide
from Thawte
are you planning your Web Server Security? Click
here to get a FREE
Thawte SSL guide and find the answers to all your
SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why are we using this bogus construct
On Thursday, February 13, 2003, at 01:46 PM, Toby Allsopp wrote: My advice, FWIW, is to stop messing around and just use util.concurrent by Doug Lea (http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/ intro.html). There aren't many people who can prove that their tricky concurrent Java code is correct, but Doug Lea can. Just use EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap and sleep at night. I see no reason to bring out an aircraft carrier when a dingy will do. The concurrent package is just a behemoth when we could just simply synchronize the access correctly and simply. I bet that if you correct and simple synchronization, the performance difference would be barely measurable. I say to it correctly and simply; if it latter *proves* to be slow, we fix it. What it that Kunth quote early optimization is the root of all evil? -dain --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Remote class loading servlet
Scott, I'm putting the question for you at the top, so you can see it. How do we specify the code base for remote loading? If James writes this he will need to change it to point to the servlet. James, You are way over thinking this. I suggest you just start coding. :D On Friday, February 7, 2003, at 10:40 AM, James Cooley wrote: Scott M Stark wrote: You don't have to worry about the port or interface as these are attributes of the web server context the servlet is deployed to. Okay the default container listens on 8080 from what you're saying there's no need to listen on 8083 anymore. I'm not sure how you'd map the WebServer replacement servlet in the web.xml if the port is not exclusive - perhaps a filter to check each call or something but that's a fair bit of overhead. So what I think is needed here are 2 Tomcat Connectors/Jetty Adapters to one to bind to 8080 and another to bind to 8083 - the 8083 connector/adapter can be setup as part of the servlet containers config. You create a war named say class-loader. Then we set the codebase for remote stubs to be http://whatever:8080/class-loader [the question for Scott above]. Then create a servlet that accepts all requests to the context-root, convert the requested file (under your context-root) into a class name, and return that class from the thread context class loader. You don't have to worry about class loaders. Just use the thread context class loader. Sorry I wasn't clear on this - WebServer has the following method You're sill trying too hard. All of that code is already handled by the the Jetty or Tomcat web container in which your servlet is running. It is really as simple as Thread().currentThread().getClassLoader().getResourceAsStream(name); -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Remote class loading servlet
On Friday, February 7, 2003, at 01:28 PM, James Cooley wrote: Dain Sundstrom wrote: Scott, I'm putting the question for you at the top, so you can see it. How do we specify the code base for remote loading? If James writes this he will need to change it to point to the servlet. James, You are way over thinking this. As I said there isn't a unit test for this so I guess it looked like it was doing more than it was doing in reality. Good idea. Can you add a unit test for this also? :) -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Remote class loading servlet
We have a small project open for a volunteer. In Jboss 2 and 3 we have a custom lightweight web server (port 8083) that returns java class files from the classLoader.getResouceAsStream to RMI clients (this is how remote class loading happens). I talked to Scott at JBoss Boot Camp and we think it is a good idea to replace this with a plain old Servlet for JBoss 4.0 so it can work with regular security, pooling and such. This is a fairly simple piece of code and shouldn't take longer then a day or two. If you are interested the code can be found in jboss-head/server/src/main/org/jboss/web/WebServer.java -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Accessing Container from an EJB?
Yes but it is not exposed on the MBean interface, so how do you get a reference to the module unless you already have a real reference to the container? -dain On Thursday, January 30, 2003, at 06:50 AM, David Jencks wrote: I'm pretty confused about what exactly you are trying to do, since there is already an instance variable ejbModule and and accessors get/setEjbModule in the Container class. ?? david jencks On Thursday, January 30, 2003, at 01:36 AM, Jeremy Boynes wrote: I am trying to write an EJBTestCase that needs access to information held in the Container (Container.getEjbModule().getModuleData(CATALOG)). I can do this if I add EjbModule as a attribute of Container but was wondering if I should do this or if there was another way? Thanks Jeremy --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Accessing Container from an EJB?
Why not? I see no reason why a client can't look up the EJB container directly using an MBean and get some information. I can see why this would be a bad idea, but we shouldn't restrict the access. Anyway this is for some test code. -dain On Thursday, January 30, 2003, at 04:23 AM, julien viet wrote: I don't think EJB can access its container directly. However maybe you could add an interceptor in stack that does nothing but provides you information you need, because they have access to container. Then your EJB could contact interceptor (with static call for instance) Maybe is it possible via JMX also ? julien JB I am trying to write an EJBTestCase that needs access to information held in JB the Container (Container.getEjbModule().getModuleData(CATALOG)). I can do JB this if I add EjbModule as a attribute of Container but was wondering if I JB should do this or if there was another way? JB Thanks JB Jeremy JB --- JB This SF.NET email is sponsored by: JB SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! JB http://www.vasoftware.com JB ___ JB Jboss-development mailing list JB [EMAIL PROTECTED] JB https://lists.sourceforge.net/lists/listinfo/jboss-development -- Best regards, julienmailto:[EMAIL PROTECTED] ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Feature request, dev assignments
Sacha,
What you suggest would require rewriting the byte code generator, which
I didn't write. Currently all the implementation of the abstract
methods does is call an invocation handler.
I do really like the idea of the PropertyChange[Veto]Listener and have
already added it to the task list. This fits into our (the cmp team)
plans to add change notification (observer pattern).
-dain
On Wednesday, January 29, 2003, at 01:45 AM, Sacha Labourey wrote:
Dain,
I agree, this is some of a hack, but any trick would be hack because it
requires the container to implicitly do some call. What your container
bytecode implementation generates is something like that (very
pseudo-code
as we all know it is something like invoke):
public void setXXX (Object bla)
{
doMyPersistenceThingForXXX();
}
I was only suggesting something like:
public void setXXX (Object bla)
{
if (XXXSeterImplementedBySuperClass())
super.setXXX(bla);
doMyPersistenceThingForXXX();
}
Pro:
- very simple for both your code and the developer code
- no need to have 2x the same setters (or getter if you want to decode
stuff)
Cons:
- proprietary
- you could just (setters) deny access by throwing an exception but
not
modify the actual content of what is stored. This is a real miss. The
Veto
thing would also need to be extended for this. Some people have to trim
white spaces for example.
Nothing magic here.
cheers
sacha
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Dain
Sundstrom
Envoye : mardi, 28 janvier 2003 01:56
A : [EMAIL PROTECTED]
Objet : Re: [JBoss-dev] Feature request, dev assignments
I never really liked this idea. I think you should provide a concrete
setPostalCode (String code) method and if the data is valid you would
call setPostalCodeField (String code) or setPostalCode_(String code).
I think this type of validation is part of the business logic.
Alternatively, there are types of validation that are really an aspect
(deployment environment specific). For example, a company specific
mail route field. The validation of this field would depend on the
deployment environment (which company it is deployed at). In this
case
I see an interceptor, possibly a Bean Scripting Framework interceptor.
What I am getting at is I think this proposed solution is a hack and I
personally would not accept the patch, but the user community has
convinced me to include things I consider hacks.
-dain
On Monday, January 27, 2003, at 08:31 AM, Themba Mbatha wrote:
Hi all;
What would be the procedure if one is interested in implementing a
feature request? There is a feature request (647669) that I also need
a.s.a.p. and I'm prepared to contribute the implementation once I'm
done.
Regards.
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Feature request, dev assignments
I don't know, but we could create our own listener to support modifying
the value. I'll have to think about the implications that. We plan on
supporting notifications from the backend also, so changing the value
may be problematic. You will also be able to have many entities fields
mapped to the same column. . . . Maybe we should have two listener
interfaces: one for local changes and one for backend changes. Anyway,
I simply prefer a listener approach to an implicit method call.
-dain
On Wednesday, January 29, 2003, at 11:40 AM, Sacha Labourey wrote:
But would this allow some observer to modify the actual content of
what is
set (setter) or returned (getters)? This is the second part of the
interest
IMHO.
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Dain
Sundstrom
Envoye : mercredi, 29 janvier 2003 18:35
A : [EMAIL PROTECTED]
Objet : Re: [JBoss-dev] Feature request, dev assignments
Sacha,
What you suggest would require rewriting the byte code generator,
which
I didn't write. Currently all the implementation of the abstract
methods does is call an invocation handler.
I do really like the idea of the PropertyChange[Veto]Listener and have
already added it to the task list. This fits into our (the cmp team)
plans to add change notification (observer pattern).
-dain
On Wednesday, January 29, 2003, at 01:45 AM, Sacha Labourey wrote:
Dain,
I agree, this is some of a hack, but any trick would be hack because
it
requires the container to implicitly do some call. What your
container
bytecode implementation generates is something like that (very
pseudo-code
as we all know it is something like invoke):
public void setXXX (Object bla)
{
doMyPersistenceThingForXXX();
}
I was only suggesting something like:
public void setXXX (Object bla)
{
if (XXXSeterImplementedBySuperClass())
super.setXXX(bla);
doMyPersistenceThingForXXX();
}
Pro:
- very simple for both your code and the developer code
- no need to have 2x the same setters (or getter if you
want to decode
stuff)
Cons:
- proprietary
- you could just (setters) deny access by throwing an exception but
not
modify the actual content of what is stored. This is a real miss. The
Veto
thing would also need to be extended for this. Some people have to
trim
white spaces for example.
Nothing magic here.
cheers
sacha
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Dain
Sundstrom
Envoye : mardi, 28 janvier 2003 01:56
A : [EMAIL PROTECTED]
Objet : Re: [JBoss-dev] Feature request, dev assignments
I never really liked this idea. I think you should provide a
concrete
setPostalCode (String code) method and if the data is valid you
would
call setPostalCodeField (String code) or setPostalCode_(String
code).
I think this type of validation is part of the business logic.
Alternatively, there are types of validation that are really an
aspect
(deployment environment specific). For example, a company specific
mail route field. The validation of this field would depend on the
deployment environment (which company it is deployed at). In this
case
I see an interceptor, possibly a Bean Scripting Framework
interceptor.
What I am getting at is I think this proposed solution is a hack
and I
personally would not accept the patch, but the user community has
convinced me to include things I consider hacks.
-dain
On Monday, January 27, 2003, at 08:31 AM, Themba Mbatha wrote:
Hi all;
What would be the procedure if one is interested in implementing a
feature request? There is a feature request (647669) that I also
need
a.s.a.p. and I'm prepared to contribute the implementation once I'm
done.
Regards.
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2
See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Re: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
On Tuesday, January 28, 2003, at 12:45 AM, David Jencks wrote: On Tuesday, January 28, 2003, at 12:47 AM, Dain Sundstrom wrote: On Monday, January 27, 2003, at 09:36 PM, David Jencks wrote: On Monday, January 27, 2003, at 07:39 PM, Dain Sundstrom wrote: Wow, I had no idea it was this complicated. Anyway the real problem is a Dynamic MBean has a setAttributes method to group together an entire set of attribute changes in one operator, but when we go to standard mbeans we lose that concept because we only have a bunch of setters. That sucks. ??? You still have the setAttributes method on the mbean server, which is the only way you can get at the stuff. Ya sure, but the implementation just calls some setters. There implementation doesn't understand that this is a group of changes. If the setAttributes was implemented by hand it could understand that host, port and back log were all changed and only create the new listener socket once. So we need to fix the jmx implementation. My point is there is nothing to fix. In the end all the implementation does not have the code to handle a block of setters. I suppose you could call adding a state change (life cycle interceptor) a fix, but I wouldn't. It is simply additional frame work to deal with a deficiency in the implementation. You're not fixing the problem but coding around it. Anyway I say potato and you say potatoe :) -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: how's ecperf going?
On Tuesday, January 28, 2003, at 09:07 AM, marc fleury wrote: Agreed. In this case there is a strong performance reason to split the code into two interceptors: The point is that the call in the interceptors is JUST dissaciation and association. The mumbo jumbo we are talking about (whatever it means to suspend and resume a transaction) is not really relevant to the interceptor. I don't think we need to change the interceptor just the fact that suspend/resume should not be distributed calls just association calls in JTA. Let's treat spec bugs for what they are. BUGS. That sounds logical, but we don't get to change the specs. This would be like Scott saying that classloading works perfectly, but the Sun JVM has a bug (which is does); in the end he coded around the problem. -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Wow, I had no idea it was this complicated. Anyway the real problem is a Dynamic MBean has a setAttributes method to group together an entire set of attribute changes in one operator, but when we go to standard mbeans we lose that concept because we only have a bunch of setters. That sucks. What you have detailed looks like a good solution to me. In the end, I just want to make the admins happy. BTW, I believe we do have an orthogonal problem with MBeans being implemented incorrectly. We have a ton of beans that simply don't do what they say they will. I see no reason why an bean that has a port setting can't remove the existing socket and create a new one. Hey I just thought of something. We implement our own MBean spec... XMBean right? We could have additional state for attributes that says these attributes are only writable while the bean is stopped. Then in the MBeanMetaData getter we check the state and only return the attributes that are editable at that state. This will work since we don't cache MBean MetaData. What do you think? I also think we should extend the MBeanMetaData objects to support jboss specific stuff like the above attributes. Then we can display these in our consoles. -dain On Friday, January 24, 2003, at 08:00 PM, David Jencks wrote: Yes, that's the idea. It goes like this when jboss instantiates an mbean from a *-service.xml file: (create mbean) state: instantiated (set attributes) state: configured (call create method) ~(call destroy method) state: created (call start method) ~(call stop method) state: started where the ~() methods go backwards from the other methods. Personally I think the create and destroy methods could be safely removed as useless, but I lost the argument the last time we had it. Anyway, to see why this might be useful, lets hypothesize an mbean that takes a long time to create (just as an object) and has a socket. You want to set the ip address and port on the socket as separate attributes on the mbean. Well, creating a new socket whenever you change the host or port is not very satisfactory since there's a good chance you want to change both. Changing just one will leave the mbean in a unusable state, pointing to the right host but wrong port. You don't want to replace the mbean object with a new one because it takes a long time to create. So , the service lifecycle lets you: stop (mbean is now theoretically unusable: this should be implemented in an interceptor, but is not right now)(this would discard the old socket) change both attributes (while the mbean is off) start (this creates a new socket with all correct parameters)(mbean is now usable again). There are also mbean dependencies, whereby if your mbean has an ObjectName valued attribute, and you tell jboss, your mbean can't start until the referenced mbean has started. This is used to get most of jboss to start in an order that will work. The code that does this is now spread over ServiceController, ServiceConfigurator, and ServiceContext with a little bit of ServiceCreator thrown in. Hope this clarifies what is going on a little bit. There are no attributes that have no effect... its just that say a port number may not get into the socket until you cycle the mbean, in case you want to change the host also. I also mentioned earlier that there's an xmbean attribute indicating what the effect on service lifecycle should be of changing an attribute value. The idea behind this (unimplemented) is that if you set several attributes at once, jboss should be able to cycle the lifecycle state for you. david jencks On Friday, January 24, 2003, at 05:07 PM, Matt Munz wrote: David, We are miscommunicating. In all the mbeans I have written and seen in jboss, aside from egregious bugs, if setting an attribute doesn't have an immediate effect, it does have the desired effect if you run through the service lifecycle (usually stop, start, occasionally stop, destroy, create, start). My view is that mbeans in jboss can take advantage of the service lifecycle. If you don't want to, make all your attribute changes have their effects immediately. All our mbeans are pretty much jboss specific and most heavily use the service lifecycle. They just won't run without it. I still think it is a really convenient extension to vanilla jmx and don't see why we should replace it. I barely know what the service lifecycle is. I have not used it. I am not arguing to replace it. I never said that. You said that. How do I set an attribute correctly, step by step, for a Bean that uses the service lifecycle? It helps me to use a state metaphor when considering lifecycle issues. It sounds like there are several states a lifecycle-oriented bean can be in: destroyed, created, running. In which state is it safe to set RW attributes on lifecycle-oriented beans? Is the following the appropriate way to set values on
Re: [JBoss-dev] RE: how's ecperf going?
I completely agree that the extra suspend/ resume should not cause any performance degradation. The problem with that code it is fucking hard to read. Your stare at it for a while going what the fuck is he doing here and then you finally realize that they always suspend the tx at the beginning of the method. This code is much easier to read if you put an if/else in the outer most element and only touch the transaction if you have to. I made this change when messing around but never got to committing it. Unless there is a real measurable performance problem I think we should always favor readability and maintainability of code. -dain On Monday, January 27, 2003, at 05:40 PM, David Jencks wrote: FWIW, I agree 100% with you on this marc david jencks On Monday, January 27, 2003, at 05:34 PM, marc fleury wrote: In all of the other application servers I have been working on TransactionManager.resume() and suspend() are expensive operations, since the JTA spec version 1.0.1 (section 3.2.3) requires the TM to delist/enlist every resource that takes part in the transaction, which is costly. If it is done differently in Jboss on purpose, IT IS A BUG IN THE SPEC ! I am dead serious. Also all the discussion sucks and comes from the name of the API. Suspend() and resume() look like they are Tx lifecycle operations which require resource delisting??? NO NO NO, resume and suspend in the scope of what we do in the method is PURELY THREAD ASSOCIATION, the TX goes on. In our code it means resume association suspend association not suspend TX. I had called it dissassociateThread() and associateThread() to emph the fact that all we are looking for is association of thread to TX and THAT'S IT. It was changed in subsequent impls. You are talking about something else, you are talking about the notion of suspending THE TRANSACTION. Do we have a line? marcf Doesn't anyone else see this? I feel like I am taking crazy pills -- ZooLander -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
On Monday, January 27, 2003, at 09:36 PM, David Jencks wrote: On Monday, January 27, 2003, at 07:39 PM, Dain Sundstrom wrote: Wow, I had no idea it was this complicated. Anyway the real problem is a Dynamic MBean has a setAttributes method to group together an entire set of attribute changes in one operator, but when we go to standard mbeans we lose that concept because we only have a bunch of setters. That sucks. ??? You still have the setAttributes method on the mbean server, which is the only way you can get at the stuff. Ya sure, but the implementation just calls some setters. There implementation doesn't understand that this is a group of changes. If the setAttributes was implemented by hand it could understand that host, port and back log were all changed and only create the new listener socket once. What you have detailed looks like a good solution to me. In the end, I just want to make the admins happy. BTW, I believe we do have an orthogonal problem with MBeans being implemented incorrectly. We have a ton of beans that simply don't do what they say they will. I see no reason why an bean that has a port setting can't remove the existing socket and create a new one. I'm not sure if you are complaining about mbeans that don't actually undo the start in stop (i.e. if it creates a socket in start, it should forget it in stop, then make a new one when start is called again), or saying you think socket creation should be done immediately when you change the port, irrespective of mbean state. I hope it's the first. No I mean the second. If you change the port, it should close the existing socket and create a new one. I see no reason why the service should have to be stopped, as I can do this today... it is just an implementation decision. Hey I just thought of something. We implement our own MBean spec... XMBean right? We could have additional state for attributes that says these attributes are only writable while the bean is stopped. Then in the MBeanMetaData getter we check the state and only return the attributes that are editable at that state. This will work since we don't cache MBean MetaData. What do you think? For info-- we have this in the xmbean dtd, but we don't have any interceptor support for it yet, and I won't work on it until the aop stuff has settled down. I think some kind of icon indicating the lifecycle state needed for the change would be best. For hiding attributes, No thanks, then you can't tell what you might be able to set until you stop the mbean. Sorry, I ment to say that the attribute is read only in the running state with an icon that says you must stop the service to edit this attribute. I also think we should extend the MBeanMetaData objects to support jboss specific stuff like the above attributes. Then we can display these in our consoles. modelmbean metadata is already generically extensible, and we have extended it with stuff like the lifecycle level and (actually implemented thanks to Matt Munz) persistence. Right now I don't know of a generic way to display arbitrary metadata like this, AFAIK each item would have to be hardcoded. Maybe someone who can actually design usable interfaces could suggest something:-) Cool. I personally have no problem with hard coding our web jmx console to support the attributes we use. -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Finders, Selectors and ... deleters?
On Friday, January 17, 2003, at 11:08 AM, Jeremy Boynes wrote: This leaves the JBoss-QL part read-only (it just qualifies the instances to be deleted). We know we're deleting Transactions as the method would be on the home interface for the Transaction EJB. I think we should support a full CRUD language. Specifically, I mean that the user should not be restricted to just specifying the WHERE clause, but they should be required to specify a DELETE clause also. Then we just put in a restriction that a remove method on the home interface is only allowed to remove entities of the current type. This is the same restriction finders have. The reason I think we should have a full CRUD language is it allows an ejbSelect style method (although we may call it something else) to delete any set of objects with a single operation. This will be particularly useful to delete a subset of related objects. -dain --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Finders, Selectors and ... deleters?
It is already in the JBoss 4.0 task list. http://sourceforge.net/pm/ task.php?func=detailtaskproject_task_id=68960group_id=22866group_proj ect_id=15043 -dain On Friday, January 17, 2003, at 12:23 PM, Bill Burke wrote: Please archive this on the Persistence forum. Thanks guys. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Friday, January 17, 2003 1:14 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Finders, Selectors and ... deleters? On Friday, January 17, 2003, at 11:08 AM, Jeremy Boynes wrote: This leaves the JBoss-QL part read-only (it just qualifies the instances to be deleted). We know we're deleting Transactions as the method would be on the home interface for the Transaction EJB. I think we should support a full CRUD language. Specifically, I mean that the user should not be restricted to just specifying the WHERE clause, but they should be required to specify a DELETE clause also. Then we just put in a restriction that a remove method on the home interface is only allowed to remove entities of the current type. This is the same restriction finders have. The reason I think we should have a full CRUD language is it allows an ejbSelect style method (although we may call it something else) to delete any set of objects with a single operation. This will be particularly useful to delete a subset of related objects. -dain --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Branch_3_0 doesn't build on OSX
Maybe I have something messed up, but Branch_3_0 doesn't build anymore on my apple. I have an old version of Branch_3_0 that builds fine. Does anyone have an apple, and can build? What did you setup? Here is what I get. bash-2.05a$ which java /usr/bin/java bash-2.05a$ ls -l /usr/bin/java lrwxr-xr-x 1 root wheel 57 Jan 14 14:18 /usr/bin/java - /System/Library/Fram eworks/JavaVM.framework/Commands/java bash-2.05a$ java -version java version 1.3.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-root_1.3.1_020714- 12:46) Java HotSpot(TM) Client VM (build 1.3.1_03-69, mixed mode) bash-2.05a$ ./build.sh Error: JAVA_HOME is not defined correctly. We cannot execute java Thanks for any help. -dain --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Branch_3_0 doesn't build on OSX
That works perfectly. I didn't see the Home directory in the tree. Thanks, -dain On Thursday, January 16, 2003, at 11:54 AM, Hunter Hillegas wrote: JAVA_HOME should be set to: /System/Library/Frameworks/JavaVM.framework/Versions/1.4.1/Home or /System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home Depending on which JVM you are using... What is your set to? From: Dain Sundstrom [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Thu, 16 Jan 2003 11:28:03 -0600 To: [EMAIL PROTECTED] Subject: [JBoss-dev] Branch_3_0 doesn't build on OSX Maybe I have something messed up, but Branch_3_0 doesn't build anymore on my apple. I have an old version of Branch_3_0 that builds fine. Does anyone have an apple, and can build? What did you setup? Here is what I get. bash-2.05a$ which java /usr/bin/java bash-2.05a$ ls -l /usr/bin/java lrwxr-xr-x 1 root wheel 57 Jan 14 14:18 /usr/bin/java - /System/Library/Fram eworks/JavaVM.framework/Commands/java bash-2.05a$ java -version java version 1.3.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-root_1.3.1_020714- 12:46) Java HotSpot(TM) Client VM (build 1.3.1_03-69, mixed mode) bash-2.05a$ ./build.sh Error: JAVA_HOME is not defined correctly. We cannot execute java Thanks for any help. -dain --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNuke dev
Bill, This reminds me of an I deal I has last night (couldn't sleep). I was thinking of the script based MBean support Sacha added, and I thought can we make plain old java work like a scripting language. Here is what I came up with: + The user writes a class BlahService.java + This source file is places in our deployment directory + We run Xdoclet on it to generate the MBean deployment descriptor + We compile the java file + Deploy Java as a scripting language. What do you think? -dain On Tuesday, January 14, 2003, at 12:50 PM, Bill Burke wrote: The only negative comment I have in using JMX is that the PHP community may have a tough time switching over to Nukes on JBoss if you have to have a package structure like a SAR or a WAR. I hate to say it, but does it need to be dumbed-down for the PHP community? This type of community needs to be able to edit a JSP and immediately see the change on the webserver. Is it possible to be all JSP based for themes, modules and blocks? You could use a URL fragement and JSP:Include to decide what theme to use. Just a thought. Maybe JMX and such is the way to go. Just want to give you something to think about. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of julien viet Sent: Tuesday, January 14, 2003 11:31 AM To: SourceForge.net Subject: [JBoss-dev] JNuke dev hi folks, JNuke adventure has started. After analysis of PostNuke I've began the development, still early though. I keep everything that's good in PostNuke and throw all the shit away : modules, blocks, permissions system, url system and themes. JMX is used for PostNuke components : themes, modules and blocks are all JMX mbeans. Here are my reasons : A : general 1.we need a component structure, why not JMX ? after all another forum say that's lightweight. 2.theses components do not have to scale, i.e the number of modules, blocks and themes is very small. B : for modules 1.Ability to deploy/undeploy when application is running. 2.It's easy to deploy additional modules as a separate deployment and have them register in the same registry. 3.PostNuke is all about invoking module functions. Url like index.php?module=Userop=register means that the PN must call the method register on module User. For me that means that the servlet retrieves the mbean under the name jnuke:publicmodules:name=User and invokes the operation register(). 4.When a module is installed and configured it plug block mbeans in the JMX. C : for blocks, same reasons as above except 3 and 4 as invocation is typed for 3. D : for themes, same reasons as above except 3 and 4 as invocation is typed for 3. EJB are used for the model : UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will be CMP 2.0 beans. We'll use local invocations and same trick as in forum to make them faster. Plus more beans. Each module is made of : 1.ModuleMBean : is the module itself, does not provide fucntionnalities, it's used to manager the PublicModule. Main operations are lifecycle (initialize, activate, unactivate, uninitialize) 2.PublicModuleMBean : is created when ModuleMBean activates and is responsible for serving requests. The MBean is dynamic and operations with no arguments and no returns are served. It's up to the module to do as he wants : if he wants MVC it can, it it wants to mix HTML and code, it can. First modules won't be MVC as they simply don't need. It's up to the model to have the persistence mecanisms it wants. First modules will use EJB. With lifecycle operations, each module can install itself, for instance : a ModuleMBean is plugged : 1.module configuration, setup of variables 2.initialize : module can creates table, deploy EJB, plugs block. 3.activate : module then go to block admin and creates instances of blocks (if module use blocks), display them on the page. Each block is made of : 1.BlockMBean : manages BlockInstanceMBean. 2.BlockInstanceMBean : is a block instance, it contains a title and a position on web page + 3 operations : display(), edit(), update(). display() : displays the block instance edit() : used to edit the block in block administration update() : used to upate the block in block admin Each them is made of various callbacks that displays HTML on the page. It has to provide location of files like css, gifs, etc... THe first them I did is made of a servlet that register to JMX and the doGet operation serves the files. It's default theme. To make the thing simpler, it will be possible to make theme with JSP because I want to keep post nuke spirit. Ideally, even Module and Blocks could be made as JSP of things like that, that keeps PHP easy to do spirit. I did not thought a lot about permissions. In PostNuke, each module is responsible for checking security. I know that could be done with AOP but I don't
Re: [JBoss-dev] JNuke dev
I think you are dreaming, if you think you will every recruit php developers to any java based solution. Ben, remember the Orielly OS convention? The php guys are perl guys. -dain On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: Are we developing this for the PHP community or the Java community? Or more important for the JBoss community? To me it seems that it would depend on who you are targeting for your user base. If you want to target the PHP users to bring them to JBoss, then Bill could be right. If we do not care about the PHP community, we go down the JMX way. I think the PHP community will never want to do anything with JSP. They believe they have what they need to be successful and will continue to innovate in their own circle. For most of the PHP community, what they have built is scalable to their needs. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Bill Burke Sent: Tuesday, January 14, 2003 1:51 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev The only negative comment I have in using JMX is that the PHP community may have a tough time switching over to Nukes on JBoss if you have to have a package structure like a SAR or a WAR. I hate to say it, but does it need to be dumbed-down for the PHP community? This type of community needs to be able to edit a JSP and immediately see the change on the webserver. Is it possible to be all JSP based for themes, modules and blocks? You could use a URL fragement and JSP:Include to decide what theme to use. Just a thought. Maybe JMX and such is the way to go. Just want to give you something to think about. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of julien viet Sent: Tuesday, January 14, 2003 11:31 AM To: SourceForge.net Subject: [JBoss-dev] JNuke dev hi folks, JNuke adventure has started. After analysis of PostNuke I've began the development, still early though. I keep everything that's good in PostNuke and throw all the shit away : modules, blocks, permissions system, url system and themes. JMX is used for PostNuke components : themes, modules and blocks are all JMX mbeans. Here are my reasons : A : general 1.we need a component structure, why not JMX ? after all another forum say that's lightweight. 2.theses components do not have to scale, i.e the number of modules, blocks and themes is very small. B : for modules 1.Ability to deploy/undeploy when application is running. 2.It's easy to deploy additional modules as a separate deployment and have them register in the same registry. 3.PostNuke is all about invoking module functions. Url like index.php?module=Userop=register means that the PN must call the method register on module User. For me that means that the servlet retrieves the mbean under the name jnuke:publicmodules:name=User and invokes the operation register(). 4.When a module is installed and configured it plug block mbeans in the JMX. C : for blocks, same reasons as above except 3 and 4 as invocation is typed for 3. D : for themes, same reasons as above except 3 and 4 as invocation is typed for 3. EJB are used for the model : UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will be CMP 2.0 beans. We'll use local invocations and same trick as in forum to make them faster. Plus more beans. Each module is made of : 1.ModuleMBean : is the module itself, does not provide fucntionnalities, it's used to manager the PublicModule. Main operations are lifecycle (initialize, activate, unactivate, uninitialize) 2.PublicModuleMBean : is created when ModuleMBean activates and is responsible for serving requests. The MBean is dynamic and operations with no arguments and no returns are served. It's up to the module to do as he wants : if he wants MVC it can, it it wants to mix HTML and code, it can. First modules won't be MVC as they simply don't need. It's up to the model to have the persistence mecanisms it wants. First modules will use EJB. With lifecycle operations, each module can install itself, for instance : a ModuleMBean is plugged : 1.module configuration, setup of variables 2.initialize : module can creates table, deploy EJB, plugs block. 3.activate : module then go to block admin and creates instances of blocks (if module use blocks), display them on the page. Each block is made of : 1.BlockMBean : manages BlockInstanceMBean. 2.BlockInstanceMBean : is a block instance, it contains a title and a position on web page + 3 operations : display(), edit(), update(). display() : displays the block instance edit() : used to edit the block in block administration update() : used to upate the block in block admin Each them is made of various callbacks that displays HTML on the page. It has to provide location of files like css, gifs, etc...
Re: [JBoss-dev] JNuke dev
Who is doing the XDoclet integration? I think it would be a good project for that person. -dain On Tuesday, January 14, 2003, at 02:27 PM, Bill Burke wrote: What I should have said is content developers. Sorry for the snub, but they do requiring a dumbing down of software. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Tuesday, January 14, 2003 2:19 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JNuke dev I think you are dreaming, if you think you will every recruit php developers to any java based solution. Ben, remember the Orielly OS convention? The php guys are perl guys. -dain On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: Are we developing this for the PHP community or the Java community? Or more important for the JBoss community? To me it seems that it would depend on who you are targeting for your user base. If you want to target the PHP users to bring them to JBoss, then Bill could be right. If we do not care about the PHP community, we go down the JMX way. I think the PHP community will never want to do anything with JSP. They believe they have what they need to be successful and will continue to innovate in their own circle. For most of the PHP community, what they have built is scalable to their needs. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Bill Burke Sent: Tuesday, January 14, 2003 1:51 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev The only negative comment I have in using JMX is that the PHP community may have a tough time switching over to Nukes on JBoss if you have to have a package structure like a SAR or a WAR. I hate to say it, but does it need to be dumbed-down for the PHP community? This type of community needs to be able to edit a JSP and immediately see the change on the webserver. Is it possible to be all JSP based for themes, modules and blocks? You could use a URL fragement and JSP:Include to decide what theme to use. Just a thought. Maybe JMX and such is the way to go. Just want to give you something to think about. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of julien viet Sent: Tuesday, January 14, 2003 11:31 AM To: SourceForge.net Subject: [JBoss-dev] JNuke dev hi folks, JNuke adventure has started. After analysis of PostNuke I've began the development, still early though. I keep everything that's good in PostNuke and throw all the shit away : modules, blocks, permissions system, url system and themes. JMX is used for PostNuke components : themes, modules and blocks are all JMX mbeans. Here are my reasons : A : general 1.we need a component structure, why not JMX ? after all another forum say that's lightweight. 2.theses components do not have to scale, i.e the number of modules, blocks and themes is very small. B : for modules 1.Ability to deploy/undeploy when application is running. 2.It's easy to deploy additional modules as a separate deployment and have them register in the same registry. 3.PostNuke is all about invoking module functions. Url like index.php?module=Userop=register means that the PN must call the method register on module User. For me that means that the servlet retrieves the mbean under the name jnuke:publicmodules:name=User and invokes the operation register(). 4.When a module is installed and configured it plug block mbeans in the JMX. C : for blocks, same reasons as above except 3 and 4 as invocation is typed for 3. D : for themes, same reasons as above except 3 and 4 as invocation is typed for 3. EJB are used for the model : UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will be CMP 2.0 beans. We'll use local invocations and same trick as in forum to make them faster. Plus more beans. Each module is made of : 1.ModuleMBean : is the module itself, does not provide fucntionnalities, it's used to manager the PublicModule. Main operations are lifecycle (initialize, activate, unactivate, uninitialize) 2.PublicModuleMBean : is created when ModuleMBean activates and is responsible for serving requests. The MBean is dynamic and operations with no arguments and no returns are served. It's up to the module to do as he wants : if he wants MVC it can, it it wants to mix HTML and code, it can. First modules won't be MVC as they simply don't need. It's up to the model to have the persistence mecanisms it wants. First modules will use EJB. With lifecycle operations, each module can install itself, for instance : a ModuleMBean is plugged : 1.module configuration, setup of variables 2.initialize : module can creates table, deploy EJB, plugs block. 3.activate : module then go to block admin and creates instances of blocks (if module use blocks), display them on the page. Each
Re: [JBoss-dev] Anyone able to access cvs?
I can. bash-2.05a$ cvs -n update [EMAIL PROTECTED]'s password: cvs server: Updating . cvs server: Updating bridge M bridge/EntityBridgeInvocationHandler.java cvs server: Updating ejbql cvs server: Updating jdbc U jdbc/JDBCCommandFactory.java U jdbc/JDBCCreateEntityCommand.java U jdbc/JDBCEJBQLCompiler.java On Tuesday, January 14, 2003, at 04:47 PM, Scott M Stark wrote: CVS is still acting up on me. After clearing two more locks I now cannot even get an update. Is it just my route or is this seen by everyone jboss-3.2 38date -u Tue Jan 14 22:42:56 2003 jboss-3.2 39ping cvs.jboss.sourceforge.net Pinging cvs.sourceforge.net [66.35.250.207] with 32 bytes of data: Reply from 66.35.250.207: bytes=32 time=31ms TTL=49 Request timed out. Request timed out. Reply from 66.35.250.207: bytes=32 time=31ms TTL=49 Ping statistics for 66.35.250.207: Packets: Sent = 4, Received = 2, Lost = 2 (50% loss), Approximate round trip times in milli-seconds: Minimum = 31ms, Maximum = 31ms, Average = 15ms jboss-3.2 40 Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean persistence?
So Matt are you interested in working on the XML persistence? -dain On Monday, January 13, 2003, at 08:32 AM, Matt Munz wrote: Dain, What is going on with MBean persistence? Not much, as far as I can tell. Can we do this today? Yes, but only by persisting to ObjectOutputStream files. XML / JDBC persistence engines have yet to be written. If not is anyone working on it? I origionally wrote the code that I did to scratch an itch. As far as I know, nobody else is using it... When do you expect to have it finished? I reccommend not going to production with ObjectOutputStream persistence as it is fragile. By reusing the code from the ServiceCreator (unmarshalling) and the JMX Console (marshalling), the XML persistence engine should be fairly simple to write. - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Sat 1/11/2003 1:42 PM To: [EMAIL PROTECTED] Cc: Subject: [JBoss-dev] MBean persistence? What is going on with MBean persistence? I have been at lot of sites lately that are going into production with JBoss and the one thing admins always ask for is the ability to have changes to the beans in the JMX console to be written back out the the XML files. They don't care if the formatting changes or if comments are lost, they just want to be able to change and option and have it preserved when the server reboots. I love the practicality of system administrators. Can we do this today? If not is anyone working on it? When do you expect to have it finished? I think this fairly simple feature will make 80% of the admins happy. -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean persistence?
Yes basically. Here is what I have in mind: as each attribute is loaded from the source xml the location from where it was loaded is remembered. When an attribute is changed that was loaded from the xml, the persistence manager overwrites the existing XML. I don't think you have to explode the jar, but I do think you basically have to rewrite the entire file. I think the trick will be to convince the auto deployer to not redeploy the modified file (if you can't figure that out it is ok... I get David J to get it to work :-) Does this sound do-able? -dain On Monday, January 13, 2003, at 09:54 AM, Bill Burke wrote: Matt, I think we want seemless integration here. If the MBean is packaged within a SAR, the SAR should be exploded, the XML file modified and the SAR re-jared. Same goes with straight XML files or SARS embedded within SARs (russian doll). I'm in the process of creating task lists at SourceForge for each project. I can assign you this task? Thanks for your effort, Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: Matt Munz [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Monday, January 13, 2003 10:48 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] MBean persistence? Dain, So Matt are you interested in working on the XML persistence? Yeah, I suppose I could put some more time into it. It sounds like you know a few people that might actually be users of this feature. Do you have a use case in mind? - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 10:07 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? So Matt are you interested in working on the XML persistence? -dain On Monday, January 13, 2003, at 08:32 AM, Matt Munz wrote: Dain, What is going on with MBean persistence? Not much, as far as I can tell. Can we do this today? Yes, but only by persisting to ObjectOutputStream files. XML / JDBC persistence engines have yet to be written. If not is anyone working on it? I origionally wrote the code that I did to scratch an itch. As far as I know, nobody else is using it... When do you expect to have it finished? I reccommend not going to production with ObjectOutputStream persistence as it is fragile. By reusing the code from the ServiceCreator (unmarshalling) and the JMX Console (marshalling), the XML persistence engine should be fairly simple to write. - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Sat 1/11/2003 1:42 PM To: [EMAIL PROTECTED] Cc: Subject: [JBoss-dev] MBean persistence? What is going on with MBean persistence? I have been at lot of sites lately that are going into production with JBoss and the one thing admins always ask for is the ability to have changes to the beans in the JMX console to be written back out the the XML files. They don't care if the formatting changes or if comments are lost, they just want to be able to change and option and have it preserved when the server reboots. I love the practicality of system administrators. Can we do this today? If not is anyone working on it? When do you expect to have it finished? I think this fairly simple feature will make 80% of the admins happy. -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean persistence?
always delete the Persistence Store. When the server restarts, it returns to a clean-slate (deploy-time) state. If, as you seem to be suggesting, the (inconsistent) state has been stored in the deployment descriptors themselves, however, this clean-slate is not possible. One must go through each descriptor until the erroneous state information is found. Then it must be manually corrected. Since the MBean persistence engine will be writing to these files automatically, it may not be apparent how to do this. Could you explain further the behaviour you would like to see in MBean Persistence? - Matt -Original Message- From: [EMAIL PROTECTED] on behalf of Bill Burke Sent: Mon 1/13/2003 10:54 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] MBean persistence? Matt, I think we want seemless integration here. If the MBean is packaged within a SAR, the SAR should be exploded, the XML file modified and the SAR re-jared. Same goes with straight XML files or SARS embedded within SARs (russian doll). I'm in the process of creating task lists at SourceForge for each project. I can assign you this task? Thanks for your effort, Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: Matt Munz [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Monday, January 13, 2003 10:48 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] MBean persistence? Dain, So Matt are you interested in working on the XML persistence? Yeah, I suppose I could put some more time into it. It sounds like you know a few people that might actually be users of this feature. Do you have a use case in mind? - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 10:07 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? So Matt are you interested in working on the XML persistence? -dain On Monday, January 13, 2003, at 08:32 AM, Matt Munz wrote: Dain, What is going on with MBean persistence? Not much, as far as I can tell. Can we do this today? Yes, but only by persisting to ObjectOutputStream files. XML / JDBC persistence engines have yet to be written. If not is anyone working on it? I origionally wrote the code that I did to scratch an itch. As far as I know, nobody else is using it... When do you expect to have it finished? I reccommend not going to production with ObjectOutputStream persistence as it is fragile. By reusing the code from the ServiceCreator (unmarshalling) and the JMX Console (marshalling), the XML persistence engine should be fairly simple to write. - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Sat 1/11/2003 1:42 PM To: [EMAIL PROTECTED] Cc: Subject: [JBoss-dev] MBean persistence? What is going on with MBean persistence? I have been at lot of sites lately that are going into production with JBoss and the one thing admins always ask for is the ability to have changes to the beans in the JMX console to be written back out the the XML files. They don't care if the formatting changes or if comments are lost, they just want to be able to change and option and have it preserved when the server reboots. I love the practicality of system administrators. Can we do this today? If not is anyone working on it? When do you expect to have it finished? I think this fairly simple feature will make 80% of the admins happy. -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat --- This SF.NET email is sponsored by: FREE
Re: [JBoss-dev] MBean persistence?
On Monday, January 13, 2003, at 11:26 AM, Matt Munz wrote: Dain, Please see my recent email in response to Bill. Yes. I think sf is creating a big lag between our emails. I origionally started with this approach, but the more I thought about it, the more untenable it seemed. Based on my experience so far, I just don't want the server mucking with my deployment descriptors. I understand, but the admins do want this. As a developers, I won't be turing this feature on. As an admin, I most likely will. I'm sure I can figure out the autodeployer ;) But look what you're saying. Implement Persistence, modify deployer. Do you see how the two concerns are being tightly bound by this approach? Yes. If you modify a descriptor the auto deployer will have to be modified to not redeploy the file. Right? Am I missing something? We don't need AOP to solve this one ;) -- just locate the persistence in a separate place (this is what it wants to do anyway, IMO -- consider standalone applications. I've never seen an application open up its jars and stuff info into them. They always use a separate DB). I agree AOP is not required. I also I think we need this in 3.x. BTW, I want to relocate this discussion to the Forums, as Bill suggests, but which one? I see at least 3 JMX-related forums! Sure but you will most likely loose my comments. The server is s slow that I quickly loose interest in posting. Hopefully the new hardware will fix this problem. -dian --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean persistence?
I love you sacha! I can't seem to find the screen shot. I'll see if I can get this working on my apple. -dain On Monday, January 13, 2003, at 11:39 AM, Sacha Labourey wrote: Simpler console for common tasks The administrator the power of the JMX console, and think it is cool they can change the behavior of the entire system. On the other hand they are overwhelmed by the options. Most would like a very simple static interface that does 80% of the common tasks and the option to fire-up the full console for hard core hacking sessions. Basically they would like a static interface similar to the one supplied by Weblogic and JRun. (I have some ideas here if anyone is interested in working on this.) FYI I've commited such a framework and a basic implementation in HEAD two weeks ago: http://www.jboss.org/ modules.php?op=modloadname=phpBB_14file=indexaction= viewtopictopic=267852 There's even a screen snapshot --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean persistence?
Jeremy, Specific comments are inline... On Monday, January 13, 2003, at 11:33 AM, Jeremy Boynes wrote: Like Matt, I have concerns about modifying the files in the deployment as well. I think his concerns about division of roles are valid - I'd go further and say this needs to be able to handle a split between 'deployer' and 'operator/sys admin' as well (where e.g. deployer defines which database to use, the sys admin defines the connection pool size). Every place has a different distinction between what a developer and an admin does. At some places the developers defines the entire db pool, at some the developer really only specifiec the pool name, and there are places in between the two. I am not making the claim that this is the solution for everyone, especially developers. I am saying that the average admin wants this feature. There are also circumstances where the SAR will be unmodifyable - e.g. if it is set read-only on the OS or if it is loaded from an http: URL. If a attribute is not persistable, then we don't persist it. We should modify the jmx-console to notify the user if an attribute is persistent or not. One possibility might be to store the local changes as a transform applied against the original file e.g. an XSLT. There are very few developers that understand XSLT, I would guess even less admins. This also has the advantage that local changes don't get lost when a new version is received from development. Also the same file can be rolled dev-test-stage-prod without needing to modify the deployment descriptor each time (one of the biggest compaints I've had from sys admins). The admins I spoke with were willing to accept this. It is a common problem. When I give them the option of looking in multiple places, or looking in some database, or dealing with lost config options across upgades, they all chose the last. I personally would have gone for the second option, but I'm not an admin. -dain --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean persistence?
On Monday, January 13, 2003, at 01:26 PM, Matt Munz wrote: Dain, First off, thank you for providing much-needed field data for this work. Your comments on Persistence in general are identical to my reasons for working on MBean Persistence in the first place. When I suggest that we could write out a new different xml file that has the configuration changes, they all hated it. They want to be able to goto one file and know what is going on. Why do they want this specifically? It is important to take customer concerns and turn them into needs. Consider cooking at a restaurant. If the customer orders chocolate cake and you don't have it, do you bake a cake just because they want it? Perhaps we can give the sys admins chocolat pots de creme instead? They might even like it better... Good point. To extend you analogy, if the customer wants a hamburger you don't give them cordon bleu, just because you think they will like it better (which they would :). The admins I spoke with were willing to accept this. It is a common problem. When I give them the option of looking in multiple places, or looking in some database, or dealing with lost config options across upgades, they all chose the last. I personally would have gone for the second option, but I'm not an admin. I don't see the options this way. Losing stored MBean state across upgrades may end up being an application-specific detail at best. If the MBeans change, then the stored MBean state will likely be out of synch, regardless of where that state is stored. I don't see this as related to the issue of whether or not the mbean state store and the deployment descriptor should be merged. Ok. How do you see the options? The point about the upgrade problem not being related to the MBean persistence method, I would state as *not necessarily related*. Certain persistence schemes will necessarily create an upgrade problem and some can mitigate it. They want to be able to goto one file and know what is going on. Could you elaborate on this? Why would they be looking at files at all? I think we are running into a bit of a jam here, conceptually. They say they want to use the console to make persistent changes. Do they also want to use the filesystem to make changes? Two interfaces for the same device -- are they requesting any others? Why would they hack config files if they have the handy dandy console? ;) Yes. They want it both ways. Some admins hate consoles, and some hate config files. A lot of times you have two admins, one that can't handle file configs and one that can't stand GUIs (even web GUIs). Anyway having a single config file has a big advantage, portability. You can check it into CVS, you can copy it to another machine. You can configure it with the GUI undeploy the admin screen (security and all) and still be able to config the system with vi. I can think of many possible answers to these questions, but how would the sys admins answer them? Please stick with me on this one. I think that if we can develop a solid use case for these things, we can get to some of the core issues, and perhaps you'll understand my rationale. The use case that you gave before is completely solved by my approach, BTW. Perhaps answering the questions above will help generate a use case that shows why two files is worse than one... I understand your point, and I suggest you go talk with some full time admins, or better watch them work for a day. It will be an eye opener. One file is a huge benefit to admins. There is nothing worse then picking through the config files, changing something and it has no effect. Then 8 hours to 1 week later you discover that the file is ignored if there is an override somewhere else in the system. Hey, I'm not an admin, and when a whole bunch of them at different companies tell me they want it a very specific way, I say lets do it. The solution the propose is very simple from a user perspective, as they get it both ways. I don't expect this to be the only solution or the default solution, but it should be an option. I just want to make the admins happy. -dain --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] My fuck up
I wouldn't go that far. The php guys could have written something that has the same performance as our J2EE implementation, but they didn't. It isn't a language, spec or platform issue, it is pure issue if implementation. -dain On Monday, January 13, 2003, at 06:28 PM, Bill Burke wrote: Just validates that J2EE is the way to go and scales and this kiddy(your words Marc) PHP crap although looks sexy, just doesn't scale. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of James Higginbotham Sent: Monday, January 13, 2003 6:20 PM To: [EMAIL PROTECTED] Cc: JBoss Group Subject: RE: [JBoss-dev] My fuck up You guys thought of doing: wget --recursive http://www.jboss.org, publish the static files every 15 min, and only use the PHP for processing submission forms? Just a thought to quickly reduce your PHP dependence except for new forum posts.. Dunno if you would have to pipe each file to a sed script or something for some fine tuning, but that may be faster than waiting for Jnuke to be completed, functionally tested, and load tested.. Or, I guess you could rollback the old website and update the links to reflect 3.0.5, right? James -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 4:54 PM To: Jboss-Development@Lists. Sourceforge. Net Cc: 'JBoss Group' Subject: [JBoss-dev] My fuck up I got nuked by postnuke. The stuff just doesn't scale. Either that or we are doing something really wrong. In any case the site is UN-USABLE. We will continue with our port of postnuke and see if we can come with a real forums/nukes on jboss project. My bad. I make mistakes, I should have tested this under heavier load, PHP plain doesn't work as is. We will get the website back to its former state. Bear with us. A humbler, marcf xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi- bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean persistence?
I'm not sure if you agree with my proposal or not. Do you think we should add the feature to persist the changes back out to the deployment descriptors? -dain On Monday, January 13, 2003, at 04:07 PM, Scott M Stark wrote: This should not be a black and white option. We need a logical seperation from configuration from the deployment at the JBoss core layer. If someone wants to persist configuration with the deployment, including runtime mods let them. If someone wants to access webdav, jdbc, jndi, etc. for the configuration, let them. Quit being purists and address the administration problem. This does need to be in 3.2. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 13, 2003 11:59 AM Subject: Re: [JBoss-dev] MBean persistence? ... --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Does JRockit work yet?
Does JBoss run on JRockit yet? I mean run for a long while without crashing? I remember posts on it being broken. -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Good-bye II
Andy, I agree with the meta point that it would be better to have a publicly defined structure for how the JBoss project is managed, but I think you are the wrong advocate for this issue. I actually think you make it less likely that such a thing will ever occur. Andy, if you want to be honest with everyone, why don't you start by answering the following questions? Do you work for a commercial J2EE tools vendor (it is your choice to tell everyone who you work specifically for)? Does your company want you to work on JBoss? Do you own your own work anymore? I think everyone will agree that the legal issues alone are enough to remove rw from someone. If you get your legal issues cleared up, I think they may reconsider, but as you have already stepped outside of the legal boundaries laid down by your employer, I personally would not risk give you rw again. The good think for you is I don't make those decisions. -dain On Monday, December 23, 2002, at 11:19 AM, Andy wrote: Hi Oohh, the power of legal issues, you can justify nearly everything. Instead of looking for a mutual compromise to resolve this issue Marc (and others) sought a more terminal solution. Andy - Original Message - From: marc fleury [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: 'JBoss Group' [EMAIL PROTECTED] Sent: Monday, December 23, 2002 7:49 AM Subject: jRE: [JBoss-dev] Good-bye II Andy is working on a competing implementation to jboss. His own lawyers at his company have requested he not work on JBoss, he was doing so anyway under an alias. We only found out about the competing aspect a couple of days ago. To protect ourselves legally, we removed Andy's RW, we will in fact remove the code contributions. We cannot have a competitor's code in our base as it exposes us legally. It is only the second time this has happened in our history. The mail below is an expression of Andy's personal gripes and bitterness. Period. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Michael Bartmann Sent: Monday, December 23, 2002 9:09 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Good-bye II None of the JBG supporters has written everything by himself. This is of course a matter of control and organization, which you do very well as master of the tree. I wont let everybody do everything, but if somebody wants to contribute in the right direction he should not be blocked. OTOH if somebody would insist to commit something you dont want to go in and he refuses to restrain himself this is another question. In the end you'll have to protect jbg (and jboss) from sabotage. I cannot judge about what happend in Andy's case; most of the discussion fortunately seems to have happened in private mail. I just want to get rid of the doubt that something went wrong due to political reasons. Otherwise contributors might come to the conclusion that they support jbg, not the jboss community. So I simply wanted to provoke some clarifications; a little bit of meta-discussion might be ok on this list and of interest for other contributors, too. Regards, Michael Bartmann PS.: The forum would be ok for me, simply tell me where to go... Scott M Stark wrote: Development and support are not separable. Do you let anyone modify code you support? This discussion needs to move the forums. Marc will take it up tomorrow. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Michael Bartmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 23, 2002 1:54 AM Subject: Re: [JBoss-dev] Good-bye II - Andy: please keep cool and stay online (I like EJB timers :-) - Marc: consider developing and consulting as two different jboss ASPECTS. Again, I fear I misjudge because of lacking knowledge, but I couldn't resist to comment on this. I really don't like the idea of non-technical clash on jboss-developement. Regards, Michael Bartmann --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Copyright of personal work (Was:RE: [JBoss-dev] Good-bye II)
Rhett, It all depends on your specific case. When it comes to this type of law, there are no hard and fast rules (every contract and country/state is different). You need to talk to a lawyer. -dain On Monday, December 23, 2002, at 01:31 PM, Rhett Aultman wrote: I know that I am not a lawyer and have only a semester of law to my name, but is there any real case law related to this matter? I could see where your employer could make claims against your private work if you were working on an open source project that was the spitting image of some proprietary work you were engaged in with said employer, but I would think that the claim would not be on the copyright of your own work but instead on divulging secrets or merely representing a conflict of interest. If what you're saying is true...that anything I do in my spare time can become the copyright of my employer, then I need to seriously rethink my budding writing career, since the articles and books I am writing on my home computer could fall in a legal gray area. I honestly don't think that's the case, which leads me to suspect that your employer cannot just unilaterally annex work you do in your spare time unless they can cite a conflict of interests or some sort of other direct threat to their interests (such as stealing a trade secret). Really...does anyone know a little of the case law here? -Original Message- From: Dave Neuer [mailto:[EMAIL PROTECTED]] Sent: Monday, December 23, 2002 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Good-bye II --- Dain Sundstrom [EMAIL PROTECTED] wrote: Andy, Do you own your own work anymore? This is actually a key issue that everyone working on this type of projejct should really be aware of. If you are a permanent employee of a company in the USofA which produces copyrightable material (such as software) --unless you have a contract to the contrary -- that company owns the copyright to the work you do. Not just the work you do on company time equipment, but often even the work you do from home on your spare time. IANAL, and my understanding is that the degree to which the latter is the case MAY depend on how similar the work you've done on your own time equipment is to the work you get paid to do, but since that's up to a judge's discretion -- and case law, I guess -- it would be insane for someone running an Open Source project to knowingly allow questionable code into their base as, LGPL, GPL or Bob's License, license issues don't help you if some other entity can claim to own the copyright. This is why the FSF asks people to formally assign the copyright to free software under the GNU project to them. If Andy really does work for a company, as a regular employee, who produces software similar to JBoss, removing his code is the right thing to do even if it's technically superior to every other bit of code in the codebase and he's the sweetest human being that ever lived, to protect the right of all of the rest of us to use this awesome software. Dave Neuer __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Sar deployed before Jar?
Maybe I'm on crack, but why does it look like a sar file deployed before jar? Is this desired for some reason? Since a jar has no deployment time executable code isn't is safe to always deploy the jar first? -dain --- This SF.NET email is sponsored by: Geek Gift Procrastinating? Get the perfect geek gift now! Before the Holidays pass you by. T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Sar deployed before Jar?
I'm dumb. I have been work with SARs to much today, and I forgot that jars are also used for ejb-jars. Does the deployer only look at the name for distinction of the files? What I mean is can the main deployer, determine which files it needs to deploy, classify them into plain old jar, sar, ejb-jar, etc and then deploy the plain old jars first? I'm guessing the answer is yes, write your own sorter. -dain On Thursday, December 19, 2002, at 04:54 PM, David Jencks wrote: This is from the ordering done in or near the main deployer, right? I think the idea is to deploy ejb-jars after .sars. It probably doesn't make much difference any more since you can make an ejb (container) depend on an mbean and vice versa. Is it causing problems? david jencks On 2002.12.19 17:25:43 -0500 Dain Sundstrom wrote: Maybe I'm on crack, but why does it look like a sar file deployed before jar? Is this desired for some reason? Since a jar has no deployment time executable code isn't is safe to always deploy the jar first? -dain --- This SF.NET email is sponsored by: Geek Gift Procrastinating? Get the perfect geek gift now! Before the Holidays pass you by. T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Geek Gift Procrastinating? Get the perfect geek gift now! Before the Holidays pass you by. T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Geek Gift Procrastinating? Get the perfect geek gift now! Before the Holidays pass you by. T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossME
I personally only want one build for the powerful handhelds. If anyone wants to make the other ones, that would be cool. -dain On Thursday, December 12, 2002, at 08:53 AM, Peter Fagerlund wrote: torsdagen den 12 december 2002 kl 00.41 skrev Holger Baxmann: btw: who is talking about jboss-client? All I am saying is that there will be many different devices with different VM's out there soon ... and for us to have a compatible jboss-client build for each and every one of them is a massive task (regression testing hardware/software versions of 30+ devices), better left to those who would profit directly from it. Maybe We could try have jb-mini-client, jb-midi-client, jb-maxi-client but my fear is this will only confuse and swamp the helpdesk :-) ... Then again JBossME maybe should be a for-pay-add-on ? to me JBoss used as MOM for business systems and small device clients can be made today - transaction and security with multiplexed tcp and WebDAV at the clientside is premature as there are no devices in numbers out there yet ... consider using the serverside for those services today is IMHO sufficient. /peter_f --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossME
On Thursday, December 12, 2002, at 12:02 PM, Holger Baxmann wrote: btw: what means 'powerfull'? i have a fpga device here (call it sbc) which is able to generate a throughput of 1..2.8 Gbits/sec with rijndael block cipher. is this powerfull? I would define a powerful PDA as any PDA with enough power to run the current version of WindowCE (handheld version). What I mean are the IPaq and Zauras, both of which are currently 200 MHz 64 Meg on the low end currently and the new versions are 400 MHz 256 machines. Now that is powerful. I personally only care about general CPU speed, not the ASIC parts, and the raw memory available to thee vm. If anyone wants to make the other ones, that would be cool. yes it would ;-) yes, i would =8- It looks like Bill is going to add this to the project list. -dain --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossME
On Thursday, December 12, 2002, at 01:33 PM, Holger Baxmann wrote: I would define a powerful PDA as any PDA with enough power to run the current version of WindowCE (handheld version). What I mean are the IPaq and Zauras, both of which are currently 200 MHz 64 Meg on the low end currently and the new versions are 400 MHz 256 machines. Now that is powerful. I personally only care about general CPU speed, not the ASIC parts, and the raw memory available to thee vm. uu, here we catch a rabbit hunter ! you are mentioning window ce: you are mentioning an operating system. you are bringing this in conjunction with power. lol. rotfl. i do not understand, because i understand. enough power means - enough power for the specific purpose at a specific time. these both constraints leads us to dynamic configurable because we do not know what to do nor when to do - not to the multi-purpose [and this way: no purpose at all] pc like operating systems. they are simply useless. Read my post again. I said enough power to run WindowsCE, which is a pig, so any box that can do what is powerful in my mind. we use them, because there exist nothing else - before jboss.org what i mean is: _no_ operating system, _no_ filesystem. simply jboss.org. jbossME. for all i care. Absolutely, but that is not my personal interest. I think that would be a great project and would be fun to work on. -dain --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: AW: [JBoss-dev] jboss on j2me?
On Wednesday, December 11, 2002, at 06:24 AM, Stefan Groschupf wrote: Hope it will... cause i will use it like that in a project :) So we can try it together.. ;-) May be some more people will take the same trip. I have. I got the JBoss MBean kernel to boot with the Sun CVM, but I couldn't get anything else to run. The CVM was very buggy at the time, and I have been waiting for a binary release from Sun, which is supposed to happen this week. My goal is to target the high end handhelds, but thoes are getting so powerful (400 MHz 256MB) that I don't know if we need a 'micro' vm. -dain --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jboss j2me jmx?!
It already runs on the Sun CVM. I have personly tried it. -dain On Wednesday, December 11, 2002, at 09:41 AM, Stefan Groschupf wrote: Hi guys, Christoph Ebro told me in the jmx forum mailing list that sun has a CLDC j2me prototype of jmx. Would that be interesting for other here to port the jboss jmx to j2me? I cant do this, since I'm to poor in knowledge about that. But I see the need since then jboss can run on mobile and embedded devices. So far I know 2 guys wants run jboss on embedded devices. Lennart and I hear from Holger Baxmann that he work in a releated area. bye Stefan --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: AW: [JBoss-dev] jboss on j2me?
When the binary comes out later this week (or next) I would like to have a build for it. -dain On Wednesday, December 11, 2002, at 10:13 AM, Holger Baxmann wrote: my work is more targeted to the small 1..16mbyte devices, like ajile, ds80400 and ez80. should be possible to port the cvm to this ones. bax Von: Dain Sundstrom [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Wed, 11 Dec 2002 09:33:20 -0600 An: [EMAIL PROTECTED] Betreff: Re: AW: [JBoss-dev] jboss on j2me? On Wednesday, December 11, 2002, at 06:24 AM, Stefan Groschupf wrote: Hope it will... cause i will use it like that in a project :) So we can try it together.. ;-) May be some more people will take the same trip. I have. I got the JBoss MBean kernel to boot with the Sun CVM, but I couldn't get anything else to run. The CVM was very buggy at the time, and I have been waiting for a binary release from Sun, which is supposed to happen this week. My goal is to target the high end handhelds, but thoes are getting so powerful (400 MHz 256MB) that I don't know if we need a 'micro' vm. -dain --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
