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

[Design of POJO Server] - Re: AbstractDeploymentUnit.getMetaDataFiles()

by bill.burke＠jboss.com

"scott.stark(a)jboss.org" wrote : Yes, I think that is what we need to try first. The -file refers to the protocol of the vfs context root. Another reason not to nest urls is that file:/.../foo.ear/ejb.jar/META-INF/persistence.xml is not going to be a valid url unless the ear and jar are unpacked. Let the vfs deal with this. | I can't believe how easy this was once I figured out how to plug in a URLConnectionHandler. check out containter module: org.jboss.net.protocol.vfsfile Now I just have to modify the VirtualFile so that a VFS url is regurgitated from VirtualFile.toURL() View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979748#3979748 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979748

19 years, 5 months

1
0
0 / 0

[Design of the JBoss EJB Container] - Performance Impact of call-by-value

by smodou

Hi All, I hope this is the right place for this question: How significant is the performance degration that results from using EJB call-by-value as opposed to the JBOSS default call-by-reference? Thanks in advance for your help. regards, Modou View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979746#3979746 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979746

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Client Asynchronous Calls

by ovidiu.feodorov＠jboss.com

genman wrote : For durability, SonicMQ supports durability by using persistence on the client side; MessageProducer.send() persists messages on disk, then delivery happens asynchronously in another thread. Again, some sort of mechanism would provide flow control. | | For "thin clients", you'd to have to provide some sort of simple client-side persistence model. A central database wouldn't make much sense. I'm guessing a "simple" transaction log might work. ("simple" rarely is though.) There'd have to be some sort of recovery mechanism and callbacks for error detection... Yes, this is the "point of sale" scenario. There is a JIRA task about this ... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979733#3979733 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979733

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Client Asynchronous Calls

by genman

AMQP is certainly meant to work async on the client side. Non-durable messages could be supported by using a memory buffer. (There would have to be some sort of "flow control" to avoid out of memory conditions.) For durability, SonicMQ supports durability by using persistence on the client side; MessageProducer.send() persists messages on disk, then delivery happens asynchronously in another thread. Again, some sort of mechanism would provide flow control. For "thin clients", you'd to have to provide some sort of simple client-side persistence model. A central database wouldn't make much sense. I'm guessing a "simple" transaction log might work. ("simple" rarely is though.) There'd have to be some sort of recovery mechanism and callbacks for error detection... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979716#3979716 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979716

19 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - Deployment architecture for 3.x

by julien＠jboss.com

Deployment architecture for JBoss Portal 3.x thoughts Currently JBoss Portal integrates directly with the JBoss 4.0.x deployment system. The main benefit is that it provides a transparent deployment of a web archive and does not require the developer to perform any extra work as the war file containing the portlet.xml file will just be deployed. With the requirement of JBoss Portal 3.x to be runnable everywhere we need to work on improving the current deployment architecture and find out solutions for every kind of environment. When a web archive is deployed the requirements are : 1/ the portlet container deployer needs aware of the deployment life cycle in order to create/destroy related portlet containers 2/ the web application context needs to be modified in order to include the proper hooks that will make the portlet container execute portlets. Injection of new servlet / servlet filter are good examples. 3/ injection of tld file in the war file (optional) I foresee 2 major ways of deployment techniques, each having its advantages/drawbacks. Indeed there is no universal solution because the lack of synergy between the portlet expert group and servlet expert group does not exist as of today. - Technique 1 : native integration this is what we do currently in JBoss 4.0.x. The portlet container deployer integrates directly with the deployer and is able to create on the fly the missing servlet / servlet filter in tomcat (by modifying the object model). It is also able to inject tld in the unpacked war file. It is completely transparent to the developer and probably provides the best integration. The drawback is that it is native to the environment and is not always possible for various reasons (technical or legal). - Technique 2 : prepare the war file ahead of deployment time it consist in modifying the war file by injecting the necessary hooks like modifying the web.xml for example. There are different flavors. . a special directory can be scanned for war files, modify them and then deploy them in the target environment (through JSR 88 in the case of an app server J2EE 1.4 certified) . the developer can be made aware of what is required and ask him to do that directly . a file upload mechanism can be used to act as in the first case The best we can do is to provide technique 1 whenever possible and technique 2 otherwise. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979714#3979714 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979714

