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

[Design of POJO Server] - Re: appclient remote home regression

by ALRubinger

This is what I'm not understanding. I thought BasicJndiBindingPolicy was only for EJB3. EJB2 would follow a different pattern, and it's be handled there, no? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166053#4166053 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166053

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: appclient remote home regression

by scott.stark＠jboss.org

With the changes I made for JBMETA-79, all the appclient tests are passing. We can add a decorator, but the current BasicJndiBindingPolicy is simply broken for ejb2x behavior when there is a deployment summary with an ear scope, so it needs to be fixed. This was not being tested. All that was tested was an empty deployment summary. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166052#4166052 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166052

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: appclient remote home regression

by ALRubinger

I follow what you're getting at with the new test, "testRemoteHomeWithEarScope". Problem I see is that "sbeanMD" is not decorated with any JNDI Policy, instead falling back on the @Deprecated methods with too much (improper) logic. Why don't we introduce a JNDI Policy for EJB2, decorate with it at the deployer level, and get rid of the "detemine*" methods alltogether? I'm either sitting on the panacea of simple fixes which resolve all this, or am missing something big. :) S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166050#4166050 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166050

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: [jboss-metadata] No ResourceProcessor for JBoss50Creator

by ALRubinger

Hmm, AbstractComponentProcessor has no "process" method which handles a ResourceEnvironmentReferencesMetaData. Emanuel, does this look like the root cause why I'm not seeing these @Resource field-level annotations populated in my returned metadata? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166049#4166049 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166049

17 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Sweet life on the journal...

by clebert.suconic＠jboss.com

I was dealing with one of the most obscure bugs I had ever seen on my 20 years programming. After I found it, as aways it was a dumb and obvious bug, but it was a little hard to find this one: When the journal was creating a byte buffer, it was sending it to the JNI layer and it was immediately releasing the reference to the ByteBuffer. As the write was being done asynchronously, the ByteBuffer could be eventually released (GC) at the same time it was being written, what was creating gargabe on the journal. Well.. at least that was a good exercise during my tests, so I'm pretty sure the journal is loading data properly and dealing with holes on transactions. I have written a few Stress Tests to catch this bug. I can't reproduce this on a Unit Test. I will write a few more tests on Reload and incomplete transactions, and maybe make few other improvements on the journal. (Maybe improve the collections on the journal making it use less memory. I have a few ideas that I will input on the forums tomorrow). BTW: Most of the information is on the WIKI already. I have made a few modifications on the code regarding Transactions counter to deal with holes and I will put that on the WIKI tomorrow. (I'm writing the counter per journal file, as reclaiming could legally get part of a transaction). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166048#4166048 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166048

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: appclient remote home regression

by ALRubinger

So this was likely introduced in tandem with fixes for JBMETA-78. http://fisheye.jboss.org/changelog/JBossAS/?cs=76015 So the tests were also aligned to match: http://wiki.jboss.org/wiki/DevJNDIBinding ...which *does* call for a base name in EJB2.x Homes. Or are we confusing "EJB2.x Homes" for "EJB2.x View of EJB3"? If so, can we further remove *all* determine* logic from the object model and apply the LegacyEjbJndiPolicy to EJB2.x deployments via a new Deployer, much like I'm doing w/ BasicJndiBindingPolicy for EJB3? We're *still* fighting against each other in circles. :) I think the refactoring done in jboss-metadata to remove the JNDI Policy from the caller is the right direction in which to head, but please let me know how to want to handle the above. Also note, BasicJndiBindingPolicy *is* for EJB3...EJB2.x should be using another policy. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166047#4166047 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166047

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: appclient remote home regression

by scott.stark＠jboss.org

The problem is that the BasicJndiBindingPolicy that is the default used by the metadata layer is returning a remote home that is not compatible with the given jndi-name. Its returning the basename derived from the deployment summary which is an ejb3ism. I thought we had ejb2 style tests for the binding policy in metadata. Either the test is missing or its been changed to match the deployment scoped name, which is not compatible with how ejb2 homes are bound. https://jira.jboss.org/jira/browse/JBMETA-79 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166045#4166045 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166045

17 years, 8 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Coordination work

by julien＠jboss.com

Is the alias implementation started (Map<QName, Set>) ? I haven't seen sample yet. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166040#4166040 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166040

17 years, 8 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Coordination work

by julien＠jboss.com

one glitch I noticed is that in the explicit case, if a parameter is not explicit declared in a binding then it will simply never retain its state. It is visible in the explicit sample if you update PublicParametersPortletWindow1 juu1 parameter. The value is lost. I think it should rather remain private rather than being discarded, which would mean that in the explicit case this parameter is considered like a private parameters and is stored in the per window navigational state. Which would mean to add a Map<String, String[]> in the WindowNavigationalState to store such state. What do you think ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166038#4166038 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166038

17 years, 8 months

1
0
0 / 0

[Design of JBoss Portal] - Coordination work

by julien＠jboss.com

I worked a bit on the coordination: I started to redo the samples to better reflect the various use cases, for now I have done explicit and implicit, fallback will be redone tomorrow probably I have an initial impl for linking page parameters to bindings of a page. It is possible to try the implicit and explicit samples. - in the explicit case, one need to use a binding name with values, like http://localhost:8080/portal/portal/default/Coordination+Samples/Paramete... - in the implicit case, it only works with the empty namepaced parameters that are declared by a portlet and urls use the parameter name, like http://localhost:8080/portal/portal/default/Coordination+Samples/Paramete... The trick is that bindings are stored as empty namespaced parameters in the Map<QName, String[]> per page. So on an explicit page, the binding is stored as QName(XMLConstants.DEFAULT_NS_PREFIX, "binding1") and in the implicit case the binding is stored as QName(XMLConstants.DEFAULT_NS_PREFIX, "foo"). The PortalObjectCommandFactory take any parameter in the page URL and will update the PageNS Map<QName, String[]> using the XMLConstants.DEFAULT_NS_PREFIX prefix when building the QName from the url parameters. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166037#4166037 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166037

17 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 July 2008