It's clear from your post that you haven't used JBoss in several years. PDF docs are available for all major products and have been for some time. The printed materials they sell are just hard copies of the PDFs. Selling documentation hasn't been their model for some time.
As for being bloated, I'm starting to doubt that you have ever used *any* J2EE app server for that matter. JBoss is exactly what you make of it and is the only J2EE app server that you can strip into a ~56MB footprint easily removing what you don't need. You don't need EJBs? Don't use them. Try that with WebSphere or WebLogic.
Azul sells specialized processors for high-end Java applications (last I looked). You can't just slap any binary you want on these things and run it. All apps run inside a proprietary OS inside their boxen, there's no installing what you want here, just uploading jar files.
Interesting to see MySQL architects leaning on the GPL to comfort users given their partnership with SCO who seems to care so little about the license and arguably seeks to defeat it. I feel like one hand doesn't know what the other is doing.
Too bad also that they were never able to create a transactional table type on their own rather than allowing someone else to do it for them, they wouldn't be in this position.
It depends on what your product is doing. If you simply need a web application, then there isn't much need to introduce all of JBoss into the mix unless you need to cluster it and manage a large number of nodes in a centralized manner.
However, it is quite possible to slim JBoss down by stripping out many parts of the app server to make it lightweight and suitable as simply a web application container. I've actually used JBoss as a framework for a product before and it absolutely shined. We didn't need EJB so that was yanked out. We need portability through JCA, that worked beautifully. We implemented most of our functionality as JBoss SAR services and used the velocity-based template service for deployments of new components (see the user's guide and wiki, it's all quite well documented), all worked beautifully.
You're sinking fast. Others have already addressed the "JBoss isn't claiming to invent JMX argument" so I won't go there.
Most FOSS application servers as well as commercial servers do expose JMX objects so this isn't something that sets them apart. What does set them apart is that they base their architecture on JMX where as others simply expose JMX objects, usually for mundane tasks simply to get the checkbox on feature set. JBoss on the other hand, uses JMX to bootstrap the entier application server, almost every component within the server is configured with a JMX MBean meaning you can use the JMX server infrastructure to easily interrogate and alter the configuration at runtime if desired. This is what sets them apart.
I feel like we are seeing the birth of a new term in Internet slang. In five months I predict a wikipedia entry, a series of "All your MOGs are belong to us" slashdot posts and something about Soviet Russia but I haven't quite worked that one out yet. I had no idea who MOG was prior to this but I have a feeling she will live in infamy as Internet slang representing the swift justice applied by the masses when one does something sleazy in the face of a techno-community. She will be the Roy Munson of Linux without the whole hot girl ending part.
This is wrong on so many levels, I'm not sure where to start. For one, my mom *should* be using WEP and MAC filtering but good luck explianing that to a non/.'er. Second, even if you manage to sniff an open network for a month whilst recording a gig of usless broadcast traffic and then manage to re-assemble a tcpdump session, that doesn't give you unabated access bank accounts or passwords. You would still need to crack a 256-bit SSL session with periodic renegotiation; should take you somewhere on the order of 400 years on a modern processor. WEP != poor security, Wireless != poor security, poor usage practices == poor security. If you connect to you bank, email, whatever over an un encrypted connection, you get what you pay for. Simply using Wireless/WEP doesn't make you *more* vulnerable, if nothing else it's another layer on top of a good policy.
Eanabiling remote administration is not, in itself a bad idea, particularly if you are away from your lan/wlan on a regular basis. Not changing the default password is a bad idea, not connecting over an encrypted channel is a bad idea, however simply enabling remote administration does not signify a failure on the part of the home administrator.
Slashdot Mirror
It's clear from your post that you haven't used JBoss in several years. PDF docs are available for all major products and have been for some time. The printed materials they sell are just hard copies of the PDFs. Selling documentation hasn't been their model for some time.
As for being bloated, I'm starting to doubt that you have ever used *any* J2EE app server for that matter. JBoss is exactly what you make of it and is the only J2EE app server that you can strip into a ~56MB footprint easily removing what you don't need. You don't need EJBs? Don't use them. Try that with WebSphere or WebLogic.
Azul sells specialized processors for high-end Java applications (last I looked). You can't just slap any binary you want on these things and run it. All apps run inside a proprietary OS inside their boxen, there's no installing what you want here, just uploading jar files.
Interesting to see MySQL architects leaning on the GPL to comfort users given their partnership with SCO who seems to care so little about the license and arguably seeks to defeat it. I feel like one hand doesn't know what the other is doing. Too bad also that they were never able to create a transactional table type on their own rather than allowing someone else to do it for them, they wouldn't be in this position.
It depends on what your product is doing. If you simply need a web application, then there isn't much need to introduce all of JBoss into the mix unless you need to cluster it and manage a large number of nodes in a centralized manner. However, it is quite possible to slim JBoss down by stripping out many parts of the app server to make it lightweight and suitable as simply a web application container. I've actually used JBoss as a framework for a product before and it absolutely shined. We didn't need EJB so that was yanked out. We need portability through JCA, that worked beautifully. We implemented most of our functionality as JBoss SAR services and used the velocity-based template service for deployments of new components (see the user's guide and wiki, it's all quite well documented), all worked beautifully.
You're sinking fast. Others have already addressed the "JBoss isn't claiming to invent JMX argument" so I won't go there. Most FOSS application servers as well as commercial servers do expose JMX objects so this isn't something that sets them apart. What does set them apart is that they base their architecture on JMX where as others simply expose JMX objects, usually for mundane tasks simply to get the checkbox on feature set. JBoss on the other hand, uses JMX to bootstrap the entier application server, almost every component within the server is configured with a JMX MBean meaning you can use the JMX server infrastructure to easily interrogate and alter the configuration at runtime if desired. This is what sets them apart.
I feel like we are seeing the birth of a new term in Internet slang. In five months I predict a wikipedia entry, a series of "All your MOGs are belong to us" slashdot posts and something about Soviet Russia but I haven't quite worked that one out yet. I had no idea who MOG was prior to this but I have a feeling she will live in infamy as Internet slang representing the swift justice applied by the masses when one does something sleazy in the face of a techno-community. She will be the Roy Munson of Linux without the whole hot girl ending part.
This is wrong on so many levels, I'm not sure where to start. For one, my mom *should* be using WEP and MAC filtering but good luck explianing that to a non /.'er. Second, even if you manage to sniff an open network for a month whilst recording a gig of usless broadcast traffic and then manage to re-assemble a tcpdump session, that doesn't give you unabated access bank accounts or passwords. You would still need to crack a 256-bit SSL session with periodic renegotiation; should take you somewhere on the order of 400 years on a modern processor. WEP != poor security, Wireless != poor security, poor usage practices == poor security. If you connect to you bank, email, whatever over an un encrypted connection, you get what you pay for. Simply using Wireless/WEP doesn't make you *more* vulnerable, if nothing else it's another layer on top of a good policy.
Eanabiling remote administration is not, in itself a bad idea, particularly if you are away from your lan/wlan on a regular basis. Not changing the default password is a bad idea, not connecting over an encrypted channel is a bad idea, however simply enabling remote administration does not signify a failure on the part of the home administrator.