Hi there. My name is Ray Kiddy. I'm in the WebObjects Engineering group. And we're here to talk about JBoss, the J2EE container that is shipped with Mac OS X Server. And we're Just FYI, probably the level of the talk, it's kind of hard to describe in the terms in the catalog.

This is an introductory probably talk about JBoss itself. For instance, we can talk about setting up the connection managers to talk to the Apple CDSA system to get secure authentication. And that by itself would take several hours. So we're not going into extreme detail on any of these kind of things.

Probably if you're here because you use Mac OS X Server and you deploy Java applications or you build some Java applications and are needing to move them to a more serious deployment environment, you've heard of JBoss, you've looked at it, it's confusing. You can read some of this documentation and it makes my eyes go blurry when I read it. Some of the Sun documentation. It's just famously, you go catatonic reading it.

But if you're at that point, you can read the magazines. They don't explain anything. You can read some of those articles and you can come out of it thinking, well, I know some more buzzwords, but I know zero more information. There's no more knowledge that I know. So I'm hoping to get you past the first hurdle in deciding, yes, this is a realistic sort of deployment scheme to look at.

And on Mac OS X Server, we think we've made it a lot easier. So if you're already ready to ask me questions about your XML descriptors and problems you're seeing in cross-configurations, that's probably not the kind of thing we can go over here, but I think most people are not quite up to that point. And to go into a very advanced talk would take quite a while.

So JBoss is ready to take on the enterprise. Really, businesses are taking open source tools very seriously now. JBoss has managed to make a name for itself. It's known. The promoters of it are very outspoken. The enterprises are realizing that they want to not be locked into certain platforms, that they want to not be locked into certain tool sets.

And so they're looking for these kind of solutions where things are available. Even college kids can get this, and they can find people who know this moving forward. Ray Kiddy And, you know, it helps to have somebody who actually comes from a research firm that the enterprise people listen to. So we put this on.

So another marketing-oriented slide. Sorry about that. But I wanted to show that this is published by JBoss, but it's by a third party. So you can have a bit of faith in that. Between 2002 and 2003, the deployments in enterprise of JBoss doubled. It was pretty significant growth.

This one, as a development environment, or for developing J2EE applications, JBoss is actually the most popular. So what that means is that people out there may be deploying on other J2EE servers, but they have JBoss available. It's free, so they have it. And the people writing the applications are familiar with JBoss. So going forward, those people, as they become more senior, make decisions eventually. And JBoss has some legs in terms of lasting, because the new people coming in are using it more. We'll get off the marketing slides soon, I promise.

Again, for the future, JBoss is moving forward very quickly. Now, Apple has the latest version 3 on its servers. Version 4 is, of course, much talked about by the JBoss organization, but it's still very new. Cutting edge, as in you will slice your hand if you use it. So we're not putting that on every server we ship out the door. But JBoss has done a really good job of having the documentation is a lot more available than it used to be. The wikis and the blogs are very active.

They're active in the JSR process, moving the J2EE standard forward. In particular, I don't know if you've seen the EJB 3.0 stuff, but I wish EJB looked like that two or three or four years ago. It's finally seeming to become a little bit more simpler. And companies, as I said, are increasingly setting policies that they would prefer to use open source tools, tools that don't lock them into licenses, that don't lock them onto platforms. Tools that they can deploy on different servers without asking some big company. So why Mac OS X Server and JBoss? We think we've done good things to make JBoss a lot easier to use out of the gate. So I'm going to talk about those.

So we've customized it. That's significant. The server admin application to start and stop the container and to control which configuration you're running. Server admin is used to administer a lot of other services on Mac OS X Server. So the DHCP servers or the FTP or the mail or whatever. We've made starting the application just very easy. Essentially, you can think about starting the JBoss server and then 10 minutes later you can have it up running and then actually deploy an app in it about three minutes later.

So, you know, that's not the end of your learning task. But it's at least a lot easier to get started. You can download JBoss and try to set up a distribution. It's going to take you a while just to figure out the first couple error messages you see. So we've saved you from a lot of that. Once you start to do something strange, you'll see those error messages.

You'll have to figure them out eventually. But we've customized this for a couple different scenarios that you can use that will handle a lot of people's use cases. And we have graphical tools for the monitoring deployment and configuration of the container. So if you've tried to do this stuff by hand, swinging without a net, you end up VI and the XML and you end up writing scripts to unbundle. It's a pain. It's a bother. So just getting an initial configuration up that's reasonable for your machine can be quite a learning experience. And we've essentially made that automatic.

There are three configurations that come out of the box, and we'll talk more about them later, but two of the configurations are deployment. One is a deployment standalone, just a single machine. One of them is deployment for a clustered environment. We've set that up for you so it works just automatically.

And then another one is a development environment. You're developing the application. You want to get a lot of information out of what's going on, and you don't need it to be performant. You don't need to emphasize the performance of the application itself. The development configuration is set up that way.

