I'd like to introduce Melissa Turner and her lovely assistant Jesus Ahuactzin. They're going to talk about J2EE made easier. Everything about deploying J2EE applications on Mac OS X Server including WebObjects applications. Thanks Francois. So at this point I was supposed to make a joke, but Francois sort of beat me to the punch about how after four years of working with Jesus for this presentation, I finally actually learned something. I've learned how to pronounce his last name. Four years. I'm obviously an engineer.

I'm here today to talk about deploying enterprise applications on Mac OS X, not surprisingly. I'm going to give you in this session an introduction to J2EE and JBoss. I'm going to discuss deploying J2EE applications, managing J2EE applications once you've got them deployed, and I'm going to talk a little bit about deploying WebObjects applications in JBoss.

What I'm hoping you'll take away from this presentation is for those of you who don't already know what J2EE is, sort of the 30,000 foot overview of what J2EE is, a bit of an idea about the JBoss and JBoss architecture, some idea of how we've integrated JBoss with Mac OS X, how to deploy a J2EE application on Mac OS X and how to manage it.

J2EE, what is J2EE? A lot of you have probably heard this particular acronym by now. It's been around for several years. being heckled from down here. What is it? It's a platform for building multi-tier applications. It's standardized modular components and basically it uses... Could whoever is talking please stop? It's very distracting. Someone down here.

Is it behind me? Sorry about that. Basically the way J2EE works is you have a container that provides services that can be used by multiple applications because there's a lot of things you don't really need to hard code in every single application you want to use. Say, for example, you want to talk to a database or you want to send or receive e-mails. That's not the kind of thing you should need to reimplement every time you want to write an application. So you can offload that work onto the container.

J2EE's in charge is a set of interfaces and standards for taking that kind of work off the application developer's hands and moving it into the container. Why do you care about J2EE? Well, it's one of the best ways to, well, we think it's one of the better ways, to implement enterprise applications so that it isolates you from a lot of the work. I just gave you an example of how to do that.

And it also, you know, insulates you to a certain degree from your vendors. I know one of the big problems with buying or developing an enterprise application is platform lock-in. You decide to go with one specific vendor and you're stuck with that vendor forever. J2EE is an attempt at breaking that and letting you build your enterprise application and deploy it to any one of a number of containers developed by any one of a number of vendors. You don't have to worry so much about your vendor suddenly jacking up licensing prices. We don't know any vendors that do that, do we? Some of the technologies in the J2EE area you've probably heard of.

We have EJB, JSP, and Servlets. Those are the big ones. EJB is your database or your business logic. JSP and Servlet puts a web front end on it. Some of the other technologies you'll hear about - JDBC, JNDI, JMS. There's more up there. Forward looking, there's stuff like Web Services, Jack, Sage, a whole bunch of other stuff. This is mostly slides so those of you who aren't familiar with these technologies can scribble down all the acronyms and go Google for them later.

Sorry about that. We don't usually do this on stage. You plug in EJB, JDBC, anything you need. As your applications grow, as you've got new responsibilities, new needs, you plug in more pieces. If you decide you don't need some of them, it's just as easy to take those pieces back out.

What else do we know about JBoss? Well, as I said, they're an open source container. That means it's primarily written by developers. Developers are really good at writing code, especially for stuff they need, but most of the people who do this are, well, really happy with Emacs, which means they've got really lousy deployment and management tools.

Most of these people work, like I said, in Emacs, don't see anything wrong with keeping track of 20 or 30 XML files in Emacs. We thought there was a better way to do that, which brings us to JBoss on Mac OS X. JBoss is going to be part of Mac OS X. We're going to be shipping some developer tools, deployment on Mac OS X Server, and we've integrated it with some of our other tools.

on the client, it's going to be part of the developer tools package. You'll get a JBoss developer configuration, which is JBoss set up with all the services that a developer is likely to need to program against. And we're going to give you some Xcode templates for building J2EE applications, EARs, WARs, JAR files, that kind of thing. For those of you who've already been, and I'm assuming this is most of you at this point, poking around on the disks we gave you on Monday, it's shipped in the sneak peeks area of the developer preview CD.

On Mac OS X server it should be part of the default install. We're going to use it as a replacement for Tomcat. I'll get around to talking about that a little bit later. You'll get JBoss. We'll ship you multiple configurations because we realize that one configuration is not going to suit everybody's needs.

