[JBoss JIRA] Moved: (TEIIDDES-1064) In Designer, when trying to deploy the vdb after overriding a translator property, produce an error dialog indicating the translator is not found on the server
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-1064?page=com.atlassian.jira.plu... ]
Van Halbert moved SOA-3355 to TEIIDDES-1064:
--------------------------------------------
Project: Teiid Designer (was: JBoss Enterprise SOA Platform)
Key: TEIIDDES-1064 (was: SOA-3355)
Affects Version/s: 7.4.2
(was: JBDS)
(was: 5.2.0.ER3)
Component/s: VDB & Execution
(was: Tooling)
(was: EDS)
Security: (was: Public)
Fix Version/s: 7.4.2
(was: JBDS)
(was: 5.2.0 GA)
> In Designer, when trying to deploy the vdb after overriding a translator property, produce an error dialog indicating the translator is not found on the server
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIIDDES-1064
> URL: https://issues.jboss.org/browse/TEIIDDES-1064
> Project: Teiid Designer
> Issue Type: Bug
> Components: VDB & Execution
> Affects Versions: 7.4.2
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Blocker
> Fix For: 7.4.2
>
> Attachments: screenshot-1.jpg
>
>
> Trying to override a property on the translator. Created the override (loopback-1), then changed the Translator for the source model (long.xmi) to map to the loopback-1 override. Saved the vdb. Then tried to deploy the vdb to the server and got the "VDB Not Deployed" dialog indicating the translator is missing.
> To get around the issue, manually copied the vdb from the workspace to the server and was able to verify the override worked.
> What appears to be happening is Designer is validating the vdb against a list of translators that don't include the override.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] Moved: (TEIIDDES-1063) Refactoring vdb with expectation to also change name only changed name of file, not name to connect to it
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-1063?page=com.atlassian.jira.plu... ]
Van Halbert moved SOA-3354 to TEIIDDES-1063:
--------------------------------------------
Project: Teiid Designer (was: JBoss Enterprise SOA Platform)
Key: TEIIDDES-1063 (was: SOA-3354)
Affects Version/s: 7.4.2
(was: JBDS)
(was: 5.2.0.ER3)
Component/s: VDB & Execution
(was: Tooling)
(was: EDS)
Security: (was: Public)
> Refactoring vdb with expectation to also change name only changed name of file, not name to connect to it
> ---------------------------------------------------------------------------------------------------------
>
> Key: TEIIDDES-1063
> URL: https://issues.jboss.org/browse/TEIIDDES-1063
> Project: Teiid Designer
> Issue Type: Bug
> Components: VDB & Execution
> Affects Versions: 7.4.2
> Reporter: Van Halbert
> Assignee: Van Halbert
> Attachments: screenshot-1.jpg
>
>
> Built a vdb (LookbackTest), but the name was not the one I wanted. Refactored the vdb (to Loopback) with the expectation that was the name I should see the server exposing it as. However, it only changed the name of the file, not the reference name. In designer, looking at the vdbs on the server, the old name (LoopbackTest) was still there and when I unzipped the vdb, LoopbackTest was the name in the vdb.xml.
> In designer, the properties that were show when the vdb was selected, had no way to change the "name" of the vdb. It referred to the name as "Loopback.vdb", which is the filename, not the reference name. Additonally, this "name" property was not updatable. So its confusing as to how to name the vdb or change its name that I want to use when connecting via jdbc.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] Assigned: (TEIIDDES-1063) Refactoring vdb with expectation to also change name only changed name of file, not name to connect to it
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-1063?page=com.atlassian.jira.plu... ]
Van Halbert reassigned TEIIDDES-1063:
-------------------------------------
Assignee: Barry LaFond (was: Van Halbert)
> Refactoring vdb with expectation to also change name only changed name of file, not name to connect to it
> ---------------------------------------------------------------------------------------------------------
>
> Key: TEIIDDES-1063
> URL: https://issues.jboss.org/browse/TEIIDDES-1063
> Project: Teiid Designer
> Issue Type: Bug
> Components: VDB & Execution
> Affects Versions: 7.4.2
> Reporter: Van Halbert
> Assignee: Barry LaFond
> Attachments: screenshot-1.jpg
>
>
> Built a vdb (LookbackTest), but the name was not the one I wanted. Refactored the vdb (to Loopback) with the expectation that was the name I should see the server exposing it as. However, it only changed the name of the file, not the reference name. In designer, looking at the vdbs on the server, the old name (LoopbackTest) was still there and when I unzipped the vdb, LoopbackTest was the name in the vdb.xml.
> In designer, the properties that were show when the vdb was selected, had no way to change the "name" of the vdb. It referred to the name as "Loopback.vdb", which is the filename, not the reference name. Additonally, this "name" property was not updatable. So its confusing as to how to name the vdb or change its name that I want to use when connecting via jdbc.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] Created: (TEIIDDES-1057) java.lang.IllegalArgumentException (modelResource == NULL) importing PartsSupplier from DB2
by Barry LaFond (JIRA)
java.lang.IllegalArgumentException (modelResource == NULL) importing PartsSupplier from DB2
-------------------------------------------------------------------------------------------
Key: TEIIDDES-1057
URL: https://issues.jboss.org/browse/TEIIDDES-1057
Project: Teiid Designer
Issue Type: Bug
Components: Import/Export
Affects Versions: 7.5
Reporter: Barry LaFond
Assignee: Dan Florian
Priority: Critical
Fix For: 7.5
java.lang.IllegalArgumentException: modelResource is null
at com.metamatrix.core.util.CoreArgCheck.isNotNull(CoreArgCheck.java:139)
at org.teiid.designer.core.extension.ModelObjectExtensionAssistant.getModelResource(ModelObjectExtensionAssistant.java:69)
at org.teiid.designer.core.extension.ModelObjectExtensionAssistant.hasExtensionProperties(ModelObjectExtensionAssistant.java:253)
at com.metamatrix.modeler.internal.ui.explorer.ModelExplorerLabelProvider.decorate(ModelExplorerLabelProvider.java:354)
at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:263)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:81)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:365)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:347)
at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:370)
at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:330)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] Created: (TEIIDDES-1062) Models With 7.4 Extension Properties Are Not Being Decorated
by Dan Florian (JIRA)
Models With 7.4 Extension Properties Are Not Being Decorated
------------------------------------------------------------
Key: TEIIDDES-1062
URL: https://issues.jboss.org/browse/TEIIDDES-1062
Project: Teiid Designer
Issue Type: Bug
Components: Modeling
Affects Versions: 7.5
Reporter: Dan Florian
Assignee: Dan Florian
Fix For: 7.5
The default behavior is that if the model is storing any of the registered Model Extension Definitions (MEDs) than the model is decorated with the extension model overlay. But the 7.4 models with extension properties do not have a MED stored in them. The DeprecatedModelExtensionAssistant needs to override the superclass functionality and check a model's model objects to see if any have 7.4 properties.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months