JBoss itself, when you download it, if you were to download it, it would be conservative about what JVM you're looking at. So it would assume you have one of the 1.3 versions of the JVM, and options would be turned off. These options can be turned on if you have the 1.4 JVM. You wouldn't necessarily know which options those are. And actually, we've gone in. We know you're on a system with 1.4, and actually now probably 1.4 too. And so we've gone in and turned on those options. But we've also tuned the parameters for that.

And also we've, frankly, looked at what the parameters mean for the JVM, whether they make sense, whether they do what they say they're going to do. And if they didn't make sense, we don't turn them on. So you don't have to go through that discovery process yourself. You have n number of configuration options and how many combinations of that.

And we've also done some test configurations to sort of scope out and run tests on to see what you want. It's pretty complicated. So we've optimized it for the version of Java that's on Mac OS X server that you've got. And we've optimized the deployment environments for performance. Reliability and performance tests were run quite a while, and the spec compliance as well. You know, you get it from JBoss. Their interpretation of the spec is sometimes a little bit flexible. And we think we've interpreted the spec to see what it means and made the change that was appropriate to that. So this will help your learning process.

So on Mac OS X Server, it's not just a standard Unix distro. The file system has laid out certain things. The tools, server admin, it expects things to be in certain places that make sense. And indeed, we've put JBoss into library JBoss. The logging is redirected to the library logs directory, which is where most of the system expects logs to be.

And you could go in and manually defeat that to put logs somewhere else, but there's really no reason to do that. The nice thing about this is that when you switch configurations, you don't have to re-figure out where your logs are. The standard distribution, you know, all the logs go to different places when you switch configurations, so it can be a bit confusing.

We've essentially made JBoss fit in with the other tools on Mac OS X Server by putting it in the expected places. And then, frankly, you know, dealing with the changes that fell out of that, dealing with the things which should be settable, and yet you set them and they do something odd. So we fixed all that.

Server admin, as I said, is the tool that Mac OS X Server uses to administer all of the different server services on the machine. And so it's as easy as clicking on a button in a list and picking the configuration. And from a pull-down and then clicking one button, your JBoss container is running. So I'm going to say again, that's really nice.

You know, a lot of times, I don't know about you, but, you know, if I can make the first step, it's a lot easier to figure out the second or third steps. But sometimes the first step itself, you know, I remember trying to write in a language I hadn't worked with, and until I saw somebody give me a 20-line program that did something, you know, I was like, oh, that's a good idea. You know, it didn't make sense.

But once I saw that very first, you know, yes, this works, then I could step off from there. This gives you a place to step off from. This gives you a working server, a working container, you know. And then when you go to the JBoss list for help or information, you can say, you know, before I did X, you know, this worked.

You know, and I know it worked. You know, Apple shipped it. They had tested it. You know, it's more than just, you know, your Joe Bob calling in. You know, I'm doing something weird over here, and tell me why it's not working. You know, that's a little bit hard for them to answer. But we have a known scenario. We have a known system, and it gets you started, puts you in a really solid position.

So Watchdog is not JBoss specific, but it launches processes for you, watches them, makes sure if you register your container process with it and make sure it stays up, the reliability, if things shut down, they'll come back up. So it's very simple to use. There's a man page.

and not really too much else to say about that. The more of these things, you know, the better these things work, the less there is to say about them. Security is, of course, a huge ball of string. It's just one little slice of the pie here. But actually, that makes sense. As I said, we could take just one aspect of security and talk all day about it. But really, Mac OS X Server comes with some things that make security and authentication fairly easy. And JBoss just takes advantage of them without any extra effort.

Mac OS X Server comes with a JAAS implementation based on the CDSA standard stuff that Apple's done and really strong authentication. The NetInfo configuration, just having regular user accounts in NetInfo and setting up your communication with the container to require authentication via those accounts is very easy. So then you've got the server admin. That can set up your user accounts as well. And you can just use the Mac OS X Server tools to set up your users in a very natural way. And then JBoss just knows about them.

Apache is another one there's not too much to say about because it works well. I'm not going to tell you anything about Apache that you don't know. We use the 1329 version of the server on there right now. The mod JK is included on the system if you want to include it, if you want to have it be used by the Apache server to more tightly bind the server and your container. You may want to have them in different -- with a farther connection from each other, different process spaces and everything. Or you may want to use the mod JK to have Apache do things a little bit more quickly with JBoss. And that's your choice. So that's there.

So MySQL, of course, everybody knows MySQL, fairly robust. Another open source project like JBoss, a bit older, probably. JBoss comes with hypersonic, of course, and hypersonic has some nice things. But frankly, how many O'Reilly books are there about hypersonic versus how many are there about MySQL? MySQL is quite a bit more known, scales up to larger deployments much more easily.

