January 2009 - jboss-dev-forums - Jboss List Archives

by ALRubinger

An update for anyone following along. Last week we bumped every component to 1.0.0 as a startoff point for the EJB3 1.0.0 release. We decided to make this one-time concession to line up the release versions to a stable start. In future releases we'll be keeping the cycle independent for components. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205131#4205131 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205131

17 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Redesign of Pool Configuration

by ALRubinger

Looking over @Pool and @Cache configurations, I'm not happy with the metamodel available and the implementation I'd put in place last year while resolving API leaks. Starting this Thread to document the discussion so far. "#ejb3 IRC" wrote : (02:12:20 AM) ALR: Some things are bothering me with @Pool configs. | (02:12:24 AM) ALR: 1) 1/2 the stuff we don't have tests for | (02:12:32 AM) ALR: 2) I hate the Pool configuration now. | (02:13:29 AM) ALR: carlo: I really messed that up when working around the API leaks. I was new, and wasn't thinking of things I should have been. The whole PoolFactoryRegistry thing is an indirection that requires more configuration than necessary. | (02:13:46 AM) carlo: ALR: :-) | (02:13:53 AM) ALR: carlo: And there's no mechanism to define properties for each Pool impl. Everything should be an injected MC bean factory. | (02:14:03 AM) carlo: ALR: We still have to get a good blueprint for Pool annotations | (02:14:15 AM) ALR: carlo: So now I'm thinking on how to fix it while maintaining backwards-compatibility. | (02:14:27 AM) ALR: carlo: For AS6 we can get it right. Same for @Cache and @CacheConfig. | (02:14:55 AM) carlo: ALR: What I really want to have is that @Cache and @CacheConfig are no longer part of ext-api | (02:15:16 AM) ALR: carlo: Yes, I'd rather the whole thing be ejb3-cache-jboss-beans.xml | (02:15:19 AM) carlo: ALR: Each cache implementation should have it's own annotations, metadata and deployers. | (02:15:28 AM) ALR: carlo: And ejb3-pool-jboss-beans.xml | (02:15:42 AM) ALR: carlo: With some nice annotations/metadata overrides. | (02:15:45 AM) carlo: ALR: So you won't even get ejb3-pool-jboss-beans.xml | (02:16:04 AM) ALR: carlo: I like it as a mechanism to configure the factory defaults. :) | (02:16:04 AM) carlo: ALR: More like: ejb3-default-pool-jboss-beans.xml | (02:16:10 AM) ALR: carlo: Yes, that. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205130#4205130 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205130

17 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: jboss-ejb3-project

by ALRubinger

"project" is also a pretty bad name, I don't have a knack for this. Suggestions for one word that signify that "this module has all transitive dependencies and defines an EJB3 release" are appreciated. assembly? composite? ejb3? (like: org.jboss.ejb3:ejb3) S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205128#4205128 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205128

17 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - jboss-ejb3-project

by ALRubinger

This is to document a new component we'd discussed in IRC. "project" module is to define the dependency chain, taking this responsibility away from "as-int". "as-int" may then be broken into "as5-int" and "as6-int", both to live outside the EJB3 Project, depending upon "project". Additionally, jboss-ejb3-project should declare two assemblies, one each for the binaries and source JARs for all components under the EJB3 umbrella. This was recommended by one of our users: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204792 Without arguments I'll start on this in tandem with moving some things out of AS bit by bit. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205127#4205127 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205127

17 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Sub-Profiles ProfileService changes

by bstansberry＠jboss.com

You're right; I think it's fine. I'd misunderstood what the validate(ControllerContext) call was really doing. I got sucked into a unrelated debugging fest today so haven't proved it yet, but it should be fine. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205125#4205125 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205125

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Looking to configure custom ThreadPoolExecutor

by clebert.suconic＠jboss.com

The general jboss jboss dev list is https://lists.jboss.org/mailman/listinfo. But I wouldn't make that suggestion, unless you have a very good point. What you suggest seems pointless to me. But even if you have a point, good luck with politics convincing a croud of developers about your implementation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205097#4205097 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205097

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Looking to configure custom ThreadPoolExecutor

by tmuldoon

I'm hoping to extend the edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor to override the beforeExecute and/or afterExecute methods (to ensure that the log4j NDC threadLocal is reinitialized) within a JBoss (4.2.2) environment. While extending the class is easy, I'm hoping that someone can shed a little light regarding just how to "tell" JBoss to use my implementation. I unfortunately came up empty in my search of the JBoss forums. Thanks, Tom View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205084#4205084 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205084

