Skip to main content
1-Visitor
October 18, 2010
Question

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

  • October 18, 2010
  • 18 replies
  • 4324 views

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?

18 replies

1-Visitor
January 3, 2012
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
12-Amethyst
January 3, 2012
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?

1-Visitor
January 3, 2012

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?

12-Amethyst
January 3, 2012
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...

1-Visitor
January 3, 2012

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
12-Amethyst
January 4, 2012
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

1-Visitor
January 4, 2012

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.

12-Amethyst
January 4, 2012
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.