And we've included the database descriptor XML information that lets you just use the MySQL server that's included on the machine and just lets you drop that in and go, not worry about it. You don't have to set up the database to start with. You don't have to populate everything to start with. You can just start using it.

That's certainly a lot of the task, a lot of the job is getting your container to communicate with the database, and we've made that easy. So, again, there's a whole lot of error messages you might have to figure out if we didn't already do this for you. You don't have to learn those. You can just start using it.

So, and LDAP is popular for enterprises. The directories, the authentication, user authentication, JBoss can take advantage of that as well. So if you use LDAP for that purpose, it's trivial to use the LDAP information for identifying users in the container. So Apple uses LDAP internally as well. And so the open source tools for LDAP are very nice. We've included those on Mac OS X Server. server as well.

So, a bit repetitive, I know, but we like to think that we've done the hard work of setting up the configurations for you. You don't have to edit the XML yourself. You don't have to worry about, you know, you've got a key-value pair in the XML that takes an enumerated set of values. You don't need to figure out what those are. It's not going to be obvious what those are. Very often, it's two or three indirections away.

Where it's explained what the enumerated values can be. We've set those up. So, for instance, you know, pull-downs show you the values that are possible. You won't have to worry about mistyping something. Typing data source and putting a DETA, you know, that will mess you up for a day and a half. It really will. And we make it so that you don't make those kind of mistakes because it's provided for you.

It's a whole level of things that you don't have to worry about. And again, the logging is centralized, so you can switch between configurations and not worry about where things are supposed to be going, where the information about what's happening is supposed to be going. It's right there in the same place, and the server admin application can allow you to look at the logs also remotely. So you can be on another machine and then deploying the server over there and looking at the logs over there and everything. So it makes it quite easy to administer these.

These are the two deployment configurations that I was talking about. And they are optimized for performance quite a bit. Out of the box, we were seeing performance and we got multiples better by doing things, doing some fairly non-obvious things to make it work on the system that we have with the JVM that we have, with the database we have. So we've done all that for you. The two deployment configurations are standalone.

not so happy, but clustering is -- I'm not sure if you can hear me. is going to talk about the configuration of the cluster. You can try to set up the clustering yourself with the configuration. Again, a whole new slew of error messages to learn and things to find that are not optimal in the default configurations.

There is a lot of information about JBoss on their site. www.JBoss.org. They have a wiki. It is fairly interactive. You can get on and ask questions or provide your documentation of how you think it is working and see what they say. All of that. But we do provide these configurations to be working, to come out of the box, to launch, to run, and to get you started.

Tomcat, of course, a server that by default is run within the JBoss container. and plays well with the standard Apache configuration. Basically, if you know Tomcat, somebody's started up JBoss, you can use the Tomcat services without worrying about what JBoss is doing. It subsumes them, wraps them up.

So Tomcat is in its own directory as well, library/tomcat. And the HTTPS services, the connection services, are easy to set up and use. And when you start it up in the JBoss container, it's on a port 8080, which is sometimes a little confusing. Because--next slide-- the standalone Tomcat is on a different port.

So if you want Tomcat, but you don't want the JBoss container running, you can--one of the configurations of the JBoss container is Tomcat only. So you can go into the server admin application, select JBoss from the list, go to, say, Tomcat only, and start. And it doesn't start JBoss, it just starts Tomcat. And Tomcat will behave in the way that it's expected to behave. So if you're doing something that you don't want to involve the container in your JBoss stuff, this is there for you.

So we're going to do a real quick demo of the server admin application. OK. Great. So the server admin tool is really simple. Let me just launch it really quickly. And what we did with JBoss and Tomcat was made it a first-class system within the server admin. And there's an application server plug-in here.

As you can see, most of your other major services like FTP, mail are accessible here. So we put it at the top level. So if you select it, as you can see, the service isn't started. This first pane is just giving you a little bit of the configuration information. And boom, we've just started our server without having to do much.

Other things of note within our server admin is that you can have access to various log files and stuff like that. So this is the bootstrapping files.

Ray was talking about the three configurations that we give to you out of the box. There's deploy cluster, deploy standalone, and develop.

Primarily on a deployment platform, you'd be interested in either the cluster or standalone. I've also got a custom configuration for the XPET store. So if you do create a custom configuration, it is accessible through the admin. It's not like hardwired to anything. So it dynamically picks that up.

So these other configurations are both on 8080. So that's our quick demo, just getting us up and running. So we have a server going. Back to slides. And just for the tech people, try not to do that deep sigh into the microphone again. It's been a long week, hasn't it? You guys made it to Friday.

You know, the conference is a lot of work for us. You know, the bad thing about the conference is it's incredibly disruptive on all of the processes, the development work at Apple. The good thing about the conference, though, is it's very disruptive on processes. You know, because really, you know, I want to say we really, really appreciate hearing from you all.