Get a management tool and a deployment tool, which Jesus will be showing you later. And we've integrated with server admin. So those of you who know, were at my presentation last year and part of the WebObjects group. And we've traditionally not been terribly well integrated. So with our JBoss product we're trying to integrate into the Mac OS X general tools a little bit more.

And for those of you who heard me say that we're providing JBoss as a replacement for Tomcat and panicked because they were using JBoss before, nothing important has changed. The biggest change you'll see is that instead of enabling Tomcat from the web page, you now enable it from the application server page. Runs on the same port. It's still in library Tomcat. And if you want, you can still go in and configure it to run standalone.

A couple of things have changed that we think are kind of impressive. We're going to be running a newer version, shipping a newer version, since we know many, many, many of you have been asking for a newer version. And when you're running the JBoss Tomcat configuration, you'll be able to use our tools to manage and configure it. Instead of just having an on/off checkbox, you'll have a little bit more control.

The other configurations we'll be shipping are standalone, which is the basic small site configuration. Tomcat Web Server has EJB containers, JNDI, a few other things. Corba Orb is in there, if I remember correctly. And it supports hot deployment of applications. All you need to do is copy your J2EE application into library, Jboss 3.2 deploy and if Jboss is running it'll look there every few seconds, find that there's a copy or a new copy if you upgrade, undeploy if necessary, redeploy that new application without you having to intervene. We're shipping also a clustered configuration.

Clustered configuration is almost identical to standalone configuration except that, well, it's cluster. Supports HTTP session failover for Tomcat, supports load balancing and it supports automatically propagating changes to applications or services to all nodes in the cluster. Means that you don't have to worry about upgrading all of the nodes if you're upgrading applications. You just drop it in one and it will be propagated out to the rest of the nodes in the cluster.

We're also shipping a Netboot client configuration. This is sort of the, "Wow, we want to build a computing grid" configuration. You can centralize your configuration on one server and tell all of your JBoss instances to start and download their configuration from that central point. It gives you one location to manage.

I've got Netboot Server here as a configuration. It's not really a configuration, but this seemed a good place to talk about it. A Netboot server is simply any WebDAV enabled web server. For example, Apache with WebDAV turned on on Mac OS X. It's pretty simple to set up. All you have to do is copy the configuration that you want distributed to all your Netboot clients into the Apache document route. Tell all the network clients where to go to download their configuration and it happens. And at this point I'm going to hand you off to Jesus who's going to talk a bit about the application lifecycle for J2EE applications in JBoss.

Hi everybody, my name is Jesus Ahuactzin. I learned also to pronounce my last name today. I'm here to talk to you about, before I go into the deployment tool, I want to tell you how all this fits. J2 applications are laid out in such a way that The application lifecycle can be taken care of by different people and with different skills. Also, each one of these stages can be handled by different tools so that people in charge of each one of these stages can do its job.

So here is the application lifecycle. The first thing is that you've got a developer. The developer is going to be in charge of developing your application or your modules. So once you have your developer creating all these modules, they will pass it to the assembler. The assembler guy is in charge of collecting all the parts and pieces of your application. Because you could have somebody, some developer, working very hard in your servlets and other working in your EJBs. And then you have somebody who's collecting all these modules and integrating them in one application. He will actually create one unit.

This unit is actually a jar. And it has a special extension called "ear". So now here you have the assembler. Depending on your organization, it could be the same guy. So the developer is actually the assembler who is getting you the ear. And now that you have your ear, you're going to pass it to the deployer. The deployer is in charge of mapping the resources that your application is going to need to those who are in your application server.

So he maps everything and now he goes and deploys it. So you just dump it on your application server and now his administrator has to go and look that everything that your application is going to use is there and also is going to monitor that your application's vital signs are strong and well. And then again, if something goes wrong, they're probably going to call the developer and they have to fix the things and then you see this circle.

So in each one of these stages, we wanted to do something for you to create your J2EE applications. Yesterday, we have an entire presentation talking about what we did for the development and assembling part. Today, I'm just going to go to do a brief recap of what we did. So from Xcode, what we provide is three new templates.

We create -- we add a Web module template, an EJB module template, and an enterprise application template. So you can, in fact, create those modules, as I said, and then wrap them -- everything up in one application. We're using to build this Ant. Ant is becoming the factory standard for creating Java applications, so we wanted to leverage that.

