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

[Design of EJB 3.0] - Ejb3Deployment.resolveMessageDestination

by emuckenhuber

Following up on the current failures of the ejb30/mdb/dest tests.. The cause for those failures is that the messageDestinationResolver in the ejb3 module does not resolve the correct names for message-destination-refs. "scott.stark(a)jboss.org" wrote : | We really should not be calling the Ejb3Deployment.resolveMessageDestination any longer as this should have already been resolved by the MappedDeploymentEndpointResolver. Improvement on resolving message-destination-refs was the change I made yesterday. | That said - overriding the resolveMessageDestination in Ejb3JBoss5Deployment and using the correct information from MappedReferenceDeployer makes those tests pass (*) Basically there are only two places left where that is used: * org.jboss.injection.ResourceHandler * org.jboss.ejb3.Ejb3Deployment Furthermore ClientENCInjectionContainer is still refering to the messageDestinationResolver, but not using it anymore. (*) There are still two remaining failures due to this: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168503#4168503 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168519#4168519 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168519

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Pushing correct aspect manager for a deployment

by kabir.khan＠jboss.com

I have attempted to add the correct manager to the metadata for the deployment in my deployer | unit.getMutableMetaData().addMetaData(scopedManager, AspectManager.class); | This gets added to a MemoryMetaDataLoader with | ScopeKey=[APPLICATION=vfszip:/Users/kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-scopeddependency-scoped.sar] | However, the bean's MetaData does not contain that, it only contains MetaDataRetrievals for the following levels: | WORK=10814978] | [INSTANCE=ScopedManager_6_vfszip:/Users/kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-scopeddependency-scoped.sar] | [CLASS=class org.jboss.test.aop.scopeddependency.ScopedTester] | [JVM=THIS] | Is this a bug, or have I completely misunderstood? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168518#4168518 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168518

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Making the BPM API more generic?

by kukeltje

Hmmm... I admire JBoss having this discussion on a public forum. It is good to have the intention to achieve synergy. Personally though, I get the impession there are, at least to a certain extend, 2 competing camps. If I were a potential/current customer/user I'd become a little restless on where 'everything' (and I know I exaggerate) is going. 'Drools executing BPEL', jBPM runtime mappings? A second PVM, OSWorkflow?... Besides that, as an (upcomming) consultant, I to have to be able to rely on something. A stable API?afaik, the jBPM api was kind of stable. Not very transparant, but stable. In fact it is not that different from what Kris mentions for Drools. I know this is only partially a comment on the contents of this topic, but I thought I'd give my â¬0.0125 (at an exchangerate of 1:1.6) anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168515#4168515 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168515

17 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - messagingType optional issue

by scott.stark＠jboss.org

