[JBoss JIRA] (AS7-3822) Unable to deploy without Bundle-Manifest Version or with Bundle-ManifestVersion: 1
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-3822?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler commented on AS7-3822:
-------------------------------------
I believe Bundle-ManifestVersion: 1 is invalid.
There is actually no way to specify a Bundle-ManifestVersion less than 2.
We use this code to determine the bundle manifest version
{code}
// At least one of these manifest headers must be there
// Note, in R3 and R4 there is no common mandatory header
String bundleName = getManifestHeaderInternal(manifest, Constants.BUNDLE_NAME);
String bundleSymbolicName = getManifestHeaderInternal(manifest, Constants.BUNDLE_SYMBOLICNAME);
String bundleVersion = getManifestHeaderInternal(manifest, Constants.BUNDLE_VERSION);
if (bundleName == null && bundleSymbolicName == null && bundleVersion == null)
return -1;
String manifestVersion = getManifestHeaderInternal(manifest, Constants.BUNDLE_MANIFESTVERSION);
return manifestVersion != null ? Integer.parseInt(manifestVersion) : 1;
{code}
> Unable to deploy without Bundle-Manifest Version or with Bundle-ManifestVersion: 1
> ----------------------------------------------------------------------------------
>
> Key: AS7-3822
> URL: https://issues.jboss.org/browse/AS7-3822
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.1.0.Final
> Reporter: Rico Neubauer
> Assignee: Thomas Diesler
> Fix For: 7.1.2.Final
>
> Attachments: server.log
>
>
> Affects version 1.1.5, included in JBoss 7.1.final.
> OSGI-specification r4.core.pdf chapter 3.5.7 holds the rules for legacy (version 1) bundles.
> According to that a bundle without Bundle-ManifestVersion must be handles as Bundle-ManifestVersion: 1.
> Neither a bundle having Bundle-ManifestVersion: 1, not without a Bundle-ManifestVersion does deploy at all. You can only see "Starting deployment of ..." in the log, nothing else happens.
> See attached log file for a test showing the deployment of a bundle without/with version-1/with versio-2 ManifestVersion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] Created: (AS7-1738) CLI usability: unclear that the CLI is managing a domain not a host
by Radoslav Husar (JIRA)
CLI usability: unclear that the CLI is managing a domain not a host
-------------------------------------------------------------------
Key: AS7-1738
URL: https://issues.jboss.org/browse/AS7-1738
Project: Application Server 7
Issue Type: Bug
Components: CLI
Affects Versions: 7.0.1.Final, 7.0.0.Final
Reporter: Radoslav Husar
Assignee: Alexey Loubyansky
Looks to me that the CLI is behaving differently if you are running in a domain mode or in a stadnalone mode managing just a host. However it is not really clear from the CLI help messages.
In the following log
* the console does not say its running in the domain mode
* claims that the --profile argument is optional even though its indeed required
* does not say that it is not the master domain controller and refuses all changes anyway
{code}
[domain@rhusar:9999 /] add-jms-queue --help
Synopsis: add-jms-queue [--profile=profile_name] --name=queue_name [--entries=entry(,entry)*] [--selector=selector_name] [--durable=(true|false)]
Description: creates a JMS queue
Arguments:
profile - is allowed and required only in the domain mode, specifies the profile
in which the JMS resource should be created.
name - the name of the queue.
entries - an optional comma-separated list of JNDI names the queue should be bound under.
If not present, the name will be used as the JNDI name.
selector - optional selector.
durable - optional, specifies whether the queue should be durable or not (the default is true).
[domain@rhusar:9999 /] add-jms-queue --profile=ha --name=rQ
Operation add for address [
("profile" => "ha"),
("subsystem" => "messaging"),
("jms-queue" => "rQ")
] can only handled by the master Domain Controller; this host is not the master Domain Controller
[domain@rhusar:9999 /] add-jms-queue --name=rQ
--profile argument value is missing.
[domain@rhusar:9999 /] quit
Closed connection to rhusar:9999
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (AS7-4183) Cannot reference fragments in autostart capabilities
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-4183:
-----------------------------------
Summary: Cannot reference fragments in autostart capabilities
Key: AS7-4183
URL: https://issues.jboss.org/browse/AS7-4183
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Reporter: Thomas Diesler
Assignee: Thomas Diesler
Fix For: 7.1.2.Final
When enabling the felix admin console like this
{code}
<capability name="org.ops4j.pax.web:pax-web-jsp:1.1.2" startlevel="1"/>
<capability name="org.ops4j.pax.web:pax-web-jetty-bundle:1.1.2" startlevel="1"/>
<capability name="org.apache.felix:org.apache.felix.webconsole:3.1.6.SP1" startlevel="1"/>
<capability name="org.jboss.osgi.webconsole:jbosgi-webconsole:1.0.6" startlevel="1"/>
{code}
I see
{code}
12:18:33,516 ERROR MSC00001: Failed to start service jbosgi.AutoInstallProvider.COMPLETE: org.jboss.msc.service.StartException in service jbosgi.AutoInstallProvider.COMPLETE: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
Caused by: java.lang.IllegalArgumentException: Not a HostBundleState: jbosgi-webconsole:1.0.6
at org.jboss.osgi.framework.internal.HostBundleState.assertBundleState(HostBundleState.java:70)
at org.jboss.osgi.framework.internal.StartLevelPlugin.setBundleStartLevel(StartLevelPlugin.java:165)
at org.jboss.as.osgi.service.AutoInstallIntegration.startBundle(AutoInstallIntegration.java:268)
at org.jboss.as.osgi.service.AutoInstallIntegration$1.start(AutoInstallIntegration.java:180)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (JBJCA-762) Use real Connection type in ManagedConnection
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-762:
-------------------------------------
Summary: Use real Connection type in ManagedConnection
Key: JBJCA-762
URL: https://issues.jboss.org/browse/JBJCA-762
Project: IronJacamar
Issue Type: Task
Components: Code Generator
Reporter: Jesper Pedersen
Assignee: Jeff Zhang
The 'connection' variable in the generated ManagedConnection should be the class of the Connection implementation, like
{code}
private AcmeConnectionImpl connection;
{code}
and the following should be added to "associateConnection":
{code}
if (connection == null)
throw new ResourceException("Null connection handle");
if (!(connection instanceof AcmeConnectionImpl))
throw new ResourceException("Wrong connection handle");
this.connection = (AcmeConnectionImpl)connection;
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (JBJCA-759) ResourceAdapter vs. Serializable
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-759:
-------------------------------------
Summary: ResourceAdapter vs. Serializable
Key: JBJCA-759
URL: https://issues.jboss.org/browse/JBJCA-759
Project: IronJacamar
Issue Type: Task
Components: Code Generator
Reporter: Jesper Pedersen
Assignee: Jeff Zhang
We should add an option to let the ResourceAdapter class implement Serializable.
Resource adapter class name [AcmeResourceAdapter]:
Should the resource adapter class be Serializable (Y/Yes/N/No) [N]:
Resource adapter config properties [enter to quit]:
If the answer is "Y" then let the ResourceAdapter class implement the java.io.Serializable interface and set a serialVersionUID field to 1L.
If the answer is "N" then do
{code}
private transient ResourceAdapter ra;
{code}
for all objects that implements ResourceAdapterAssociation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months