RE: [JBoss-dev] New JBoss Monitoring services
Well done Bill, this is good stuff:) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Friday, December 12, 2003 4:24 PM To: Jboss-Dev; JBoss 2; [EMAIL PROTECTED] Subject: [JBoss-dev] New JBoss Monitoring services This will be released in JBoss 3.2.4, but it is now available in 3.2 branch: cvs checkout -r Branch_3_2 jboss-3.2 I've also attached some screen shots JBoss Monitoring In JBoss 3.2.4, we've implemented some new JMX MBean monitoring and a nice GUI around this infrastructure as well as a way to plug in how alerts are processed. Why didn't we use the JMX Gauge and String monitors that come implemented with the JMX spec? 3 reasons: 1. They are not integrated with our Service architecture 2. They have no way of determining which monitors have sent an alert and are currently disabled because an alert was reached 3. They have no way of reseting an alert So, what infrastructure have we built? First let's look at configuring a JMX MBean monitor through the plain old -service.xml interface that you would to create any MBean. All Monitors are MBeans that start a thread to watch the values of another MBean's attribute. When a monitoring threshold is reached, the MOnitor will send out an MBean Notification to a set of registered listeners. Currently in JBoss, the are two types of listeners, a dumb Console listener, and an Email listener which will send out an email whenever an alert is received. Of course, the messages are fully configurable. Numeric Attribute Monitors The first type of monitor is a org.jboss.monitor.ThresholdMonitor that is used to track Numberic MBean attributes. Here is an example configuration of a monitor of free available memory. It will send a JMX Notification when free memory goes below one megabyte. The MBean it is watching over that has this particular stat is jboss.system:type=ServerInfo. File: FreeMemory_Monitor-service.xml ?xml version=1.0 encoding=UTF-8? server mbean code=org.jboss.monitor.ThresholdMonitor name=jboss.monitor:service=FreeMemory attribute name=MonitorNameFreeMemory Monitor/attribute attribute name=ObservedObjectjboss.system:type=ServerInfo/attribute attribute name=ObservedAttributeFreeMemory/attribute attribute name=Threshold100/attribute attribute name=CompareTo1/attribute attribute name=Period1000/attribute attribute name=Enabledtrue/attribute depends-list optional-attribute-name=AlertListeners depends-list-elementjboss.alerts:service=ConsoleAlertListener/depends -list-element depends-list-elementjboss.alerts:service=EmailAlertListener/depends-l ist-element /depends-list /mbean /server Let's walk through each attribute: attribute name=MonitorNameFreeMemory/attribute The display name in which this monitor will be shown in the web-console. If you create monitors by hand you can have it managed by the web-console if you have one monitor defined in one file only and the name of the file is the same name as the monitor and the file lives in ./deploy/management/monitors/ So The above example the filename should be FreeMemory_Monitor-service.xml, notice that whitespace is substituted with an '_' charater. attribute name=ObservedObjectjboss.system:type=ServerInfo/attribute attribute name=ObservedAttributeFreeMemory/attribute These are the MBean and the MBean attribute this monitor will watch. If the MBean is a ServiceMBean then you should make this a depends optional-attribute so that this monitor doesn't start before the watched MBean is loaded. attribute name=Threshold100/attribute attribute name=CompareTo1/attribute The Threshold is the value threshold of the attribute. The CompareTo is a numeric value, -1 means (greater than), 0 means = (equal), 1 means (less than). These are the same values used by Java comparators. So in this example, when the FreeMemory attribute is less than 100 a JMX notification will be sent. attribute name=Period1000/attribute The MBean creates a thread that will wake up every so often to check the threshold against the MBean attribute it is watching. The Period is the time in milliseconds this thread will sleep. attribute name=Enabledtrue/attribute Enabled determines whether or not this monitor should actually monitor. It is the on/off switch of the monitor. depends-list optional-attribute-name=AlertListeners depends-list-elementjboss.alerts:service=ConsoleAlertListener/depends -list-element depends-list-elementjboss.alerts:service=EmailAlertListener/depends-l ist-element /depends-list When the threshold is triggered, the Monitor will send JMX NOtification to all registered listeners. For this particular MOnitor, a Console and Email listener have been registered. We'll look into how to configure the Email and Console listener in a bit, but when a threshold is breached, a message will be sent to the JBoss console
RE: [jboss-group] FW: [JBoss-dev] [ jboss-Bugs-643739 ]unknown-pk?missing in jbosscmp-jdbc_3_0
bring him the america:) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of marc fleury Sent: Friday, October 10, 2003 1:21 PM To: 'Private list for internal JBoss Group discussion'; [EMAIL PROTECTED] Subject: RE: [jboss-group] FW: [JBoss-dev] [ jboss-Bugs-643739 ]unknown-pk?missing in jbosscmp-jdbc_3_0 Let's get laurent on board, it seems our bravo ta bite comment made it through, he buys it :) Cool, Sacha keep a close eye on this guy he is good, marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sacha Labourey Sent: Friday, October 10, 2003 11:56 AM To: [EMAIL PROTECTED] Subject: [jboss-group] FW: [JBoss-dev] [ jboss-Bugs-643739 ] unknown-pk?missing in jbosscmp-jdbc_3_0 Laurent is our new bug-report serial-killer!!! ;) That's great, thanks! I did it once, it was good to close all these cases! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of SourceForge.net Sent: vendredi, 10. octobre 2003 17:52 To: [EMAIL PROTECTED] Subject: [JBoss-dev] [ jboss-Bugs-643739 ] unknown-pk? missing in jbosscmp-jdbc_3_0 Bugs item #643739, was opened at 2002-11-25 21:04 Message generated for change (Comment added) made by letiemble You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=6 43739group_id =22866 Category: None Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Harald Venström (hvenstrom) Assigned to: Laurent Etiemble (letiemble) Summary: unknown-pk? missing in jbosscmp-jdbc_3_0 Initial Comment: The optional defaults element unknown-pk? is missing in the online document: http://www.jboss.org/j2ee/dtd/jbosscmp-jdbc_3_0.dtd for reason unknowed it seem to have been lost in the latest update? (fFrom the 22/11...). -- Comment By: Laurent Etiemble (letiemble) Date: 2003-10-10 17:52 Message: Logged In: YES user_id=437455 This feature is only available in 3.2.0. That why it doesn't not appear in the dtd. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=6 43739group_id =22866 --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ jboss-group mailing list [EMAIL PROTECTED] http://mail.jboss.org/mailman/listinfo/jboss-group ___ jboss-group mailing list [EMAIL PROTECTED] http://mail.jboss.org/mailman/listinfo/jboss-group --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
Dave, Think about this. If we wait for the spec to implement the kind of stuff dot net is doing, J2EE is dead anyhow. At 10K per CPU J2EE is dead as well. We are moving to a commodity based infrastructure, dot net can play so can open source and IBM. Not sure too many others can join the ride. Realize that we are saving Java not destroying it. More people download JBoss than the reference implementation. Ben Sabrin Director of Sales and Business Development JBoss Group, LLC 404-467-8555 x202 - office 404-664-9466 - cell 404-948-1496 - fax [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED] On Behalf Of Dave Smith Sent: Wednesday, March 26, 2003 10:20 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] AOP versioned ACID objects 1st iteration :rotfl .. a Frenchman wanting action This is hot shit. Plain and simple. Take the J2EE spec and piss all over it. When you wrote it your mind was small and feeble, we have seen the light. The question is how long before the world realizes it or does J2EE implode and we all are paying homage to Bill and .NET May God Bless America and Java. marc fleury wrote: So in the quest to impove J2EE have you killed it? bla bla bla bla marc fleury wrote: do you motherfuckers realize how BIG this is? obviously some of you don't get it, give it time, it will become very obvious enough wasted time in the U.N. Time for some good ol' action marcf --- 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 --- 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] FW: Linux World Arwards
All, Today has started off great, we just got a call from Frank at Linux World letting us know that we are finalists in two categories at Linux World. They are: Best Open Source Project other finalists include Eclipse, Open Office, Vovida, and ephibian (spelling could be wrong) Best Network / Server Application other finalists include IBM WebSphere, SuSE Enterprise Server, CA Unicenter, and a product called Orion (not the one we would think of). This category can be open source or proprietary as you can see. In any case, this is good company to be in and I think we are going to win at least one of these. Everyone associated with JBoss is doing an awesome job in writing the best application server in the industry, keep up the great work. Ben Sabrin Director of Sales and Business Development JBoss Group, LLC 404-467-8555 - office 404-664-9466 - cell 404-948-1496 - fax [EMAIL PROTECTED]
[JBoss-dev] FW: Open Source Excellence Awards
Thought you might want to read the official release. We are swimming with the Sharks:) I think we can and should win the open source project as we have a more mature code base and more downloads than any of the other projects. It should be interesting to see what happens. We are competing against Sun, IBM, and Computer Associates to name a few. Ben Sabrin Director of Sales and Business Development JBoss Group, LLC 404-467-8555 - office 404-664-9466 - cell 404-948-1496 - fax [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 16, 2003 10:56 AM To: [EMAIL PROTECTED] Subject: Open Source Excellence Awards Ben, Congratulations!! (See attached file: LWNY03 Award finalists 1.16.doc) See you in NY. Frank LWNY03 Award finalists 1.16.doc Description: MS-Word document
RE: [JBoss-dev] JNuke dev
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... THe first them I did is made of a servlet that register to JMX and the doGet operation
RE: [JBoss-dev] JNuke dev
You need to think in a one dimensional world. J2EE = JBOSS ! That is the future, learn it, live it, love it A quote from Fast Times at Ridgemont High. Ben Sabrin Director of Sales and Business Development JBoss Group, LLC 404-467-8555 - office 404-664-9466 - cell 404-948-1496 - fax [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Nathan Phelps Sent: Tuesday, January 14, 2003 2:48 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev I would think that we'd want to make this a J2EE application so it can run on ANY J2EE application server. Therefore, I would elect to go down a pure J2EE route instead of a JBoss only JMX route. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ben Sabrin Sent: Tuesday, January 14, 2003 1:04 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev 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
RE: [JBoss-dev] JNuke dev
Oh I remember, which is why I feel that we need to concentrate this app towards the Java people not the interesting Perl Mongers:) Ben Sabrin Director of Sales and Business Development JBoss Group, LLC 404-467-8555 - office 404-664-9466 - cell 404-948-1496 - fax [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [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
[JBoss-dev] RE: [jboss-group] FW: Sun says Opensource is bad
I could not agree more! He is foolish, we give people an entry point into J2EE that is affordable and can rival .Net. This coupled with Microsoft new licensing policies, should catapult J2EE to the top. If we are screwing up the revenue model, what is Sun doing by providing Sun One for free? This is something we should ask Mr. Mcneely. I think he was caught off guard with this question and fumbled the ball. Ben Sabrin Director of Sales and Business Development JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Saturday, August 03, 2002 1:10 PM To: marc fleury; 'Jboss-Group@Jboss. Org' Cc: Jboss-Dev Subject: RE: [jboss-group] FW: Sun says Opensource is bad Is the RI source-available? I didn't think it was. Yeah, McNealy is an idiot. Even without JBoss, .Net's price point will bring down J2EE revenues. The difference is, with JBoss, people will stay under the Java/J2EE umbrella. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Saturday, August 03, 2002 7:43 AM To: 'Jboss-Group@Jboss. Org' Cc: Jboss-Development@Lists. Sourceforge. Net Subject: [jboss-group] FW: Sun says Opensource is bad Scott McNealy says we are destroying the revenue models of the J2EE marketplace, imbecile, he doesn't even know what is sexy. marcf -Original Message- From: Lawrence E. Rosen [mailto:[EMAIL PROTECTED]] Sent: Friday, August 02, 2002 8:13 PM To: 'Nathalie Mason'; 'marc fleury' Subject: FW: Sun says Opensource is bad I just received this today. /Larry -Original Message- From: Peter Donald [mailto:[EMAIL PROTECTED]] Sent: Friday, August 02, 2002 5:04 PM To: Jakarta General List Subject: Sun saids Opensource is bad http://www.oetrends.com/cgi-bin/page_display.cgi?77 And that is why I am glad that jakarta is starting to get .Net technologies on board. ___ jboss-group mailing list [EMAIL PROTECTED] https://secure.jboss.org/mailman/listinfo/jboss-group ___ jboss-group mailing list [EMAIL PROTECTED] https://secure.jboss.org/mailman/listinfo/jboss-group --- 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