17 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Sub-Profiles ProfileService changes

by emuckenhuber

"bstansberry(a)jboss.com" wrote : Re: resurrecting DeploymentPhase, that wouldn't help with my example case of a war in deploy-hasingleton/. The missing dependency in the example is deploy/jbossweb.sar (the web server) *not* deployers/jbossweb.deployer. (One of the things the war deployers do is establish a dependency on the web server.) So, the MC knows to wait to install the war beans until the webserver is available. But validating the "deploy-hasingleton" profile won't give the MC a chance to be patient. | | ... | | This validation thing is a pain in general; I vaguely recall some discussion with Scott about a similar issue a year or two back. Perhaps we should move away from automatically validating and instead make it part of the SPI? Let the caller decide when they want a validation check and what to validate? Yes we could let the caller decide if he wants to validate the profile or not, but i'm not really sure what exactly is failing for you. Maybe because of the mainDeployer.process() which is done after each profile ? As validating the profile does not validate the deployments. mainDeployer.checkComplete() is only done once after the profiles are activated. Maybe you want to commit your .profile files? so that i can take a look what exactly is failing ? But i've renamed the root.profile to embedded.profile ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205073#4205073 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205073

17 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Sub-Profiles ProfileService changes

by bstansberry＠jboss.com

Re: resurrecting DeploymentPhase, that wouldn't help with my example case of a war in deploy-hasingleton/. The missing dependency in the example is deploy/jbossweb.sar (the web server) *not* deployers/jbossweb.deployer. (One of the things the war deployers do is establish a dependency on the web server.) So, the MC knows to wait to install the war beans until the webserver is available. But validating the "deploy-hasingleton" profile won't give the MC a chance to be patient. anonymous wrote : I did not really get what you meant with skipping the validation on a re-entrant activateProfile :-/ The reentrant call path looks like this: ProfileServiceBootstrap.start(Server) --> ProfileService.activateProfile("all") --> HASingletonDeployer bean starts, becomes master --> HASingletonProfileManager.activateProfile() --> ProfileService.activateProfile("deploy-hasingleton") One call to activateProfile() leads to another nested call. Below is an example of ignoring the validation in a re-entrant call. (This is based on doctoring AbstractProfileService rev 83388 before you change validate() to limit validation to a single context.) | private final ThreadLocal<Boolean> reentrantActivate = new ThreadLocal<Boolean>(); | | public void activateProfile(ProfileKey key) throws Exception | { | ... | | ProfileContext context = this.registeredProfiles.get(key); | if(context == null) | throw new NoSuchProfileException("No such profile: "+ key); | | Boolean reentrant = reentrantActivate.get(); | reentrantActivate.set(Boolean.TRUE); | try | { | try | { | log.info("Activating profile: " + context.getProfile()); | controller.change(context, ControllerState.INSTALLED); | } | catch(Throwable t) | { | throw new RuntimeException(t); | } | | // Check if the profile was activated successfully | if (Boolean.TRUE.equals(reentrant) == false) | { | validate(); | } | } | finally | { | reentrantActivate.set(reentrant); | } | } This validation thing is a pain in general; I vaguely recall some discussion with Scott about a similar issue a year or two back. Perhaps we should move away from automatically validating and instead make it part of the SPI? Let the caller decide when they want a validation check and what to validate? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205054#4205054 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205054

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Security services deployer for the MC

by anil.saldhana＠jboss.com

"david.lloyd(a)jboss.com" wrote : I'm in the process now of adding tags to create injectable keys from key files and keystores. A logical extension of that would be to inject passwords (read from files? maybe as char arrays, maybe as some kind of opaque object (like a CallbackHandler that handles PasswordCallbacks perhaps?)). What kind of security precautions should be taken? The implication here is that if the password "lives" in the microcontainer's managed space, then anyone who has access to that space gets the password. Maybe a special permission that includes the password bean name should be required to access it? What do you guys think? If I introduce special permissions for password access, I would think we'd want to do the same for SecretKey/PrivateKeys as well since they have similar security implications from what I can see. * Apart from directly injecting passwords from files, another option would be to use Password Based Encryption (password, salt, iteration count). * Agree on the special permission. I feel that a special permission category (similar to classloader perm) can be created to give a super user type access to the sensitive keys and then individual permissions for the password, privatekey.... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205053#4205053 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205053

17 years, 2 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 January 2009