And not only that, it allows us to use other technologies that are out there, like XDocklet, that could create or generate a web application. So we have a lot of different tools that could create or generate the interfaces that your application needs and also the deployment descriptors. So for the assembling part, well, we are -- it happens in the build phase and is using XDocklet.

Again, XDocklet is an open source tool that -- what it allows you is that you hint in your source code which information is going to be in your interfaces and your deployment descriptors. If you hint in your code, you have some experience with J2E, you know that sometimes you spend a lot of time not on your code but creating tons of files about the interfaces that you need and tons of files -- and tons of deployment descriptors. So the idea is that we provide a way for you to write the code, hint the deployment -- hint the XDocklet engine, and so the XDocklet engine could go and create those files for you.

So we have a way -- the benefits that you get is that we have a central platform. We have a central platform that we can use to create the XDocklet engine. So we have a way -- the benefits that you get is that we have a central platform that we can use to create the XDocklet engine. So we have a way -- the benefits that you get is that we have a central place where you can synchronize your deployment descriptors and your source code and also synchronize all those deployment descriptors. So now we have the developer part and the assembly part.

Here is just an example of xDocklet. As you can see, xDocklet is just an extension of JavaDock and what we are telling is just some hints about, for example, this is going to be a session state lesbian and then we just run your application. As a result, we create deployment descriptors for you and also we create all the interfaces.

So now we're done with the assembly part and it's time to talk about the deployment part. So the first you might ask is why are we interested in creating such a tool? Well, you know, J2EE applications have this characteristic that allow you to change the behavior of your application at deployment time.

The idea is that each application will have a set of deployment descriptors that are in your application. If you change those deployment descriptors, you might change your application behavior in different circumstances. So a deployment descriptor actually is a way, a declarative way to figure out which services the container will impose on your bins.

So you can tell, for example, to tell your container to use a specific data source when your application is running on testing. And then when you want to deploy it on production to tell you to use a completely different one. And you do this by changing this information not in the application itself but rather by tweaking the deployment descriptors. So, so far so cool, right? This is really great.

Well, if you think of all the information that you have that you can manage in this fashion, you soon realize that this is becomes not a problem. You can actually manage this in a very simple way. So, you can actually manage this in a very simple way. So, you can actually manage this in a very simple way. So, you can actually manage this in a very simple way. So, you can actually manage this in a very simple way. So, you can actually manage this in a very simple way. So, you can actually manage this in a very a trivial task.

Only one has to go and look at all the deployment descriptors and all the interrelationships between those Even for the simplest application to realize that just using IMAX is not going to get us anywhere. So a tool with a friendly UI becomes necessary. We decided to create one.

When we were sitting down saying, well, which technology should we use to create this tool? Well, you know, in one side we have all these schemas and DTDs that we're modeling, the deployment descriptors, and in the other hand we wanted to create an HTML-based application. But we didn't want to spend a lot of time just constructing HTML pages with text fields that would actually update the information in the XML files. So we say, well, why don't we just go with the only capable of doing that? So we decided to do a WebObjects application using direct to web.

So not only that, we leverage some of the technology that's out there. Essentially, specifically we use Java XML bindings. And this layer, what it allows us is to marshal and unmarshal information from the XML files into the objects. On the top of that layer that is provided by Jaxby, we added an EOF layer. And over the top of that EOF layer, we use our direct to web components and our rules and our web components. And that's how we created our tool.

But you know, we didn't just want to create a fancy XML editor. We wanted to provide some value added to our tool. We think that one of the things that are important for the deployer is to get some info, to actually get the information that sometimes leaves in the application container.

So we didn't want to go to the application server and get that information. We wanted to provide a way for the user to have it just there. So we opened a channel, a communication channel between the application and the application server, and we pulled that information that we think is important for the player to know at deployment time.

Not only that, we also do some cross-linking. The idea is that all these deployment descriptors that you can have, have reference within one another. And we wanted to organize and present it so you didn't have to find out, well, this information actually lives in here or it should actually be there. We try to hide you from that and organize the information so you have just to change in one place. And finally, we do some verification.

