December 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5543) [7.1] Intermittent failure due to missing OSGi service

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-5543?page=com.atlassian.jira.plugin.s... ] Thomas Diesler reassigned AS7-5543: ----------------------------------- Assignee: Thomas Diesler (was: David Lloyd) > [7.1] Intermittent failure due to missing OSGi service > ------------------------------------------------------ > > Key: AS7-5543 > URL: https://issues.jboss.org/browse/AS7-5543 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi, Server > Affects Versions: 7.1.2.Final (EAP) > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Priority: Critical > Fix For: 7.1.4.Final (EAP) > > > For the first OSGi related deployments we intermittently see > {code} > Services with missing/unavailable dependencies" => > ["jbosgi.integration.PersistentBundles.INSTALL > Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"webapp.war\".REGISTER > {code} > which is due to a race condition at subsystem startup. > h4. Background > At startup the framework goes through various phases > # Framework.CREATE > # Framework.INIT > # Framework.ACTIVE > During framework INIT persistent bundles (i.e. from a former run) are installed/started according to their persistent settings. > In terms of services it means that the Framework.INIT service may depend on a number of Bundle.INSTALLED or Bundle.ACTIVE services. This however cannot be modelled as service dependencies because it must be possible to uninstall a persistent bundle (i.e. remove the Bundle.INSTALL) service without taking the framework down. > Currently, we use a ServiceListener for the persistent Bundle services and install a PersistentBundles.COMPLETE service that Framework.INIT can actually depend on. > There is currently no guarantee that the PersistentBundles.COMPLETE service gets installed (and as a consequence that the Framework.INIT starts up) before the OSGi deployment does its phase checking for missing services. > AFAICS, there is currently no way to model this type of dependency properly without having this race condition. > A possible solution may be a notion of DependencyType.WEAK. The semantic would be a required dependency that can go away once the target service has reached its target state (or has failed) > h4. Example > * serviceA depends on serviceB with DependencyType.WEAK > * serviceA starts when serviceB has started > * serviceA stays UP when serviceB gets removed -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-6202) Deploying to a 7.2 DC with a 7.1.2 or 7.1.3 slave fails in OSGi

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-6202?page=com.atlassian.jira.plugin.s... ] Thomas Diesler resolved AS7-6202. --------------------------------- Resolution: Duplicate Issue Very likely duplicates AS7-5543 > Deploying to a 7.2 DC with a 7.1.2 or 7.1.3 slave fails in OSGi > --------------------------------------------------------------- > > Key: AS7-6202 > URL: https://issues.jboss.org/browse/AS7-6202 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP) > Reporter: Kabir Khan > Assignee: Thomas Diesler > Attachments: domain.xml, host.xml > > > I noticed this when working on the mixed-domain tests. The attached domain.xml and host.xml contain adjustments for the older slave to work (replacing the MERGE3 jgroups protocol with MERGE2, since 7.1.x does not have that version), and makes all its servers auto-start="false". > To reproduce, start up a DC built from master using those files. Then start up a slave HC built from 7.1.2.Final or 7.1.3.Final using a command like: > ./build/target/jboss-as-7.1.3.Final/bin/domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=127.0.0.1 -Djboss.management.native.port=19999 > Now in CLI: > {code} > [domain@localhost:9999 /] /deployment=test.war:add(content=[{"url" => "file:/Users/kabir/sourcecontrol/jboss-as7/git/jboss-as/testsuite/mixed-domain/target/deployments/MixedDomainDeployment_7_1_2_Final_TestCase/archives/test.war"}] > { > "outcome" => "success", > "result" => undefined, > "server-groups" => undefined > } > [domain@localhost:9999 /] /deployment=test.war:remove [domain@localhost:9999 /] /server-group=main-server-group/deployment=test.war:add(enabled=true) > { > "outcome" => "failed", > "result" => undefined, > "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.", > "rolled-back" => true, > "server-groups" => {"main-server-group" => {"host" => {"kabirs-macbook-pro.local" => {"server-one" => {"response" => { > "outcome" => "failed", > "result" => undefined, > "failure-description" => {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.osgi.as.module.registration.\"deployment.test.war:main\" Missing[jbosgi.Environment]"]}, > "rolled-back" => true > }}}}}} > } > {code} > The console log for the slave shows > {code} > [Server:server-one] 17:21:22,201 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "test.war" > [Server:server-one] 17:21:22,556 INFO [org.jboss.web] (MSC service thread 1-7) JBAS018210: Registering web context: /test > [Server:server-one] 17:21:22,771 INFO [org.jboss.as.server] (host-controller-connection-threads - 1) JBAS015870: Deploy of deployment "test.war" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.osgi.as.module.registration.\"deployment.test.war:main\" Missing[jbosgi.Environment]"]} > [Server:server-one] 17:21:22,814 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment test.war in 42ms > {code} > The deployment is very simple, and just contains an html file: > {code} > $unzip -l testsuite/mixed-domain/target/deployments/MixedDomainDeployment_7_1_2_Final_TestCase/archives/test.war > Archive: testsuite/mixed-domain/target/deployments/MixedDomainDeployment_7_1_2_Final_TestCase/archives/test.war > Length Date Time Name > -------- ---- ---- ---- > 210 12-17-12 16:34 index.html > -------- ------- > 210 1 file > {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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-6206) Deprecate AbstractWriteAttributeHandler constructor variants not based on AttributeDefinition

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-6206: ------------------------------------- Summary: Deprecate AbstractWriteAttributeHandler constructor variants not based on AttributeDefinition Key: AS7-6206 URL: https://issues.jboss.org/browse/AS7-6206 Project: Application Server 7 Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 7.2.0.Alpha1 Deprecate legacy usage. Extend the deprecation to subclasses that expose equivalent constructors. -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-6191) SimpleAttributeDefinition spams the logs with deprecation messages

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6191?page=com.atlassian.jira.plugin.s... ] Brian Stansberry reassigned AS7-6191: ------------------------------------- Assignee: Brian Stansberry > SimpleAttributeDefinition spams the logs with deprecation messages > ------------------------------------------------------------------ > > Key: AS7-6191 > URL: https://issues.jboss.org/browse/AS7-6191 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > Fix For: 7.2.0.Alpha1 > > > If an attribute is deprecated, SAD writes INFO messages in the log in both parse and the marshallAs methods. The superclass does it in validateAndSet. The superclass is sufficient. -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-6205) Remove WriteAttributeHandlers

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-6205: ------------------------------------- Summary: Remove WriteAttributeHandlers Key: AS7-6205 URL: https://issues.jboss.org/browse/AS7-6205 Project: Application Server 7 Issue Type: Sub-task Components: Domain Management Reporter: Brian Stansberry Fix For: 7.3.0.Alpha1 Parent task deprecates in 7.2; this task is to remove. -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBCLUSTER-302) AbstractJBossCacheService swallows root cause of exception

