Best practice deployment for custom Java - to JAR or not to JAR?

[MartyRoss]

What are some best practices for packaging and deploying custom Java into a Windchill environment?

I am used todeveloping packaged groupings of java code for deployment as JAR files, so I'm surprised to see pretty much everything "exploded" into one giant "codebase" directory in Windchill.

Should my deployment strategy for custom Windchill code avoid the use of JAR files for deployment, and if so, what is the reasoning?

[tbusch]

We've always done everything as JARs as well, but one advantage of deploying exploded is that it makes it much simpler for you to override in-built classes, if you plan on doing that.

That said, I've been struggling with the same question, so I'm interested in this discussion 🙂

-Thomas R. Busch
Sr. Software Developer
Stryker Instruments
(269) 323-7700 x4014
tom.busch@stryker.com<">mailto:tom.busch@stryker.com>

[jessh]

Overall I'd recommend sticking everything in jars /except/ where you
want the classes (etc) to be accessible to remote Java clients (i.e.
applets and Java Web Start applications). In this case you can /still
/have everything as jars if you want to have these clients reference
(and thus download as needed) entire jars from the set of jars you're
adding -- in which case you can just put these jars in codebase/lib (and
produce .pack.gz files from these whenever you change these files --
which you can do yourself or via MakeJar.xml's pack200Libs target). If
you find yourself only wanting to deliver part of a jar to a client, you
can refactor the jars you're producing either into smaller, more
targeted jars or with some classes being compiled into codebase.

One of the big reasons for there being so many loose files in codebase
is that there many files have been there for a long time /in case/ they
were needed by a remote Java client. MakeJar.xml is used to produce
client jars from selected sets of these files in codebase -- where the
set is based on testing of what is actually used by remote clients. The
testing is not necessary totally comprehensive nor does it cover custom
clients, so the other files remain in codebase "in case". Some new
Windchill modules produce jars in codebase/lib specifically targeted for
client usage. Most new Windchill modules, however, are created as jars
without placing any files in codebase or placing any jars in
codebase/lib -- effectively asserting that these modules consist of code
that should not be visible to remote clients.

[ddemay]

I ALWAYS build into and then deploy as a jar and explode it on the server using the unjar and copy tasks in Apache ANT which is already in Windchill and is like UNIX makefiles on steroids. I have even written commands to sense what is deployed and run the correct command say ResourceBuild or LoadFromFile.

PTC is currently developing their BIF deployment suite available thru solution center in Uniontown, PA. It's okay for most folk, but personally wouldn't pay extra for something like it. Most of it is open source code and PTC documented command line binaries.

On a side note depending on your classpath configuration in MethodServers, you can override OOTB class files simply by placing your jar file in classpath or codebase before the original file is found. First come, first serve. I recently had to do this to override OOTB code in jar files located in WTHome/srclib and WTHome/codebase/WEB-INF/lib/ that were using com.ptc.xxx.xxx etc. But were inside PTC jar files.

Dave


Sent from my Verizon Wireless BlackBerry

[ddemay]

Sorry should also have added you don't want to get in ugly habit of deleting and updating jars for one small code change.

It is much better to unjar on server, and use Subversion, MKS, ClearCase, or Visual SourceSafe to tag/basline/freeze your code deployments to handle historical or reverting should some mistake or bug get reported.

wtCustom and wtSafeArea are good to compare to OOTB file versions but are poor for the above processes.

Dave

Sent from my Verizon Wireless BlackBerry

[ddemay]

I agree with you Jess, but only for files or UI changes impacting java applets.

Dave

Sent from my Verizon Wireless BlackBerry

[dtkach1]

What about the front end (java scripts, css, html, etc files) that was
developed on GWT (Google Web Toolkit - used to develop data analysis
tools, reports, etc against Windchill)? What will be the right approach
to deploy it on Windchill server?

Thanks,
Dmitry

[PreetiGupta]

We usually have one or two java file updates. We manage all source files(Java, JSP, xmls, rbinfo, OIRs etc) in Serena Version Manager.

We drop in the class files in production. We maintain wtsafearea and wtcustom for rest of the files also on Windchill Server.

[MartyRoss]

In Reply to Dave DeMay:

I ALWAYS build into and then deploy as a jar and explode it on the server using the unjar and copy tasks in Apache ANT which is already in Windchill and is like UNIX makefiles on steroids.

Can you tell me more about "Copy Tasks"? I have been looking for an Ant task that will install tasks and register them for SOAP

[ddemay]

Marty, here is the documentation.you want to register Info*Engine "tasks"
via a command line, you can use the SSH and/or exec ANT tasks to accomplish
this. ANT tasks are not the same as Info*Engine tasks, just to be clear.

[JeffStevenson]

Sorry to be late on this, but I'm having trouble with this same issue. I'm trying to execute my jar from a JSP under codebase/com/mycompany. I put my jar into codebase/lib, but I still cannot get the jar to execute. What is the relative path to a jar living in codebase/lib from a JSP in codebase/com?

[ddemay]

Put it under codebase/WEB-INF/lib/ and then open your jar up to see the file and what the class file is invoked. From your JSP, you can invoke that class and call its static main method in jsp like:

<% Package.Classname.main(String[]);
%>

Jar file being on classpath of Windchill and Tomcat should help.


Sent from my Verizon Wireless BlackBerry

[jessh]

Well the underlying question is really what you're trying to invoke where?

Do you want to run some Java on the server? Or on the client?

[JeffStevenson]

My jar is executing a rather lengthy export function using Info Engine so I'd prefer for it to execute on the server.

In Reply to Jess Holle:

Well the underlying question is really what you're trying to invoke where?

Do you want to run some Java on the server? Or on the client?

[jessh]

Then just call the appropriate API from the jar, whether that's
SomeClass.main(args) or whatever.

Of course you'll presumably have results of your export to do something
useful with. Also if it's so lengthy you really don't want to just do
this in the request thread in question, but rather throw this into a
queue for background processing...

[ddemay]

I wanted to answer your earlier question for the heck of it. That being said removing code from the jar and placing in codebase is a much better idea.

JSP is not best approach if report is really big and takes a long time to execute.




Sent from my Verizon Wireless BlackBerry

[jessh]

There's nothing wrong with packaging things up in a jar.

The bigger question is one of what the code is going to do -- not packaging.

If your SomeClass.main(String[]) takes a bunch of command line options
and runs for 30 minutes spewing various files to the file system and
outputting things to stdout/err, then you don't want to just call it "as
is" from an HTTP(S) request handling thread (servlet or JSP, makes no
difference) as there are numerous clear issues with such an approach.