The verification is not only us going and trying to apply the constraints that the schemas and DTDs are imposing on those files. We ask our J2EE expert and find out that there are some validations that are unnecessary, that are not part of the deployment descriptors, that are convenient for you to look. And instead of going and then realizing later that you have a problem, you can... You can fix the problem when you are deploying your application. So why don't you just stop talking about the deployment tool and show you how it works.

So the first thing I want to do is load my application and what I have here is an expat store here. The expat store here actually was built yesterday on the presentation of the J2EE presentation we had yesterday. I tweaked it so it works for the purpose of this demo.

So what we're doing is we load our application and what we are doing first is we're trying to do that verification I told you. We try to do some validation and if we find that there are missing data in your ear, we try to flag it so you know up front that you have some problems that you have to fix before you deploy it. So let me just give a brief tour of the navigation bar that I have here. In the top I have some actions that are self-explanatory and I will go a little bit more in detail on what CONNECT is and why it's there.

Then in the bottom side what we have is more or less the structure that you will find in your ear. In this case what you see is that we have three branches and each one is representing a WAR file in your ear or a JAR file in the case for EJBs. So the idea is, so for example in here I will have a deployment descriptor that corresponds to the entire ear.

The deployment descriptor in the ear is the easiest one. And the idea is, well, it just tells you what information is inside of your ear. As you can see, we are just describing which modules are in your ear. And they are the same that we are describing that are in the navigation bar.

But I wanted to bring this here because I wanted to show you this stuff, the JBoss stuff. So what we are doing right now is we're trying to provide, JBoss also needs some information related to your application that sometimes is necessary and sometimes it is not. In this case, we don't need it.

But what I wanted to bring up is that we tried to put the information that you need in one spot. We didn't want to go and click another place to find out, well, if I want to configure the JBoss specific files. We wanted to provide it just there. there.

In here what you have is the deployment descriptor for your web app. If you're familiar with serverless, you know that this file is the file web.xml that lives inside the webinf directory. So you can change information here. You will have -- you see that you can have information about the serverless mappings or filters. And the idea is that you can change this information or if you just want to look how it looks, well, it's there.

Now, you see that I also have a servlet section. And the idea is that if you have seen a web.xml file is that in each, in this file, you will have sections where you are describing also your servlets. We didn't want to put all that information in the top, but rather present it as servlets in a different link.

So if you wanted to modify some information related to one specific servlet, you could do it by just clicking, do one click. So here it is. Here is the servlet information. There are initial parameters, when you can, how, if you want to load it on the startup, etc. There are some security issues, some security features that you might want or not modify.

But the most interesting part comes in the EJBs. And why is this more interesting? Well, because you can at least have three files to configure this. You can have the EJB.xml file, you can have the JBoss.xml file, and for your CMPs you can have the JBoss.xml file. Those files are going to be interrelated and there will be information, again, in the top level and there will be information that you can have in sections for each one of your bins.

And so let me just show you what I have here in the top level. And so something that is interesting and convenient for you is that if you set some defaults in the higher level of your archive, that information can be used as default for each one of your individual bins. This is pretty convenient because, for example, if I want to go to the CMP default settings, you see that I have the data source and data source mapping in here.

And the idea is that if I go to one of my entity bins, order item is one of those, and I go to CMP database mapping, you see that the data source is choosing the default setting and there is no data source mapping. I'm saying that I need both, but I'm not setting it and I'm not putting it in red because I know that you have a valid default. and the Archive level. So what this allows you is to make changes at the higher level and then forget about making changes in the individual bins. And that's really convenient.

So, if we go to account, what I want to do is, now that you see we have account, we have this thing is the one who is having some problems. And I know it has some problems because I went to the file and delete the table name of the entity bean and also the column names for the attributes of the entity bean.

What I want to do now is if I go here and I go try to do CMPBase database mapping, you see that you have a data source that is not being set and where this information is coming? Well, if you actually see here, we can connect to the application server and when we connect, we are already connected but I unfortunately lose the other guy. That's bad. So let me just bring it back. Sorry for that. that.

Okay, so let me just go back to account and then go to the CMP-based data mapping. And see, so if you remember we have popups here and now we don't have them. And the idea is, well, if I want to make now these changes I have to remember that information. And so that's when I say that we added this functionality so we could connect to the server and, well, now it didn't close. That's pretty cool. So we connect to the server. And if we go back to that bin.

