July 2007 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Annotation features

by alesj

"adrian(a)jboss.org" wrote : | Instead, you should use the MetaData from the MetaDataRepository for that instance. | That is where the overridden annotations are stored at the instance level. | | BasicKernelMetaDataRepository.java | | /** | * Initialise metadata retrieval | * | * TODO lots more work | * @param context the context | * @return the retrieval | */ | protected MetaDataRetrieval initMetaDataRetrieval(KernelControllerContext context) | { | MutableMetaDataRepository repository = getMetaDataRepository(); | ScopeKey scopeKey = context.getScope(); | ArrayList<MetaDataRetrieval> retrievals = new ArrayList<MetaDataRetrieval>(); | for (Scope scope : scopeKey.getScopes()) | This is probably where this should already be stored/done, but the TODO is not that overwhelming ... :-) I'm trying to do this: | // properties | Set<PropertyInfo> properties = info.getProperties(); | if (properties != null && properties.isEmpty() == false) | { | for(PropertyInfo pi : properties) | { | Signature pis = new MethodSignature(pi.getName(), Configurator.getParameterTypes(trace, new TypeInfo[]{pi.getType()})); | MetaDataRetrieval cmdr = retrieval.getComponentMetaDataRetrieval(pis); | if (cmdr != null) | { | System.out.println("cmdr = " + cmdr); | } | } | } | Or what's the way to 'join' info from MetaDataRetrieval and [Class|Property|Method]Info, and populate BeanMetaData. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066662#4066662 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066662

18 years, 5 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Allow setAutoCommit(false) on managed connections

by adrian＠jboss.org

That would be in violation of the spec. JavaEE5 EE.6.2.4.2 anonymous wrote : | | The component | should not attempt to change the transaction characteristics of the connection, | commit the transaction, roll back the transaction, or set autocommit mode. | Attempts to make changes that are incompatible with the current transaction | context may result in a SQLException being thrown. The EJB speci?cation | contains the precise rules for enterprise beans. | It would also break the semantics of the code: | Connection c = dataSource.getConnection(); | try | { | c.setAutoCommit(false); | // do multiple operations | } | finally | { | if (errorOccurred) | c.rollback(); | else | { | c.commit(); | // HERE WE KNOW THE WORK WAS DONE | } | } | The proposed change would mean we need to ignore the c.commit() as well (the JTA transaction handles it) so the assumption in the above code is broken. I suspect what you really asking for is a piece of configuration that already exists. i.e. use a no-tx-datasource such that the code controls the transaction and not the appserver. Or use NOT_SUPPORTED transaction demarcation (so the connection is not enlisted in a JTA transaction - there isn't one). i.e. You have a misunderstanding about what the real requirements are. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066645#4066645 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066645

18 years, 5 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - JBAS-4574 and JBAS-1476

by adrian＠jboss.org

As mentioned on JBAS-4574 you need to discuss things on the forums before opening JIRA issues. This avoids wrong conclusions and hacks to workaround problems (JBAS-1476) when the original problem should be fixed. On JBAS-4574 Ben appears to claim (its not clear actually what he claims) that the problem is that naming context is getting cached. This is irrelevant. For HAJNDI the naming context uses the cluster view for the transport (regardless of how many naming contexts you create). It is the fact that it is using the cluster view from a different cluster instance (JBAS-1476) that is the problem. It doesn't update the view because the "view change" is less than it previously was. That's not to say that there isn't a case for flushing the cached naming context on a naming CommunicationException and transparently recreating it, but that doesn't help in thise case since the underlying problem will not be fixed. And such a change would require significant testing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066629#4066629 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066629

18 years, 5 months

1
0
0 / 0

[Design of JCA on JBoss] - Allow setAutoCommit(false) on managed connections

by dimitris＠jboss.org

This was raised as a JIRA feature request on EAP, so I'm copying the request here. I'm not sure yet what the proper workflow would be, i.e. where EAP issues should be discussed, before JIRAs are opened against the corresponding projects (i.e. AS in this case). anonymous wrote : | Invoking setAutoCommit(false) on a managed connection should simply be ignored instead of rising an exception. | | It is not a sensible thing to do, of course, but some frameworks do this. | It would be nice to have this feature, making JBoss more flexible and tolerant towards 3rd party software that has this deficiency. http://jira.jboss.com/jira/browse/JBPAPP-243 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066625#4066625 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066625

18 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Usage of the new jboss50 new deployer architecture

by thomas.diesler＠jboss.com

The hooks work mutually exclusive. i.e. there is one hook for every type of deployment. The hooks themselves delegate to a DeloymentAspectManager, which excecutes the DeploymentAspects - the work of those aspects are rolled back on failure. | // start the deployment | for (int i = 0; i < getDeploymentAspects().size(); i++) | { | DeploymentAspect aspect = getDeploymentAspects().get(i); | try | { | logInvocation(aspect, "Start"); | aspect.start(dep); | } | catch (RuntimeException rte) | { | while (i-- >= 0) | { | // destroy the deployment | failsafeDestroy(aspect, dep); | } | throw rte; | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066606#4066606 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066606

18 years, 5 months

1
0
0 / 0

[Design of JBossXB] - Re: JBoss-4.0.4.GA and XB-1.0.0.CR5+

by rodgerca

I'm having the same problem on v4.2 - did you figure out what it was? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066553#4066553 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066553

18 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Scheduling of services

by beve

Hi, I've updated the wiki page with the suggestion given here. Tom, could you take a look an make sure that this is what you meant? I might need this sooner that I had previously thought. For our WSGateway we need to perform an additional task before creating the SOAP message as we need to pass variable arguments to the web service. We need to maintain state between calls and we also need to perform a task after the message has been retreived to update the state. The way I've been doing it was letting the WSGateway have an abstract method so that subclasses can perform tasks prior to invoking the web service. And subclasses can also implement a method that will be invoked after the action processing pipleline is completed by waiting for a reply like this: | TwoWayCourier replyCourier = CourierFactory.getPickupCourier( replyEpr ); | try | { | Message replyMessage = replyCourier.pickup( maxMillisForResponse ); | responseMethod.invoke( responseObject, new Object[] { replyMessage }); | } | I think I'm instead going to use the a scheduling listener only to trigger an action pipeline process that starts a jBPM process, so the compose method will simply create an empty ESB Message object. The jBPM process will perform the first task which will add information to the ESB Message object and then invoke a service that sends the message to the web service(using a SOAPClient action). The final step in the process will be the updating of the state which will complete the jBPM process. Any comments or suggestion on this are welcome? Thanks, Daniel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066543#4066543 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066543

18 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Property lookup interceptors

by alesj

"alesj" wrote : | I'll just focus on the actual value-factory. Done. http://jira.jboss.com/jira/browse/JBMICROCONT-197 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066467#4066467 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066467

18 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Region management issues

by bstansberry＠jboss.com

Last monologue post... When we think about regions, keep in mind that PojoCache adds a 3rd use case beyond marshalling and eviction. For PojoCache, the presence of a region functions as a mechanism to scope reference sharing of pojos. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066424#4066424 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066424

18 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Region management issues

by bstansberry＠jboss.com

Sorry, my last paragraph about finding regions faster is semi-nonsense. You only get a benefit if there is a marshalling region at a depth below the eviction region. Not total nonsense though, as that can happen with the Hibernate use case. Related to the speed of finding regions, seems we lost the stuff Elias did in 1.4 where we tracked the depth of the deepest Fqn used to create a Region. Then for any getRegion() request we trim the passed-in Fqn to that depth, and only start looking at that level or higher. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066423#4066423 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066423

18 years, 5 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 July 2007