August 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Eclipse IDE (dev)] - Re: Tutorial 1.2.2 Deployment problem

by ttkong

I have encountered the same problem: 18:06:59,866 WARN [verifier] EJB spec violation: Bean : Fibo Section: 22.2 Warning: The Bean Provider must specify the fully-qualified name of the Java class that implements the enterprise bean's business methods in the <ejb-class> element. Info : Class not found on 'tutorial.ejb.FiboBean': No ClassLoaders found for: tutorial.ejb.FiboBean 18:06:59,866 ERROR [MainDeployer] Could not create deployment: file:/C:/JBOSSIDE-1.6.0/jboss-4.0.4.GA/server/default/tmp/deploy/tmp47761FiboApp.ear-contents/FiboEJB.jar org.jboss.deployment.DeploymentException: Verification of Enterprise Beans failed, see above for error messages. at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:610) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) However, the problem did not happen then I perform the tutorial in another machine with the same software versions. Who can help explaining this situation? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3963968#3963968 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3963968

19 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: JPDL Eclipse Graphical Editor - problem building.

by kukeltje

Koen, Some other small things regarding the GPD build: - add the target dir to cvs ignore - add the target/output dir for the classes to the .project file explicitly on the designer source tree and have it point to the same dir as in the ant file (that prevents the javac issue I posted before, which happend on the new ws dir I added locally as well until I added an explicit target/output dir. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3963930#3963930 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3963930

19 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jbpm drools integration meeting

by kukeltje

I know some things about drools and use it (and probably will use it in a major financial system in the Netherlands, but I still have to convince people). Some things I read above: 1: anonymous wrote : This scenario allows for rule bases to be deployed and managed separately from processes but in the same repository. andanonymous wrote : A special simplified use case is when a process archive contains a set of rules in source format.sounds contradictory, do I miss something? anonymous wrote : In a process you can then say 'fireAllRules' without specifying a specific rule base. All rules specific to that process right? or also global rules? Making processes dependend on global rules in not neccesarilly a problem, but keeping referential integrity is. 2: I cannot grasp the first part of this paragraph which might be the reason for the next questions anonymous wrote : In a subsequent process operation, you might want to fire all rules again. Currently, that would require that all the process variables will have to be fed in again.I do not think this is unwanted behaviour since the chances are big they have changed anonymous wrote : By default, jBPM will fire all rules when a process variable is updated.I hope you mean after all process variables in a transaction are updated. I do not (never?) want rules to go of after one update if I update several variables in e.g. a task And why automatically? What is the usecase for this. Isn't doing it explicitly in an actionhandler/decisionnode/custom node enhough? 3: Initially this sounds ok, but this introduces the chance people start signalling tasks/nodes from within JBoss Rules (not drools anymore right ;-)). you get a mix then of the pd and the rules which might lead to a more complex definition. We internally made the choice to let the rules have a minimal impact on the process, just return an outcome and have the pd use that info to e.g. make a decision. Since we WANT to store the outcome anyway, we have a mapping of the outcome of the rules to a process variable and NOT have the rules definition set the process variable. The only situation where we want to have the rules engine start a number of tasks is in a custom node (not implemented yet) is in a kind of evaluation system where depending on the outcome each of 100 rules, either a task should be started, a message send or some dossier has to be updated e.g. | if (var1 > 10) { | start task2; | risk = risk + 10; | } | | if (var2 = "yes") { | start task5; | send message3; | } | | etc... | This is one rulebase (customer risk assertion) which will fire. We'd like the tasks to be separately defined in the pd (due date etc...) but created if needed (create task=false or even skip the node) Maybe we can take this as an example usecase and see how JBoss rules fits in this) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3963929#3963929 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3963929

19 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Pushing beans into the kernel

by scott.stark＠jboss.org

One thing I'm hung up on in terms of the SARDeployer migration is getting the ServerImpl bean into the kernel for use by the JMXKernel so that a ServerImplMBean can be exposed. What I have tried to do is just put the server instance into the kernel registry with a ControllerState.CONFIGURED requiredState and state value: | // Register the Server instance in the kernel | KernelRegistry registry = getKernel().getRegistry(); | AbstractKernelRegistryEntry serverEntry = new AbstractKernelRegistryEntry(server) | { | @Override | public ControllerState getRequiredState() | { | return ControllerState.CONFIGURED; | } | | @Override | public ControllerState getState() | { | return ControllerState.CONFIGURED; | } | }; | registry.registerEntry("org.jboss.system.server.Server", serverEntry); | | // Validate that everything is ok | kernelDeployer.validate(); | however the validation of the deployer-beans.xml initialization is failing with this error: | *** DEPLOYMENTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State} | JMXKernel -> org.jboss.system.server.Server{Configured:Configured}, JMXClassLoader{Described:Installed} | SARDeployer -> JMXClassLoader{Described:Installed}, JMXKernel{Configured:Instantiated}, JMXKernel{Configured:Instantiated} | It looks like everything is to the required state so I'm not sure why this error is occuring. What is it telling me? The bigger question is what is the correct way to push a fully Instantiated bean into the kernel for use in dependency relationships? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3963925#3963925 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3963925