And frankly, sometimes the management needs to hear you all and reset what they're thinking. You know, they've got their five-year plan of the Soviet Union. They've got their five-year plan of the Soviet Union all mapped out in their head. You know, but the best laid plans, you know, sometimes we need to redirect these.

So it's been a challenging week, but we're almost through. I appreciate you all being up here early in the morning on Friday after the -- I was told the attendance might be really down because of the alcohol consumption at the party. But that seems not to be too much of a factor. Either that or it might make more sense if you're a little bit hungover. You know, that's always good, too.

Certainly nobody's looked at J2EE implementations and said, wow, what an elegant solution. It's not. But deploying in production environments is really hard. You're looking at it and it's like, well, see, what I'm doing now is being paged at 4 in the morning every day for two weeks. Essentially, it's like chewing glass.

These containers, with their management protocols and everything, they start to look better. We want to help you grow your applications into industrial environments. That's why we're doing all this. So configuring a monitor in JBoss, as I said, it can be pretty complicated. But we try to make it as easy as possible for you.

The different approaches, we've provided the configurations based on what you want to do. You can switch between the different configurations and try to get to where you're going. It doesn't destroy this configuration to switch to it and configure, switch back to this one and configure. You can experiment with what you're doing and we make that easy. Again, the login is all centralized and everything is easy to find. We think it works well.

So JMX console is available. It's different using it. It's not very friendly. It is a web-based system. But it's all textual key value coding. It looks as much like XML as any web page could, actually. It's simply a translation of that XML. Also, of course, when you're using the JMX console, you're changing things in memory.

for the current container. And then of course if you stop the container and restart it, it's all gone. You're off the scratch pad. It's for dynamic configuration of some of the parameters. But it doesn't allow you to persist those changes. Probably because of the bullet too farther down, which is that it's not secure.

If you expose the JMX console, you would have to figure out how to make that access point secure. yourself. And there is no validation in the JMX console. You know, you -- it asks you for a data source name. And so instead of saying, you know, MySQL DS, you say MySQL FUBAR. It's going to say, okay, fine.

And then 20 minutes later, you'll start to get some odd errors. So the errors do come up more than one step after what you've done, which always makes it harder. Because you think you've just done something, but no, it was actually the two or three things ago that caused what you're seeing now, and it's not obvious. So what we provide is more than just the JSR77 dictionaries of information. We provide a level of ease of configuration beyond that.

The XML is still there, of course, if you want to get dirty and dive down into it. But then you're swinging without a net. Eventually we all do that because we like to have -- eventually we want to have that much confidence in our systems that if the rest of the world has fallen down, we can bring things up. But it's going to take you a little while to get there. And we're giving you a solution that works until you get there. I think we're going to do another demo. Yes. Okay.

Okay, so what I'd like to do is just manage my host, and I'll select this button right here. I'll just give you a quick tour of what we can do within the JBoss management app.

Let me just show you how it appears in our management app. So contrast this to actually how the XML looks. And I'm going to open up the file here really quick.

So this is what it looks like within JBoss. And you'd have to do a lot of digging around here and hand-configuring and figuring out what exactly valid parameters are for this. And it's just kind of ugly. And there isn't a lot of comments in here to help you figure out exactly what this is.

But within our management tool, we've allowed you to -- we've exposed some of the dependencies and some of the values that are available to you. So I'm going to just show you something like our cluster being really quick.

We've exposed a lot of the min and max values so that you have an idea of what you can configure here, whereas defaults. We saved you more time grepping through files.

So let's go back to our top-level page. Other things that we've exposed are creating data sources really quickly. So if I want to create a data source for a new JMS data source or MySQL or a post-grade data source, all I'd have to do is give it a name, and it'll create my data source for me with all this configuration.

Other things you can do if you're interested in JMS is we allow you to create topics or queues. So that is exposed to you and you can save it off to a file as you can see right here. And then, of course, we allow you to deploy your applications either in clustered or standard mode. So I'll just deploy our XPET store really quickly.

And there we go. So we're deployed. So let's try just accessing it really quickly. And I think I put a link here. Oh, I'll show you one other thing. So if you just want to check if your host is up, you can hit the 8080 port and just local host.

And, okay, now I'm -- it's another way to verify that your JBoss server or your Tomcat server is up. So before I show you the Tomcat demo, one thing you have to do is actually populate the database. And there we go. So let me make sure that that's populated.

Let's hit my link here. So it's got to recompile some of the servlets and stuff like that, but basically, here's your standard Java pet store demo. This is like validates your container, or Sun at least uses it to validate that a container is like J2EE compliant, and it's like a good example app.

So there's a working app, and let me just show you really quickly, contrasted with the JMX console. So what you're seeing here is we're persisting our data, we're configuring the XML files, and if I stopped my server and stuff, it... : I think my configurations will persist, but if we go to the JMX console, oops, I hit

