May 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-4840) OSGi subsystem does not call BundleActivator

by Rico Neubauer (JIRA)

[ https://issues.jboss.org/browse/AS7-4840?page=com.atlassian.jira.plugin.s... ] Rico Neubauer reopened AS7-4840: -------------------------------- See my comment above - issue happens under certain deployment scenario. > OSGi subsystem does not call BundleActivator > -------------------------------------------- > > Key: AS7-4840 > URL: https://issues.jboss.org/browse/AS7-4840 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.1.2.Final (EAP) > Reporter: Rico Neubauer > Assignee: Thomas Diesler > Labels: osgi > Attachments: SimpleOSGi_1.0.0.201205181614.jar > > > Occurs with JBoss 7.1.2.Final (EAP) running with jbosgi-framework 1.3.0.Final > OSGi activators do not get called after bundle starts. Instead nothing happens. > Test bundle attached, but happens with any activator bundle. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-4840) OSGi subsystem does not call BundleActivator

by Rico Neubauer (JIRA)

[ https://issues.jboss.org/browse/AS7-4840?page=com.atlassian.jira.plugin.s... ] Rico Neubauer updated AS7-4840: ------------------------------- Steps to Reproduce: You can use attached simple OSGi bundle having an BundleActivator, or any other bundle with activator. Deploy it via JBoss-web-console was:You can use attached simple OSGi bundle having an BundleActivator, or any other bundle with activator. Thanks Thomas for looking into this. Unfortunately I have to reopen it. Seems it happens when deployed via JBoss-web-console (or when manually adding all the configuration to domain.xml). Here are my exact steps to reproduce: 1. Extracted Vanilla JBoss 7.1.2.Final 2. Added user via jboss/bin/add-user.bat 3. Started in domain mode: jboss/bin/domain.bat 4. Added bundle via http://localhost:9990/console/ with before created user. 5. Added and activated bundle to group "full". Below is the log outcome: {noformat} [Host Controller] 09:24:12,086 INFO [org.jboss.as.repository] (HttpManagementService-threads - 1) JBAS014900: Content an Speicherort D:\test\jboss-as-7.1.2.Final\domain\data\content\99\86f537e51f000eed004b5d23a5bc5afb6b51c4\content hinzugefügt [Server:server-one] 09:24:19,667 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "SimpleOSGi_1.0.0.201205181614.jar" [Server:server-one] 09:24:19,778 INFO [org.jboss.osgi.framework] (MSC service thread 1-8) JBOSGI011006: OSGi Framework - 1.3.0.Final [Server:server-one] 09:24:20,207 INFO [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011001: Bundle installed: jboss-osgi-logging:1.0.0 [Server:server-one] 09:24:20,220 INFO [org.jboss.osgi.framework] (MSC service thread 1-13) JBOSGI011001: Bundle installed: org.apache.felix.log:1.0.0 [Server:server-one] 09:24:20,264 INFO [org.jboss.osgi.framework] (MSC service thread 1-16) JBOSGI011001: Bundle installed: jboss-as-osgi-configadmin:7.1.2.Final [Server:server-one] 09:24:20,320 INFO [org.jboss.osgi.framework] (MSC service thread 1-7) JBOSGI011001: Bundle installed: org.jboss.spec.javax.servlet.jboss-servlet-api_2.5_spec:1.0.1.Final [Server:server-one] 09:24:20,354 INFO [org.jboss.osgi.framework] (MSC service thread 1-8) JBOSGI011001: Bundle installed: org.apache.felix.configadmin:1.2.8 [Server:server-one] 09:24:20,412 INFO [org.jboss.osgi.framework] (MSC service thread 1-15) JBOSGI011001: Bundle installed: osgi.enterprise:4.2.0.201003190513 [Server:server-one] 09:24:20,546 INFO [org.jboss.osgi.framework] (MSC service thread 1-10) JBOSGI011011: Starting bundles for start level: 1 [Server:server-one] 09:24:20,554 INFO [org.jboss.osgi.framework] (MSC service thread 1-10) JBOSGI011002: Bundle started: org.apache.felix.log:1.0.0 [Server:server-one] 09:24:20,585 INFO [org.jboss.osgi.framework] (MSC service thread 1-10) JBOSGI011002: Bundle started: org.apache.felix.configadmin:1.2.8 [Server:server-one] 09:24:20,591 INFO [org.jboss.osgi.framework] (MSC service thread 1-10) JBOSGI011002: Bundle started: jboss-osgi-logging:1.0.0 [Server:server-one] 09:24:20,594 INFO [org.jboss.osgi.framework] (MSC service thread 1-10) JBOSGI011002: Bundle started: jboss-as-osgi-configadmin:7.1.2.Final [Server:server-one] 09:24:20,595 INFO [org.jboss.osgi.framework] (MSC service thread 1-10) JBOSGI011000: OSGi Framework started [Server:server-one] 09:24:20,599 INFO [org.jboss.osgi.framework] (MSC service thread 1-5) JBOSGI011001: Bundle installed: SimpleOSGi:1.0.0.201205181614 [Server:server-one] 09:24:20,644 INFO [org.jboss.as.server] (host-controller-connection-threads - 1) JBAS018559: Deployed "SimpleOSGi_1.0.0.201205181614.jar" {noformat} > OSGi subsystem does not call BundleActivator > -------------------------------------------- > > Key: AS7-4840 > URL: https://issues.jboss.org/browse/AS7-4840 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.1.2.Final (EAP) > Reporter: Rico Neubauer > Assignee: Thomas Diesler > Labels: osgi > Attachments: SimpleOSGi_1.0.0.201205181614.jar > > > Occurs with JBoss 7.1.2.Final (EAP) running with jbosgi-framework 1.3.0.Final > OSGi activators do not get called after bundle starts. Instead nothing happens. > Test bundle attached, but happens with any activator bundle. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-4840) OSGi subsystem does not call BundleActivator

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-4840?page=com.atlassian.jira.plugin.s... ] Thomas Diesler moved JBOSGI-556 to AS7-4840: -------------------------------------------- Project: Application Server 7 (was: JBoss OSGi) Key: AS7-4840 (was: JBOSGI-556) Workflow: GIT Pull Request workflow (was: jira) Affects Version/s: 7.1.2.Final (EAP) (was: JBossOSGi 1.3.0) Component/s: OSGi (was: Core Framework) Security: (was: Public) > OSGi subsystem does not call BundleActivator > -------------------------------------------- > > Key: AS7-4840 > URL: https://issues.jboss.org/browse/AS7-4840 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.1.2.Final (EAP) > Reporter: Rico Neubauer > Assignee: Thomas Diesler > Labels: osgi > Attachments: SimpleOSGi_1.0.0.201205181614.jar > > > Occurs with JBoss 7.1.2.Final (EAP) running with jbosgi-framework 1.3.0.Final > OSGi activators do not get called after bundle starts. Instead nothing happens. > Test bundle attached, but happens with any activator bundle. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-4841) Poor handling of network failures between master Host Controller and slaves

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-4841: ------------------------------------- Summary: Poor handling of network failures between master Host Controller and slaves Key: AS7-4841 URL: https://issues.jboss.org/browse/AS7-4841 Project: Application Server 7 Issue Type: Bug Components: Domain Management Affects Versions: 7.1.2.Final (EAP), 7.1.1.Final Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Blocker Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 The detection and handling of network disruptions between slave HCs and masters is not working properly. 1) Network disruptions are not being detected until an operation is invoked from the master to the slave, and the detection will not happen until the TCP layer give up trying to transmit the message, which could take up to 20 mins with default linux tcp settings. 2) If no operation is invoked, or the TCP level detection has not happened yet, the master still regards the slave as registered. So if the network heals and the slave tries to reregister, the re-registration attempt will be denied. To solve this I am going to re-implement a variant of the ping-pong stuff we had in 7.0. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-4829) Some logging doesn't print i18n message

by Takayoshi Kimura (JIRA)

Takayoshi Kimura created AS7-4829: ------------------------------------- Summary: Some logging doesn't print i18n message Key: AS7-4829 URL: https://issues.jboss.org/browse/AS7-4829 Project: Application Server 7 Issue Type: Bug Components: Logging Affects Versions: 7.1.2.Final (EAP) Reporter: Takayoshi Kimura Assignee: James Perkins AS7 master HEAD. When booting JBoss with LANG=ja_JP.utf8, some messages appear in English though they have corresponding Japanese message. For example, JDBC-compliant message: {quote} 11:24:18,084 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 27) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) {quote} In ConnectorLogger.java: {code} @LogMessage(level = INFO) @Message(id = 10403, value = "Deploying JDBC-compliant driver %s (version %d.%d)") void deployingCompliantJdbcDriver(Class<? extends Driver> driver, int majorVersion, int minorVersion); {code} In ConnectorLogger.i18n_ja.properties: {code} deployingCompliantJdbcDriver=JDBC \u6E96\u62E0\u306E\u30C9\u30E9\u30A4\u30D0\u30FC %1$s (version %2$d.%3$d) \u3092\u30C7\u30D7\u30ED\u30A4\u3057\u3066\u3044\u307E\u3059\u3002 {code} (Native: deployingCompliantJdbcDriver=JDBC 準拠のドライバー %1$s (version %2$d.%3$d) をデプロイしています。) I'm attaching server.log and boot.log. -- 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, 1 month

1
4
0 / 0

[JBoss JIRA] (AS7-3199) RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present

by Ryan Carlson (JIRA)

[ https://issues.jboss.org/browse/AS7-3199?page=com.atlassian.jira.plugin.s... ] Ryan Carlson commented on AS7-3199: ----------------------------------- I just ran into this issue too. Sad that it won't be fixed... > RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present > --------------------------------------------------------------------------------------------- > > Key: AS7-3199 > URL: https://issues.jboss.org/browse/AS7-3199 > Project: Application Server 7 > Issue Type: Bug > Components: REST > Affects Versions: 7.1.0.CR1b > Reporter: Pavel Janousek > Assignee: Stuart Douglas > Attachments: ExampleJAXRS.war > > > If I packed WAR WebApp with more that one subclass of javax.ws.rs.Application, deployment fails with "JBAS011232: Only one JAX-RS Application Class allowed." > This is not correct because it is against JAX-RS 1.1. specs where invalid situation (in section 2.3.2) is only when "It is a n error for > more than one application to be deployed +at the same effective servlet mapping+". > If you have any objections, please compare to reference JEE6 and JAX-RS implementation represented by the GlassFish Prelude 3.1.1 application server with already +fully JEE6 platform support+. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-4063) Adding quick start for jboss-logging-tools

by Darrin Mison (JIRA)

Darrin Mison created AS7-4063: --------------------------------- Summary: Adding quick start for jboss-logging-tools Key: AS7-4063 URL: https://issues.jboss.org/browse/AS7-4063 Project: Application Server 7 Issue Type: Enhancement Reporter: Darrin Mison Assignee: Darrin Mison Creating quick start for jboss-logging-tools. Will demonstrate using i18n/l10n loggers, exceptions and generic messages. -- 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, 1 month

1
1
0 / 0

[JBoss JIRA] (AS7-4709) Duplicate keys in model -- Host controller complains

by Heiko Rupp (JIRA)

Heiko Rupp created AS7-4709: ------------------------------- Summary: Duplicate keys in model -- Host controller complains Key: AS7-4709 URL: https://issues.jboss.org/browse/AS7-4709 Project: Application Server 7 Issue Type: Bug Components: Domain Management Affects Versions: 7.1.1.Final Reporter: Heiko Rupp Assignee: Tomaz Cerar Priority: Critical Host controller complains sometimes [Host Controller] 14:38:03,748 ERROR [org.jboss.as.domain.http.api] (HttpManagementService-threads - 2) JBAS015100: Unexpected error executing model request: org.jboss.as.controller.OperationFailedRuntimeException: JBAS014662: Duplicate path element 'server' found [ "JBAS014662: Duplicate path element 'server' found" ] Enabling check for dups in RHQ shows that one culprit is the runtime info on mail [domain@localhost:9999 mail-session=java:jboss/mail/Default] :read-children-types { "outcome" => "success", "result" => ["server"] } [domain@localhost:9999 mail-session=java:jboss/mail/Default] pwd /host=master/server=server-one/subsystem=mail/mail-session=java:jboss/mail/Default [10:51:50] <pilhuhn> [domain@localhost:9999 mail-session=java:jboss/mail/Default] pwd [10:52:23] <pilhuhn> here the child-type from a mail-session is named "server", which collides with the /host=x/server=y key -- 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, 1 month

5
10
0 / 0

[JBoss JIRA] (AS7-4838) Real time updates to truststore within security realms.

by Darran Lofthouse (JIRA)

Darran Lofthouse created AS7-4838: ------------------------------------- Summary: Real time updates to truststore within security realms. Key: AS7-4838 URL: https://issues.jboss.org/browse/AS7-4838 Project: Application Server 7 Issue Type: Task Components: Domain Management, Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 7.2.0.Alpha1 Within the CLI we already have an example of how the trust store can be updated during runtime - we should update the use of a trust store within the security realms so that updates can be picked up at runtime, this could either be the addition or removal of certificates. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-4814) service jboss.osgi.as.initial.deployments.COMPLETE (missing) with disabled deployments

by Rico Neubauer (JIRA)

Rico Neubauer created AS7-4814: ---------------------------------- Summary: service jboss.osgi.as.initial.deployments.COMPLETE (missing) with disabled deployments Key: AS7-4814 URL: https://issues.jboss.org/browse/AS7-4814 Project: Application Server 7 Issue Type: Bug Components: OSGi Affects Versions: 7.1.2.Final (EAP) Reporter: Rico Neubauer Assignee: Thomas Diesler Attachments: jboss-as-osgi-service-PersistentBundlesIntegration.patch Occurs with JBoss 7.1.2.Final (EAP). Posting here in OSGI, since other commits of the file were also related to this component, please move if desired. When having deployments with attribute enabled="false" in domain.xml, the service jboss.osgi.as.initial.deployments.COMPLETE will not start-up, since in org.jboss.as.osgi.service.PersistentBundlesIntegration.InitialDeploymentTracker all deployments are read-in and only after all were deployed it is considered complete - in contrast to condition "after all enabled deployments are deployed" Following error message appears: {noformat} INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report JBAS014775: Neue fehlende/unbefriedigte Abhängigkeiten: (this is German, in English. sth. like Missing/unresolved dependencies) service jbosgi.integration.PersistentBundlesHandler.COMPLETE (missing) dependents: [service jbosgi.framework.INIT] service jboss.osgi.as.initial.deployments.COMPLETE (missing) dependents: [service jbosgi.integration.PersistentBundlesHandler] ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss AS 7.1.2.Final "Steropes" started (with errors) in 40516ms - Started 5594 of 5693 services (2 services failed or missing dependencies, 93 services are passive or on-demand) {noformat} Extract from https://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/... which shows the configuration attribute: {noformat}<xs:complexType name="server-groupDeploymentType"> <xs:annotation> <xs:documentation>A deployment that has been mapped to a server group.</xs:documentation> </xs:annotation> <xs:complexContent> <xs:extension base="base-deploymentType"> <xs:attribute name="enabled" use="optional" type="xs:boolean" default="true"> <xs:annotation> <xs:documentation>Whether the deployment deploy automatically when the server starts up. </xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> {noformat} e.g. this would be a disabled deployment: {noformat} <deployment enabled="false" name="com.company.project.jar" runtime-name="com.company.project.jar"/> {noformat} I will attach a proposed patch, doing a simple check for an enabled="false" attribute. -- 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, 1 month

2
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2012