Hi, Walking through jira issues for JBT 3 beta1 and I just stumbled into https://jira.jboss.org/jira/browse/JBIDE-2702 which is caused by <security:rule-based-permission-resolver security-rules="#{securityRules}"/> now being in components.xml by default. That is for some reason failing for us - probably we are missing a drools jar or something ;) Before I start finding these changes in 2.1 that might break current tools behavior the hard way, do you guys got a list of major 2.1 changes that changes lib dependencies/startup sequence etc. ?

Hi, Walking through jira issues for JBT 3 beta1 and I just stumbled into https://jira.jboss.org/jira/browse/JBIDE-2702 which is caused by <security:rule-based-permission-resolver security-rules="#{securityRules}"/> now being in components.xml by default. That is for some reason failing for us - probably we are missing a drools jar or something ;)

On Tue, 21 Oct 2008 20:00:56 +0200, Max Rydahl Andersen <max.andersen(a)redhat.com > wrote: > Hi, > > Walking through jira issues for JBT 3 beta1 and I just stumbled into > https://jira.jboss.org/jira/browse/JBIDE-2702 which is caused by > <security:rule-based-permission-resolver security- > rules="#{securityRules}"/> > now being in components.xml by default. > > That is for some reason failing for us - probably we are missing a > drools jar or something ;) hmm...this is caused by security:rule-based-permission-resolver should map to org.jboss.seam.security.RuleBasedPermissionResolver Every other construct in components.xml does that but that class does not exist as far as I can see so that gives an error. Is it us or Seam 2.1.CR that is broken ?

/max _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

Another curious one I've bumped into is that @jndiPattern@ is evaluated to null in Seam 2.1 even though component.properties exist. Same project works fine on Seam 2.0... /max > Hi, > > Walking through jira issues for JBT 3 beta1 and I just stumbled into > https://jira.jboss.org/jira/browse/JBIDE-2702 which is caused by > <security:rule-based-permission-resolver security- > rules="#{securityRules}"/> > now being in components.xml by default. > > That is for some reason failing for us - probably we are missing a > drools jar or something ;) > > Before I start finding these changes in 2.1 that might break > current tools behavior the hard way, > do you guys got a list of major 2.1 changes that changes lib > dependencies/startup sequence etc. ? > -- /max _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

Hi, Walking through jira issues for JBT 3 beta1 and I just stumbled into https://jira.jboss.org/jira/browse/JBIDE-2702 which is caused by <security:rule-based-permission-resolver security-rules="#{securityRules}"/> now being in components.xml by default. That is for some reason failing for us - probably we are missing a drools jar or something ;) Before I start finding these changes in 2.1 that might break current tools behavior the hard way, do you guys got a list of major 2.1 changes that changes lib dependencies/startup sequence etc. ?

On Wed, 22 Oct 2008 00:23:45 +0200, Shane Bryzak <shane.bryzak(a)jboss.com&gt; wrote: > This attribute was simply moved (from identity to > rule-based-permission-resolver) in Seam 2.1.0, no library > requirements were changed for security. Is there a security rules > file present, and is there a specific exception produced? This > change was documented in seam21migration.txt in the root of the Seam > dist, might be worth checking there for any other potentially > breaking changes. The problem is the missing class...we translate security:rule-based-permission-resolver to org.jboss.seam.security.RuleBasedPermissionResolver; that is apparently not enough anymore for the core tags. /max > > Max Rydahl Andersen wrote: >> Hi, >> >> Walking through jira issues for JBT 3 beta1 and I just stumbled into >> https://jira.jboss.org/jira/browse/JBIDE-2702 which is caused by >> <security:rule-based-permission-resolver >> security-rules="#{securityRules}"/> >> now being in components.xml by default. >> >> That is for some reason failing for us - probably we are missing a >> drools jar or something ;) >> >> Before I start finding these changes in 2.1 that might break current >> tools behavior the hard way, >> do you guys got a list of major 2.1 changes that changes lib >> dependencies/startup sequence etc. ? >> >