Usually it allows you to add some kind of values here and then invoke it.

And so it's not always a pretty thing. You don't know what are valid values, what aren't valid values. It allows you to kill your container. And this is only that instance of the container and at runtime. If you invoke something like this, then it will show you a thread dump in particular. So we think that we've added a little bit more value on top of the JMX console, and like Ray said, we validate on your values.

We also are more secure because you actually had to log in to get to our tool versus the JMX console. hopefully that gives you an idea of the interaction. And they are complementary. If you are just in development mode, the JMX console is a great way to tweak values.

We showed you one way of deploying applications. But of course, we didn't do anything with that application. That application was already set up and waiting for us. Once you have it set up and waiting for you, you can use that interface. And it's very easy to get it deployed.

But of course, before you deploy it, you start out, you build it for the first time, you've got a bunch of things in the archive for the container that you've got to change somehow. So if you're doing it manually, you un-jar all these things, move them around, edit the XML, get them re-jared up in the right place. And it can be a bit of a mess.

So, you know, the web and EJB module descriptors all have to be changed, and usually, of course, they need to be changed in two or three different places. If you just change them in one place, again, new kinds of error messages until you find the next place you were supposed to set it, and then maybe the next place after that.

Ray Kiddy So, you know, our tool links these things together. You change it in one place, and every place that is supposed to have that same value, it gets pushed to it. So, you don't have to worry about, you know, did you type it different here? Did you type it different there? Did you remember to go to this other descriptor, this other level in the system to set it again? And, you know, just set the same values over and over again. Ray Kiddy So, it makes the cycle of, you know, the archiving, deployment, unarchiving, it makes it very easy with our tools.

Ray Kiddy So, you know, our tool links these things together. You change them in one place, again, new kinds of error messages until you find the next place you were supposed to set it, and maybe the next place that is supposed to be. So we think that makes a good experience on Mac OS X Server.

We validate the XML. You're not going to get some Jaxby parser error or something that doesn't -- it's not going to make much sense. The XML parsing, again, new classes of errors. You can override the settings in the containers and The possible values are shown to you, so you don't have to guess. It's very nice.

So what I'm going to show off is a deployment tool. And so this is if you need to configure application for your particular container or you need to reconfigure your war bundle or your bundle. So let me just start it really quick. And it will pop up in our Safari browser in a minute.

So I need to give the location of my pet store here. I also have this checkbox for validating XML files. So what that does is it also checks for various values and

So I think some of these things are self-explanatory except for the connect link right here. I'll explain that in a second. But what I'd like to show you is just some of the validation features that go on here within the tool. So say I strip this data source mapping.

Let me just show you some of the enterprise beans. So with the blue colors, this says, okay, everything is validated and it checks out. But if I remove, like, some values here that are necessary or dependent on other -- by other beans or servlets, they'll highlight in red and say, hey, there's a cross-dependency here. You've just changed your global data source and none of these beans -- these beans depend on it. : This is an easy way of -- or we've exposed this and made it easy for you to tell if you've configured your app correctly.

So what I was doing here was just editing by, you know, if I had some specific knowledge of my data source. But what if I didn't know what my container, what kind of data sources or configurations I had available in the specific container I was going to deploy to? We've added this connect feature where I can connect to my actual JBoss server. And then the deployment tool will figure out, okay, what settings or configurations does my server support that I'm deploying to? And as you notice, those text fields went away in the same, our global CMP settings.

And actually, it figured out from our server that these various HSQL data sources are available to me. And so we hand-hold you a little bit so that you don't have to go and figure out some of those settings. And that makes it pretty easy to figure out what's going on. on.

Other things of note, here's where you check your global settings on servlets. You know, if you had various filters that you were adding or needed to edit, this is the place you would do it. And I think we only have one servlet here for the expat store. And then once you're done editing all your configuration, then you can save it off somewhere.

So that's kind of the quick tour. I encourage you to play with the tool more. It really does help having something which shows you the proper JNDI names for all these resources, you know, because you can look at the file and you won't necessarily be able to see immediately. It's not referenced by file.

It's referenced by, you know, home, other protocol, JNDI. And so you don't need to worry about that. You just, you have it tell you what's available. You know, it can see the descriptors and it can read them and understand that machine, the XMAP. more easily than you can.

So I'm realizing I'm standing up here sounding very calm. You know, I'm not really known around the company. You know, people have heard me talk. I'm not known for my calmness. But perhaps that's because really what I've been talking about is deployment, which we're not...

development on Mac OS X Server, or actually Mac OS X, because You can take a server system, put the development tools on it, get the development parts of JBoss, or you can use the client and put the JBoss development system on that as well.