and go to see the CMP database mapping. We see that now we have the popups. And essentially what we are saying is we are becoming a J2EE Java client. Our WebObjects becomes a J2EE client. And ask the server, where are your data sources? And so he introspects in itself which data sources he has. And he sent us, well, here's the data source you can have. And then I can choose the hypersonic, I guess, SQL database that is in JBoss.

And then, as you can see, I'm also introspecting which are the tables that are associated to this data source. So instead of me remembering which table should I put here, I can just go and select it. Then if we go to this guy, We are going to see that we have user ID, we can select it. Now we have introspected the table and see which columns you have and then we can update. And then go to the other guy.

And here we can choose password. And before I'm done, you see that we have a warning here. It says that the original choice bar card is not available on the JBoss server. So what happens is that we went to the ear and we find out that the choice that you have in your ear doesn't really match to anything that JBoss can have.

So what we -- and essentially the problem is that JBoss wants to provide a fully qualified type. And what we did is we put just the bar card thing. So I know that it's going to run, that it's not going to be a problem. But what I'm trying to tell you is that we try to find out where you say, well, this is not actually qualifies as an error. But, you know, you might look at it because if -- what you don't want to do is like, well, I just ignore whatever you tell me.

It's fine. I just deploy it. And then when you -- and then you have your application is crashing and then you have to go to the bulk cycles to find out that, oh, what happens is that JBoss is not supporting the bar card. I have to provide the full qualified type. So the idea is that we warn you before you go into deploying your application. So we So we update here and then we finally update here.

Okay, and so now that we changed that information, we click on validation application. As you can see, we went through the rules, find out that this is a valid ear, and now we should be able to just simply save our ear. Let's see if I have it here.

So what I'm going to do is going to save it in the deploy directory of the ExpatStore configuration. And if everything is fine, Okay, so it was saved now. So now JBoss will look in periodically pools and look that if there is some new year, if it is one year there, it will try to load it and launch it.

So let me just... I want to show you that you can see what is happening on JBoss. So here I want to go to the logs and then do... Okay, so this is the log that JBoss is spewing in and at some moment we hopefully will see that JBoss is speaking that year and is actually deploying it.

So we have to wait a second or two or three or four

It don't deploy other stuff, but it should spew some information and at the end should say, "I deployed this thing." So, I don't know if you guys can... Let me just bring... Okay, so I think I have a problem with the network and maybe I'm not able to show you this. Okay, so it's not picking it up.

Well, I would love to show you the expert story that's been deployed and it in fact, it will, that's the way you do your deployment. Unfortunately, I won't be able to show you. I don't know why it's not picking it up. But, so let's suppose that you see a big, Green Parrot here and that is the demo. Sorry for that.

But it's not picking it up. It's JBoss not picking up the ear. Okay, so sorry for that. I promise that when you do this, it won't happen. With that, I leave Melissa to... So obviously we're doing a presentation because, you know, it's not a presentation unless at least one demo decides to go haywire.

Because that was our deployment tool, that is, we think, by and large, the thing you're going to appreciate most about our offering. The UI is going to get cleaned up a little bit, we're still working on it, but it should make deploying J2EE applications a lot easier. But once you've got your application deployed, you have to manage it. Our management tools come in two components. We've basically given you two parts.

We've done a plug-in for server admin, and we have a web-based management and configuration tool. What these two together allow you to do is manage your JBoss configurations. You can start and stop the server. You can start and stop individual services. You can view and configure those services.

That last one sounds a little bit strange, but-- There's reasons for configuring the services themselves. You may want to add new JMS topics and queues. You may decide that you need to increase the number, the size of a connection pool for your CMP stuff, reasons like that. So you need to be able to configure your container as well. And in the JBoss world, that's configuring the services.

And at this point, Jesus is going to give you another demo. This time he's going to walk through the management tool. JESSE HEIMERL: So hopefully this-- we won't have problems here. I won't promise you that. So we have the server admin. So now you can -- what you can do is you have your application server as part of your server admin. It's part of the services that are vended for Mac OS X Server. So you can see that the application server is listed as any other service like FTP or open directory.

And So you can select it and you can stop the service or start the service as you wish. So if you click in there, we have the first page as well. It's just a status page telling you if the application is running or not, what type of configuration it has, the version of the application server, et cetera. Most interesting information you will find in the server section. There are two logs that I want to talk to you about. The first one is the boot log. This is important because this is information that's going to be recorded by JBoss when it starts the first time.

