August 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Portal] - Re: Initiall identity model discussion

by julien＠jboss.com

we will design portal security with plugability to allow the development of a JBoss Security plugin "anil.saldhana(a)jboss.com" wrote : JBoss Security has a pluggable authorization framework that you can use. This is in JBoss AS 5.0. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079505#4079505 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079505

16 years, 8 months

1
0
0 / 0

[Design of JBoss Portal] - hibernate session handling

by bvogt

I do not see, that hibernate session are closed, is the really not necessary? looking at portals sources I can see for example: public User findUserByUserName(String userName) throws IdentityException | { | if (userName != null) | { | try | { | Session session = getCurrentSession(); | Query query = session.createQuery("from HibernateUserImpl where userName=:userName"); | query.setParameter("userName", userName); | query.setCacheable(true); | HibernateUserImpl user = (HibernateUserImpl)query.uniqueResult(); | if (user == null) | { | throw new NoSuchUserException("No such user " + userName); | } | return user; | } | catch (HibernateException e) | { | String message = "Cannot find user by name " + userName; | log.error(message, e); | throw new IdentityException(message, e); | } | } | else | { | throw new IllegalArgumentException("user name cannot be null"); | } | } | looking at the hibernate doc I read: A typical transaction should use the following idiom: | | Session sess = factory.openSession(); | Transaction tx; | try { | tx = sess.beginTransaction(); | //do some work | ... | tx.commit(); | } | catch (Exception e) { | if (tx!=null) tx.rollback(); | throw e; | } | finally { | sess.close(); | } | | If the Session throws an exception, the transaction must be rolled back and the session discarded. The internal state of the Session might not be consistent with the database after the exception occurs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079504#4079504 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079504

16 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: InstanceClassFactory extension to the ManagedObjectFacto

by adrian＠jboss.org

I understand why you've done this. I think this is ok for now. But for MBeans I thought we would do something more generic with the ManagedObject coming from a mapping of the MBean description (MBeanInfo/descriptors) To make this useful, the MBean description would be generated using annotations like the ManagedObject stuff (in fact the annotations that will appear in JMX2.0/Java7 + our extensions). This is related to this: http://jira.jboss.com/jira/browse/JBMICROCONT-71 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079490#4079490 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079490

16 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Scopes and MetaData in the Deployers

by adrian＠jboss.org

While doing this, I reinstated the "cleanup" method on the DeploymentContext since the only clear point to remove any metadata from the repository is during undeployment. I also added a getComponents() to the DeploymentUnit which was missing and I needed for the test. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079481#4079481 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079481

16 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Scopes and MetaData in the Deployers

by adrian＠jboss.org

http://jira.jboss.com/jira/browse/JBMICROCONT-196 I've added the basic api for this (obviously there's no deployer that actually uses it yet, but that is implementation detail :-) The scopes (access and mutation) for deployments and comments can be set on the DeploymentUnit - this is similar to the ScopeInfo I refactored in the MC. get/setScope() get/setMutableScope() More likely they will come from the new ScopeBuilder. The ScopeBuilder can be set on the DeployersImpl or there is a DefaultScopeBuilder which makes scopes based on: APPLICATION = top-level deployment DEPLOYMENT = this deployment INSTANCE = component name The only reason I can see to change the scope would be for instance to assign datasources to the additional scope SUBSYSTEM=JCA. Similarly the repository to use can be set on the DeployersImpl by default it will self bootstrap from the MC's repository. There is a getMetaData() and getMutableMetaData() that will use contexts automatically populated in the repository. This will be most useful if a deployer wants to add some contextual metadata for use by the runtime. e.g. If EJB3 were to be updated to use the scoped metadata then the EARDeployer could add things like a default transaction timeout from jboss-app.xml to the APPLICATION scope. In reality, I anticipate writing a seperate deployer that can be used to populate contextual metadata from a jboss-metadata.xml Ales already started on the "policy" xml in the microcontainer project. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079480#4079480 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079480

16 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Handling cluster state when network partitions occur

by bela＠jboss.com

(3) Another solution rather than shutting down is to cease caching values and pass all requests directly on to the underlying DB. Of course, this makes only sense if we *have* a DB, otherwise shutting down is probably our own option View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079466#4079466 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079466

16 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Handling cluster state when network partitions occur

by bela＠jboss.com

(1) The problem with merging state is that it is very dependent on the application and also, in most cases, non trivial to do right. As Brian mentioned, merging web session state is simple, but what happens if an HTTP session has a Pojo as value ? Or even worse, an entity bean which has a primary key and is persistent ? Then anyone can get a ref to that bean and change it, so we cannot assume the session is the only way to access an entity bean. (2) Primary partition This is generally good, as we avoid a merging because the non-primary partition(s) discard their state and re-initialize themselves from the primary partition. However, this means that all state changes that happened in the non-primary partition is discarded ! This is probably not acceptable for most applications. (3) Primary partitions detected when they happen If we can say that (assuming we have 5 nodes in the cluster) a primary partition needs to have 3 or more nodes and - if it has less than 3 - becomes read-only, then we avoid state changes in a non-primary partition. We could define a primary partition to be the majority, requiring an odd number of nodes, or come up with a different *deterministic* scheme. Problem is: if we have {A,B,C,D,E} and then 2 partitions P1={A,B,C} and P2={D,E}, and they're all connected to a DB, then changes within P1 and replicated within P1 and persisted to the DB, but *not* replicated to P2. This means that applications connected to P2 will read stale data ! In this case, the only solution I see is to shut down P2 and redirect clients if that's possible. Shutting down could mean - Leave the cluster (P2), so D and E disconnect from the cluster - Suspend (or close) the AJP connector (if we come in via Apache mod_jk), or *somehow* let the load balancer know that it should redirect requests to P1 and not P2 anymore. This of course requires the load balancer to have visibility to P1and P2. My 2 cents View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079459#4079459 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079459

16 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Flag to scan for ejb-jar.xml DD instead of Annotations

by ALRubinger

So I'm currently working on http://jira.jboss.org/jira/browse/EJBTHREE-1040. org.jboss.ejb3.deployers.EJBRegistrationDeployer seems to have a bunch of related code already in place in the "deploy" method, and I imagine this is a good place to add the enhancements. Was hoping for some clarification: * "Create a switch with flag" - Was the intent for this to be configured in a jboss-service.xml or similar? * What's the best way to create a Unit Test, given that this task seems to depend on configuration external to the deployable unit. Examples I could follow somewhere? Thanks. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079412#4079412 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079412

16 years, 8 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Initiall identity model discussion

by anil.saldhana＠jboss.com

JBoss Security has a pluggable authorization framework that you can use. This is in JBoss AS 5.0. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079401#4079401 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079401

16 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: InstanceClassFactory extension to the ManagedObjectFacto

by scott.stark＠jboss.org

For this to work, InstanceClassFactory also needs a: | public MetaValue getValue(BeanInfo beanInfo, ManagedProperty property, Serializable object); | method to be able to populate the ManagedProperty values from the metadata. Since the mbean instance does not exist this needs to be take from ServiceMetaData object. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079395#4079395 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079395

16 years, 8 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 August 2007