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

[Design of POJO Server] - Re: DeploymentInfo and DeploymentContext information

by scott.stark＠jboss.org

The classes used and mentioned in http://wiki.jboss.org/wiki/Wiki.jsp?page=JBoss5DeploymentFramework is org.jboss.deployers.spi.deployer.DeploymentUnit. There is no use of DeploymentInfo by the new framework. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984056#3984056 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984056

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Task Forms

by kukeltje

anonymous wrote : I have a slight preference for a bean because developers will understand the bean way more rapidly. The special variable resolver might seem like magic. Something which is not appreciated in the post-ejb2 era :-) | Me to. anonymous wrote : ......Yes that solves my problem and is the best solution. Agree, well... it still leaves the issue of what to do with forms that are adapted but get another transition. Should the form-generator take this into account and add something? One of the things I hated in the staffware forms things was the 'yes you can change the form once it is generated it, but do not think you can change things in the proces View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984053#3984053 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984053

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Task Forms

by tom.baeyens＠jboss.com

"david.lloyd(a)jboss.com" wrote : Ok, in that case probably it's more appropriate to say: | <h:inputText value="#{var['payment ID']}"/> | | "tom.baeyens(a)jboss.com" wrote : Also I not so sure if a dependency on the runtime environment is a problem if that environment is properly documented and makes use of known technologies. | | But requiring certain beans to be present is a nuicance. I don't want the task forms to be expecting certain managed beans, because this restricts my ability to make changes. | I see. But you have to fix something anyway. Either a bean or a special variable resolver. The var[...] notation is more concise. I have a slight preference for a bean because developers will understand the bean way more rapidly. The special variable resolver might seem like magic. Something which is not appreciated in the post-ejb2 era :-) Afaik, all my arguments are on the table. Now you can just decide what you think is best. "david.lloyd(a)jboss.com" wrote : | <tf:button transition="to receive payments" .../> | ...but still be able to specify all the standard JSF button attributes as well, including images, ID, styleClass, etc. | Yes that solves my problem and is the best solution. As for the task form generation planning, Koen is now finishing a fix for a bug that disabled the task form generation in 3.2.Alpha1. Once that is done, i want to release 3.2.Alpha2 (hopefully before the end of the week). That version should give you a good basis for testing the task forms in the web console. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984046#3984046 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984046

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: How should deployers obtain a propper CL?

by alesj

Look at AbstractTopLevelClassLoaderDeployer (and its test: TestClassLoaderDeployer). You can define a CL in your -beans.xml for all beans or for a single bean. And you can probably use the same CL in deployer - for instance through KernelDeployment (see BeanDeployer). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984039#3984039 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984039

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - DeploymentInfo and DeploymentContext information

by vickyk

I was under the impression that the DeploymentInfo would have been removed from the Jboss5 but it looks that it is still present there. I am not sure if VDF still need the DeploymentInfo , can you please provide some hint as where to find how the DeploymentInfo is populated in Jboss5 . I was expecting the DeploymentContext replacing the DeploymentInfo but it seems that is not the case . View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984031#3984031 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984031

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Possible optimization of CachedSetImpl

by ben.wang＠jboss.com

"genman" wrote : 1. I actually don't know the difference ... I may have copied that from the original implementation. The tests seemed to pass. What's the sematic difference? attach/detach/find will go through the proper PojoCache interceptors (e.g., tx lock and rollback). See pojocache-aop.xml for the corresponding stack. anonymous wrote : | 2. I'm not sure how this would work better? | | The need for offsetting the hashcode is to deal with a typically rare edge condition. If the hash function is reasonably distributed, then the chances of hash code collision (and therefore the need to do the hash code+1 trick) would be at best 1 in 2^32 and likely only a few orders of magnitude worse otherwise. | | I think people expect hash collisions would happen more often, but that's because in ordinary hash tables, collisions happen from evaluating (hash code % some small number). I am not talking about offsetting the hashcode. I like your implementation! What I was referring to is the need to loop through the cache index consecutively, e.g., for remove(), you have: | for (int i = 0; i < size; i++) | { | Object key = toLong(hashCode, i); | Object o2 = getNoUnmask(key); | if (o2 == null) | break; | if (removed) | { | // move o2 to old key | pCache_.detach(AopUtil.constructFqn(getFqn(), key)); | pCache_.attach(AopUtil.constructFqn(getFqn(), oldkey), o2); | } | if (o.equals(o2)) | { | pCache_.detach(AopUtil.constructFqn(getFqn(), key)); | removed = true; | } | oldkey = key; | } | return removed; | insead of index looping, I could have like in pseudo code: | // This is assumed to consist of only set objects. | Collection list = cache.getNode(getFqn()).getChildren(); | for(Collection c: list) | { | // check if o is present | Object o2 = cache.find(c); | if(o == o2) cache.detach(c); | return; | } | This way, we don't maintain odered list of index. BTW, the unit tests have some failure from the Set tests. I will probably need to look into to see where they go wrong. Thanks, -Ben View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984022#3984022 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984022

19 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Integration with different JBoss Cache releases

by wolfc

That it is, but which class / interface goes into which component. StatefulBeanContext & Pool are probably part of the ejb3-core. StatefulTreeCache is part of ejb3-cache-adapter which is then dependant on core (and Cache). But then core can't instantiate StatefulTreeCache and needs a plugin point. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984018#3984018 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984018

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - What is the Attachment in the deployers projects represent?

by vickyk

I don?t understand the purpose of this class org.jboss.deployers.spi.attachments.Attachment , what is this used for ? I don?t understand the how the attachments are associated with the deployments or deployers . View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984012#3984012 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984012

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - How should deployers obtain a propper CL?

by jason.greene＠jboss.com

The WS deployer needs to obtain a correct CL during deployment (needed for annotations, reflection, and JAXB). Currently it builds its own. Is a standard method for doing this planned? Or, is a deployer expected to define a ClassLoaderFactory which builds a CL off of the context ClassPath? -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983994#3983994 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983994

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Document where non-String FQN do not work, JBCACHE-838

by ben.wang＠jboss.com

The other restriction as mentioned is the eviction policy (as a region). But that can be relaxed now providing a user configures the region programatically. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983972#3983972 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983972

19 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 November 2006