If the class is written in such a way that it can run from a client and
doesn't chatter excessively with the server, then it may be fine to
simply run such a jar on the client with few if any changes, though.

--
Jess Holle

[JeffStevenson]

I'm not sure how long the process will take on the server, within Tomcat or not. I'd like to get it running so I can benchmark it. I know that it takes longer than I'd like running off the client. But then, I'm trying to run from within Arbortext Editor and over a VPN connection. That creates more overhead. When I just run the jar outside of Editor, it's not as bad, but I still think the process would be better executed serverside in any capacity.

I could just run it on the server, but I'd like to use JSP so the user has a familiar interface to start the process.

My process really has no other tie to Windchill other than trying to utilize the tomcat install as a front-end. Would it be better or is it possible to deploy war files on the tomcat installation within Windchill? I'm wondering if it wouldn't be easier to build a seprate servlet that just executes the jar, thereby not involving Windchill at all.

[jessh]

This isn't a Windchill problem really.

This is a basic web app / UI problem.

Calling Windchill APIs (or code that calls Windchill APIs) from within a
JSP or servlet within the Windchill web app is trivial.

Figuring out how you're going to manage a potentially long running task,
manage any resulting files, provide results back to the user, and so on
-- those are the real issues here, not packaging.

You could *make* this a Windchill problem, e.g. by putting the job on a
background queue and having that job create a Windchill document
containing a compressed archive of the results of the job and sending
the user a notification upon completion, but the basic gist of the
problems you face here aren't Windchill-specific in any way.