So if you're having problems with JBoss, not launching applications or something like that, you might want to go to here and see if there is a problem. So it's a good place to start doing some diagnostic. And then the other one is server log. Here in server log, you can find all the information that the server at runtime is recording. Some of the information is important as like the life cycle of the application.

So when it gets deployed or undeployed, the information is going to be recorded here. But also if your application is misbehaving, you will have like runtime exceptions. Those problems are going to be logged here. So then again, it's a way -- a good place for you to start looking for problems.

Finally, we have the settings part. And the settings part, what we have, you can choose your configuration. Melissa already told you that you can have a remote configuration or a Tomcat only configuration. In this case, I'm using a local configuration and it's a special one. I create one called expet store. So and you have a button.

The button essentially what it does is that it brings the management tool. Observe that I'm going through HTTP. So your username and password or configuration are not going in clear text through the wire. Here something interesting as well. What you first might ask is why we are using an authentication face here. Well, we have two roles. You can have an administrator role and essentially he's allowed to change the configuration information in the application server. And he can monitor your applications.

And we have a user model. So you can see that he's able to see the code where it's just the monitoring part that he can see. So you can tell which users can modify configurations. Now look that I am typing root and I'm using -- the user root that I'm putting here is actually the root guy for this system. So what I'm trying to say is that we are interfacing with directory services. So we don't provide a funky little administration capability in this tool for your users and passwords. We are leveraging all that structure to the directory services.

So if you already have your services and they already are assigned if they belong to wheel or whatever and they are in that info servers or servers, I don't care. We will reuse that information. So I'm going to log in and if I remember the password, then it will be just very cool.

Okay, so you have three possibilities of choosing here. The first two will only be seen by the administrator and also the third one, but for the users that only care about the applications state, you will see only the last row. So I'm going to choose the expert store configuration and show you a little bit about it. So what you see is we see all the services.

is not showing them. Very good. Let me see if I can see just the deploy standalone configuration.

There you go. So in here what we're seeing is the services. All the services that your application server is offering. And so you can select one of this and then look at the information, like for example I'm seeing right now the mail service. And then you can actually go and change that information. This information is going to be actually saving the application server. So you don't have to go through your application server, look which is the proper XML file to modify it.

You can modify it there. You can do it in here. We also have other services like Tomcat that is interesting. We're using Tomcat. So you can see we have Catalina. And so you have all the attributes. You can change the attributes of your Tomcat server from here. And other stuff that you can do is we were using a data for the first demo I did for deployment tool. We were using a data for the first demo I did for deployment tool. So you can create a data source, a expert store data source. Well you can create that data source.

I already have it. But you actually create that data source from here. You click in here. You provide information. And we add that data source. That data source could point to another database like Oracle. We were using hypersonic SQL. But you can do all that management work from here. And that would be our demo for the management tool.

That would sort of be the management tool. As we said, it's web-based because we know a lot of people want to manage their configurations remotely. Hey, you have a Blackberry running over Bluetooth? Theoretically, you could manage if you could actually get the bandwidth. As we said, it's secure. We use SSL and Open Directory.

What can we say? Security is a big thing for a lot of people. We didn't want to have -- because we were plugging in with the open directory stuff, we didn't want to have your passwords floating around clear text, so we actually wrote an adapter for the WebObjects application to talk SSL.

I've had at least one question about that from people, so I'm the person you want to talk to. I'm the one who did that. And it allows you to view and configure deployed services and start and stop services. It also does a few other things. It lets you deploy applications and monitor deployed applications because, well, this is a large part of what management tools are supposed to let you do. Jesus is going to talk again.

Okay, so let's -- so from here I can change the configuration I'm looking at, but in this case I'm not modifying the configuration. Essentially what it does is takes me to the first page, and now I can actually monitor my applications running. So we're not running? That would explain why your deployment wasn't taking.

So which server? Can we know which port we are running? Try stop and start it. So here is, you can stop the application server and you can start it. And just one button. Isn't that great? Check the log. And if you're having problems trying to start it up, you can have, you know, so here.

