[JBoss JIRA] (TEIID-3589) MongoDB metadata import fails with NPE
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3589?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3589:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1246153|https://bugzilla.redhat.com/show_bug.cgi?id=1246153] from MODIFIED to ON_QA
> MongoDB metadata import fails with NPE
> --------------------------------------
>
> Key: TEIID-3589
> URL: https://issues.jboss.org/browse/TEIID-3589
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.7.1.6_2
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Labels: Beta1, ER5
> Fix For: 8.7.1.6_2, 8.12
>
>
> Deploying the following dynamic vdb fails with a NullPointerException when Teiid Connection importer is used:
> {code}
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <vdb name="mongo" version="1">
> <description>Importer VDB</description>
> <property name="UseConnectorMetadata" value="true" />
> <property name="deployment-name" value="mongo-vdb.xml" />
> <model name="importVDBSrcModel">
> <source name="importVDBSrcModel" translator-name="mongodb" connection-jndi-name="java:/mongoDS" />
> </model>
> </vdb>
> {code}
> The resource adapter is defined as:
> {code}
> <resource-adapter id="mongoDS">
> <module slot="main" id="org.jboss.teiid.resource-adapter.mongodb"/>
> <transaction-support>NoTransaction</transaction-support>
> <connection-definitions>
> <connection-definition class-name="org.teiid.resource.adapter.mongodb.MongoDBManagedConnectionFactory" jndi-name="java:/mongoDS" enabled="true" use-java-context="true" pool-name="mongoDS">
> <config-property name="Database">
> bqt
> </config-property>
> <config-property name="RemoteServerList">
> vmgdb01.mw.lab.eng.bos.redhat.com:27017
> </config-property>
> <config-property name="Username">
> dv
> </config-property>
> <config-property name="Password">
> dv
> </config-property>
> </connection-definition>
> </connection-definitions>
> </resource-adapter>
> {code}
> Server log:
> {code}
> 16:46:49,793 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015876: Starting deployment of "mongo-vdb.xml" (runtime-name: "mongo-vdb.xml")
> 16:46:49,809 DEBUG [org.teiid.RUNTIME] (MSC service thread 1-5) VDB mongo-vdb.xml has been parsed.
> 16:46:49,835 INFO [org.teiid.RUNTIME] (MSC service thread 1-1) TEIID50029 VDB mongo.1 model "importVDBSrcModel" metadata is currently being loaded. Start Time: 7/23/15 4:46 PM
> 16:46:49,869 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015859: Deployed "mongo-vdb.xml" (runtime-name : "mongo-vdb.xml")
> 16:46:50,626 WARN [org.teiid.RUNTIME] (teiid-async-threads - 3) TEIID50036 VDB mongo.1 model "importVDBSrcModel" metadata failed to load. Reason:java.lang.NullPointerException: java.lang.NullPointerException
> at org.teiid.translator.mongodb.MongoDBMetadataProcessor.addTable(MongoDBMetadataProcessor.java:92)
> at org.teiid.translator.mongodb.MongoDBMetadataProcessor.process(MongoDBMetadataProcessor.java:57)
> at org.teiid.translator.mongodb.MongoDBMetadataProcessor.process(MongoDBMetadataProcessor.java:38)
> at org.teiid.translator.ExecutionFactory.getMetadata(ExecutionFactory.java:935) [teiid-api-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.query.metadata.NativeMetadataRepository.loadMetadata(NativeMetadataRepository.java:73) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.query.metadata.ChainingMetadataRepository.loadMetadata(ChainingMetadataRepository.java:55) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.jboss.VDBService$6.run(VDBService.java:395) [teiid-jboss-integration-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.jboss.VDBService$7.run(VDBService.java:442) [teiid-jboss-integration-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (TEIID-3623) HBase translator - boolean and biginteger values are not translated correctly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3623?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3623:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1252385|https://bugzilla.redhat.com/show_bug.cgi?id=1252385] from MODIFIED to ON_QA
> HBase translator - boolean and biginteger values are not translated correctly
> -----------------------------------------------------------------------------
>
> Key: TEIID-3623
> URL: https://issues.jboss.org/browse/TEIID-3623
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1.6_2
> Environment: Hbase: 1.1.1
> Phoenix: 4.5.0-HBase-1.1
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Fix For: 8.7.1.6_2, 8.12
>
> Attachments: insert_biginteger.log, inser_boolean.log
>
>
> *1. Boolean values:* The Teiid translates the value true/false as 1/0, but HBase does not support integer representation of boolean values [1].
> *2. BigInteger values ( <= -2):* Teiid's bigInteger data type is wider than HBase's bigint (as wide as long) type, so it make sense to define column in HBase as e.g. _decimal(30,0)_ and map it to Teiid's biginteger type.
> From Teiid's point of view: There is no problem if inserted value is greater than or equal to -1. But if the value is less than -1, then a ClassCastException is thrown [2]. Phoenix driver require something like "UPSERT INTO smalla (intkey, bigintegervalue) VALUES (1, -10 *.0*)"
> [1]
> *Query:* insert into hbase.smalla (intkey, booleanvalue) values (55, true)
> *Column definition:*
> - source: booleanvalue boolean
> - VDB: BooleanValue boolean OPTIONS (nameinsource 'booleanvalue', NATIVE_TYPE 'boolean')
> *Stack trace:*
> insert_boolean.log
> [2]
> *Query:* insert into hbase.smalla (intkey, bigintegervalue) values (55, -10)
> *Column definition:*
> - source: bigintegervalue decimal(20,0)
> - VDB: BigIntegerValue biginteger OPTIONS (nameinsource 'bigintegervalue', NATIVE_TYPE 'decimal')
> *Stack trace:*
> insert_biginteger.log
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (TEIID-3625) JDG translator has disabled capabilities for GT and LT
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3625?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3625:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1252914|https://bugzilla.redhat.com/show_bug.cgi?id=1252914] from MODIFIED to ON_QA
> JDG translator has disabled capabilities for GT and LT
> ------------------------------------------------------
>
> Key: TEIID-3625
> URL: https://issues.jboss.org/browse/TEIID-3625
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1
> Reporter: Filip Elias
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> Operations GT and LT are not pushed down to JDG. Indexes are enabled for all columns. Operations GE and LE are pushed down correctly.
> Example:
> The first query is pushed down correctly. The second query doesn't push the "greater than" operator to the source.
> Query:
> {code}select intkey from smalla where intNum >= 5 order by intkey{code}
> PROCESSOR PLAN:
> {code}
> AccessNode(0) output=[c.intKey AS IntKey] SELECT g_0.intKey FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.intNum >= 5 ORDER BY g_0.intKey
> {code}
> Query:
> {code}select intkey from smalla where intNum > 5 order by intkey{code}
> Plan:
> {code}
> SortNode(0) output=[c.intKey AS IntKey] [SORT] [IntKey]
> ProjectNode(1) output=[c.intKey AS IntKey] [c.intKey AS IntKey]
> SelectNode(2) output=[c.intKey] c.intNum > 5
> AccessNode(3) output=[c.intNum, c.intKey] SELECT g_0.intNum, g_0.intKey FROM SmallAs.smallARemotecache AS g_0
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (TEIID-3616) HBase translator - NPE if date value is 'null'
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3616?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3616:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1252005|https://bugzilla.redhat.com/show_bug.cgi?id=1252005] from MODIFIED to ON_QA
> HBase translator - NPE if date value is 'null'
> ----------------------------------------------
>
> Key: TEIID-3616
> URL: https://issues.jboss.org/browse/TEIID-3616
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1.6_2
> Environment: Hbase: 1.1.1
> Phoenix: 4.5.0-HBase-1.1
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Fix For: 8.7.1.6_2, 8.12
>
> Attachments: log
>
>
> If the source table in HBase contains a 'NULL' date value, Teiid throws an NPE. I did not encounter any NPE using org.apache.phoenix.jdbc.PhoenixDriver [1]. Other data types seem to be OK too.
> I have tried integer, char, varchar, float, double, tinyint, smallint, bigint, decimal, varbinary, boolean, time, date, timestamp.
> [1]
> Connection con = new org.apache.phoenix.jdbc.PhoenixDriver().connect("jdbc:phoenix:localhost", new Properties())
> ResultSet rs = con.createStatement().executeQuery("select datevalue from smalla");
> while(rs.next()){
> System.out.println(rs.getDate(1));
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (TEIID-3665) Undeployable dynamic vdb if its runtime name does not have extension ".xml"
by Juraj Duráni (JIRA)
[ https://issues.jboss.org/browse/TEIID-3665?page=com.atlassian.jira.plugin... ]
Juraj Duráni commented on TEIID-3665:
-------------------------------------
A runtime name of the static VDB need not end with ".vdb" because "MountType.ZIP" is default. But it is better to encourage users to use *.vdb/*-vdb.xml extensions - just like in the documentation.
> Undeployable dynamic vdb if its runtime name does not have extension ".xml"
> ---------------------------------------------------------------------------
>
> Key: TEIID-3665
> URL: https://issues.jboss.org/browse/TEIID-3665
> Project: Teiid
> Issue Type: Bug
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 8.12
>
>
> If the runtime name of a dynamic VDB (*-vdb.xml) does not contain ".xml" extension, then it is undeployable \[3\]. If the runtime name does not contain ".xml", EAP tries to load it as zip \[2\].
> Management api commands \[1\]. I suggest to add at least note to the documentation.
> \[1\]
> - *fail:* /deployment=myvdb:add(runtime-name=myvdbrn,enabled=true,content=\[\{archive=false,path=/path/to/my-vdb.xml\}\])
> - *fail:* deploy /path/to/my-vdb.xml --name=myvdb --runtime-name=myvdbrn
> - *ok:* /deployment=myvdb:add(runtime-name=myvdbrn,enabled=+false+,content=\[\{archive=false,path=/path/to/my-vdb.xml\}\])
> *fail:* /deployment=myvdb:deploy
> \[2\]
> org.jboss.as:jboss-as-server:7.5.0.Final-redhat-21
> org.jboss.as.server.deployment.module.DeploymentRootMountProcessor#deploy(DeploymentPhaseContext)
> if(mountExploded) \{
> type = MountType.EXPANDED;
> \} else if (deploymentName.endsWith(".xml")) \{
> type = MountType.REAL;
> \} else \{
> type = MountType.ZIP;
> \}
> \[3\]
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit.newvdbxmlrn.STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit.newvdbxmlrn.STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "newvdbxmlrn"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018740: Failed to mount deployment content
> at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:97) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 5 more
> Caused by: java.util.zip.ZipException: error in opening zip file
> at java.util.zip.ZipFile.open(Native Method) [rt.jar:1.8.0_40]
> at java.util.zip.ZipFile.<init>(ZipFile.java:220) [rt.jar:1.8.0_40]
> at java.util.zip.ZipFile.<init>(ZipFile.java:150) [rt.jar:1.8.0_40]
> at java.util.jar.JarFile.<init>(JarFile.java:166) [rt.jar:1.8.0_40]
> at java.util.jar.JarFile.<init>(JarFile.java:130) [rt.jar:1.8.0_40]
> at org.jboss.vfs.spi.JavaZipFileSystem.<init>(JavaZipFileSystem.java:90) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.vfs.spi.JavaZipFileSystem.<init>(JavaZipFileSystem.java:77) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.vfs.VFS.mountZip(VFS.java:386) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.vfs.VFS.mountZip(VFS.java:410) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.as.server.deployment.DeploymentMountProvider$Factory$ServerDeploymentRepositoryImpl.mountDeploymentContent(DeploymentMountProvider.java:105) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:93) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 6 more
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (TEIID-3658) VDBs may start before transport service
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3658?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3658:
---------------------------------------
> Would trying to avoid VDB specific properties in subsysystem if possible
I agree that there's lots of overhead with adding subsystem properties, but there should be a default setting so that someone can easily keep the same behavior as they have today without modifying each deployed vdb - otherwise this won't be acceptable as a patch. So maybe use a system property to set the default behavior?
> VDBs may start before transport service
> ---------------------------------------
>
> Key: TEIID-3658
> URL: https://issues.jboss.org/browse/TEIID-3658
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Priority: Critical
> Fix For: 8.12
>
>
> VDBs may start before transport services, which is an issue for ODBC access as the enabled flag on the vdbrepository is toggled in by the transport. Any vdbs loaded prior to that point will not be properly accessible.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (TEIID-3665) Undeployable dynamic vdb if its runtime name does not have extension ".xml"
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3665?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3665.
-----------------------------------
Fix Version/s: 8.12
Resolution: Done
Seems like this was well covered in the past, but I couldn't find many direct references currently. So the vdb definition and deploy doc pages have now been updated.
> Undeployable dynamic vdb if its runtime name does not have extension ".xml"
> ---------------------------------------------------------------------------
>
> Key: TEIID-3665
> URL: https://issues.jboss.org/browse/TEIID-3665
> Project: Teiid
> Issue Type: Bug
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 8.12
>
>
> If the runtime name of a dynamic VDB (*-vdb.xml) does not contain ".xml" extension, then it is undeployable \[3\]. If the runtime name does not contain ".xml", EAP tries to load it as zip \[2\].
> Management api commands \[1\]. I suggest to add at least note to the documentation.
> \[1\]
> - *fail:* /deployment=myvdb:add(runtime-name=myvdbrn,enabled=true,content=\[\{archive=false,path=/path/to/my-vdb.xml\}\])
> - *fail:* deploy /path/to/my-vdb.xml --name=myvdb --runtime-name=myvdbrn
> - *ok:* /deployment=myvdb:add(runtime-name=myvdbrn,enabled=+false+,content=\[\{archive=false,path=/path/to/my-vdb.xml\}\])
> *fail:* /deployment=myvdb:deploy
> \[2\]
> org.jboss.as:jboss-as-server:7.5.0.Final-redhat-21
> org.jboss.as.server.deployment.module.DeploymentRootMountProcessor#deploy(DeploymentPhaseContext)
> if(mountExploded) \{
> type = MountType.EXPANDED;
> \} else if (deploymentName.endsWith(".xml")) \{
> type = MountType.REAL;
> \} else \{
> type = MountType.ZIP;
> \}
> \[3\]
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit.newvdbxmlrn.STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit.newvdbxmlrn.STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "newvdbxmlrn"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018740: Failed to mount deployment content
> at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:97) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 5 more
> Caused by: java.util.zip.ZipException: error in opening zip file
> at java.util.zip.ZipFile.open(Native Method) [rt.jar:1.8.0_40]
> at java.util.zip.ZipFile.<init>(ZipFile.java:220) [rt.jar:1.8.0_40]
> at java.util.zip.ZipFile.<init>(ZipFile.java:150) [rt.jar:1.8.0_40]
> at java.util.jar.JarFile.<init>(JarFile.java:166) [rt.jar:1.8.0_40]
> at java.util.jar.JarFile.<init>(JarFile.java:130) [rt.jar:1.8.0_40]
> at org.jboss.vfs.spi.JavaZipFileSystem.<init>(JavaZipFileSystem.java:90) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.vfs.spi.JavaZipFileSystem.<init>(JavaZipFileSystem.java:77) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.vfs.VFS.mountZip(VFS.java:386) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.vfs.VFS.mountZip(VFS.java:410) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.as.server.deployment.DeploymentMountProvider$Factory$ServerDeploymentRepositoryImpl.mountDeploymentContent(DeploymentMountProvider.java:105) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:93) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 6 more
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (TEIID-3664) Only JDK 1.7 can build Teiid code base success
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3664?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3664.
-----------------------------------
Resolution: Rejected
We've been building under 1.8 since TEIID-3081. Including ever release I've run.
Can you provide more specifics about what you are seeing?
> Only JDK 1.7 can build Teiid code base success
> ----------------------------------------------
>
> Key: TEIID-3664
> URL: https://issues.jboss.org/browse/TEIID-3664
> Project: Teiid
> Issue Type: Quality Risk
> Components: Build/Kits
> Affects Versions: 8.12
> Reporter: Kylin Soong
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> The following depiction exist in README.md
> {code}
> install JDK 1.7 or higher
> {code}
> But the build commands
> {code}
> $ mvn clean install -P release -s settings.xml
> {code}
> will execute failed if use JDK 1.8
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
[JBoss JIRA] (TEIID-3665) Undeployable dynamic vdb if its runtime name does not have extension ".xml"
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3665?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-3665:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1257901
Bugzilla Update: Perform
> Undeployable dynamic vdb if its runtime name does not have extension ".xml"
> ---------------------------------------------------------------------------
>
> Key: TEIID-3665
> URL: https://issues.jboss.org/browse/TEIID-3665
> Project: Teiid
> Issue Type: Bug
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Priority: Minor
>
> If the runtime name of a dynamic VDB (*-vdb.xml) does not contain ".xml" extension, then it is undeployable \[3\]. If the runtime name does not contain ".xml", EAP tries to load it as zip \[2\].
> Management api commands \[1\]. I suggest to add at least note to the documentation.
> \[1\]
> - *fail:* /deployment=myvdb:add(runtime-name=myvdbrn,enabled=true,content=\[\{archive=false,path=/path/to/my-vdb.xml\}\])
> - *fail:* deploy /path/to/my-vdb.xml --name=myvdb --runtime-name=myvdbrn
> - *ok:* /deployment=myvdb:add(runtime-name=myvdbrn,enabled=+false+,content=\[\{archive=false,path=/path/to/my-vdb.xml\}\])
> *fail:* /deployment=myvdb:deploy
> \[2\]
> org.jboss.as:jboss-as-server:7.5.0.Final-redhat-21
> org.jboss.as.server.deployment.module.DeploymentRootMountProcessor#deploy(DeploymentPhaseContext)
> if(mountExploded) \{
> type = MountType.EXPANDED;
> \} else if (deploymentName.endsWith(".xml")) \{
> type = MountType.REAL;
> \} else \{
> type = MountType.ZIP;
> \}
> \[3\]
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit.newvdbxmlrn.STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit.newvdbxmlrn.STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "newvdbxmlrn"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018740: Failed to mount deployment content
> at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:97) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 5 more
> Caused by: java.util.zip.ZipException: error in opening zip file
> at java.util.zip.ZipFile.open(Native Method) [rt.jar:1.8.0_40]
> at java.util.zip.ZipFile.<init>(ZipFile.java:220) [rt.jar:1.8.0_40]
> at java.util.zip.ZipFile.<init>(ZipFile.java:150) [rt.jar:1.8.0_40]
> at java.util.jar.JarFile.<init>(JarFile.java:166) [rt.jar:1.8.0_40]
> at java.util.jar.JarFile.<init>(JarFile.java:130) [rt.jar:1.8.0_40]
> at org.jboss.vfs.spi.JavaZipFileSystem.<init>(JavaZipFileSystem.java:90) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.vfs.spi.JavaZipFileSystem.<init>(JavaZipFileSystem.java:77) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.vfs.VFS.mountZip(VFS.java:386) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.vfs.VFS.mountZip(VFS.java:410) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.as.server.deployment.DeploymentMountProvider$Factory$ServerDeploymentRepositoryImpl.mountDeploymentContent(DeploymentMountProvider.java:105) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:93) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 6 more
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month