I found a great resource for people starting out developing Web Services on the WebLogic platform via Jason’s blog. In his blog entry, Jason talks about the two “underground” code repositories maintained by BEA engineers that are not officially sanctioned by BEA’s management. The first link to http://webservice.bea.com/ fails but the second link to Manoj’s page works. Manoj is a BEA engineer and he has created a great site for his Web Services tutorial. If you are new to Web Services in the WebLogic world, you must check out this site. Now why didn’t I know about this site when I was putting together my Web Services class?
Update: (09/03) Ravi – Thanks for the update. It appears that http://webservice.bea.com is working now.
As a recurring feature, I post a list of books that I am currently reading. I am a voracious book collector and (usually) reader as well. With a new baby that’s less than 2 months old, reading time is at a premium and so I’ve built up quite a backlog. Books I am currently reading include:
Some of the non-technical books that I am currently reading (or collecting dust in my new book pile) are:
If you’ve haven’t run into this issue yet, you’ll appreciate this little nugget. I’m not sure if this is a feature or a bug in WebLogic’s deployment infrastructure. I ran into this issue a while back and completely forgot about it, till I ran into it this weekend.
A little background first: Most people that deploy WebLogic in a corporate environment take advantage of the concept of domains, admin and managed servers. A domain is the basic administration unit for WebLogic Server instances and consists of one or more WebLogic Server instances (and their associated resources) that you manage with a single Administration Server. For application deployment mode, WebLogic offers the ability to ‘stage’ your applications on the Administration server, which determines how the deployment files (ear, war, etc) are made available to target servers. WebLogic Server provides three different options for staging files: stage mode, nostage mode, and external_stage mode. I personally prefer and use the stage mode where the admin server first copies the deployment unit source files to the staging directories of target servers. The target (managed) servers then deploy using their local copy of the deployment files using the redeploy feature or via a simple staggered restart. This allows for clean deployment across the cluster and HttpSession replication allows users to failover without taking an outage of the application.
This really works well unless you add another ejb jar or war file to your existing, deployed and targeted application. So I just added a new
customer.war file to my existing ear file and modified the
application.xml to appropriately list the new web module. You would think that deploying the new ear file with the new war file would work as expected, but alas it doesn’t. WebLogic will redeploy the new ear file but not target and deploy the new war file as it wasn’t explicitly deployed using the WebLogic deploy tool or the console. The managed or target servers will have the new code but the new war or ejb jar just won’t be targeted and deployed on that server. Bizarre, right? I think so but I am not sure if this is a bug or a feature. To correctly target and deploy a new module that’s part of an existing and currently targeted/deployed application, you will need to use weblogic.Deployer tool to tell WebLogic about the new addition to the existing ear file. Sample command:
java weblogic.Deployer -adminurl http://admin:8001 -username xxx -password xxx -deploy -targets customer@app_name -name app_name -source ./applications/app_name.ear
More information about weblogic.Deployer is @ http://e-docs.bea.com/wls/docs81/deployment/tools.html#999152
Thanks Brennan for reminding me – I almost forgot about the upcoming Wisconsin Java Users Group meeting on Wednesday, August 25th. The topic for this meeting is Tapestry and Erik Hatcher will give the talk. The goal of this talk is to introduce Tapestry gently through interactive demonstrations. For the uninitiated, Tapestry is an open-source, all-Java framework that offers true event-driven, component-oriented web development. I am planning on attending this meeting as I am trying to learn more about Tapestry.
So what’s new, right? In typical Sun fashion, Sun asked JDocs to pull off the J2SE, J2ME and J2EE API’s from the JDocs site. According to the JDocs.com Update from Rick Ross, Sun claims that its business interests are not served by allowing them to be included in the JDocs site. Ok – I can that Sun would be afraid if JDocs would keep old and out-dated API’s out there but that wouldn’t be the case here. The update continues to state that Sun is adamant that the javadocs for Sun APIs must be accessible solely and exclusively from sun.com – nowhere else. I wonder if Sun is afraid that people would comment on the APIs?
This is just another in a series of many boneheaded moves by Sun. Not the first and won’t be the last. Come on Hani – Ready, Set, Bile!!!
Just got an email from BEA announcing something called BEA dev2dev Live! BEA dev2dev Live! is an online technical event center bringing together live webinars and both downloadable and on-demand training events. BEA dev2dev Live is focused on educating and training developers, architects, and administrators with key tips, tricks, best practices, and in-depth “how-to” sessions from top BEA engineers and customers. Looks pretty interesting at first glance – Another one for the bookmarks.