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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: [JBMESSAGING-1367] Create JCA resource adapter for JBM 2

by jesper.pedersen

Just a follow up on our discussion last Friday -- I think you are thinking about the inbound part of the RA after have gone over the JMS spec. The generic JMS resource adapter uses the ServerSessionPool in its inbound part. This won't work with JBM 2.0 like you said as it isn't supported. So we will implement the inbound part a different way -- which we will figure out once the outbound part has been committed. For now I'll finish up the outbound part - check with the jms.client implementation - and either commit or upload the patch to the JIRA issue. That way it would be easier to discuss the inbound part. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205050#4205050 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205050

17 years, 2 months

1
0
0 / 0

[Design of JBoss Wiki] - Re: [b]Moving from Maven 1.x to Maven 2.x[/b]

by piergiorgiolucidi

We have JBossWiki as Maven 2 project ^__^ I have completed the Maven 2 porting of JBossWiki project and I hope to commit it soon... if someone (JBoss admin) will allow me to create an issue on JIRA :-P I hope to post great news soon ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205047#4205047 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205047

17 years, 2 months

1
0
0 / 0

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

by david.lloyd＠jboss.com

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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205046#4205046 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205046

17 years, 2 months

1
0
0 / 0

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

by emuckenhuber

"bstansberry(a)jboss.com" wrote : | That's OK, but fragile. It also forces breaking things up into more fine-grained sub-profiles. It's a bit of a shame to have to do that since the MC can already properly handle the dependencies. | Well i don't like it - i think it's broken, because it confuses myself too, which is not a very good sign :) I mean what we could do is to resurrect the DeploymentPhase in the xml, where you can say if it's a deployer or an application. Maybe we can also put something there where you can say that it should ignore this profile. That's actually the only reason behind this exercise that all the deployers are fully installed before any app is getting deployed. Otherwise the deployment won't be recognised and nothing would happen. I did not really get what you meant with skipping the validation on a re-entrant activateProfile :-/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205045#4205045 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205045

17 years, 2 months

1
0
0 / 0

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

by bstansberry＠jboss.com

"emuckenhuber" wrote : The original idea was to have something like: | common/profiles/ and conf/profiles - where you could then basically say that all profiles in conf/profiles | are getting registered. And only the root.profile gets activated (not really sure about that yet) Perhaps this should be explicit a la ControllerMode. There's a lot of black art in what you just described. anonymous wrote : independent profile is correct, although i'm not really happy with the DeploymentRepository stuff. | if you e.g. look at the FilteredDeploymentRepositoryFactory - where the repository is doing the filtering. IMHO this should actually be done by the Profile itself. I'll keep poking around, trying to prototype. I won't commit as I know you are changing stuff. But I'll give you feedback. I was going to move farming off the list for 5.1, but won't just yet. It *really* bugs me that it's gone, and now I'm starting to see a path to getting it back. anonymous wrote : Although this would need to be registered in the bootstrap/profile-service.xml No problem. anonymous wrote : But as said maybe profiles should be defined as <hot-deployment-profile/> <maven-profile/> <ha-singleton-profile/> | or something like that ? That seems more understandable View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205035#4205035 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205035

17 years, 2 months

1
0
0 / 0

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

by bstansberry＠jboss.com

anonymous wrote : Basically all profiles need to declare their dependencies - this might get a bit redundant. Therefore implicit dependencies based on ordering. | | So all profiles defining deployers (maybe also mixed with some runtime beans related to it) need to be activated/deployed first. Your clustering profile would need to get deployed after this like same for a hot-deployment profile. Yes. When I was experimenting with the XML-based profiles yesterday I divided the clustering stuff into 3 chunks -- 1) the core clustering stuff, which went earlier in the chain, 2) at the end a "clustered-deployment" profile which contained deploy-hasingleton-jboss-beans.xml and 3) the independent "deploy-hasingleton" profile for the content. That's OK, but fragile. It also forces breaking things up into more fine-grained sub-profiles. It's a bit of a shame to have to do that since the MC can already properly handle the dependencies. I was going to suggest going to the approach of skipping the validation on a re-entrant activateProfile call. But that has a downside too, so I'll just put down a quick pro/con for the record/my memory: PRO: avoids need for black art in ensuring that anything that activates a profile gets put at the right point in the list of subprofiles. CON: code that makes the reentrant call doesn't get an exception if there truly is something wrong with the nested profile. E.g. if HASingletonProfileActivator on node 1 tries to start and activate the deploy-hasingleton profile, but there's a misconfig *on node 1 only*, the HASingletonProfileActivator needs the exception so it doesn't start properly. That should then result in node 2 becoming the master and deploying the content. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205032#4205032 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205032

