A problem I see in the jbossas startup when an ejb3 deployment exists is the RoleBasedAuthorizationInterceptorFactory attempting to do a lookup for the java:/jaas/* content to obtain the security domain binding. With the current security refactoring, this context is established by a separate JBossSecurityJNDIContextEstablishment bean on which there is no dependency.
For now that dependency should be part of the configuration specifying the RoleBasedAuthorizationInterceptorFactory.
More generally this should be a jndi @Resource type of dependency that gets mapped to a bean that provides the jndi binding via an alias on an mc bean for example.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140298#4140298
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140298
"pgier" wrote :
| I don't understand enough about how OSGi works, but as a second option, can we translate the maven version to something OSGi compatible in our builds? So maybe use the maven standard versions in our poms, but then put the equivalent OSGi version string into jar metadata, or somewhere else that it can be used?
The osgi versioning convention is simply what we describe as ours here:
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossProductVersioning. Its just two short sections from the osgi r4 core spec:
"osgi 4.0.1 core spec" wrote :
| 3.2.4 Version
| Version specifications are used in several places. A version token has the following grammar:
| version ::=
| major( '.' minor ( '.' micro ( '.' qualifier )? )? )?
| major ::= number
| minor ::= number
| micro ::= number
| qualifier ::= ( alphanum | â_â | '-' )+
| A version token must not contain any white space. The default value for a
| version is 0.0.0.
| 3.2.5 Version Ranges
| A version range describes a range of versions using a mathematical interval notation. See  Mathematical Convention for Interval Notation.
| The syntax of a version range is:
| version-range ::= interval | atleast
| interval ::= ( '[' | '(' ) floor ',' ceiling ( ']' | ')' )
| atleast ::= version
| floor ::= version
| ceiling ::= version
| If a version range is specified as a single version, it must be interpreted as the range [version,â). The default for a non-specified version range is 0, which maps to [0.0.0,â).
| Note that the use of a comma in the version range requires it to be enclosed in double quotes. For example:
| Import-Package: com.acme.foo;version="[1.23, 2)", com.acme.bar;version="[4.0, 5.0)"
| In the following table, for each specified range in the left-hand column, a
| version x is considered to be a member of the range if the predicate in the
| right-hand column is true.
| Table 2 Examples of version ranges
| Example Predicate
| [1.2.3, 4.5.6) 1.2.3 <= x < 4.5.6
| [1.2.3, 4.5.6] 1.2.3 <= x <= 4.5.6
| (1.2.3, 4.5.6) 1.2.3 < x < 4.5.6
| (1.2.3, 4.5.6] 1.2.3 < x <= 4.5.6
| 1.2.3 1.2.3 <= x
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140272#4140272
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140272
"adrian(a)jboss.org" wrote : 4) Longer term EJB3 wants to go its own way anyway so shared dependencies aren't even the correct solution.
Yes, but in the interim, EJB3 requires the AS runtime and component-matrix was built to ensure that our compile/runtime dependencies would match.
"adrian(a)jboss.org" wrote : 5) The correct way to integrate things is via interfaces NOT implementations.
| In my view EJB3 is just being lazy (can't be bothered creating a version
| of EJB3 that isn't so brittle to thirdparty implementation details and versions)
| and forcing JBossAS to jump through hoops because of that.
You assume that we have access to the SPI/API/interfaces required for us to build.
At the moment, the "integration" project (http://anonsvn.jboss.org/repos/jbossas/projects/integration/trunk/)
holds SPIs for a whopping 3 projects. Until all of our AS Component dependencies are properly extracted into SPI/Impl, we'll depend on implementations and hence have a cyclic dependency preventing release.
The EJB3 team's efforts towards Mavenization has lead to the discovery of cyclic dependencies in AS. The problems were already there, and the new build tool is bringing them to the surface. For this laziness, you are welcome.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140261#4140261
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140261