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

[Design of EJB 3.0] - Re: JBMETA-6, JBMETA-25 resolved jndi name

by scott.stark＠jboss.org

This means the ejb3-ext-api will depend on metadata as this annotation would now refer to the DefaultJndiBindingPolicy api from metadata: | public @interface JndiBindingPolicy { | | /** | * The JNDI Binding Policy that will be used | * | * @return | */ | Class<? extends DefaultJndiBindingPolicy> policy(); | | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146602#4146602 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146602

16 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JBMETA-6, JBMETA-25 resolved jndi name

by scott.stark＠jboss.org

I created http://jira.jboss.com/jira/browse/EJBTHREE-1321 to move the ejb3-ext-api to metadata. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146598#4146598 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146598

16 years, 5 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Solution of JBREM-954 and ramifications into UnifiedInvo

by galder.zamarreno＠jboss.com

"ron.sigal(a)jboss.com" wrote : Is there any reason to prefer one solution over the other? One could argue that an interruptible EJB or JMS client *should* declare that it throws an InterruptedException, but that discussion might be more theological than technical. [theological] EJB business interface methods should not have to declare IE just because the underlying library can be interrupted. You could use plain RMI that does not require interface methods to declare InterruptedException but they do need to declare RemoteException. Then again, plain RMI is neither performant and nor flexible, which is why we created Remoting or Pooled Invoker...etc :) "ron.sigal(a)jboss.com" wrote : I'm leaning towards wrapping in RuntimeExceptions, which seems more straightforward and avoids the UndeclaredThrowableException problem. Sounds fine to me :). "ron.sigal(a)jboss.com" wrote : There's one more concern. Suppose a Remoting user detected the InterruptedException possibility and their code looks for InterruptedExceptions wrapped in CannotConnectExceptions. Then replacing CannotConnectExceptions with RuntimeExceptions might break their code. I'm leaning towards | | 1. for Remoting 2.2.2.SP8 | | a) leaving the current behavior in place as the default behavior, and | | b) making the new behavior a configurable alternative. +1 "ron.sigal(a)jboss.com" wrote : 2. for Remoting 2.4.0, replacing the current behavior with the new behavior. | | Now WDYT? +1 as well. I might a test on the AS side that replicates this and see how assert that the correct thing is being thrown back to the client and whether the client can make further invocations. I'd probably use some mocking for this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146597#4146597 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146597

16 years, 5 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Security EJB2 and dependencies

by scott.stark＠jboss.org

I'll take a look at it in case its a side-effect of the resolver work I'm doing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146584#4146584 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146584

16 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JBMETA-6, JBMETA-25 resolved jndi name

by scott.stark＠jboss.org

The same type of deployment summary info has to be passed into the metadata layer, and both the metadata and deployment summary would be passed to the jndi policy. The deployment layer has to create the summary view, so that will contain both the parent deployment base name (an ear or standalone jar) and the ejb deployment simple name. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146582#4146582 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146582

16 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JBMETA-6, JBMETA-25 resolved jndi name

by wolfc

As long as the ear name can somehow be obtained. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146581#4146581 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146581

16 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Maven ESB plugin

by Andre1001

Following the correct XML: | <dependencies> | <dependency> | <groupId>JBoss</groupId> | <artifactId>jbossesb-rosetta</artifactId> | <version>4.2.1</version> | <scope>provided</scope> | </dependency> | </dependencies> View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146576#4146576 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146576

16 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Maven ESB plugin

by Andre1001

"beve" wrote : Hi, | | do you have a dependency setup in your pom for jbossesb-rosetta? | Could you post it if you do? | | Thanks, | | Daniel Yes, I do. Now, I've changed to "provided" and the lib directory persists (without jbossesb-rosetta). JBoss jbossesb-rosetta 4.2.1 provided Thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146575#4146575 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146575

16 years, 5 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Security EJB2 and dependencies

by anil.saldhana＠jboss.com

Adrian, based on my current run, for the pooled tests - BaseStressTestCase fails with some JNDI related lookup issues (probably JNDI names are wrong) and the SSLContextUnitTestCase is passing fine. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146572#4146572 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146572

16 years, 5 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Scoping of FIELD granularity session pojos

by bstansberry＠jboss.com

Currently, pojos stored in a FIELD replication granularity web session are stored in a section of the cache scoped to the webapp, not to the session. I'm more and more inclined to change this to session scoping, and would appreciate any comments anyone may have. Allowing different sessions to share pojos has a fundamental drawback, plus it introduces a number of implementation hassles: Fundamental drawback is users running on different nodes can attempt to concurrently modify the pojo. This can lead to anomalous behavior or distributed deadlocks Implementation hassles: 1) Can't passivate pojos along with sessions. Making them sharable gives them an independent lifecycle, so they can't be stored in the cache in the subtree belonging to a particular session. So, evicting a session's subtree doesn't remove the pojos. Leads to the need for a very hacky and imprecise introduction of raw JBC node eviction concepts into jboss-web.xml to let users configure pojo eviction. 2) Data gravitation. Again, sharable pojos can't be stored under a session's subtree. So, gravitating that subtree following failover doesn't bring the associated pojos. That has to be managed separately, and requires telling PojoCache to always do a data gravitation check any time it doesn't find something in the cache. That's inefficient when new objects are inserted. Plus I haven't gotten it work properly yet now that PC no longer does it by default. ;) 3) Ownership with buddy replication. Related to data gravitation. If a pojo is shared and the sessions sharing it end up on different nodes, the shared pojo will start getting gravitated back and forth between between the nodes. This is contrary to the whole idea of buddy replication, which is that data is owned by own node and only moves to handle failover. Possible solutions: 1) Store pojos under the session that first passes them to setAttribute. Pros: solves above problems Cons: if webapp stores the same pojo under two different sessions, PC will support this. But if the first session is removed, the underlying pojo will be removed with it and if the second session tries to use it they will get an exception. 2) Make it configurable via a pojo-scope element in jboss-web.xml, valus are APPLICATION or SESSION, default is session. Basically, still support the existing behavior. Log a WARN if user specifies ATTRIBUTE with a buddy replication cache. Pros: give people who count on current behavior a way out. Cons: ignores the "fundamental problem" discussed above. Requires supporting the hacky JBC eviction configuration via jboss-web.xml stuff. Comments? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146547#4146547 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146547

16 years, 5 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 April 2008