17 years, 2 months

1
0
0 / 0

[Design of JBoss Labs] - Re: JBoss Community Leaders polls not working

by rayme

Stefano, we are looking into this. -Rayme. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205026#4205026 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205026

17 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - Re: New identity API - feedback needed

by thomas.heute＠jboss.com

First of all, thank you Bolek, this new identity model should (among other things) let JBoss Portal introduce the notion of groups/organization/... on top of rthe notion of roles we have today. And this is theoretically *very* flexible, this is just begging to have a use-case that proves the opposite :) The SPI to connect to any identity manager is also very important and this is a more mature version of what we have today in JBoss Portal (learnt from experience) If you had requirements about groups/hierarchy of users/identity/identity server plugins/... now is the best time to check that what we'll bring you fits you View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204976#4204976 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204976

17 years, 2 months

1
0
0 / 0

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

by emuckenhuber

"bstansberry(a)jboss.com" wrote : | Didn't work -- the deploy-hasingleton.profile wasn't registered. ProfileServiceBootstrap only registers the 'embedded' profile and its subprofiles. Independent ones are not registered. | Yes this is a limitation of the current implementation/example. The original idea was to have something like: common/profiles/ and conf/profiles - where you could then basically say that all profiles in conf/profiles are getting registered. And only the root.profile gets activated (not really sure about that yet) "bstansberry(a)jboss.com" wrote : | OT, I'm starting to think about how to use an independent profile to do farming. A farmed profile would use a different DeploymentRepository impl. | independent profile is correct, although i'm not really happy with the DeploymentRepository stuff. if you e.g. look at the FilteredDeploymentRepositoryFactory - where the repository is doing the filtering. IMHO this should actually be done by the Profile itself. Maybe the xml also needs some updating - as currently the profile is more or less defined over it's profile-source. You can basically plugin this process by creating your own ProfileSourceMetaData. You then would need to register this metadata over the singletonSchemaFactory (or whatever this is called) with it's own namespace and your own DeploymentRepositoryFactory, which gets called based on the type of the source metadata. Although this would need to be registered in the bootstrap/profile-service.xml That's how it's basically looks at the moment: | <profiles | xmlns="urn:jboss:profileservice:profiles:1.0" | name="profiles"> | <profile name="immutable"> | <profile-source> | <source>${jboss.server.home.url}conf</source> | </profile-source> | <sub-profile>ejb3</sub-profile> | <deployment>myEjb3Deployment.ear</deployment> | </profile> | <profile name="mutable-source"> | <hotdeployment-source> | <source>${jboss.server.home.url}deploy</source> | </hotdeployment-source> | <sub-profile>immutable</sub-profile> | </profile> | <profile name="maven-source"> | <maven-source xmlns="urn:jboss:profileservice:source:maven:1.0"> | <source>http://repository.jboss.org/maven2</source> | </maven-source> | <sub-profile>hotdeployment</sub-profile> | <deployment>org/jboss/jboss-profileservice/6.0.0-GA/profileservice-spi.jar</deployment> | </profile> | </profiles> | But as said maybe profiles should be defined as <hot-deployment-profile/> <maven-profile/> <ha-singleton-profile/> or something like that ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204972#4204972 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204972

17 years, 2 months

1
0
0 / 0

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

by emuckenhuber

"bstansberry(a)jboss.com" wrote : | One concern with the validate is you can get unsatisfied dependencies. Say you have a war in deploy-hasingleton. And say during the 'all' profile deploy the cluster/deploy-hasingleton-jboss-beans.xml file is deployed before jboss-web.sar. That will trigger activation of the deploy-hasingleton profile, and the war will not complete deployment pending dependency on jboss-web.sar. Not a problem, since at the end of the whole thing the dependency will be satisfied and the war will deploy. Except, the validate call during the deploy-hasingleton activation will throw an exception. Hmm yes i understand your concern - in general PS is about managing profiles it does and should not really care about the actual type of deployments in a profile. Which basically means that you also need corretly defined profiles :) This leads a bit into the implicit/explicit dependcies and deployment ordering. Basically all profiles need to declare their dependencies - this might get a bit redundant. Therefore implicit dependencies based on ordering. So all profiles defining deployers (maybe also mixed with some runtime beans related to it) need to be activated/deployed first. Your clustering profile would need to get deployed after this like same for a hot-deployment profile. At the moment the legacy behavior of PS is still there - so deploy is activated after deployers, and therefore your HASingleton basically activates the profile correctly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204970#4204970 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204970

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