19 years, 5 months

1
0
0 / 0

[Design of JBoss Eclipse IDE (dev)] - JUnit testing in Ant scripts - using container services WebS

by fbadt

How can JUnit be used in an ANT script (inside the IDE AND from a standalone OS prompt) to run tests against code that needs container services such as WS deployment and / or persistence ejb's. ie: perhaps all that is available to test against is the WAR / EAR file(s) Anyone have some build scripts to share? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979708#3979708 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979708

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: extending form / task functionality

by cocampo

"tom.baeyens(a)jboss.com" wrote : What you guys didn't yet show me is the problem i (or our users) would run into if they didn't separate ui from process logic. | | I don't yet see an intrinsic downside of mixing UI with process logic. | | I agree that UI and process logic should not be FORCEFULLY TIED together. But i don't see a problem in offering an optional form field in the task that can optionally be used by UI technologies. | | This can already cover most situations where there will be 1 UI technology involved for each task form. Tom, I fully agree with you. You shouldn't have to declare this form field, unless you want it. Also, I think that having the pageflow in another file is better, so you can handle different aspects of your process (yes, I believe UI is also part of a process definition, maybe not in jBPM - yet - but yes in business process modeling in a broad sense, more on this later), and still having a relationship among them. Regarding complexity, you WILL have complexity in your XML, no matter what you do, if you have a process with, lets say 200+ tasks (including human and computer tasks, as I've seen in the past). So, we can't avoid complexity, but we can think of ways to handle it. Maybe, we should start by defining (or just posting as a Wiki) best practices to handle complexity in large processes, and even think how jBPM and GPD could help to such matter. But a good starting point would be to separate concerns (i.e. process definition and UI, yet they would be related somehow, maybe by a form field as proposed by Tom). Regarding what (IMHO) could define a business process (in a broad sense, not limited to a BPM technology), I think these elements would be: - workflows (defined by tasks, roles, applications, artifacts, business rules, business events, business goals) - disciplines (defined by best practices, techniques, standards, methods) - guidelines (including templates, procedures - guides for using tools and artifacts, etc.-) I don't intend this to be an exhaustive list; I think you can't have all of these elements modeled in any BPM tool available. However, I believe you can completely model workflows (as defined before) with JBoss's jBPM/Seam/Rules (maybe with the exception of automatic monitoring of business goals, but that should be a possibe requirement for jBPM BAM or whatever its name will be). Though, I don't know if this would be useful to all of you guys, or perhaps you have a different understanding of business process modeling. Regards. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979698#3979698 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979698

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Eviction thread behaviour

by manik.surtani＠jboss.com

As reported in http://jira.jboss.com/jira/browse/JBCACHE-794 there are a few issues with the eviction thread's behaviour in concept. The bits I'm specifically concerned about are: 1) Should the eviction thread always use a lock acquisition timeout of 0, simply because if anyone else has a lock on the node being evicted then it should not be evicted? Since this is algorithm-specific, the BaseEvictionPolicy's evict() method should return an appropriate value if the eviction failed because of a timeout (rather than throw an exception, as this may be quite common with a timeout of 0) 2) BaseEvictionAlgorithm.evictCacheNode(), which calls BaseEvictionPolicy.evict(), would have to decide on whether a failure to evict because of a timeout should result in the eviction call being put back on the queue. In the case of an LRU type policy, this probably should *not* happen since the fact that the node is locked, it should be treated as a nodeVisited event and this eviction call should be removed from the eviction queue. What do people think about this? Cheers, Manik View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979697#3979697 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979697

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: POJOization of config elements

by manik.surtani＠jboss.com

anonymous wrote : | If you haven't can you move the InvocationContext() stuff to Cache? That will make testing easier, as not having it there breaks some of the current session repl code. If you don't want to I can work around that, but a bit more work. | done already. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979692#3979692 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979692

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: POJOization of config elements

by bstansberry＠jboss.com

OK, hopefully I can get the eviction stuff done this evening in the airport. I'll try to do the MC test in the AS over the weekend, but not sure if will be done your Mon AM (wife/kid get a vote :). If you haven't can you move the InvocationContext() stuff to Cache? That will make testing easier, as not having it there breaks some of the current session repl code. If you don't want to I can work around that, but a bit more work. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979690#3979690 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979690

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 October 2006