ptc_note

Assuming that the command was executed from the Windows C:\ptc\Windchill\bin directory,
xconfmanager -d wt.home
xconfmanager  --help
The Java executable. Default is the wt.java.cmd
variable value specified in the $WT_HOME/
codebase/wt.propertiesfile.

The Windchill Client Architecture is Model-View-Controller based. There are two
MVC based paths available for use, a Java Builder based approach and a JSP based
approach.
Java Builder based
This approach is new for this release and is the recommended way of
implementing tables, trees, information pages, and panels of attributes. When
implementing one of these components, the configuration of the component is
specified in a ComponentConfigBuilder (java file) and the data acquisition is
specified in a ComponentDataBuilder (java file).
JSP and Tags based
This approach was used in previous releases and should only be used for
implementing wizards (create/edit) and property panels.

NmAction represents a line from actions.xml which describes a page in
Windchill. It is rendered as all the icons and links that one can click to make
changes to the Windchill system. Each jsp page should be described by an
NmAction in an xml file. The localized attributes of the NmAction can be found
in the action.properties or other rbInfo files.

NmContext represents a UI address of a page. (Note that this is becoming
obsolete and should be deprecated in the next release.)

Wizard.js functions
goBack Make the wizard go back one step
goNext Make the wizard go to the next step

In Windchill 9.x, for JCA Clients, JSP was serving both as the Controller and
View. In Windchill 10.0, we are introducing a clear separation between Controller
and View for which we are using Spring MVC Framework.
The primary motivation for this move is to enable our components to be both
requested by and rendered to any client technologies.

