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

[Design of JBoss Build System] - Re: Inconsistency in thirparty

by pgier

I wasn't able to reproduce this. I built the thirdparty dir, checked the component-info.xml at 0.1.2. Then I changed component-matrix to point to 1.0.0-Beta1 and rebuilt and the component-info.xml was updated. I saw a problem like this one time when the pom was pointing to an older version of the parent. But I checked this and all the poms seem to be set to 5.0.0-SNAPSHOT like they should be. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183621#4183621 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183621

16 years, 2 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Inconsistency in thirparty

by bstansberry＠jboss.com

Forgot to say, deleting thirdparty/jboss/jboss-jpa-deployers and building again fixed the problem. Reminds me of the good old build-magic days. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183620#4183620 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183620

16 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJB3 Core Release

by bstansberry＠jboss.com

The AS is now using jpa-deployers 1.0.0-Beta1. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183618#4183618 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183618

16 years, 2 months

1
0
0 / 0

[Design of JBoss Build System] - Inconsistency in thirparty

by bstansberry＠jboss.com

Paul, I just updated the version of version.org.jboss.jpa in component-matrix from 0.1.2 to 1.0.0-Beta1, ran the build and ended up with inconsistencies in thirdparty/jboss/jboss-jpa-deployers. My component-info.xml says 1.0.0-Beta1, but the jar in lib is still 0.1.2. Is this because I followed Carlo's instructions and named it 1.0.0-Beta1 rather than 1.0.0.Beta1? ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183614#4183614 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183614

16 years, 2 months

1
0
0 / 0

[Design of Security on JBoss] - JBoss ACL schema

by sguilhen＠redhat.com

We've been talking about an ACL configuration file that would specify the ACL policies for resources. These ACLs would be installed upon deployment and would be available through the ACLProvider that has been configured for the security domain. An example of the configuration file (jboss-acl-policy.xml?): | <jboss-acl xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | xsi:schemaLocation="urn:jboss:jboss-acl-config:1.0" | xmlns="urn:jboss:jboss-acl-config:1.0" | xmlns:jbxb="urn:jboss:jboss-acl-config:1.0"> | | <acl-definition resource="com.mycompany.Resource:XYZ"> | <entry> | <identity-name>Administrator</identity-name> | <permissions>CREATE,READ,UPDATE,DELETE</permissions> | </entry> | <entry> | <identity-name>Guest</identity-name> | <permissions>READ</permissions> | </entry> | </acl-definition> | |  | <acl-definition resource="com.mycompany.Resource:ABC" extends="com.mycompany.Resource:XYZ"> | <entry> | <identity-name>Regular_User</identity-name> | <permissions>READ,UPDATE</permissions> | </entry> |  | <entry> | <identity-name>Guest</identity-name> | <permissions>READ,UPDATE</permissions> | </entry> | </acl-definition> | | </jboss-acl> | when deployed, the above configuration file would result in the creation of 2 ACLs: one for resource XYZ with 2 entries (Administrator and Guest) and one for resource ABC with 3 entries (Administrator, Guest and Regular_User). Code that wants to apply ACL checks would call the AuthorizationManager in order to verify if an identity has or not the expected permissions. I'm opening this thread to gather opinions on this configuration file. Does it look ok? Do you think it is missing something? Would you specify the ACLs using a different schema? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183603#4183603 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183603

16 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Default JNDI naming scheme in EJB3.0 and possible confli

by jaikiran

"jaikiran" wrote : | I think the second example will be handled gracefully in 3.1 as per the specs (Section 4.4.1): | | anonymous wrote : Each portable session bean global JNDI name has the following syntax : | | | | java:global[/<app-name>]/<module-name>/<bean-name>#<fully-qualified-interface-name> | | | | The container registers a separate global JNDI name entry for each local business interface, each remote business interface, and any no-interface view, 2.x local home interface, or 2.x remote home interface. For the the no-interface view, the last portion of the entry name is the fully-qualified bean class name. | | | | The fully-qualified-interface-name will generate a unique JNDI name. | On second thoughts, Carlo is right. The following scenario will not work even in 3.1: Both packaged in same EAR/JAR: package org.myapp.business; | | @Stateless | public class ManagerBean implements org.myapp.Manager { | | } | package org.myapp.persistence; | | @Stateless | public class ManagerBean implements org.myapp.Manager { | | } | Both of these will resolve to java:global[/<app-name>]/<module-name>/ManagerBean#org.myapp.Manager | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183581#4183581 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183581

16 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Default JNDI naming scheme in EJB3.0 and possible confli

by jaikiran

"wolfc" wrote : | The second example will even fail in 3.1, but I consider it bad practice to have two classes with the same name in 1 module. I think the second example will be handled gracefully in 3.1 as per the specs (Section 4.4.1): anonymous wrote : Each portable session bean global JNDI name has the following syntax : | | java:global[/<app-name>]/<module-name>/<bean-name>#<fully-qualified-interface-name> | | The container registers a separate global JNDI name entry for each local business interface, each remote business interface, and any no-interface view, 2.x local home interface, or 2.x remote home interface. For the the no-interface view, the last portion of the entry name is the fully-qualified bean class name. | The fully-qualified-interface-name will generate a unique JNDI name. "ALRubinger" wrote : | Otherwise we could default the EJB Name to the FQN of the bean impl class, but I think that'll cause more problems (migration) that it'll solve. | I agree - changing the default EJB name at this point would not be of much help for this not so common scenario. "ALRubinger" wrote : | So the workaround is to set it explicitly. | Right, but the current behaviour just silently ignores the 2nd EJB and does not bind it. So if we have the information that we have already bound bean1 to the same name then maybe we could log a WARN message to highlight this issue so that the user opts for the workaround. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183564#4183564 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183564

16 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Default JNDI naming scheme in EJB3.0 and possible confli

by ALRubinger

This is all just because we default the EJB Name in the case it's not specified. So the workaround is to set it explicitly. Otherwise we could default the EJB Name to the FQN of the bean impl class, but I think that'll cause more problems (migration) that it'll solve. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183557#4183557 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183557

16 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Default JNDI naming scheme in EJB3.0 and possible confli

by wolfc

The first example is a pain, which is easily circumvented by setting another JNDI policy. Which will be the cases when we go 3.1. The second example will even fail in 3.1, but I consider it bad practice to have two classes with the same name in 1 module. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183552#4183552 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183552

16 years, 2 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - (Extremely) Basic protocol implementation

by david.lloyd＠jboss.com

I've renamed the current "basic" to "multiplex" because that's really what it is, and made a real "basic" protocol. This protocol exists simply for testing and messing around; I don't want to produce any production configuration which uses this protocol. Basically it uses a single connection for each client rather than managing a multiplexed connection with service advertisement and so forth. This might be useful as a point of reference for the compatibility interface. I plan to use it to help me finish up the stream marshalling stuff. The one test fails with a security manager due to a bug in River, which has been fixed in that project's trunk. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183545#4183545 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183545

16 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2008