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

[Design of EJB 3.0] - Re: New persistence unit deployers

by scott.stark＠jboss.org

Why is the WEB-INF/classes/META-INF/persistence.xml needed? Is this just what you had to use to find the WEB-INF/classes/persistence.xml descriptor? I need to see an example war. I'll see if I can find one in the ejb3 testsuite. Deployment scoping should be determined by the class loader import/export policy under the new class loader. What is this comment about? // FIXME: if in EAR then unscoped else scoped An ear lib is not identified specially other than a deployment unit with an org.jboss.metadata.ear.spec.Ear5xMetaData attachment(type will be EarMetaData in terms of getting the attachment) with a libraryDirectory for which a VirtualFile exists. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108640#4108640 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108640

16 years, 10 months

1
0
0 / 0

[Design of JBoss Portal] - Translation update

by lucboudreau

I'll soon commit changes made to the french ressource bundles. I used a great Eclipse plugin for this. The downside is that it moves the messages in the keys alphabetic order. The plugin allows for quick and easy translation and helps us ensure that all messages are present in each bundle. It does a really great job and I suggest everyone working with bundles use it. It can be found here : http://www.resourcebundleeditor.com/wiki/ResourceBundleEditor There were some french bundles missing so I added them and edited the corresponding portlet.xml files accordingly. The affected modules will be : core-samples (users portlet sample), core-search, migration (the faces-config was modified here). There are still missing localized strings in some languages I can't translate (mainly italian) but the Eclipse plugin should help the persons responsible for the translation to spot them fast and easy. I'm currently running the tests to ensure I didn't screw anything up, so I'll soon add those changes to the 2.6 branch. Cheers ! Luc View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108624#4108624 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108624

16 years, 10 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Transaction Sticky LB policy for 4.2/trunk

by galder.zamarreno＠jboss.com

I have also seen that you have implemented the new load balance policies that didn't leak Invocation. As the new lbps use the Invocation parameter to check whether it contains a transient sticky target i'll be creating them in the org.jboss.ha.framework.interfaces package. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108617#4108617 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108617

16 years, 10 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Transaction Sticky LB policy for 4.2/trunk

by galder.zamarreno＠jboss.com

Ok, ic. Keeping the proxy implementations independent of any specific LBP has indeed some benefits. I'll keep it simple :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108597#4108597 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108597

16 years, 10 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Transaction Sticky LB policy for 4.2/trunk

by bstansberry＠jboss.com

I don't think #2 does much for you. Even if the LBP used by the proxy isn't "TransactionSticky" it's quite likely the class will be on the classpath, as it's packaged in the same jar as the other LBP impls. Anyway, -1 to it because you are hard-coding things so it only works if *your* TransactionSticky is on the classpath. Keep it simple; don't stress too much about a couple map operations. Walk a debugger through a complete method invocation on an EJB; the amount of stuff it goes through is amazing. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108580#4108580 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108580

16 years, 10 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - JBoss Remoting SVN conversion is today!

by david.lloyd＠jboss.com

We will be converting our current CVS repository to Subversion today at 5:00pm EST (that's 22:00 UTC). Around this time the CVS repository will be "locked down", and copied to the new SVN repository (this process should not take long; it only took a few minutes in my tests). Then we (the Remoting team) will be checking things over, and if everything looks OK we'll open up the Subversion repository for all to use. This means that if you've got outstanding work at the time the conversion takes place, you will not be able to commit it in to CVS. You'll have to wait until after the conversion, and then reapply your local changes into a fresh SVN checkout or something of that nature. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108529#4108529 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108529

16 years, 10 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Transaction Sticky LB policy for 4.2/trunk

by galder.zamarreno＠jboss.com

I had a prototype of this solution for a while, but I had encountered some issues while attempting to finalise it. These issues are (except for EJB3) now resolved and while looking back at the prototype, I came across this: At the beginning of the invocation, I do a get on the tx failover map passing the current tpc. If it returns not null, I add it to the invocation transient payload so that the load balance policy can choose the right target. Also, after the invocation has returned, I get the transaction sticky target from the transient map and put it with the tpc in the tx failover map. So far so good. At the moment, before these two sections, I check whether the load balance policy is instanceof TransactionSticky. This class does the work of checking whether a chosen target is in the invocation transient payload and if it isn't, delegates to a standard lbp). There're 4 matching versions (FA, R....etc) of TransactionSticky, each containing a delegate for the standard type. These matching lbps extend TransactionSticky. There's a problem though with just doing instanceof TransactionSticky. Pre transaction sticky clients would get a nice CNFE. I can see two alternatives: 1.- do not check instanceof TransactionSticky and do the lookup in the tx failover map and put the result as chosen target in the invocation transient map regardless. For non sticky versions, it would null would be returned from the map lookup and null would be put in the inv transient map. This would mean that all transactional invocations would have 3 added map operations added to the cost of the invocation. Not good and makes the code less readable. 2.- add a transient boolean instance variable to each proxy with the value of T.getCurrentT().getCCL().loadClass(TransactionSticky) being successfull AND lbp instanceof TransactionSticky returning true. I could then use this parameter in the proxy to avoid unnecessary map get/puts. This solution would safe 3 map operations per transactional invocation for non tx sticky situations. Both this solutions avoid possible issues with pre transaction sticky clients that won't have those classes. My personal preference is with 2, although I'm not 100% sure about the cost of a loadClass() vs cost of a map operation. I do imagine though that if clients cache the proxy and reuse it, the having the transient boolean option would perform much better. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108526#4108526 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108526

16 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: ExpressionEvaluator

by pete.muir＠jboss.org

Yeah, it doesn't actually do any damage to the evaluation of the expressions, just means we can't throw the exceptions that people are used to with Unified EL. I was half way through a set of if-then-else statements to allow us throw a generic exception and log the possible specific exceptions so I will finish that off as a workaround for now. Thanks :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108523#4108523 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108523

16 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: ExpressionEvaluator

by tom.baeyens＠jboss.com

at the time, i thought it was a cool thing that you didn't have to separate between value binding expressions and method binding expressions. now i still think that is cool, but the compatibility with what people know of unified expressions wins over the coolness argument. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108519#4108519 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108519

16 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: ExpressionEvaluator

by tom.baeyens＠jboss.com

i don't think we can currently support this in jPDL 3. it would require big changes, including schema updates that will be forced to all our user base. i do plan to make that separation in the next version of jPDL 4. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108517#4108517 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108517

16 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2007