[JBoss JIRA] (TEIIDDES-2130) REST mxd is missing in the build jar
by Mark Drilling (JIRA)
Mark Drilling created TEIIDDES-2130:
---------------------------------------
Summary: REST mxd is missing in the build jar
Key: TEIIDDES-2130
URL: https://issues.jboss.org/browse/TEIIDDES-2130
Project: Teiid Designer
Issue Type: Bug
Components: Extension Framework
Affects Versions: 8.5
Reporter: Mark Drilling
Assignee: Mark Drilling
Fix For: 8.5
Noticed errors on Designer startup when installing from the update site.
The rest.mxd is not found (see attached). This results in subsequent NPE, also shown in the attached log snippet.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (TEIIDDES-1992) Designer generates wrong view model transformations for some services
by Ted Jones (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-1992?page=com.atlassian.jira.plu... ]
Ted Jones updated TEIIDDES-1992:
--------------------------------
Fix Version/s: 8.5
8.4
> Designer generates wrong view model transformations for some services
> ---------------------------------------------------------------------
>
> Key: TEIIDDES-1992
> URL: https://issues.jboss.org/browse/TEIIDDES-1992
> Project: Teiid Designer
> Issue Type: Bug
> Components: Web Services Support
> Affects Versions: 8.3
> Reporter: Van Halbert
> Assignee: Ted Jones
> Priority: Critical
> Fix For: 8.3.1, 8.4, 8.5
>
>
> When generating web service view from WSDL, the designer incorrectly adds the namespace to the request. The request [1] declares the "tns" prefix but since the namespace is not added to the actual request it generates [2].
> User can workaround this by directly modifying the request [3].
> [1]
> CREATE VIRTUAL PROCEDURE
> BEGIN
> SELECT XMLELEMENT(NAME getPeopleByName, XMLNAMESPACES('http://www.jboss.org/jbossas/dv/PeopleJaxws' AS tns)) AS xml_out;
> END
> [2] Caused by: javax.xml.ws.ProtocolException: Remote javax.xml.ws.soap.SOAPFaultException: Unexpected wrapper element getPeopleByName found. Expected {http://www.jboss.org/jbossas/dv/PeopleJaxws}getPeopleByName.
> [3]
> CREATE VIRTUAL PROCEDURE
> BEGIN
> SELECT XMLELEMENT(NAME getPeopleByName, XMLNAMESPACES(DEFAULT 'http://www.jboss.org/jbossas/dv/PeopleJaxws')) AS xml_out;
> END
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (TEIIDDES-1992) Designer generates wrong view model transformations for some services
by Ted Jones (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-1992?page=com.atlassian.jira.plu... ]
Ted Jones commented on TEIIDDES-1992:
-------------------------------------
Looks like the commit was only made to 8.3.x. Will need to apply to master as well.
> Designer generates wrong view model transformations for some services
> ---------------------------------------------------------------------
>
> Key: TEIIDDES-1992
> URL: https://issues.jboss.org/browse/TEIIDDES-1992
> Project: Teiid Designer
> Issue Type: Bug
> Components: Web Services Support
> Affects Versions: 8.3
> Reporter: Van Halbert
> Assignee: Ted Jones
> Priority: Critical
> Fix For: 8.3.1, 8.4, 8.5
>
>
> When generating web service view from WSDL, the designer incorrectly adds the namespace to the request. The request [1] declares the "tns" prefix but since the namespace is not added to the actual request it generates [2].
> User can workaround this by directly modifying the request [3].
> [1]
> CREATE VIRTUAL PROCEDURE
> BEGIN
> SELECT XMLELEMENT(NAME getPeopleByName, XMLNAMESPACES('http://www.jboss.org/jbossas/dv/PeopleJaxws' AS tns)) AS xml_out;
> END
> [2] Caused by: javax.xml.ws.ProtocolException: Remote javax.xml.ws.soap.SOAPFaultException: Unexpected wrapper element getPeopleByName found. Expected {http://www.jboss.org/jbossas/dv/PeopleJaxws}getPeopleByName.
> [3]
> CREATE VIRTUAL PROCEDURE
> BEGIN
> SELECT XMLELEMENT(NAME getPeopleByName, XMLNAMESPACES(DEFAULT 'http://www.jboss.org/jbossas/dv/PeopleJaxws')) AS xml_out;
> END
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (TEIIDDES-2094) Support for dynamic extension metadata
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-2094?page=com.atlassian.jira.plu... ]
Ramesh Reddy commented on TEIIDDES-2094:
----------------------------------------
> I don't see any difference in your 2 use-cases.
Well, then we got more work to do in terms of convincing the other -:)
>It's obvious that extension properties on view models requires MEDs since there are no corresponding "annotations" in the Teiid Runtime.
Not really, they are really defined in Teiid Metadata API. Look at "org.teiid.api" package. If you look at supported externalized DDL form you will see extended metadata as "OPTION" properties. "annotations" is *a* way Teiid choose to define dynamic/custom metadata in translators. That does not mean that all the extension metadata needs to be defined as such in Teiid. Most of it is driven by SQL and SQL/MED, then Teiid custom extensions. While it is true that currently there is *no* way query these standard "extension metadata" through Admin API. But this type of "extension metadata" requirement *never* involves a user/customer, it is only involves Teiid and Designer teams.
>When dealing with custom translators, users must write the translator and probably use tooling to write that translator. To me, it seems more intuitive >to require the user to define their Extension properties in the form of a schema (aka MED file) . We happen to have tooling that can help users >create error-free MEDs but the format/definition is pretty straight forward and can be edited by hand if tooling is an issue.
That is you view of it, which I am fine with.
* But *do not* assume that a translator developer is also a tooling user and they know how to define MEDs (error-free) in each and every machine.
* if the developer does do the MED, how does he share it? does tooling give a "enterprise" wide repository where they can retrieve it from? Then each Designer user specifically loads a MED file, register it, then apply on particular model they are interested in? Would't be *easier* for *user*, if we provide a mechanism this works OOB
* How do you suggest the version gap between Designer and Teiid be minimized in terms of supporting new translators. Good example, Teiid put in 4 new translators in 8.7, for testing I/developer can do MED fine. But the end user has to wait however long for the for Designer to pull together next version before they can be supported. This *must* be eliminated.
You can not expect a translator developer to first define a MED in Designer and take that file to Teiid translator development, read/parse and use those properties and the supply the MED a part of the translator, when they can simply do this in single line of code. This makes a tight coupling between tooling and Teiid. Do not forget Teiid also has dynamic vdbs to support. If you remember this is same we did with function model in MMx/early Teiid, see what we had to do to fix it.
>I think the biggest issue I have is that we now have a disconnect between design-time and runtime extension metadata.
I am trying to show that these are different usecases and *may* need different solutions, I am NOT trying to suggest that you shoehorn these in MED framework, if you think that is not feasible or correct. I understand the designer requirements, as per this JIRA the only use case, I am interested in is
> allow users to add runtime extension properties required by custom translators
what I am saying from usability aspect, what Designer has is not sufficient, it is just a workaround IMO.
>This jira is pushing for Designer to:
> remove the requirement for MEDs being used for custom translators
I am not saying remove MED requirement, that is an implementation detail, the only *REAL* requirement in this usecase is, when Teiid schema import presents its DDL, then *DO NOT THROW AWAY* properties in OPTIONS clause that tooling does not understand. The decision to use some custom property is already been done, just honor it in the tooling, and provide a way to edit the values if needed. How we support it is implementation details, which Admin API is trying to help with. It not trying to redefine how MED are created.
>make it much harder to present any sense of version-control/validation for the user in the tooling since there doesn't appear to be any info coming >through the API to make that available
We have not seen any use case for version-control as requirement yet
>force the user to extract and register the MED definition from a source model if they wish to create a source model from scratch for that same data >source/translator
Typically this not a normal flow, if user deviates then I am fine with they doing extra work to figuring out and defining what they need, as suggest in beginning. We can document that procedure.
>Note that @ExtensionMetadataProperty annotation only supports:
That is not true. It does provide isMasked, allowedValues. It does not currently populate default value, but, when the property is "required" it must be defined by the user. If the property is not "required" runtime will automatically will provide a default value. There is no such rule that all properties MUST have a default. That is same paradigm runtime treats all the translator properties. "Locale" support is done by the translator developer. The remaining property is "fixedValue" what does this do?
>So still not sure on how to satisfy both the support for runtime dynamic extension metadata and make it useful in design-time and clear to the user >what is going on.
IMO, we once again created this MED framework which is not solving all the previously not foreseen cases such as this. Hypothetically, how would you solve this if there was no MED framework? Then again, what that lacking MED framework, makes this so challenging? Lets start there.
> Support for dynamic extension metadata
> ---------------------------------------
>
> Key: TEIIDDES-2094
> URL: https://issues.jboss.org/browse/TEIIDDES-2094
> Project: Teiid Designer
> Issue Type: Enhancement
> Components: Import/Export
> Reporter: Ramesh Reddy
> Assignee: Paul Richardson
> Priority: Critical
>
> Currently when Teiid core implements a new translator or customer/user implements a custom translator that has extension metadata, before they can use the translator in Designer to do some modeling, they need to define MED and register it.
> With completion of TEIID-2904, in Teiid 8.7, a Admin api method can be used to interrogate the extension metadata properties defined for a translator.
> Currently if user uses Teiid Connection importer with any new translator, it ignores all the extension metadata properties and removes them from the returned DDL that Designer did not recognize. That is really bad for custom connectors, because the VDB will not work properly once it is deployed back to Teiid Server.
> I propose to devise a way to generate a dynamic MED for the purposes of current metadata import of the source and use it during the import and not ignore those extension metadata properties.
> Depending upon implementation detail, we can also read the translators and their extension metadata support during the initial connection time and create all the required MEDs and register them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (TEIIDDES-2129) Teiid Connection Importer - issues on Windows OS
by Mark Drilling (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-2129?page=com.atlassian.jira.plu... ]
Mark Drilling resolved TEIIDDES-2129.
-------------------------------------
Resolution: Cannot Reproduce Bug
Installed IDE on Windows for debug. And... Now I cant reproduce the issue.
- Tested OK on JBDS kit install.
- Tested OK when launched from IDE.
I will continue to do some general testing with JBDS on Windows and will re-open if I can reproduce.
> Teiid Connection Importer - issues on Windows OS
> ------------------------------------------------
>
> Key: TEIIDDES-2129
> URL: https://issues.jboss.org/browse/TEIIDDES-2129
> Project: Teiid Designer
> Issue Type: Bug
> Components: Import/Export
> Affects Versions: 8.5
> Reporter: Mark Drilling
> Assignee: Mark Drilling
> Fix For: 8.5
>
>
> Several issues observed in the Teiid Connection Importer on Windows 7 OS (not observed on linux OS)
> - First page of wizard, the datasources table does not populate
> - Click 'New...' to create a new datasource - the driver column of the table is not populated.
> - Continue in the wizard to deploy the dynamic VDB. In the server console you can see the vdb deploy and go ACTIVE, be the control never returns to the wizard. It times out.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (TEIIDDES-844) Display Grid on Teiid Metadata model diagram fails with org.eclipse.swt.SWTError: "No more handles"
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIIDDES-844?page=com.atlassian.jira.plug... ]
Barry LaFond resolved TEIIDDES-844.
-----------------------------------
Resolution: Won't Fix
Printing removed as a feature
> Display Grid on Teiid Metadata model diagram fails with org.eclipse.swt.SWTError: "No more handles"
> ---------------------------------------------------------------------------------------------------
>
> Key: TEIIDDES-844
> URL: https://issues.jboss.org/browse/TEIIDDES-844
> Project: Teiid Designer
> Issue Type: Bug
> Affects Versions: 7.2
> Environment: Linux, GTK, x86
> Java 6 Openjdk
> Teiid installed from JBoss Tools Development update site 7.1.0.v20110119-0345-H399-CR1
> Reporter: Denis Golovin
> Assignee: Barry LaFond
>
> Display Gr Grid button from Metadata model diagram editor throws exception after printer is selected
> {noformat}
> org.eclipse.swt.SWTError: No more handles
> at org.eclipse.swt.SWT.error(SWT.java:4109)
> at org.eclipse.swt.SWT.error(SWT.java:3998)
> at org.eclipse.swt.SWT.error(SWT.java:3969)
> at org.eclipse.swt.printing.Printer.internal_new_GC(Printer.java:393)
> at org.eclipse.swt.graphics.GC.<init>(GC.java:159)
> at org.eclipse.swt.graphics.GC.<init>(GC.java:125)
> at com.metamatrix.modeler.diagram.ui.printing.DiagramPrintingAnalyzer.getPrinterGC(DiagramPrintingAnalyzer.java:228)
> at com.metamatrix.modeler.diagram.ui.printing.DiagramPrintingAnalyzer.getFreshPrinterGraphics(DiagramPrintingAnalyzer.java:220)
> at com.metamatrix.modeler.diagram.ui.printing.DiagramPrintingOperation.printLandscape_PrinterIsPortrait(DiagramPrintingOperation.java:690)
> at com.metamatrix.modeler.diagram.ui.printing.DiagramPrintingOperation.printPages(DiagramPrintingOperation.java:403)
> at com.metamatrix.modeler.diagram.ui.printing.DiagramPrintingAnalyzer.countPages(DiagramPrintingAnalyzer.java:170)
> at com.metamatrix.modeler.diagram.ui.printing.DiagramPrintingAnalyzer.setPageSize(DiagramPrintingAnalyzer.java:68)
> at com.metamatrix.modeler.diagram.ui.printing.DiagramPrintingAnalyzer.<init>(DiagramPrintingAnalyzer.java:44)
> at com.metamatrix.modeler.diagram.ui.editor.DiagramViewer.updateForPrintPreferences(DiagramViewer.java:358)
> at com.metamatrix.modeler.diagram.ui.actions.ShowPageGridAction.doRun(ShowPageGridAction.java:140)
> at com.metamatrix.ui.actions.AbstractAction$1.run(AbstractAction.java:537)
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
> at com.metamatrix.ui.actions.AbstractAction.run(AbstractAction.java:540)
> at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
> at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
> at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
> at org.eclipse.jface.action.ActionContributionItem$6.handleEvent(ActionContributionItem.java:452)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3540)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3161)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
> at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month