[JBoss JIRA] (JBOSGI-604) FactoryConfigurationError: Provider __redirected.__DocumentBuilderFactory not found
by Thomas Diesler (JIRA)
Thomas Diesler created JBOSGI-604:
-------------------------------------
Summary: FactoryConfigurationError: Provider __redirected.__DocumentBuilderFactory not found
Key: JBOSGI-604
URL: https://issues.jboss.org/browse/JBOSGI-604
Project: JBoss OSGi
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
Assignee: Thomas Diesler
{code}
2012-09-14 12:25:33,183 | ERROR | rint Extender: 1 | BlueprintContainerImpl | 9 - org.apache.aries.blueprint - 0.3.2 | Unable to start blueprint container for bundle org.apache.aries.blueprint
javax.xml.parsers.FactoryConfigurationError: Provider __redirected.__DocumentBuilderFactory not found
at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:129)[:1.6.0_33]
at org.apache.aries.blueprint.container.Parser.getDocumentBuilderFactory(Parser.java:1345)[9:org.apache.aries.blueprint:0.3.2]
at org.apache.aries.blueprint.container.Parser.parse(Parser.java:203)[9:org.apache.aries.blueprint:0.3.2]
at org.apache.aries.blueprint.container.Parser.parse(Parser.java:219)[9:org.apache.aries.blueprint:0.3.2]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:254)[9:org.apache.aries.blueprint:0.3.2]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:230)[9:org.apache.aries.blueprint:0.3.2]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_33]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_33]
at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_33]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_33]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_33]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_33]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_33]
at java.lang.Thread.run(Thread.java:662)[:1.6.0_33]
{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, 6 months
[JBoss JIRA] (JBOSGI-591) Allow WAR deployments as OSGi bundles
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-591?page=com.atlassian.jira.plugin... ]
Thomas Diesler deleted JBOSGI-591:
----------------------------------
> Allow WAR deployments as OSGi bundles
> -------------------------------------
>
> Key: JBOSGI-591
> URL: https://issues.jboss.org/browse/JBOSGI-591
> Project: JBoss OSGi
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
>
> It should be possible to deploy webapps running on JBossWeb as OSGi bundles. The webapp can then be broken up in functional units (modularized in a standard way) which can be maintained separately.
> Needless to say that such webapps can natively integrate, make use of and provide OSGi services. Functionality can be turned on/off depending on service availability.
--
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, 6 months
[JBoss JIRA] (JBOSGI-590) Allow EE deployments as OSGi bundles
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-590?page=com.atlassian.jira.plugin... ]
Thomas Diesler deleted JBOSGI-590:
----------------------------------
> Allow EE deployments as OSGi bundles
> ------------------------------------
>
> Key: JBOSGI-590
> URL: https://issues.jboss.org/browse/JBOSGI-590
> Project: JBoss OSGi
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Thomas Diesler
>
> This essentially means that you can put OSGi metadata into an EE deployment manifest, which essentially makes it an OSGi bundle.
> Deployment unit processing should be such that the EE bundle gets resolved according to it's defined capabilities/requirements. Subsystem processors should not need to care whether the Module was created as a result of OSGi resolution or by the ModuleSpecProcessor.
> This task is complete when we can do this with the EE core technologies (i.e. webapp, ejb3, cdi)
--
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, 6 months