June 2009 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?

by camunda

Okay, I have to investigate a bit more here as well. But i still think, there is a use case to use the CommandService, e.g. - sending Commands either via JMS asynchronously or execute the synchronously (think of batch operations) - migration from jbpm 3, would be possible to write a simple "CommandTranslator" and plug it in the CommandService, so you don't have to change existing client code using Commands (okay, maybe you have to change some, but not all) So basically I like the CommandService and want to keep it for sure in the API, don't make it internal please. And I still would like to see an EJB3 implementation. For us, the development team, to make it easier but as well for marketing purposes (even if you don't see it in the code, the people ask what runs under the hood). But maybe it doesn't have a high priority, ok... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236879#4236879 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236879

16 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Cleaning up Logging

by ALRubinger

I know we've discussed this before, but let's just get these on the table. I want to kill the following (to DEBUG): 12:53:39,374 WARN [StatelessBeanContext] EJBTHREE-1337: do not get WebServiceContext property from stateless bean context, it should already have been injected ...and... 12:53:39,382 WARN [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container ...and... 22:55:08,580 INFO [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext@988821214{vfsfile:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/profileservice-secured.jar/} ...and... 23:18:05,567 INFO [EJB3EndpointDeployer] Deploy AbstractBeanMetaData@6687ec13{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true} ...and... 23:18:05,572 INFO [Ejb3MetricsDeployer] Attaching MC Bean: SecureManagementView-metrics-instance Will make JIRAs for each Thursday pending no objections. S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236878#4236878 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236878

16 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Leaks.. leaks.. leaks...

by clebert.suconic＠jboss.com

another one is channels on RemotingConnection: references on QueueImpl(name=7sub2) !-- FieldReference private final org.jboss.messaging.core.server.Queue org.jboss.messaging.core.server.impl.ServerConsumerImpl.messageQueue=TOSTRING(org.jboss.messaging.core.server.impl.ServerConsumerImpl@326b9c84), class=org.jboss.messaging.core.server.impl.ServerConsumerImpl !--!-- FieldReference volatile java.lang.Object java.util.concurrent.ConcurrentHashMap$HashEntry.value=TOSTRING(java.util.concurrent.ConcurrentHashMap$HashEntry@54e9a7c2), class=java.util.concurrent.ConcurrentHashMap$HashEntry !--!--!-- arrayRef [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;[0] id=@939842843 !--!--!--!-- FieldReference transient volatile java.util.concurrent.ConcurrentHashMap$HashEntry[] java.util.concurrent.ConcurrentHashMap$Segment.table=TOSTRING(java.util.concurrent.ConcurrentHashMap$Segment@a25ef73[Unlocked]), class=java.util.concurrent.ConcurrentHashMap$Segment !--!--!--!--!-- arrayRef [Ljava.util.concurrent.ConcurrentHashMap$Segment;[10] id=@1082879033 !--!--!--!--!--!-- FieldReference final java.util.concurrent.ConcurrentHashMap$Segment[] java.util.concurrent.ConcurrentHashMap.segments=TOSTRING({0=org.jboss.messaging.core.server.impl.ServerConsumerImpl@326b9c84}), class=java.util.concurrent.ConcurrentHashMap !--!--!--!--!--!--!-- FieldReference private final java.util.Map org.jboss.messaging.core.server.impl.ServerSessionImpl.consumers=TOSTRING(org.jboss.messaging.core.server.impl.ServerSessionImpl@4cc5f20f), class=org.jboss.messaging.core.server.impl.ServerSessionImpl !--!--!--!--!--!--!--!-- FieldReference private final org.jboss.messaging.core.server.ServerSession org.jboss.messaging.core.server.impl.ServerSessionPacketHandler.session=TOSTRING(org.jboss.messaging.core.server.impl.ServerSessionPacketHandler@6c229ed4), class=org.jboss.messaging.core.server.impl.ServerSessionPacketHandler !--!--!--!--!--!--!--!--!-- FieldReference private org.jboss.messaging.core.remoting.ChannelHandler org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handler=TOSTRING(org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl@5722cc7e), class=org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl !--!--!--!--!--!--!--!--!--!-- FieldReference volatile java.lang.Object java.util.concurrent.ConcurrentHashMap$HashEntry.value=TOSTRING(java.util.concurrent.ConcurrentHashMap$HashEntry@4b7361e2), class=java.util.concurrent.ConcurrentHashMap$HashEntry !--!--!--!--!--!--!--!--!--!--!-- arrayRef [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;[0] id=@69165857 !--!--!--!--!--!--!--!--!--!--!--!-- FieldReference transient volatile java.util.concurrent.ConcurrentHashMap$HashEntry[] java.util.concurrent.ConcurrentHashMap$Segment.table=TOSTRING(java.util.concurrent.ConcurrentHashMap$Segment@28a50da4[Unlocked]), class=java.util.concurrent.ConcurrentHashMap$Segment !--!--!--!--!--!--!--!--!--!--!--!--!-- arrayRef [Ljava.util.concurrent.ConcurrentHashMap$Segment;[13] id=@1032432821 !--!--!--!--!--!--!--!--!--!--!--!--!--!-- FieldReference final java.util.concurrent.ConcurrentHashMap$Segment[] java.util.concurrent.ConcurrentHashMap.segments=OBJ(java.util.concurrent.ConcurrentHashMap@1532712380) !--!--!--!--!--!--!--!--!--!--!--!--!--!--!-- FieldReference private final java.util.Map org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.channels=TOSTRING(org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl@4959d87f), class=org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236874#4236874 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236874

16 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Multi-threaded replication

by clebert.suconic＠jboss.com

anonymous wrote : When the operation is replicated to the backup we must ensure that the state changes on any affected stateful objects must occur in the same order as they did on live. | don't forget about paging. Paging will add a bunch of messages to the queue, and that happens outside of the context of sending. Right now the server only allow us to control this at Session level. We need to ensure some control at Queue level also, somehow. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236873#4236873 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236873

16 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Leaks.. leaks.. leaks...

by clebert.suconic＠jboss.com

I have found a few leaks already on the code. Nothing that stops production...but affects the testsuite because of stop/start the servers. (stress tests are affect by those) I have added -XX:+PrintClassHistogram to the testsuite. If you call kill -3 you would see QueueImpl, MessageReference growing a lot, mainly on all the MultiThreadFailoverTests. One of the leaks I saw was Remoting has a reference to Management that has references to Queues. The management reference is never cleared. (maybe?) Another I saw was during a run on XALargeMessageMultiThreadFaviloverTest. Somewhere on management has a reference to the resourceManager. Operations are never released of that resourcemanager (maybe more than 1 resourceManager instance here). queues and messages are building up and the test could get OME depending on the memory settings. I would need more time to investigate those.. but maybe Tim and Jeff would have a better clue since this is your guys areas. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236871#4236871 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236871

16 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Journal Cleanup and Journal Compactor

by clebert.suconic＠jboss.com

Most databases will have an internalID and an userID (AKA Primary Key). If we change the journal to work this way, we could move IDs from one file to another. This would be a very simple solution, and very easy to implement. Also, we wouldn't need to do any external synchronizations. All would be controlled within the journal. This way, the compactor would just: | | List listOfIDs = .... find the list according the way you (Tim) specified, based on file usage.... | | | for (InternalID id: listOfIDs) | { | journal.startTransaction(); | journal.delete(internalID); | journal.append(PrimaryKey, data); | journal.commitTransaction(); | } Doing this, we would eliminate all the empty files like you said. And it would also fix the linked-list issue. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236870#4236870 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236870

16 years, 6 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: EJB3 managed component names and types

by ALRubinger

I'll reply to this one very generally. :) Citing: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156782 As an EJB3 team member, I don't have any opinion/input on what the mappings should be. Things like naming conventions and desired properties are requests of the Jopr project. I've introduced the test case in AS to halt the changing requirements. From the onset I haven't had clear definition, and we've had many change/release/integration requests already. Let's get everything ironed in contract in Branch_5_x, clear the test, and then merge when done. http://anonsvn.jboss.org/repos/jbossas/branches/Branch_5_x/testsuite/src/... S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236869#4236869 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236869

16 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?

by kukeltje

hmmm... ok, I did not know this. Time for me to start reading some more. I was under the same impression as Bernd and thinking about using the same approach. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236867#4236867 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236867

16 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - JBoss Reflection Questions

by flavia.rainone＠jboss.com

Ales, After taking a look at JBoss Reflection implementation, I have a few questions: - Why aren't the classes JavassistField, JavassistConstructor, JavassistMethod and JavassistReflectionFactory package-protected? Those names can be easily mistaken with JavassistFieldInfo, JavassistConstructorInfo, etc and they are only used inside their own package. -What is MutableMethodInfoCommand for? -At JavassistTypeInfo, what do the TODOS like the one below mean? //TODO: need to change the use of getType() here public boolean isCollection() { return Collection.class.isAssignableFrom(getType()); } I see that getType is deprecated. But what is the main idea behind this? - Are the Javassist Expression interfaces needed? I mean, from http://www.jboss.org/index.html?module=bb&op=viewtopic&t=148169&postdays=..., It is clear they were created for JBoss AOP integration. And I also see that those interfaces were not even implemented. Is it that all, or there is another use case for those? Just trying to define the priority of filling in these blanks. Plus, I've seen a TODO with JBMICROCONT-132 at ValueConvertor class and this task was resolved in 2006. You left an open question on whether we should remove the support for value creation via constructor with one String parameter. Do you have an answer to this question? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236866#4236866 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236866

16 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - ClassPool for JBoss Reflection

by flavia.rainone＠jboss.com

Kabir, As was mentioned at the f2f meeting, I'm responsible for completing the Javassist implementation for JBoss Reflection. Given all the work that Stale has done for https://jira.jboss.org/jira/browse/JBREFLECT-49, the main thing left is the ClassPool :). As far as I understand, the ClassPools you created for JBAOP-666 are the only ones compatible with AS CL structure and should be needed in order for the Javassist to work correctly inside AS, right? Can we move those ClassPools to jboss-reflect? Does this ClassPool structure does everything it is supposed to do or do I need to complement some functionality? Ales, talking about ClassPools, I think JBREFLECT-3 is outdated? Now ScopedClassPool is not enough anymore. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236863#4236863 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236863

16 years, 6 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 June 2009