[JBoss JIRA] Resolved: (AS7-867) Dependency issue on OSGi bundle in AS7
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-867?page=com.atlassian.jira.plugin.sy... ]
Thomas Diesler resolved AS7-867.
--------------------------------
Resolution: Rejected
The module identity of a bundle is
{code}
deployment.[symbolic-name].[version]
{code}
Have a look at AS7-768
> Dependency issue on OSGi bundle in AS7
> --------------------------------------
>
> Key: AS7-867
> URL: https://issues.jboss.org/browse/AS7-867
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Environment: jbossas7-beta3
> Reporter: Gary Brown
> Assignee: Thomas Diesler
> Attachments: TestBundle.jar, WS-Dependencies.war
>
>
> When I deploy the attached "TestBundle.jar" OSGi bundle (with activation set to eager in standalone.xml, to force it to activate),
> <subsystem xmlns="urn:jboss:domain:osgi:1.0" activation="eager">
> I get:
> 10:57:14,168 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Starting deployment of "TestBundle.jar"
> 10:57:14,273 INFO [org.jboss.as.osgi] (MSC service thread 1-3) Installing deployment: [TestBundle:1.0.0.201105171313,location=TestBundle.jar]
> 10:57:14,277 INFO [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-3) Install bundle: TestBundle:1.0.0.201105171313
> 10:57:14,282 INFO [stdout] (MSC service thread 1-3) Hello World!!
> 10:57:14,282 INFO [stdout] (MSC service thread 1-3) CREATED TEST SERVICE
> 10:57:14,294 INFO [org.jboss.osgi.framework.internal.HostBundleState] (MSC service thread 1-3) Bundle started: TestBundle:1.0.0.201105171313
> which is expected - i.e. the "Hello World!!" message is generated from the activator's start method, so indicates that the bundle has activated.
> However if I deploy a war that has a dependency on this module (WS-Dependencies.war), I get:
> 10:58:59,335 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) Starting deployment of "WS-Dependencies.war"
> 10:58:59,399 INFO [org.jboss.as.server] (MSC service thread 1-2) Service status report
> New missing/unsatisfied dependencies:
> service module.spec.service."deployment.TestBundle.jar".main (missing)
> 10:58:59,417 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Stopped deployment WS-Dependencies.war in 14ms
> 10:58:59,417 INFO [org.jboss.as.server] (MSC service thread 1-1) Service status report
> Newly corrected services:
> service module.spec.service."deployment.TestBundle.jar".main (no longer required)
> But if I do this same process with a TestBundle.jar that has no OSGi metadata (so just a plain jar), when I deploy the war I get:
> 11:08:19,704 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) Starting deployment of "TestBundle.jar"
> 11:08:34,780 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "WS-Dependencies.war"
> 11:08:34,849 WARN [org.jboss.wsf.stack.cxf.deployment.aspect.DescriptorDeploymentAspect] (MSC service thread 1-1) Spring not available, skipping check for user provided jbossws-cxf.xml / cxf.xml configuration files.
> 11:08:34,855 INFO [org.jboss.wsf.stack.cxf.metadata.MetadataBuilder] (MSC service thread 1-1) Add Service
> id=HelloPortType
> address=http://localhost:8080/WS-Dependencies/HelloPortType
> implementor=test.HelloPortTypeImpl
> invoker=org.jboss.wsf.stack.cxf.InvokerJSE
> serviceName={http://test/}HelloPortType
> portName={http://test/}HelloPortTypeImplPort
> wsdlLocation=null
> mtomEnabled=false
> 11:08:34,856 INFO [org.jboss.wsf.framework.management.DefaultEndpointRegistry] (MSC service thread 1-1) register: jboss.ws:context=WS-Dependencies,endpoint=HelloPortType
> 11:08:35,831 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (MSC service thread 1-1) Creating Service {http://test/}HelloPortType from class test.HelloPortType
> 11:08:36,215 INFO [org.apache.cxf.endpoint.ServerImpl] (MSC service thread 1-1) Setting the server's publish address to be http://localhost:8080/WS-Dependencies/HelloPortType
> 11:08:36,300 INFO [org.jboss.wsf.stack.cxf.deployment.WSDLFilePublisher] (MSC service thread 1-1) WSDL published to: file:/home/gbrown/NotBackedUp/testing/riftsaw/as7/jboss-7.0.0.Beta3/standalone/data/wsdl/WS-Dependencies.war/HelloPortType.wsdl
> 11:08:37,149 INFO [org.jboss.web] (MSC service thread 1-3) registering web context: /WS-Dependencies
> First line shows the plain jar being deployed.
> This seems to indicate that the OSGi bundle is not in a fully activated state from the jboss modules perspective?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 12 months
[JBoss JIRA] Moved: (AS7-867) Dependency issue on OSGi bundle in AS7
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-867?page=com.atlassian.jira.plugin.sy... ]
Thomas Diesler moved JBOSGI-454 to AS7-867:
-------------------------------------------
Project: Application Server 7 (was: JBoss OSGi)
Key: AS7-867 (was: JBOSGI-454)
Workflow: GIT Pull Request workflow (was: jira)
Component/s: OSGi
(was: Integration (JBoss))
Security: (was: Public)
> Dependency issue on OSGi bundle in AS7
> --------------------------------------
>
> Key: AS7-867
> URL: https://issues.jboss.org/browse/AS7-867
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Environment: jbossas7-beta3
> Reporter: Gary Brown
> Assignee: Thomas Diesler
> Attachments: TestBundle.jar, WS-Dependencies.war
>
>
> When I deploy the attached "TestBundle.jar" OSGi bundle (with activation set to eager in standalone.xml, to force it to activate),
> <subsystem xmlns="urn:jboss:domain:osgi:1.0" activation="eager">
> I get:
> 10:57:14,168 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Starting deployment of "TestBundle.jar"
> 10:57:14,273 INFO [org.jboss.as.osgi] (MSC service thread 1-3) Installing deployment: [TestBundle:1.0.0.201105171313,location=TestBundle.jar]
> 10:57:14,277 INFO [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-3) Install bundle: TestBundle:1.0.0.201105171313
> 10:57:14,282 INFO [stdout] (MSC service thread 1-3) Hello World!!
> 10:57:14,282 INFO [stdout] (MSC service thread 1-3) CREATED TEST SERVICE
> 10:57:14,294 INFO [org.jboss.osgi.framework.internal.HostBundleState] (MSC service thread 1-3) Bundle started: TestBundle:1.0.0.201105171313
> which is expected - i.e. the "Hello World!!" message is generated from the activator's start method, so indicates that the bundle has activated.
> However if I deploy a war that has a dependency on this module (WS-Dependencies.war), I get:
> 10:58:59,335 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) Starting deployment of "WS-Dependencies.war"
> 10:58:59,399 INFO [org.jboss.as.server] (MSC service thread 1-2) Service status report
> New missing/unsatisfied dependencies:
> service module.spec.service."deployment.TestBundle.jar".main (missing)
> 10:58:59,417 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Stopped deployment WS-Dependencies.war in 14ms
> 10:58:59,417 INFO [org.jboss.as.server] (MSC service thread 1-1) Service status report
> Newly corrected services:
> service module.spec.service."deployment.TestBundle.jar".main (no longer required)
> But if I do this same process with a TestBundle.jar that has no OSGi metadata (so just a plain jar), when I deploy the war I get:
> 11:08:19,704 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) Starting deployment of "TestBundle.jar"
> 11:08:34,780 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "WS-Dependencies.war"
> 11:08:34,849 WARN [org.jboss.wsf.stack.cxf.deployment.aspect.DescriptorDeploymentAspect] (MSC service thread 1-1) Spring not available, skipping check for user provided jbossws-cxf.xml / cxf.xml configuration files.
> 11:08:34,855 INFO [org.jboss.wsf.stack.cxf.metadata.MetadataBuilder] (MSC service thread 1-1) Add Service
> id=HelloPortType
> address=http://localhost:8080/WS-Dependencies/HelloPortType
> implementor=test.HelloPortTypeImpl
> invoker=org.jboss.wsf.stack.cxf.InvokerJSE
> serviceName={http://test/}HelloPortType
> portName={http://test/}HelloPortTypeImplPort
> wsdlLocation=null
> mtomEnabled=false
> 11:08:34,856 INFO [org.jboss.wsf.framework.management.DefaultEndpointRegistry] (MSC service thread 1-1) register: jboss.ws:context=WS-Dependencies,endpoint=HelloPortType
> 11:08:35,831 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (MSC service thread 1-1) Creating Service {http://test/}HelloPortType from class test.HelloPortType
> 11:08:36,215 INFO [org.apache.cxf.endpoint.ServerImpl] (MSC service thread 1-1) Setting the server's publish address to be http://localhost:8080/WS-Dependencies/HelloPortType
> 11:08:36,300 INFO [org.jboss.wsf.stack.cxf.deployment.WSDLFilePublisher] (MSC service thread 1-1) WSDL published to: file:/home/gbrown/NotBackedUp/testing/riftsaw/as7/jboss-7.0.0.Beta3/standalone/data/wsdl/WS-Dependencies.war/HelloPortType.wsdl
> 11:08:37,149 INFO [org.jboss.web] (MSC service thread 1-3) registering web context: /WS-Dependencies
> First line shows the plain jar being deployed.
> This seems to indicate that the OSGi bundle is not in a fully activated state from the jboss modules perspective?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 12 months
[JBoss JIRA] Closed: (AS7-646) NPE due to TCCL usage in clustering
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/AS7-646?page=com.atlassian.jira.plugin.sy... ]
Jason Greene closed AS7-646.
----------------------------
Resolution: Done
I believe this was fixed
> NPE due to TCCL usage in clustering
> -----------------------------------
>
> Key: AS7-646
> URL: https://issues.jboss.org/browse/AS7-646
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Reporter: Jason Greene
> Assignee: Paul Ferraro
> Fix For: 7.0.0.CR1
>
>
> AS7-635 has pointed out TCCL usage which is causing NPEs. If these descriptors are in the same module as the calling code, then it should just do Caller.class.getClassloader().
> (see http://community.jboss.org/wiki/ModuleCompatibleClassloadingGuide for more info why)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.clustering.jgroups.subsystem.ProtocolDefaultsService.find(ProtocolDefaultsService.java:95)
> at org.jboss.as.clustering.jgroups.subsystem.ProtocolDefaultsService.load(ProtocolDefaultsService.java:85)
> at org.jboss.as.clustering.jgroups.subsystem.ProtocolDefaultsService.start(ProtocolDefaultsService.java:76)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
> ... 3 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.clustering.infinispan.subsystem.EmbeddedCacheManagerDefaultsService.find(EmbeddedCacheManagerDefaultsService.java:131)
> at org.jboss.as.clustering.infinispan.subsystem.EmbeddedCacheManagerDefaultsService.load(EmbeddedCacheManagerDefaultsService.java:110)
> at org.jboss.as.clustering.infinispan.subsystem.EmbeddedCacheManagerDefaultsService.start(EmbeddedCacheManagerDefaultsService.java:84)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
> ... 3 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 12 months
[JBoss JIRA] Created: (AS7-813) configuration option to show/hide system/user application exceptions and possibly new api method for logging a system exception versus user application exception
by Scott Marlow (JIRA)
configuration option to show/hide system/user application exceptions and possibly new api method for logging a system exception versus user application exception
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: AS7-813
URL: https://issues.jboss.org/browse/AS7-813
Project: Application Server 7
Issue Type: Feature Request
Components: Logging
Reporter: Scott Marlow
Assignee: Jason Greene
Priority: Minor
I would like to be able to show/hide system exception call stacks in the logs based on a configuration option. The same for showing/hiding user application exception call stacks.
To support the above configuration change, I would like to see a way to log a system exception versus an user application exception.
By system exception, I mean any exception that is logged via a distinctive api method. Perhaps something like:
log.systemError(String message, Throwable infrastructureException);
This would help reduce the time it takes to debug infrastructure issues (e.g. the NPE at http://pastie.org/1917562 is well hidden which in itself is a bug).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 12 months
[JBoss JIRA] Created: (JBRULES-2211) StatefulKnowledgeSession leaves threads running
by Edson Tirelli (JIRA)
StatefulKnowledgeSession leaves threads running
-----------------------------------------------
Key: JBRULES-2211
URL: https://jira.jboss.org/jira/browse/JBRULES-2211
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.0.1.FINAL, 5.0.0.FINAL
Reporter: Edson Tirelli
Assignee: Edson Tirelli
Fix For: 5.1.0.M1
Hi all,
I've downloaded Drools fusion sample and started to make some changes to
the code (first of all wipe out the UI so I can test it easier).
I tried to get to a minimal set so I can run a console main class and see
what happens but I am facing a strange behaviour.
As soon as I start pushing events into the WorkingMemoryEntryPoint
("StockTick stream") a Thread - not daemonized since it blocks shutdown from
ending - is spawned and this prevents my JVM from shutting down (obviously
if I call System.exit(0) it will but I am avoiding this).
I've tried both to halt and dispose the session that this entry point
belongs but with no success. Does anyone know how could I get rid of this
thread?
==================
Hi Edson!
as I've already mentioned I've modified the sample so, if you get the StockTick sample and replace the Main class this will run fine.
The sample shuts down fine but as I saw it sets the JFrame uses frame.setDefaultCloseOperation( WindowConstants.EXIT_ON_CLOSE ); which in turn makes the trick.
Below the code of my modified main class:
package org.drools.examples.broker;
import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseConfiguration;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.conf.EventProcessingOption;
import org.drools.examples.broker.model.Company;
import org.drools.examples.broker.model.CompanyRegistry;
import org.drools.examples.broker.model.StockTick;
import org.drools.io.ResourceFactory;
import org.drools.runtime.StatefulKnowledgeSession;
import org.drools.runtime.rule.WorkingMemoryEntryPoint;
public class Main {
private static final String RULES_FILE = "/broker.drl";
static StatefulKnowledgeSession session;
static WorkingMemoryEntryPoint tickStream;
/**
* @param args
*/
public static void main(String[] args) throws Exception {
// set up and show main window
CompanyRegistry companies = new CompanyRegistry();
KnowledgeBuilder builder = KnowledgeBuilderFactory.newKnowledgeBuilder();
try {
builder.add( ResourceFactory.newInputStreamResource( Main.class.getResourceAsStream( RULES_FILE ) ),
ResourceType.DRL);
} catch ( Exception e ) {
e.printStackTrace();
}
if( builder.hasErrors() ) {
System.err.println(builder.getErrors());
System.exit( 0 );
}
KnowledgeBaseConfiguration conf = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
conf.setOption( EventProcessingOption.STREAM );
KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase( conf );
kbase.addKnowledgePackages( builder.getKnowledgePackages() );
session = kbase.newStatefulKnowledgeSession();
session.setGlobal( "services", new BrokerServices() {
public void log(String message) {
System.out.println(message);
}
});
for( Company company : companies.getCompanies() ) {
session.insert( company );
}
session.fireAllRules();
tickStream = session.getWorkingMemoryEntryPoint( "StockTick stream" );
for (int i=10;i>0;i--) {
tickStream.insert(new StockTick("RHT", i*10, System.currentTimeMillis()));
session.getAgenda().getAgendaGroup( "evaluation" ).setFocus();
session.fireAllRules();
}
session.dispose();
session.halt();
System.out.println("Still running...");
}
}
regards,
Rafael Ribeiro
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 12 months
[JBoss JIRA] Created: (JBRULES-2862) fusion not evicting events from memory when it should
by Radai Rosenblatt (JIRA)
fusion not evicting events from memory when it should
-----------------------------------------------------
Key: JBRULES-2862
URL: https://issues.jboss.org/browse/JBRULES-2862
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (fusion)
Affects Versions: 5.1.1.FINAL
Environment: windows xp, JDK 6u21
Reporter: Radai Rosenblatt
Assignee: Mark Proctor
using the following declaration:
declare Event
@role( event )
@duration ( duration )
@timestamp( finished )
end
when writing the following rule:
rule "Match Any Two Events In Window"
when
$eventOne : Event() over window:time( 3d ) from entry-point "Event Stream"
$eventTwo : Event() over window:time( 3d ) from entry-point "Event Stream"
then
//nothing
end
and simulating a long run (longer than 3 days), old events (older than 3 days) are not evicted from memory. however, dropping the $eventTwo line entirely evicts events from memory properly
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 12 months
[JBoss JIRA] Created: (JBRULES-2881) sliding window:length(1) sticks to old event
by Wolfgang Laun (JIRA)
sliding window:length(1) sticks to old event
--------------------------------------------
Key: JBRULES-2881
URL: https://issues.jboss.org/browse/JBRULES-2881
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.1.1.FINAL
Reporter: Wolfgang Laun
Assignee: Mark Proctor
A rule combining two events of type A and B, each "seen" through a sliding window of length 1 misfires. Rather that combining the latest A with the latest B, it keeps firing the latest B together with *all* old A's.
Interestingly, this effect disappears if the order of patterns in the rule is inverted. Given the event sequence: A, A, B, A, B, the
rule ab when A() over window:length(1) B() over window:length(1) then ... end
misfires, but
rule ba when B() over window:length(1) A() over window:length(1) then ... end
works correctly.
This may be related to JBRULES-2862.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 12 months
[JBoss JIRA] Created: (JBAS-9347) Create a "jboss-welcome.war" greeting page application
by David Lloyd (JIRA)
Create a "jboss-welcome.war" greeting page application
------------------------------------------------------
Key: JBAS-9347
URL: https://issues.jboss.org/browse/JBAS-9347
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: David Lloyd
Fix For: 7.0.0.CR1
The application should create a /index.html page in the root of the web server, and should contain a greeting message with some getting-started instructions and useful links. It should include instructions for how to remove the application from the configuration, and possibly even some functionality to carry that out.
It should work in both domain and standalone mode and it should be referenced from the configuration as a filesystem-backed deployment, not as managed content or as a hot deployment.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 12 months