[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
12 years
[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
12 years
[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
12 years
[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
12 years
[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
12 years
[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
12 years