It doesn't matter. Of course, we keep saying Mac OS X Server, but of course, really the difference between server and client are some extra things, some extra goodies. It's not a fundamentally different operating system. Ray Kiddy We have integration with Xcode with the developer UI to make it much easier to build applications. There are other IDs as well, and they do a lot for you as well. You can try them out, but we think Xcode is a very good solution.

in a web module project within two or three minutes and just put some text onto that page and then hit build. And about two minutes later, you can go to your browser and see the app running. You don't have to jump through a lot of extra hoops to develop and test it as you're going along.

So if you have the server system, you have JBoss, you can put the development tools, of course, on server. But that's not actually going to get you the ability to, for instance, get the WebModule project and some of these J2EE-specific tools. And obviously, if you have a client system, you don't have JBoss by default. So you can, again, go to JBoss.org and try to get it. But then again, you've got your configuration problem.

What you can do instead, actually, is go to this site and download. This is with an ADC membership, which is, of course, free, as they've been saying. And you download this package. And one thing to keep in mind... will bite you, maybe, is that this includes JBoss. So if you've got a server system with JBoss and you've configured some things and then later on decide you want to develop on that machine, this bit me. So that's why I'm saying this. It will gladly overwrite what you've got. So just pay attention to that. Because you're not only getting the web modules, the Xcode integration tools, but you're also getting JBoss, the same version, configured the same. as is shipping on the server.

So if you've got just a client development machine and you don't want all those other tools that the server provides, you don't need to get them to do this. You just download this one package. And it is big. It's a big package. It includes JBoss. It has to be big. But it is just one package. And it's as non-intrusive as it can be.

What else is there to say about this, really? You know, Ant is becoming the standard for these things, and we provide the Ant projects, the projects that you create. By default, they use Ant. So, you know, it's cross-platform. It works with other platforms, and people know it, so why not use it? It works. So we did.

Not much else to say about that. Like, you know, it works, so there's less to talk about. That's okay. and xDocklet. These are the tags that we use. So if you're looking at the xDocklet implementation, then this is what you want to look at. So if you haven't looked at writing custom docklets, this is going to make a little bit more sense.

But if you go to the Java doc page on Sun and see some of the really whacked out things people have done with docklets, at least that will sort of point you to the fact that this is -- Java doc has gone way beyond what it was intended for. But in interesting ways. And then this is one of them.

The develop configuration, actually in the UI, it's a lowercase d. Again, we have preconfigured this so that it works. You can run it, hot deploy the applications, check out what's going on, get all the information. As I said before, it's not optimized for performance, but that's not necessary. You're changing things anyway.

This isn't the stage you should be looking at performance in a J2EE application, frankly. There's many other layers to look at it. And we're going to do a demo of using Xcode for this. RAY KUDWAR: OK, thanks, Ray. So after you've installed the application server developer preview, you'll get some templates that will show up.

So what I'd just like to show you quickly is the web module because EJB modules aren't so sexy for demoing. We will call this test and build this really quickly.

So some of the version information and what are some other-- the servlet home directories and stuff like that. So if you really have to remap your jars or other resources, this would be the place to do it. Here's our build XML, just in case you need to customize it for any reason. And this is specifically the web build XML for building servlets.

Here's our source file, and this is just like your generic hello world kind of starter project. And you can notice up here there's a bunch of X doclet tags that you can configure, and these parameters are pushed into your various config files. One pattern I'll just configure here really quickly is the URL pattern.

Basically, when you contact the host, as you'll see later, the URL, I can remap it to different paths. I'm just going to call this Hello WDC. And let's just do a couple other configurations, like we'll change the title. is going to be posting here. This is not particularly that difficult. This is just a basic HTML page that we're going to be posting here. Okay, so let's just build and run that.

I'm going to just double check that my JBoss server is still up. It should Okay, so if I want to contact my host, one other thing I should point out. In our targets directory, I think... Okay, so this is just the build script that is invoked. So we've wrapped that in a target. Okay, so here should be the URL to my servlet and we've gotten that. It's really easy to configure this. So, let's Hopefully, that's just a quick demo of what the serverlet templates are about and just how we've exposed them in Xcode.

So obviously, as you know, there's a lot more. We're just showing you very simple applications. But really, this does get you onto the road past step zero. A lot of times, you're coming to a completely new technology like this, and you try something for the first time, and it doesn't work. And you have that period of time in which you say, am I just an idiot that I don't get this? But actually, what we give you is that you can very quickly deploy, get this container running.

You can deploy a first application, and you can say, okay, at least this ground that I'm standing on is firm so that I can decide to step forward whichever direction I want to step forward. Now, once you step forward, of course, the JBoss documentation becomes important if you're doing unusual things.

JBoss is the main site. They actually have, as I said, they have the blogs, they have the wikis. So for instance, you could look, there might be information, for instance, specific to Mac OS X Server. On the JBoss wiki. And we as community members can put our questions or answers there. And so I hope that might be useful.