The servlet and servlet mapping for the Web container is defined in
<Windchill>\codebase\WEB-INF\web.xml. The below mentioned url
patterns are mapped to Spring DispatcherServlet and hence will be termed
as MVC requests.
<servlet-mapping>
<servlet-name>MVCDispatcher</servlet-name>
<url-pattern>/servlet/WizardServlet/*</url-pattern>
<url-pattern>/servlet/ActionsMenu/*</url-pattern>
<url-pattern>/servlet/RecentList/*</url-pattern>
...


Action Handling
Actions can be broadly divided into three groups.
These actions can be performed once your objects are loaded.
• Group 1 – Actions which act only on loaded data
○ Row-level and multi-select actions
○ Select all, Ctrl/Shift select, Clear all
○ View selected objects only
• Group 2 – Actions which act on the entire data set
These actions can be performed anytime (If incomplete data set, goes to the
server to get all the data)
○ Switching table views
○ Search in table
○ Export list
• Group 3 – Actions which apply to the table itself
These actions can be performed anytime
○ Create actions
○ Cancel data loading
○ Save table view

Element Type Description
*actionModels.xml XML Files which define the models where
actions are used. If an action is not already
defined in a model, one will need to be
created for the validation code to find the
action and properly set visibility.
actionmodels.xml is located in
<Windchills>/codebase; other
*actionmodels.xml files are generally in
<Windchill>/codebase /config/actions
*actions.xml XML Files where actions and other UI
components are defined. Actions are
optionally given a uicomponent value.
actions.xml is located in <Windchill>/
codebase; other *actions.xml files are
generally in <Windchill>/codebase /config/
actions.
Generic

roleaccessprefs.xml XML File for assigning default visibility to UI
components. Setting items in this file can
make them not appear at all for the site or
containers. Whether or not the container
manager can override the default value can
also be changed here.
Located in <Windchill>/codebase.
roleAccessResource.
rbInfo
XML Defines the labels to provide in the Uis for
the actions or UI components.
Located in <Windchill>/wtCustom/ com/
ptc/netmarkets/ roleAccess/.

the create folder action sample

Folder Contents -> New Document sample before actions Page 539


Action Service
Configuration of actions and action models that are available within the system
are defined using xml files. There is an action service that reads these xml files
and manages the set of actions and action models. Interaction with the service is
done via the components. Developers in general would not call the service
directly. For more detailed information about the action framework see Adding
Actions and Hooking Them Up in the UI on page 513

This section describes the action framework for the Windchill Client Architecture.
It does not include information on how to control the display of the action. For
more information on controlling the display see Related Documentation on page
548.

A service, called the StandardNmActionService manages the
set of actions and action models in the system.
StandardNmActionService .java <Windchill>\codebase\com \ptc\netmarkets\util\misc
actions.xml <Windchill>\codebase\config\actions
actionmodels.xml <Windchill>\codebase\config\actions
actions.dtd <Windchill>\codebase\config\actions
actionmodels.dtd <Windchill>\codebase\config\actions

The default actions.xml and actionmodels.xml files contain commonly used
actions, such as copy, cut, and commonly used action models such as wizard
buttons. Additional actions*.xml and actionmodels*.xml files contain
actions. and action models related to their functional areas. (e.g.
ChangeManagement-actions.xml contains actions related to change
management, PartManagement-actions.xml contains actions related to part management).

Here is an example of an action definition for the New Document wizard.
<objecttype name="document" class="wt.doc.WTDocument" resourceBundle="com.ptc.windchill.enterprise.doc.documentResource">
<action name="create" uicomponent="CREATE_DOC" dtiUpload="true">
<command class="com.ptc.windchill.enterprise.doc.forms.CreateDocFormProcessor"
method="execute" windowType="popup" onClick="validateCreateLocation(event)"/>
<includeFilter name="projectM4D" />
<nonSupportedTypes value="wt.part.WTPart"/>
<supportedTypes value="wt.doc.WTDocument"/>
</action>
</objecttype>

We support modularized actions and actionmodels within the system, so
to find what file an action is defined in, or what action models the action is used
in, there is a reporting tool that can be used. On a running Windchill installation,
you can use the Actions and ActionModels reports.

Action Report
http://<your machine name>/<app-name>/ app/#ptc1/
carambola/tools/actionReport/action The Action report allows you to search for actions managed by the
StandardNmActionService. You can search by several properties for the action
including the label (aka Description), action name, objecttype.

Debug Tool
There is also a debug mode that can be enabled in the UI that can help track down
information about a particular action on a page. See Debugging on page 442 for
information on enabling and using this tool.

Reload Action(s)
http://<your machine name>/<app-name>/app/#ptc1/carambola/tools/list
This tool reloads the action models from their xml files without having to restart
the method server.

As mention earlier in Solution Elements on page 517 section, there are two files,
custom-actions.xml and custom-actionmodels.xml, that are delivered with the
product. If you want to add/modify an action/actionmodel you can put the changes
in these files.

Toolbar Actions for a Table
Displaying Toolbar Actions for a Table
1. Define the actions in an actions.xml file. See Procedure – Defining a new
action on page 519 for more information.
2. Add the actions to an action model . See Procedure – Defining a new action on
page 519 for more information. Action models that used in the toolbar need to
contain “toolbar” in the name of the action model.
<model name="part toolbar actions">
Adding Actions and Hooking Them Up in the UI 583
<action name="create" type="Part"/>
<action name="create" type="Document"/>
…
</model>
3. Add the action model to your table by calling the setActionModel(action_
model_name) in your MVC builder:
public ComponentConfig buildComponentConfig (ComponentParams params) {
ComponentConfigFactory factory = getComponentConfigFactory ();
JcaTableConfig table = (JcaTableConfig) factory.newTableConfig ();
// add the toolbar action model to the table
table.setActionModel (“part toolbar actions”);
....
return table;
}

Soft Typing is the name of the set of Windchill capabilities that allows a
customer to, at runtime, add additional types and attributes to the out-of-thebox
Windchill Schema. This is done without having adding additional tables
to the database, without restarting the database, and without restarting the
system.

The Windchill Supported API includes those classes that customizers are meant to
work with directly. A class might be in the Supported API because it is meant to
be extended by customizers or, more likely, because it has some methods for
customizers to call.

ant -f bin/tools.xml eclipse_project.help

wordsBySon

paleontologist
gecko
nocturnal
brachiosaurus/T rex/triceratops/giganotosaurus
carnivore/omnivorous
turquoise
bam
bugous
piggy-ride
platypus
meteorite
tarantula (the spider)
ogaguawa (the gorilla)
emarald
xylophone
weasel
bound choy
Ninja
platurn (star)
chrysalis
pupa
syrup

Hadoop: The Definitive Guide

Hadoop: The Definitive Guide
1. Sample programs:
http://www.hadoopbook.com/
1+.
Cloudera's distribution for Hadoop (CDH) is a comprehensive Apache Hadoop based management platform and Cloudera Enterprise
includes the tools, platform, and support necessary to use Hadoop in production.
This edition uses the new MapReduce API for most of the examples. The major change in Hadoop 2.0 is the new MapReduce runtime, MapReduce 2
1.2+
This, in a nutshell, is what Hadoop provides: a reliable shared storage and analysis
system. The storage is provided by HDFS and analysis by MapReduce. There are other
parts to Hadoop, but these capabilities are its kernel.
1.3+
for updating a small proportion of records in a database, a traditional
B-Tree (the data structure used in relational databases, which is limited by the
rate it can perform seeks) works well. For updating the majority of a database, a B-Tree
is less efficient than MapReduce, which uses Sort/Merge to rebuild the database.
2.
for updating a small proportion of records in a database, a traditional
B-Tree (the data structure used in relational databases, which is limited by the
rate it can perform seeks) works well. For updating the majority of a database, a B-Tree
is less efficient than MapReduce, which uses Sort/Merge to rebuild the database.
In many ways, MapReduce can be seen as a complement to a Rational Database Management
System (RDBMS).
MapReduce is a good fit for problems that need to analyze the whole dataset
in a batch fashion, particularly for ad hoc analysis. An RDBMS is good for point queries
or updates, where the dataset has been indexed to deliver low-latency retrieval and
update times of a relatively small amount of data.
MapReduce suits applications where
the data is written once and read many times, whereas a relational database is good for
datasets that are continually updated.
MapReduce works well on unstructured or semistructured
data because it is designed to interpret the data at processing time.
Normalization poses problems for MapReduce because it makes reading a record a
nonlocal operation, and one of the central assumptions that MapReduce makes is that
it is possible to perform (high-speed) streaming reads and writes.
2+
MapReduce is a linearly scalable programming model. The programmer writes two
functions—a map function and a reduce function—each of which defines a mapping
from one set of key-value pairs to another. These functions are oblivious to the size of
the data or the cluster that they are operating on, so they can be used unchanged for a
small dataset and for a massive one. More important, if you double the size of the input
data, a job will run twice as slow. But if you also double the size of the cluster, a job
will run as fast as the original one. This is not generally true of SQL queries.
MapReduce is designed to run jobs that last minutes or hours on trusted, dedicated
hardware running in a single data center with very high aggregate bandwidth interconnects.
3.
Although this may change in the future, these are areas where HDFS is not a good
fit today:
Low-latency data access
Applications that require low-latency access to data, in the tens of milliseconds
range, will not work well with HDFS. Remember, HDFS is optimized for delivering
a high throughput of data, and this may be at the expense of latency.
Lots of small files
Multiple writers, arbitrary file modifications
Files in HDFS may be written to by a single writer. Writes are always made at the
end of the file. There is no support for multiple writers or for modifications at
arbitrary offsets in the file. (These might be supported in the future, but they are
likely to be relatively inefficient.)
4.
The namenode keeps a reference to every file and block in the filesystem in memory,
which means that on very large clusters with many files, memory becomes the limiting
factor for scaling
5.
The new API makes extensive use of context objects that allow the user code to
communicate with the MapReduce system. The new Context, for example, essentially
unifies the role of the JobConf, the OutputCollector, and the Reporter from
the old API.
6.
There are two types of nodes that control the job execution process: a jobtracker and
a number of tasktrackers. The jobtracker coordinates all the jobs run on the system by
scheduling tasks to run on tasktrackers.
7.
Low-latency data access
Applications that require low-latency access to data, in the tens of milliseconds
range, will not work well with HDFS. Remember, HDFS is optimized for delivering
a high throughput of data, and this may be at the expense of latency. HBase
(Chapter 13) is currently a better choice for low-latency access.
8.
An HDFS cluster has two types of nodes operating in a master-worker pattern: a namenode
(the master) and a number of datanodes (workers). The namenode manages the
filesystem namespace. It maintains the filesystem tree and the metadata for all the files
and directories in the tree.

SpringInAction_note

1. The act of creating associations between appli-
cation components is commonly referred to as wiring.
2. There’s no single Spring container. Spring comes with several container implementa-
tions that can be categorized into two distinct types. Bean factories (defined by the
org.springframework.beans.factory.BeanFactory interface) are the simplest of
containers, providing basic support for DI. Application contexts (defined by the
org.springframework.context.ApplicationContext interface) build on the notion
of a bean factory by providing application framework services, such as the ability to
resolve textual messages from a properties file and the ability to publish application
events to interested event listeners.
3. By default, all Spring beans are singletons.
To force Spring to produce a new bean instance each time one is needed,
you should declare the bean’s scope attribute to be prototype.
<bean id="ticket"
class="com.springinaction.springidol.Ticket"scope="prototype"/>
To set a property to null, you simply use the <null/> element.
4. Spring provides four flavors of autowiring:
 byName—Attempts to match all properties of the autowired bean with beans
that have the same name (or ID) as the properties. Properties for which there’s
no matching bean will remain unwired.
 byType—Attempts to match all properties of the autowired bean with beans
whose types are assignable to the properties. Properties for which there’s no
matching bean will remain unwired.
 constructor—Tries to match up a constructor of the autowired bean with
beans whose types are assignable to the constructor arguments.
 autodetect—Attempts to apply constructor autowiring first. If that fails,
byType will be tried.
Autowiring using byType works in a similar way to byName, except that instead of con-
sidering a property’s name, the property’s type is examined.
5. Since Spring 2.5, one of the most interesting ways of wiring beans in Spring has been
to use annotations to automatically wire bean properties.
Annotation wiring isn’t turned on in the Spring container by default. So, before we
can use annotation-based autowiring, we’ll need to enable it in our Spring configura-
tion. The simplest way to do that is with the <context:annotation-config>
6. Spring 3 supports a few different annotations for autowiring:
 Spring’s own @Autowired annotation
 The @Inject annotation from JSR-330
 The @Resource annotation from JSR-250
7.
@Autowired(required=false)
private Instrumentinstrument;
Here, Spring will try to wire the instrument property. But if no bean of type
Instrument can be found, then no problem. The property will be left null.
The centerpiece of JSR-330 is the @Inject annotation. This annotation is an almost
complete drop-in replacement for Spring’s @Autowired annotation. Unlike @Autowired, @Inject doesn’t have a required attribute.
8.
The <context:component-scan> element
does everything that <context:annotation-config> does, plus it configures
Spring to automatically discover beans and declare them for you. What this means is
that most (or all) of the beans in your Spring application can be declared and wired
without using <bean>.
By default, <context:component-scan> looks for classes that are annotated with one
of a handful of special stereotype annotations:
 @Component—A general-purpose stereotype annotation indicating that the class
is a Spring component
 @Controller—Indicates that the class defines a Spring MVC controller
 @Repository—Indicates that the class defines a data repository
 @Service—Indicates that the class defines a service
 Any custom annotation that is itself annotated with @Component

web service_note

On the client side, as I mentioned, cookies are handled automatically when you use the higher-level network functions. ?
1.
Implement the web service server side from the scratch
2.
Deploy the updated web service server side to the server
3.
Continue the web service GUI client
4.
Test the connect/disconnect
5.
Implement the GetBaseline method
Implement CreatePDF by returning the server PDF
6.
Write the document
7.
Distribute (ant backup)

1. On a technical level, web services can be implemented in various ways. The two types of web
services discussed in this section can be distinguished as “big” web services and “RESTful” web services.
JAX-WS provides the functionality for “big” web services, which use XML messages that follow the Simple Object
Access Protocol (SOAP) standard, an XML language defining a message architecture and message formats. Such systems often contain
a machine-readable description of the operations offered by the service, written in the Web Services Description Language (WSDL),
an XML language for defining interfaces syntactically.
JAX-RS provides the functionality for Representational State Transfer (RESTful) web services. REST is well suited for basic, ad hoc
integration scenarios. RESTful web services, often better integrated with HTTP than SOAP-based services are, do not require XML
messages or WSDL service–API definitions. Because RESTful web services use existing well-known W3C and Internet Engineering
Task Force (IETF) standards (HTTP, XML, URI, MIME) and have a lightweight infrastructure that allows services to
be built with minimal tooling, developing RESTful web services is inexpensive and thus has a very low barrier for adoption.
A RESTful design may be appropriate when the following conditions are met.
The web services are completely stateless. A good test is to consider whether the interaction can survive a restart of the server.
A caching infrastructure can be leveraged for performance.
The service producer and service consumer have a mutual understanding of the context and content being passed along. Because there
is no formal way to describe the web services interface, both parties must agree out of band on the schemas that describe the data
being exchanged and on ways to process it meaningfully. In the real world, most commercial applications that expose services as
RESTful implementations also distribute so-called value-added toolkits that describe the interfaces to developers in popular programming languages.
Bandwidth is particularly important and needs to be limited. REST is particularly useful for limited-profile devices, such as PDAs
and mobile phones, for which the overhead of headers and additional layers of SOAP elements on the XML payload must be restricted.

Although SOAP messages are complex, the JAX-WS API hides this complexity from the application developer. On the server side, the developer
specifies the web service operations by defining methods in an interface written in the Java programming language. The developer also codes
one or more classes that implement those methods. Client programs are also easy to code. A client creates a proxy (a local object
representing the service) and then simply invokes methods on the proxy. With JAX-WS, the developer does not generate or parse SOAP
messages. It is the JAX-WS runtime system that converts the API calls and responses to and from SOAP messages.

the default style is document.

A service endpoint interface or service endpoint implementation (SEI) is a Java interface or class, respectively, that declares the
methods that a client can invoke on the service. An interface is not required when building a JAX-WS endpoint. The web service
implementation class implicitly defines an SEI.
You may specify an explicit interface by adding the endpointInterface element to the @WebService annotation in the implementation
class. You must then provide an interface that defines the public methods made available in the endpoint implementation class.

Business methods that are exposed to web service clients must have JAXB-compatible parameters and return types.
The implementing class may use the javax.annotation.PostConstruct or the javax.annotation.PreDestroy annotations on its methods for lifecycle
event callbacks.

infoEngineUserGuide_note

Info*Engine tasks are always stored as text documents within the Info*Engine task
root. There are several ways to execute tasks, including the following:
An external Simple Object Access Protocol (SOAP) request.

Some of the Info*Engine tags can execute webjects that extract data
from enterprise systems through an adapter

When a task is contained in its own document, it is called a standalone task.

Queuing a task for execution. After you queue a task, you can disconnect
from your application. Any results are queued for later retrieval either by
you or others. By queuing a task, you can also guarantee that the task is
completed, even if it is interrupted due to a system problem.

In addition, requests can come from
SOAP requests that come from third-party applications through the Info*Engine
SOAP servlets.

Adapters provide a connection between the Info*Engine server and information
systems. One side of the adapter communicates with the Info*Engine server and
the other side communicates with the information system. The adapter translates
Info*Engine server requests into information system requests.

Info*Engine standalone tasks are XML-based documents that provide you with a
way to control the retrieval and manipulation of data outside of your JSP pages or
application.

Query webjects search external databases for objects that match specified
criteria. Each adapter supports a unique set of query webjects because the
adapter must handle queries differently due to the nature of the underlying
data repositories.
When Info*Engine encounters a query webject, it passes the webject to the
appropriate adapter. The adapter then performs the specified query. The group
of objects returned by a successful query is stored by Info*Engine. Thus,
making the results available to other webjects. For more information, see
Task Webject Reference on page 355.

For advanced users, Info*Engine also provides methods such as setOutputStream,
setInputStream, and sendContent that can manipulate BLOBs and the Java
language provides classes such as java.io.ByteArrayInputStream and
java.io.ByteArrayOutputStream to read or write BLOBs to or from
memory.

<h2>Upload File to Oracle BLOB Column</h2>
<form method="POST" action="/Windchill/servlet/IE/tasks/com/company/UploadBlob.xml"
enctype="multipart/form-data">

The UploadBlob.xml task identified in the action attribute of the form element
is the task that the Info*Engine server executes. This task (which is described in
the next section) uses the form variables to identify the adapter instance and specify
the name that corresponds to the BLOB in the table row where the BLOB is stored.

<form method="POST" action="/Windchill/servlet/IE/tasks/com/company/DownloadBlob.xml" enctype="multipart/form-data">

The following actions are allowed in this example application:
• Query—Search a given repository for parts.
• Fetch—Fetch a single part from a given repository.
• Download—Download the primary content of a part.
This example can be located in your Windchill installation at:
This example can be located in your Windchill installation at:
<Windchill>/prog_examples/federation/search_portal

Info*Engine provides a directory structure under which you should save your
task files.
Windchill is configured to look for Info*Engine tasks within the
<Windchill>/tasks directory.

Entering a task URL in the web browser is an easy way to execute the task without
providing the additional coding required to execute the task through an application
or JSP page.
Therefore, to execute the com/company/CreateGroup.xml task using
the myServer host name and the Windchill application URL, specify the
following URL:
http://myServer/Windchill/servlet/IE/tasks/com/company/CreateGroup.xml

The following rules apply to credentials mapping:
• If the author of a task or JSP page explicitly specifies DBUSER and PASSWD
parameters on a webject, those parameters take precedence over any other
authentication information that might be available.
• If DBUSER and PASSWD parameters are not explicitly specified, Info*Engine
attempts to provide values for them from the credentials mapping information.

Windchill is pre-configured to include a credentials mapping task.
This task is configured through the Windchill adapter using the
wt.federation.task.mapCredentials property value, which is set
to /wt/federation/MapCredentials.xml. The contents of this task
are dynamically generated, starting with the following file:
<Windchill>/tasks/wt/federation/
MapCredentials.xml.template
using the property values found in site.xconf.
Windchill’s LDAP access for user and group information relies on this
credentials mapping task, and can provide credentials to adapters based on
whether the current user is an administrator or a regular user. If you would like
to modify mapped credentials, you can set properties in site.xconf

If you need to customize this task you should do so by modifying the
MapCredentials.xml.template file. You should also keep a
backup copy, because patch or maintenance release installation may
overwrite your customization.

Using the xconfmanager utility, you can commands similar to the following to set
these properties:
xconfmanager -p -s "mapcredentials.admin.adapters=<adapter name>^
<privileged User>^<privileged
To set credentials for a Windchill administrator, use the following command:
mapcredentials.admin.adapters=<unique name of the adapter>^<username>^<password>
To set credentials for a user without Windchill administration privileges, use the
following command:
mapcredentials.nonprivileged.adapters=<unique name of the adapter>^<username>^<password>

Windchill offers a toolset that facilitates deployment of the same Info*Engine-based
web service that leverages JAX-WS (Java API for XML Web Services) in order
to handle the SOAP/XML and security-related web service details. This toolset
is available in addition to the Info*Engine-based web services that are supplied
by the SimpleTaskDispatcher servlet.

Aside from leveraging JAX-WS for the SOAP-related details, a major advantage
to using this framework is the addition of configurable and efficient security.

Legacy Info*Engine web services rely solely upon web server authentication
for security. This means that SOAP clients must have complete access to
user credentials, and must supply those credentials to the web server per its
authentication requirements (typically HTTP Basic Authentication). However, this
presents a fairly significant roadblock to developing applications that implement
SSO (Single Sign On).

With web service security support in Windchill, you can establish a trust
relationship between an application (such as a portal server) and an Info*Engine
web service by exchanging public key information, requiring that SOAP message
exchanges be properly signed and encrypted, and requiring that they contain a
valid username token that the web service should trust. As long as the incoming
SOAP message meets the security requirements and can be decrypted using a
public key found in the server’s truststore, the web service then executes a request
that has been authenticated with the username.

The supplied tooling is enabled using Apache Ant, located in:
<Windchill>/ant
(where <Windchill> is the Info*Engine installation directory).
The tooling is intended to be run from a windchill shell, in which case the ant
command is already in your path.

The directory that contains the Apache Ant build tools for deploying a web service
is located in <Windchill>/bin/adminTools/WebServices and contains
the following:
• build.xml
The primary Apache Ant build script used to deploy web services and associate
those services with security policies.
• security.properties
A properties file containing the security-related configuration information
used when deploying a web service. This file contains the security policy to
use, the server-side truststore and keystore configurations, and any additional
policy-specific configuration (if necessary) that is to be used at deployment
time.

This shared, symmetric key is generated at runtime and
encrypted using the service’s certificate. The client must specify the alias in the
truststore by identifying the server’s certificate alias.

The server security.properties file is found at:
<Windchill>/bin/adminTools/WebServices/security.properties

If you want to undeploy your web service from your installation, simply run the
undeploy target for the src/build.xml script of your project. For example:
% cd <Windchill>/prog_examples/MyProject/src
% ant undeploy
The undeploy target completes the following actions:
• Removes the servlet configuration from web.xml
• Removes the web service configuration from sun-jaxws.xml
• Removes the security policy configuration file
• Removes the JAR file supporting your web service
• Uninstalls the Info*Engine tasks (if your service is based on Info*Engine tasks)

Using Security Policies
When securing a web service with one of the supported security policies (other
than web server authentication), a Java client needs access to its own keystore and
truststore. Paths to these files (keystore and truststore) are configured for use by
the build framework in the following:
<Windchill>/bin/adminTools/WebServices/client/security.properties

English collections

polyglot
entrepreneur
walleye/bass
measle vaccine

A car backing out of a driveway hits you as you are driving past.
You are rear-ended at an intersection as you wait for the light to change.
You know, collect your baggage, maybe grab a coffee?

If you truly want to be good at another language, forget your native one.
It has been said that “more data usually beats better algorithms,” which is to say that ..