[JBoss JIRA] (WFLY-783) Cannot get bytes from InputStream for DEPLOYMENT_ROOT VirtualFile.openStream() on second call
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-783?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler reopened WFLY-783:
---------------------------------
> Cannot get bytes from InputStream for DEPLOYMENT_ROOT VirtualFile.openStream() on second call
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-783
> URL: https://issues.jboss.org/browse/WFLY-783
> Project: WildFly
> Issue Type: Bug
> Components: OSGi, Server
> Reporter: Thomas Diesler
>
> The effect is that the copy of a installed OSGi bundle is 0bytes in the data/osgi-store area
> Digging into this shows that during the first call isDirectory() is false and the file gets mounted. The returned stream works fine. For the second call isDirectory() is true and e read() on the returned InputStream returns -1
> {code}
> public InputStream openStream() throws IOException {
> if(isDirectory()) {
> return new VirtualJarInputStream(this);
> }
> final VFS.Mount mount = VFS.getMount(this);
> return mount.getFileSystem().openInputStream(mount.getMountPoint(), this);
> }
> {code}
> I assume that the root VirtualFile
> {code}
> VirtualFile virtualFile = deploymentUnit.getAttachment(Attachments.DEPLOYMENT_ROOT).getRoot();
> {code}
> should be readable twice.
--
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
13 years
[JBoss JIRA] (WFLY-1233) Decouple naming & transaction from OSGi
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-1233?page=com.atlassian.jira.plugin.... ]
Thomas Diesler reopened WFLY-1233:
----------------------------------
> Decouple naming & transaction from OSGi
> ---------------------------------------
>
> Key: WFLY-1233
> URL: https://issues.jboss.org/browse/WFLY-1233
> Project: WildFly
> Issue Type: Task
> Components: OSGi
> Reporter: Thomas Diesler
>
> Currently the naming & transaction subsystem register services on behalf of OSGi
> {code}
> [tdiesler@tdvaio jboss-as]$ git grep "\"xservice\""
> naming/src/main/java/org/jboss/as/naming/subsystem/NamingSubsystemOSGiService.java: ServiceName serviceName = ServiceName.of("jbosgi", "xservice", regi
> transactions/src/main/java/org/jboss/as/txn/service/TransactionManagerService.java: serviceBuilder.addAliases(ServiceName.of("jbosgi", "xservice", Tran
> transactions/src/main/java/org/jboss/as/txn/service/UserTransactionService.java: serviceBuilder.addAliases(ServiceName.of("jbosgi", "xservice", UserTra
> {code}
--
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
13 years
[JBoss JIRA] (WFLY-1244) Dynamic dependencies for non OSGi deployments
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-1244?page=com.atlassian.jira.plugin.... ]
Thomas Diesler reopened WFLY-1244:
----------------------------------
> Dynamic dependencies for non OSGi deployments
> ---------------------------------------------
>
> Key: WFLY-1244
> URL: https://issues.jboss.org/browse/WFLY-1244
> Project: WildFly
> Issue Type: Task
> Components: OSGi, REST
> Reporter: Thomas Diesler
>
> Currently the RestEasyIntegrationTestCase deploys a JAXRS endpoint that integrates with an OSGi service. The endoint deployment does not trigger the OSGi subsystem to start up, but depends on the compendium being deployed. The compendium gets deployed during OSGi subsystem startup.
> There is currently no way for deployment foo to declare a dependency on deployment bar when bar gets deployed during subsystem startup, which gets triggered by deployment foo.
> OSGi has the notion of dynamic package import which seems to be required here for non-osgi deployments
--
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
13 years