View source

From Eclipsepedia

You do not have permission to do that, for the following reason:
The action you have requested is limited to users in the group user.
You can view and copy the source of this page:
<TABLE border="1">
	<TR>
		<TD bgcolor="#0099FF" width="500">
			<B>Known problem or limitation</B>
		</TD>

		<TD bgcolor="#0099FF" width="500">
			<B>Workaround</B>
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Project with spaces:</i>
			When creating a capability in a project that has spaces in
			its name (for example, Test 1), a redmark shows up next to
			the capability file and when it is opened, all the fields
			are empty.
		</TD>

		<TD width="500">
			Create capabilities only in projects that do not have a
			space in the name
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Capability definition import:</i>
			Import of any XSD or WSDL which imports another XSD or WSDL
			using a
			<i>HTTP URI</i>
			, requires a network connection to resolve the imported XSD
			or WSDL file.
		</TD>

		<TD width="500">
			Before importing any WSDL or XSD file into an existing
			capability or while creating a new capability make sure that
			an internet connection is available.
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Capability definition import:</i>
			XSD property removed from capability cannot be imported
			again
		</TD>

		<TD width="500">
			Do not remove imported properties but instead create a new
			capability
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Capability definition editor:</i>
			When a property is removed from the capability editor, the
			related fields are disabled but still show values
		</TD>

		<TD width="500">Known Limitation</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Renaming capability definitions:</i>
			When renaming a capability definition file (.mcap), a
			confirmation dialog requesting confirmation for removal of
			the corresponding XSD and RMD files is shown.
		</TD>

		<TD width="500">
			Known Limitation. This will be addressed in the next release
			by providing a "Package Explorer" like view that hides the
			different files that compose a capability definition.
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Capability Definition:</i>

			Changes to operation name are not reflected
		</TD>

		<TD width="500">
			Known limitation. Only workaround is to create a new
			capability.
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Creating a new project:</i>

			In some cases, Cannot create new WSDM capability or managed
			resource type definition from File menu
		</TD>

		<TD width="500">
			When creating new Capability/managed resource type from the
			File menu, Select the target Project i.e. Project1 using
			browse button; if it shows up in the corresponding text
			field as
			<i>\Project1</i>

			update it to
			<i>/project1</i>

			before proceeding.
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>
				Array return type for operations in capability
				definition:
			</i>

			If user selects to return array values for an operation,
			then the generated WSDL file is marked invalid in the
			generated project
		</TD>

		<TD width="500">
			Known Limitation. This is a WSDL validation issue and does
			not affect the generated endpoint's operation.
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Notification Topics:</i>

			Topics provided in capability definition may lead to failure
			of resource initialization on endpoint deployment
		</TD>

		<TD width="500">
			In the generated project, you will find an extra package
			called
			<i>org.eclipse.tptp.wsdm.runtime.capability</i>

			. Delete this package before deploying the generated
			endpoint.
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Manageable Resource Type:</i>

			When a capability definition that is used in one or more
			Manageable resource type (.mrt) files is removed, the
			corresponding .mrt files fail validation
		</TD>

		<TD width="500">
			Before deleting the capability definition from the project,
			remove it from the Manageable Resource Type definitions that
			use the capability. Unfortunately, once a resource type
			definition has been marked invalid, the reference to the
			missing capability can be removed only by opening the file
			in a text editor and manually removing the entry.
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Deployment descriptor editor</i>

			: Custom Serializers shows up even when the related
			manageable resource type is removed from the deployment
			descriptor template file
		</TD>

		<TD width="500">
			Known limitation. Open the .dd file in a text editor and
			remove all the &lt;custom-serializer&gt; elements that were
			used by removed resource type
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Code Generation:</i>

			On Java 1.4, code generation dialog does not show J2EE
			option
		</TD>

		<TD width="500">
			Known Limitation. J2EE based endpoints cannot be created on
			Java 1.4 since Web tools project requires Java 1.5 or above.
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Code generation</i>

			: Generated deployment descriptor file (in the generated
			project) does not contain any custom serializers
		</TD>

		<TD width="500">
			Known problem. Generate the deployment descriptor template
			from the manageable resource type definition (right click on
			the .mrt file). Associate custom serializer in the generated
			deployment descriptor template and then generate java code
			from the deployment descriptor file (right click on the .dd
			file)
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Code generation:</i>

			When codegeneration is successful for manageable resource
			type definition that has Relationship, Service group and/or
			Notification producer Capabilities additional packages are
			generated
		</TD>

		<TD width="500">
			Known Limitation. Remove the additional packages from the
			generated project. Keep only the packages that correspond to
			the namespaces of the custom capability used in the resource
			type definition.
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Code generation:</i>

			Generasted Java code has compilation problems if the
			namespace provided for capability does not end in a format
			such as test2.org
		</TD>

		<TD width="500">
			Known problem. If you wish to use a specific namespace for a
			capability, format it such that it ends with x.y. i.e.
			http://test1.org/test2 and http://test1.org/test2/test3 are
			incorrect; http://test1.test2.org is correct
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Code generation:</i>

			Could not generate code when capability has a property
			defined as writable and as constant for mutability
		</TD>

		<TD width="500">
			A constant property cannot be writable. Ensure that constant
			properties are defined as read only.
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Code Generation:</i>

			Could not generate code if an existing project name is
			specified as target event if the "Overwrite Files" checkbox
			is checked
		</TD>

		<TD width="500">
			When Generating code, provide a non-existent project name
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Generated Endpoint:</i>

			RuntimeException throws up when deploying Javacode on Tomcat
		</TD>

		<TD width="500">
			Known Limitation. There are no side effects and the endpoint
			will function normally.
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Spec compliance:</i>

			:Service Group and Relationship capabilities do not provide
			topics as defined by the specification
		</TD>

		<TD width="500">
			Known Limitation. The topics can be manually added to the
			corresponding files after code generation.
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Generated endpoint:</i>

			Generated OSGI project is not valid
		</TD>

		<TD width="500">
			Export these packages: org.apache.muse.core.platform.osgi,
			org.apache.muse.core.platform.osgi.descriptor,
			org.apache.muse.core.platform.osgi.internal,
			org.apache.muse.ore.platform.osgi.routing and
			org.apache.muse.core.platform.osgi.util from
			'org.apache.muse.osgi.core' plugin as a jar to the created
			OSGI project. Add it as an additional jar to the project.
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Managed Agent Explorer:</i>

			Unsubscribe does not work
		</TD>

		<TD width="500">
			The resource you are introspecting with the Managed Agent
			Explorer must support WS-RL for unsubscribe to be supported
		</TD>
	</TR>

	<TR>
		<TD width="500">
			<i>Managed Agent Explorer:</i>

			Can not set values for Operation parameter arrays through
			MAX
		</TD>

		<TD width="500">Known Limitation</TD>
	</TR>
</TABLE>
Return to BtM WSDM TPTP 4.4 Limitations.
Retrieved from "http://wiki.eclipse.org/BtM_WSDM_TPTP_4.4_Limitations"