Of course, I'm a WebObjects engineer. WebObjects is near and dear to my heart. WebObjects is just a Java application. Getting it to run in JBoss was fairly simple. We just translated some of the application configuration information to make it look like a servlet. It's a very thin layer to wrap it. I'm just going to do a quick talk about WebObjects.

Of course, you can use JBoss for many months and not do WebObjects development. Mac OS X Server is a very good platform for Java development, traditional Java or plain Java development, whatever you want to call it. You can do all sorts of different kinds of applications and deploy them in a JBoss container.

I'm merely showing you WebObjects because we think it's Amazing. Cool. Wonderful. So, we're going to show it to you, since we have you captive for a few more minutes. I actually thought that this might go too quickly, but it turns out actually that speaking legibly has slowed me down. So, interesting phenomenon. I wasn't expecting that. I think my manager probably was expecting that, but I was not.

So, I never go in order. From the bottom, JBoss has a lot of name recognition. Obviously, you look at the magazines. It's very cool in the buzzword compliance stage of things. Tool development is not the point of JBoss. So, I'm going to go ahead and We like to think that WebObjects will let you more easily build database applications. And then if you need to deploy them in a JBoss environment, it's trivial to do so.

So, you know, if you're, you know, frankly, WebObjects is a very cool technology, but, you know, sometimes you're talking to a somewhat hostile environment, you know, guys in the red ties, you know, that don't get how cool this technology -- cool doesn't work for them, you know, that they want to hear standards-based, they want to hear industrial strength, you know, they don't want to hear elegant, frankly. Elegance is for after work for them. You know, it's -- you know, they want to be able to bolt it on and know it's going to stick to the floor.

So, you know, this lets you get WebObjects applications into those sort of environments because you can say I'm doing an application for you, J2EE compliant, you know, and you want me to do this EJB thing, that's fine. We'll do it. You know, and you just traipse in the door that way. So it gives you sellability into industrial data centers, places where they might not be showing the Apple logo prominently.

So -- and WebObjects is a world-class development environment. It's, you know, it predates, frankly, all the application servers that are out there. It's not as often acknowledged in that role as we think it should be. But, you know, we were doing this stuff quite a bit before, and Sun got started on some of it.

And some of the industry leaders were working on EOF and before that DBKit and WebObjects. And, you know, we've been doing model view controller pattern use, you know, since before any of this was ever talked about. I'll stop now. This is my baby. I have to, you know, I can't help it.

So if you're not familiar with WebObjects, you didn't go to the sessions, that's okay. We forgive you. I forgive you. For now. WebObjects turns databases into object graphs. And as I explained to you, when you're talking to your parents or something, you have to explain it. It takes databases and turns it into some cool stuff.

And then WebObjects also will take that kind of cool data stuff and put it out to the web. And so then R tool allows you to write cooler stuff in the middle which can be very thin or you can have a huge thick wedge of coolness stuck there in the middle in between those two layers. You don't have to handle the web HTTP request, you don't have to handle the SQL yourself. So that's my, you know, trying to explain to my mother what I do.

So of course, it has visual tools for the web interface, dynamic prototype, yada, yada, yada. There we go. just cool, right? So with a -- when you take a WebObjects application, if you build WebObjects, normally you end up getting a WOA with a jar inside, with resources inside. It doesn't look J2E-ish yet.

But if you tell it to include the J2E functionality, then when you build it, it will automatically generate a war. It will automatically put it in JBoss for you. So it will automatically deploy it. Just by building it. Frameworks you use in WebObjects projects get bundled up as archives inside the application and made available to the application. And you can choose whether to put the resources into whichever form, wars, jars or ear files.

And your WebObjects application can use the JNDI protocol to look around itself at the container, figure out what's going on, some something in the outside. With a regular WebObjects application, you have environment variables. The J2EE version of that is probably JNDI properties. Quite a bit less obvious how to use them, but they are there.

So the serverlet features are available. You can do all these things within WebObjects applications, with WebObjects applications. Integrated in J2EE, I don't need to say this again. This is the benefits of J2EE. Less pain being the main benefit. Less deployment hassles. Hopefully less being paged in the middle of the night kind of behavior because you've given it to a deployer, somebody who knows deployments, somebody who's got a bunch of racks of metal. Let them worry about it because we're developers. We want to do our job, send it off and go hit the beach or whatever. So this allows you to do that.

And we're going to do a quick demo of deploying the WebObjects application. Okay, so hopefully -- yeah, okay. So what I'd like to show you -- I mean, I might lose some of the audience if you guys are just J2EE developers, but if you aren't -- and if you're not familiar with WebObjects, we might go a little too quickly. But what I'd like to do is create a quick direct web application and then deploy it to JBoss. And so let me start by creating our application, just calling it Test App.