There we go. Okay. So let me see if I can monitor. Select new configuration. and David Koehn. I feel like those are not related. Okay. So apparently JBoss has decided to drive us nuts. - Wait, you should go into the manage thing. - To the-- - Top one. - Okay, so we'll fake it. Scoot. Told him to scoot.

Okay, so now, well, actually, given that we're running out of time, that's not such a bad thing. But what you would see if you were seeing this is Jesus would go into the same page where he was showing the logout and change configuration pages. He would be able to click on the deploy application button. A sheet would come down and let him pick which application he wanted to deploy.

He'd hit deploy application. And the application would be uploaded through the management tool, pushed out to the JBoss configuration, written into the deploy directory. And from there, everything would be as per normal, as everything would happen exactly the way it would if you had copied a file into that directory.

And now comes the brief WebObjects and J2EE section of this. You can now deploy WebObjects applications in JBoss. We're providing support for building .wars in the WebObjects world from Xcode. And those of you who've worked with previous versions of our product probably know that you could, in 5.2, create a .wo directory that could also be used as a .war and deployed as an exploded directory.

For the next release, we're hoping to provide the ability to deploy as a single-file archive, which means we've had to do some reworking of the NSBundle loading stuff. And for those of you who didn't actually believe us when we said in 5.1 that we were deprecating some of the NSBundle and NSResourceManager APIs, we've done it. If you try and run a bundle or run an application which is bundled as an archive and you're using those APIs, things are going to go drastically wrong. We told you so.

We also have the ability to package our frameworks as JAR archives so that you can then embed them inside other archives. You can load them that way. And we're providing support for JNDI properties. What this means is that, as many of you know, if you run inside a container, system properties becomes a pretty vague and nebulous thing.

So we have support for using JNDI as a properties lookup mechanism. If we find things in JNDI properties or if we find properties files set up there, we won't actually try and access system resources. So it gives you two places to look, two ways to configure your application. I think we've also added a few extra properties just for containers, but I don't remember what they are.

At this point, Jesus is sort of going to show you that we actually can and have done this. This is easy because we don't actually have to use the tools. This is all from the command line. But we need gate balls anyway, so... Well, not really. We can show them that hello-world.org is actually a WebObjects application. Interesting. So we can do that internally. Okay.

Let's try to deploy it. And if JBoss is willing, we'll see our hello-world application. It's a WebObjects application in a single deployment directory form. We'll see it run. So what I'm going to do is just take the hello-world.org. And the only thing I should do is just go and copy it over to the deploy directory of JBoss. In the same fashion as the expat store should, in some moments, pick it up, and I should be able to show you from the web browser. We can give it a shot anyway. I can try.

So now it's like a nice time to do those pullings about how many do you think this thing is going to work. Show of hands, how many of you think this one's going to work? There they are. Oh, we have optimism. We have believers. Good. You like us.

Okay, so let's see. Hello world. No, we have a problem. We didn't have network. Oh. Yeah, this is-- It's-- well, we had problems earlier, so we had to take this host off the network. And it looks like we may have quite thoroughly confused its networking capabilities. Apparently, it's not capable of believing that it's not on a network, but it should still allow the loopback address to work. So who could have known? You know, it's a presentation. They gave us the machines 15 minutes beforehand. That's why we started late. Sorry.

So anyway, so what we've shown you, or at least we've told you if not shown you, is that you can develop J2EE applications on Mac OS X client. You can deploy them on Mac OS X Server in JBoss. We have the best tools out there for JBoss, and they'll get better, we promise.

We've got an assembly tool that will make your life a lot easier. I know you might have looked at it and thought that looks awfully complicated. Trust me. Trust Stefan, who's sitting over there in the audience. Things cannot get worse than Emacs and XML files. And you can deploy WebObjects in JBoss, and I know that's something that a lot of you have been asking for. So at this point, for more information, go to the website, jboss.com/jboss.

This is mostly for the DVDs later, but these are the people you can contact if you've got questions about this presentation. Here's the reference library. Places to go, things to read. This is a little bit more interesting for us, I think. This is the open source projects that we're attached with or that we're using that you might want to go have a look at.

We've got the sourceforge.net project for JBoss. There are actually two separate organizations. There's JBoss.org, which is a commercial arm group that does development of JBoss and sells consulting services for it. And then there's the open source project itself. That's where you'd find Tomcat at Apache and that's where you'd find the Ant and X Docklet stuff.