We are seeing problems with some of the tck tests not supplying a message-destination-type (it is optional in javaee5) and the activation layer complaining about this: | 23:38:41,162 INFO [EJBContainer] STARTED EJB: com.sun.ts.tests.ejb30.bb.mdb.dest.common.DestBean ejbName: DestBean | 23:38:41,225 ERROR [AbstractKernelController] Error installing to Start: name=jboss.j2ee:ear=mdb_dest_optional.ear,jar=mdb_dest_optional_ejb.jar,name=DestBean,service=EJB3 state=Create | org.jboss.deployers.spi.DeploymentException: Required config property RequiredConfigPropertyMetaData@350bd2[name=destinationType descriptions=[DescriptionMetaData@c234ef[language=en]]] for messagingType 'javax.jms.MessageListener' not found in activation config [ActivationConfigProperty(password=j2ee), ActivationConfigProperty(user=j2ee), ActivationConfigProperty(destination=MDB_QUEUE), ActivationConfigProperty(subscriptionDurability=false)] ra=jboss.jca:service=RARDeployment,name='jms-ra.rar' | at org.jboss.resource.deployment.ActivationSpecFactory.createActivationSpec(ActivationSpecFactory.java:95) | at org.jboss.resource.deployers.RARDeployment.createActivationSpec(RARDeployment.java:313) | at org.jboss.resource.deployers.RARDeployment.internalInvoke(RARDeployment.java:277) | at org.jboss.system.ServiceDynamicMBeanSupport.invoke(ServiceDynamicMBeanSupport.java:156 | Do we need to fill this info in or should this be getting defaulted? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168503#4168503 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168503

17 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: Custom data versions

by manik.surtani＠jboss.com

no, it won't be applied to side-effect nodes - perhaps one way to do this is to create the "side effect nodes" explicitly with the option? :-( Regarding the metadata, I see it more as an internal API rather than a public one. I.e., changes are made explicitly to a node - e.g., node.setResident( true ) and internally, this flag is stored in a MetaData object which is persisted/replicated along with the node. And regarding OL (and PL) I see these as being deprecated in 3.0. I would expect folk to focus on MVCC as I think this is far better thought out and conceptually more correct than either of the previous locking schemes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168498#4168498 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168498

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Making the BPM API more generic?

by mark.proctor＠jboss.com

Drools in M3 in about 3 weeks will be orienting away from a rules centric api to a knowledge centric api - i.e. it will not be process centric either, nor will it be tied to Drools. This has been planned for a while: http://www.mail-archive.com/rules-dev@lists.jboss.org/msg00757.html This api will be able to wrap, to some degree, other process engine apis. Our PVM will also be capable of executing their models. As proof of concepts krisv has done partial implementations for BPEL, OSWorkfow and jBPM. BPEL runtime is almost complete (Drools is able to execute most examples), although it has not been wired up to WS and still needs work on XML assignment issues. OSWorkflow and jBPM runtime mappings are about 70% complete. Diego from OSWorkflow is keen on finishing the OSWorkflow adaption. And I'm hoping someone else will take ownership of the BPEL side - we are in talks with large health organisation that is possible going to lend 2 resources for BPEL and WS-Human-Task implementation. We've checkout the Eclipse BPEL tooling and it's now much more improved and almost complete, making BPEL support with tooling now a possibility. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168496#4168496 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168496

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Making the BPM API more generic?

by KrisVerlaenen

"tom.baeyens(a)jboss.com" wrote : Are your API docs online ? A link would be great. Yes, of course, all Drools code can be found in our svn repository. But as it might be a bit difficult to find what you need in this web of classes, let me give you a high-level overview. Note that I will only include generic interfaces, specific process languages could extend some of these interfaces to offer more options to the end users. /* A process contains the definition of the business logic, specific process languages need to extend this interface. */ Process void setId(String id); String getId(); void setName(String name); String getName(); void setVersion(String version); String getVersion(); void setType(String type); String getType(); void setPackageName(String packageName); String getPackageName(); void setMetaData(String name, Object value); Object getMetaData(String name); /** End users that want to execute processes interact with a session */ Session ProcessInstance startProcess(String processId); ProcessInstance startProcess(String processId, Map<String, Object> parameters); public Collection getProcessInstances(); public ProcessInstance getProcessInstance(long id); /** A process instance represents one instance of a process that is currently executing, specific process languages need to extend this interface */ ProcessInstance long getId(); String getProcessId(); int getState(); void setState(int state); /* Events */ void signalEvent(String type, Object event); /* Variable Scope */ Object getVariable(String name); Map<String, Object> getVariables(); void setVariable(String name, Object value); /* Whenever the execution engine want to invoke external services, it does so using an abstract workitem (contains name-value parameters) */ WorkItemHandler void executeWorkItem(WorkItem workItem, WorkItemManager manager); void abortWorkItem(WorkItem workItem, WorkItemManager manager); /* Results of these invocations can be returned to the execution engine */ WorkItemManager void completeWorkItem(long id, Map<String, Object> results) void abortWorkItem(long id) Then there are of course also interfaces for storage and deployment, monitoring, etc. Note that these interfaces are generic and contain nothing specific about Drools Flow. Kris View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168489#4168489 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168489

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MC roadmap - 2.0.0.CR1/GA, Post Final, 3.x

by kabir.khan＠jboss.com

This will need to go into the next aop-mc-int release http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168487#4168487 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168488#4168488 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168488

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Pushing correct aspect manager for a deployment

by kabir.khan＠jboss.com

Whatever we go for this will need to be part of the next aop-mc-int release View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168487#4168487 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168487

17 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: Custom data versions

by bstansberry＠jboss.com

"manik.surtani(a)jboss.com" wrote : As a workaround, you could use a NonBlockingDataVersion in an option for ALL calls that touch any nodes in the OptimisticCacheProvider. If that results in all created-as-a-side effect parent nodes also getting the NonBlockingDataVersion, on both the local node and any remote node, that should work fine. :) "manik.surtani(a)jboss.com" wrote : | I think the DataVersionProvider concept should not be developed if DataVersions themselves are a deprecated concept. | | Metadata is a different story though - there is a JIRA about exposing node metadata as a single object that can be persisted, shipped around - which would include stuff like whether nodes are resident, whether data and child maps are ordered (potentially - this is in discussion), and some transient information like node validity, whether data and/or children are loaded, etc. | So would this include something like the "Provider" concept -- i.e. a solution to setting metadata on created-as-a-side-affect parent nodes that is different from the final child node? Also, even if DataVersion is deprecated, IMHO as long as it exists it should be included in any general solution to problems; e.g. if there were a NodeMetaData and NodeMetaDataProvider, NodeMetaData should include the data version as a property. As far as the Hibernate 2LC use case and JBC 3.0.0 goes, I have a hacky solution already for this problem. I'd like to get rid of it. Probably your solution of passing NonBlockingDataVersion will take care of it. If not, perhaps getting rid of it could mean "don't use OPTIMISTIC in your cache, use MVCC." Perhaps a general solution to metadata handling will take care of it, either in 3.0.0 or some later 3.x release. But at this point I don't see any reason this is a critical issue for 3.0.0. Doesn't seem like anything we are talking about would produce an incompatible change; i.e. something that has to go in the major release. It will probably be Q4 before we really start attacking a Hibernate/JBC3 integration in earnest anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168484#4168484 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168484

17 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2008