What we want to do is create a standalone WAR bundle, and that's important, so that it encloses all of our WebObjects frameworks and resources within the WAR bundle. There are other options that you can explore that some of you have used. That last pane was actually the only thing that you have to do that's J2EE-ish to use WebObjects. So it's nice. Everything after this is WebObjects.

Next thing you have to do is embed a deployment license in there. So you'll need that. We'll just take the defaults. These are just web server support, adapter support. Take the standard frameworks. And what I'll do is I'll just work with the real estate model. That's part of our example databases, or one of our example database sets. We'll just do a neutral look. And let's just finish this really quickly.

So a couple things I'll just point out within Xcode. And I think a lot of people have been interested in finding out exactly where you have to tweak or what So, I think one of the parameters you have to tweak to actually, if you have a legacy project to create a new one, is to have a Hi, everyone. I'm Ray Kiddy. I'm the founder of JBoss.

So as you can see, I just have a full-featured direct web app. This is not running in JBoss just yet. I'll just show you that it's fully functional, and we can search on some of the parameters here.

Okay, so what it also did when I built that app is it deployed into JBoss the slash library 3.2 deploy directory. Let me make sure, let me get JBoss running. So I'm on a client system currently right here. So if you install the application server developer preview, you'll find it here in library JBoss 3.2. And, oops, dang. Can't type.

So you'd invoke the run.sh script to start it. And this is on the client system, not-- All right, so I think we're up right now. And so let's just try connecting to our application. Actually, I wanted to point out, he didn't start it with a configuration. And what it does in that case is it uses, if you looked in the list really closely, when we said, here's the three, there was also a fourth and a fifth. The fifth was the example, but the fourth was default. So by default, you've decided on this machine to point to one of those configurations. And when you just invoke run.sh, it uses the default.

So as you can see, I just deployed-- the URL has the 8080 port on there, so you know that you're in JBoss. And here's my same direct web application. And we built this within minutes, and it's all fully functional. I just searched on these addresses. We can go over and take a look at something else like a rating or something, or users. And it's fully functional. So JBoss deployment with WebObjects is very simple. It's pretty easy.

And as you can see, out of the box, it can get up and running in two minutes. One nice thing about this is-- Darrell's used to me interrupting him, so I'm going to go ahead. One nice thing about this is that when you deploy this, of course, you put in the WebObjects license information. So you can deploy this on a machine that has JBoss and does not have WebObjects.

You know, it doesn't-- it doesn't matter. I mean, if the machine does have WebObjects on it, if you know the deployment machine is going to have both JBoss and WebObjects installed, then you can pick-- one of those options is the legacy war, which just includes the application-specific stuff.

But if you do the standalone, the standalone, it stands alone. It sort of includes all of the WebObjects-ish stuff it needs inside of itself to run, so that you can give it to somebody who's running a J2EE shop and say, run this thing. It's in it. And you say, good things. Run it. Go ahead.

You know, you don't need to go into details, because they're the deployer. You know, they really-- they don't have a right to ask. You've made a working program. They need to deploy it. And that should be the end of it, right? So yeah. See, enterprise people aren't boring. This is good. This is good. I think we need our screens back. Okay, there we go.

I confused the tech people by talking in the demo. They didn't know. Give me a stage. What am I going to do? I'm going to talk. Summary. So summarizing. We've made it so that configuration, you can configure JBoss easily. We've made the tools so that you don't have to edit the XML yourself. I keep saying that, but it is amazingly painful to do if you haven't done it. If you've done it, you're not minding that I'm repeating myself because you know.

We provide the development environment X-Cool, X-Code is a very nice IDE. Yeah, X-Cool, that's the new name, sure. Yeah, yeah, you build and then . You do boom, I noticed, but I think that Steve Jobs, we saw the keynote, right? I think the official sound is now .

I haven't heard that in an app yet, but it's coming, I'm sure. We have to watch our leader. We have to follow our leader. It makes it very easy. Build an application. It's gone. It's done. Xcode templates for just regular Java development. Java, Xcode, we've heard the complaints about Java with Xcode. And they've done the code completion things. That's working. The indexing, finally it's out of the way. It doesn't get in your face as it used to.

And when you need to -- some of the method names in J2EE or in WebObjects is -- they get a little long, and you don't need to type them all. Add relationship to both sides. You don't have to -- you have code completion now, so it's nice. And, of course, as we said, WebObjects is just amazing. So you can deploy -- build and deploy a web build and deploy a WebObjects application in JVOS.

We're running over. We're running over? Oh, no. OK. So for more information-- actually, the second to last is my favorite URL, because-- That's one point of information about JBoss. If you go to Apple and search for JBoss information, it can be a bit scattered. But I've put a very small amount of content in this place, but this place will be there in future.

So hopefully as a pointer to the other places to find information. It can be hard to find whether it's the download for the development tools or whether it's the server documentation or is it the JBoss version of the document. It can be hard to find. So we've centralized it there. And of course, the server documentation is there. All these locations are there.