19 years, 8 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: Real classloader required before WAR startup

by scott.stark＠jboss.org

The scan of the deployment in the vdf happens during the analyze phase so that the result and associated management objects are available to the profileservice. There may not be a meaningful deployment class loader as the deployment processing can be run offline. Anything you are doing now under the current trunk branch is going to have to be ported to the virtual deployment framework based deployers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3963904#3963904 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3963904

19 years, 8 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: Real classloader required before WAR startup

by bill.burke＠jboss.com

Is there any reason we couldn't set up the appropriate classloaders before scanning for dependencies? I guess what i'm saying is that I don't want to use Javassist and a throwaway Resource classloader and that I'd rather use reflection and the real classloader that is going to be used by the application. Eh, maybe I'm just being lazy, but I just spent a bunch of time refactoring the injection code and I don't want to do it again. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3963885#3963885 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3963885

19 years, 8 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: Real classloader required before WAR startup

by scott.stark＠jboss.org

In the old deployment impl that was the purpose of the DeploymentInfo.localCl. However it had no integration with other deployment contexts. In the new vdf you should be able to scan for classes/resources using the vfs. This should be a common aspect that all deployers used to build up the deployment metadata from classes and xml descriptors. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3963875#3963875 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3963875

19 years, 8 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Real classloader required before WAR startup

by bill.burke＠jboss.com

I'm running into a Catch 22 in integrating the EE5 injection stuff I'm doing. I need a classloader set up and initialized before the start of the Web container so that I can scan classes for annotations and set up any XML injeciton targets . This classloader needs to be the same classloader that will be used by the servlet container to instantiate servlets. The problem is that the classloader, currently, is not created until the web container is initialized and I need to set up the ENC and injeciton targets before the container is initialized. This is a bit a function of how I implemented the injection code. It pre-initializes all the injection target information by setting up lists of reflection objects that will be used to do the injection. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3963823#3963823 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3963823

19 years, 8 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: classloader problems in doing injection framework

by scott.stark＠jboss.org

This is only on startup of the server or for any war deployment? The webservice deployer will not be a sar that integrates via jmx events in jboss5. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3963804#3963804 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3963804

19 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - jbpm drools integration meeting

by tom.baeyens＠jboss.com

This is a report of the jBPM drools meeting we just had in london. 1) Rules deployment model is quite different from jBPM's deployment model. This discussion brought us to an interesting conclusion: there does not seem to be an obvious common model on how domain specific sources end up on a runtime deployed system. Drools and jBPM will keep their current deployment models. But as part of the jBPM-drools integration, we worked out how we can build a unified process-rules repository. Basically, the idea will be that the unified repository will be a jBPM database, extended with a table for rule bases. A rule base will be stored as a blob and referenced by a name. Then from inside of a process, you can reference the rule bases by name. This scenario allows for rule bases to be deployed and managed separately from processes but in the same repository. A special simplified use case is when a process archive contains a set of rules in source format. In that case a default rule base will be created and associated with the process. The process and the rules will then appear to the user as one logical entity. In a process you can then say 'fireAllRules' without specifying a specific rule base. Processes will contain a mapping between logical names and rulebases. Rule bases can be referenced in the unified process repository or in any other location. One of the referenced rule bases can be the default rule base. 2) Process variables as facts. In each process operation you can already feed in all the process variables into a working memory. This will fire rules and many of the intermediate results will be kept in the working memory. In a subsequent process operation, you might want to fire all rules again. Currently, that would require that all the process variables will have to be fed in again. Re-asserting all the variables as facts is not desirable: all the concequences will be re-fired with potential side effects This implies redoing a lot of calculations of which the result was available in the working memory. Currently, there is no way to store the working memory, restore it later and re-install the process variables as facts into the working memory again. Mark will be adding support for storing and retrieving working memories. A working memory is composed of facts and an agenda. The solution will be to store the agenda and a mapping between rule-fact-handles and process variables. At working-memory reconstruction time, the agenda will be deserialized and the mapping will be used to rebind the rule-fact-handles in the agenda to the process variables. By default, jBPM will fire all rules when a process variable is updated. The working memory will be stored as process execution data (along side the process variables). 3) making process objects (varables, taskInstance, token, ...) available on the right hand side in rules as global variables. Drools will add an interface like this public interface VariableResolver { Object resolveVariable(String name); } Then jBPM and SEAM can provide a different implementations that know about the contextual objects. All questions and remarks on this strategic directions are appreciated. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3963768#3963768 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3963768

19 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2006