by Dennis Reed (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-302?page=com.atlassian.jira.plu... ] Dennis Reed resolved JBCLUSTER-302. ----------------------------------- Resolution: Done Fixed in Branch_2_0 (HA-Server-Cache-JBC 2.0.4.Final). Was already fixed slightly differently in trunk (root exception logged as DEBUG). > AbstractJBossCacheService swallows root cause of exception > ---------------------------------------------------------- > > Key: JBCLUSTER-302 > URL: https://issues.jboss.org/browse/JBCLUSTER-302 > Project: JBoss Clustering > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: HA-Server-Cache-JBC > Affects Versions: HA-Server-Cache-JBC 2.0.3.Final > Reporter: Dennis Reed > Assignee: Dennis Reed > > If an exception occurs in org.jboss.web.tomcat.service.session.distributedcache.impl.jbc.AbstractJBossCacheService#getSessionData, the exception message is logged, but the root cause is swallowed resulting in useless logging such as: > Problem accessing session data : class java.lang.NullPointerException null -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-6186) Mojarra 2.1.16 upgrade breaks Seam2.3.0 conversations

by Marek Schmidt (JIRA)

[ https://issues.jboss.org/browse/AS7-6186?page=com.atlassian.jira.plugin.s... ] Marek Schmidt commented on AS7-6186: ------------------------------------ Another weird problem. In the following app, I put things into the viewMap in the converter getAsString method (which is needed for implementing things, such as Seam EntityConverter) .if I have the "event.getFacesContext().getViewRoot().getViewMap(true);" call in the after restore view (which should be perfectly fine, as after restore view the UIViewRoot is set), I have to click the Record button twice to see the "bar". Removing the getViewMap call in the after restore view phase listner, I can see it after the first click. {code} @Model public class Action { private String foo; public String getFoo() { return foo; } public void recordViewMap() { foo = (String)FacesContext.getCurrentInstance().getViewRoot().getViewMap().get("foo"); } } {code} {code} @FacesConverter("org.jboss.seam.test.MyConverter") public class MyConverter implements Converter { public MyConverter() { } @Override public Object getAsObject(FacesContext context, UIComponent component, String value) { return null; } @Override public String getAsString(FacesContext context, UIComponent component, Object value) { context.getViewRoot().getViewMap().put("foo", "bar"); return (String)value; } } {code} {code} public class MyPhaseListener implements PhaseListener { @Override public void afterPhase(PhaseEvent event) { if (event.getPhaseId().equals(PhaseId.RESTORE_VIEW)) { // Removing this makes it work: event.getFacesContext().getViewRoot().getViewMap(true); } } @Override public void beforePhase(PhaseEvent event) { } @Override public PhaseId getPhaseId() { // TODO Auto-generated method stub return PhaseId.ANY_PHASE; } } {code} {code} <h:form> <div> Foo: <h:outputText value="#{action.getFoo()}" /> </div> <div> Converter: <h:outputText value="#{'converter'}"> <f:converter converterId="org.jboss.seam.test.MyConverter"/> </h:outputText> </div> <div> <h:commandButton value="Record" action="#{action.recordViewMap()}"/> </div> </h:form> {code} > Mojarra 2.1.16 upgrade breaks Seam2.3.0 conversations > ----------------------------------------------------- > > Key: AS7-6186 > URL: https://issues.jboss.org/browse/AS7-6186 > Project: Application Server 7 > Issue Type: Bug > Components: JSF > Affects Versions: 7.1.4.Final (EAP) > Environment: Current 7.1.4.Final-SNAPSHOT (2012-12-15), Mojarra 2.1.16, Seam2.3.0.Final > Reporter: Marek Schmidt > Assignee: Stan Silvert > Priority: Critical > Attachments: AS7-6186-viewMap.tar, AS7-6186-viewMap.war, seam-booking.ear > > > Recent Mojarra upgrade seems to break Seam 2.3.0 conversations. > Not exactly sure yet what has changed and whether it is a Mojarra bug or Seam depending on something it shouldn't. -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBCLUSTER-302) AbstractJBossCacheService swallows root cause of exception

by Dennis Reed (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-302?page=com.atlassian.jira.plu... ] Dennis Reed moved JBPAPP-10502 to JBCLUSTER-302: ------------------------------------------------ Project: JBoss Clustering (was: JBoss Enterprise Application Platform 4 and 5) Key: JBCLUSTER-302 (was: JBPAPP-10502) Issue Type: Bug (was: Support Patch) Workflow: jira (was: JBoss Platforms Support Case Workflow v1) Affects Version/s: HA-Server-Cache-JBC 2.0.3.Final (was: EAP_EWP 5.1.2) Support Case Reference: (was: https://c.na7.visual.force.com/apex/Case_View?id=500A000000BeyXVIAZ) SVN / CVS Isolated Branch: (was: https://svn.jboss.org/repos/jbossas/projects/cluster/ha-server-cache-jbc/...) Patch Visibility: (was: Public) Component/s: HA-Server-Cache-JBC (was: Clustering) Fix Version/s: (was: One Off Releases) Docs QE Status: (was: NEW) > AbstractJBossCacheService swallows root cause of exception > ---------------------------------------------------------- > > Key: JBCLUSTER-302 > URL: https://issues.jboss.org/browse/JBCLUSTER-302 > Project: JBoss Clustering > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: HA-Server-Cache-JBC > Affects Versions: HA-Server-Cache-JBC 2.0.3.Final > Reporter: Dennis Reed > Assignee: Dennis Reed > > If an exception occurs in org.jboss.web.tomcat.service.session.distributedcache.impl.jbc.AbstractJBossCacheService#getSessionData, the exception message is logged, but the root cause is swallowed resulting in useless logging such as: > Problem accessing session data : class java.lang.NullPointerException null -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3707) ObjectDataCompiler converter does not compile all template rules

by Guy Baharav (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3707?page=com.atlassian.jira.plug... ] Guy Baharav updated JBRULES-3707: --------------------------------- Environment: Windows 7 32 bit Eclipse version - Juno Java version 1.7 was:Windows 7 32 bit Working project to reproduce problem attached > ObjectDataCompiler converter does not compile all template rules > ---------------------------------------------------------------- > > Key: JBRULES-3707 > URL: https://issues.jboss.org/browse/JBRULES-3707 > Project: JBRULES > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: drools-compiler (expert) > Affects Versions: 5.3.0.Final > Environment: Windows 7 32 bit > Eclipse version - Juno > Java version 1.7 > Reporter: Guy Baharav > Assignee: Mark Proctor > Labels: Commpiler, Templates > Attachments: Pricing.rar > > > When trying to compile a rule template with a datasource of a lot of rows (more than 1000), the compilers only compiles the first 1286 lines in the datasource. > Here is the code I am using: > //50,000 classes are created in the collection > Collection<FRTRule> freights = FilesLoader.GetFreightRules(); > ObjectDataCompiler converter = new ObjectDataCompiler(); > //a very simple rule template is loaded. > final InputStream templateStream = new Object().getClass().getResourceAsStream( "/Rules/Freight.drl" ); > //only 1286 rules are created in the drl string. > String drl = converter.compile( freights, templateStream ); > Here is the rules template syntax: > template header > pol > package com.zim.pricing.rules > import com.zim.PricingPOC.PricingUI.FRTRule; > template Pricing > rule "Pricing_(a){row.rowNumber}" > when > m : FRTRule(pol == "@{pol}") > then > m.setPol("1"); > end > end template > What could the reason be that the compiler only compiles 1286 rules? > Thanks, > Guy -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3707) ObjectDataCompiler converter does not compile all template rules

by Guy Baharav (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3707?page=com.atlassian.jira.plug... ] Guy Baharav updated JBRULES-3707: --------------------------------- Attachment: Pricing.rar Working project to reproduce problem > ObjectDataCompiler converter does not compile all template rules > ---------------------------------------------------------------- > > Key: JBRULES-3707 > URL: https://issues.jboss.org/browse/JBRULES-3707 > Project: JBRULES > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: drools-compiler (expert) > Affects Versions: 5.3.0.Final > Environment: Windows 7 32 bit > Reporter: Guy Baharav > Assignee: Mark Proctor > Labels: Commpiler, Templates > Attachments: Pricing.rar > > > When trying to compile a rule template with a datasource of a lot of rows (more than 1000), the compilers only compiles the first 1286 lines in the datasource. > Here is the code I am using: > //50,000 classes are created in the collection > Collection<FRTRule> freights = FilesLoader.GetFreightRules(); > ObjectDataCompiler converter = new ObjectDataCompiler(); > //a very simple rule template is loaded. > final InputStream templateStream = new Object().getClass().getResourceAsStream( "/Rules/Freight.drl" ); > //only 1286 rules are created in the drl string. > String drl = converter.compile( freights, templateStream ); > Here is the rules template syntax: > template header > pol > package com.zim.pricing.rules > import com.zim.PricingPOC.PricingUI.FRTRule; > template Pricing > rule "Pricing_(a){row.rowNumber}" > when > m : FRTRule(pol == "@{pol}") > then > m.setPol("1"); > end > end template > What could the reason be that the compiler only compiles 1286 rules? > Thanks, > Guy -- 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

11 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2012