On Wed, 22 Oct 2008 00:27:22 +0200, Shane Bryzak <shane.bryzak(a)jboss.com&gt; wrote: > Ok as Pete said it may have something to do with the new > multi-package support for namespaces. How are you doing the > translation? As described below. We simply do org.jboss.seam.[postcolonname].[camelcaseoftagname] Was told by Gavin et.al. that would be sufficient 99% of the time ;) I guess we just hit the 1% /max > > Max Rydahl Andersen wrote: >> On Wed, 22 Oct 2008 00:23:45 +0200, Shane Bryzak >> <shane.bryzak(a)jboss.com&gt; wrote: >> >>> This attribute was simply moved (from identity to >>> rule-based-permission-resolver) in Seam 2.1.0, no library >>> requirements were changed for security. Is there a security rules >>> file present, and is there a specific exception produced? This >>> change was documented in seam21migration.txt in the root of the >>> Seam dist, might be worth checking there for any other potentially >>> breaking changes. >> >> The problem is the missing class...we translate >> security:rule-based-permission-resolver to >> org.jboss.seam.security.RuleBasedPermissionResolver; >> that is apparently not enough anymore for the core tags. >> >> /max >> >>> >>> Max Rydahl Andersen wrote: >>>> Hi, >>>> >>>> Walking through jira issues for JBT 3 beta1 and I just stumbled into >>>> https://jira.jboss.org/jira/browse/JBIDE-2702 which is caused by >>>> <security:rule-based-permission-resolver >>>> security-rules="#{securityRules}"/> >>>> now being in components.xml by default. >>>> >>>> That is for some reason failing for us - probably we are missing a >>>> drools jar or something ;) >>>> >>>> Before I start finding these changes in 2.1 that might break >>>> current tools behavior the hard way, >>>> do you guys got a list of major 2.1 changes that changes lib >>>> dependencies/startup sequence etc. ? >>>> >>> >> >> >> >

>> Ok as Pete said it may have something to do with the new multi-package >> support for namespaces. How are you doing the translation? > > As described below. We simply do org.jboss.seam.[postcolonname]. > [camelcaseoftagname] > > Was told by Gavin et.al. that would be sufficient 99% of the time ;) > > I guess we just hit the 1% So this doesn't work if you define your own namespace? Hmm, this is bad as people can do that (and clever people will do it a lot), and their tooling shouldn't tell them it's an error.

The correct way to do this would be to scan the classpath for package- info.class files, load them, and build a map of namespace:package from the @Namespace annotation on the package, and substitute package for org.jboss.seam in your above algorithm.

> > > /max > >> >> Max Rydahl Andersen wrote: >>> On Wed, 22 Oct 2008 00:23:45 +0200, Shane Bryzak >>> <shane.bryzak(a)jboss.com&gt; wrote: >>> >>>> This attribute was simply moved (from identity to rule-based- >>>> permission-resolver) in Seam 2.1.0, no library requirements were >>>> changed for security. Is there a security rules file present, and >>>> is there a specific exception produced? This change was documented >>>> in seam21migration.txt in the root of the Seam dist, might be worth >>>> checking there for any other potentially breaking changes. >>> >>> The problem is the missing class...we translate security:rule- >>> based-permission-resolver to >>> org.jboss.seam.security.RuleBasedPermissionResolver; >>> that is apparently not enough anymore for the core tags. >>> >>> /max >>> >>>> >>>> Max Rydahl Andersen wrote: >>>>> Hi, >>>>> >>>>> Walking through jira issues for JBT 3 beta1 and I just stumbled into >>>>> https://jira.jboss.org/jira/browse/JBIDE-2702 which is caused by >>>>> <security:rule-based-permission-resolver security- >>>>> rules="#{securityRules}"/> >>>>> now being in components.xml by default. >>>>> >>>>> That is for some reason failing for us - probably we are missing a >>>>> drools jar or something ;) >>>>> >>>>> Before I start finding these changes in 2.1 that might break >>>>> current tools behavior the hard way, >>>>> do you guys got a list of major 2.1 changes that changes lib >>>>> dependencies/startup sequence etc. ? >>>>> >>>> >>> >>> >>> >> > > > > --/max > _______________________________________________ > seam-dev mailing list > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev

It sounds like that you were already aware of that Max, but that the convention was good enough (the enemy of better) at the time. We should definitely have tools use the true mapping logic that Seam uses in the future. I would vote for it being important.

What i'll do is that for the upcoming beta1 i'll downgrade the error to a > warning > (makes more sense when we don't resolve it 100% correctly) and then after > beta1 > we will look into implementing it correctly via Eclipse's Java model. > https://jira.jboss.org/jira/browse/JBIDE-2957 has been created to implement the true support (https://jira.jboss.org/jira/browse/JBIDE-2958 is what I'll get into the beta). If one of you guys could add a comment where we can find the exact rules and the code in seam that does it so we can mimic it that would be great ;)