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

[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor

by alesj

"jesper.pedersen" wrote : | The goal of Papaki is to provide a simple API for developers and thereby being able to deploy the library in any environment (like one of the current users on WebSphere). | Sure, but why re-invent the wheel? * your Reflection vs. Javassist abstraction == JBoss Reflect * your split between jar or directory == JBoss VFS e.g. if you wanna add a restriction check (e.g. exclude any non-exported class by OSGi manifest), you have to do it in 4 diff places: * Reflect + jar * Reflect + directory * Javassist + jar * Javassist + directory With VFS this is a simple filter; recursion or plain resource. Reflection abstraction is a single TypeInfoFactory change; via setter. "jesper.pedersen" wrote : | If the current API and scope of the project doesn't fit into the MC project I welcome a fork of the code into a new project where we can share ideas across the projects. Yup, that's what I think I'll do. But I'm still confused by where your version of Papaki really can be used. As it clearly lacks proper integration layer with existing environments, be it MC, JBossAS, WebsFear, ... While building repo, either from existing papaki.ser or runtime, you should be able to hook into existing restriction mechanisms. Otherwise you can potentially load a bunch of code user restricted at runtime; jboss-clasloading.xml, jboss-scanning.xml, ... (and its matching metadata instances) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261288#4261288 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261288

16 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor

by david.lloyd＠jboss.com

But I thought the idea was that we don't know what annotations we're interested in at the time the classes are scanned. Isn't that the whole point? So we have to index all of them (unless there is some hint from the user that scanning is not necessary for a class or package or whatever) and remember (sans-classloading) where annotations are located, and the relationships between classes, so that we can find all classes and subclasses with certain annotations without actually loading any classes. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261282#4261282 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261282

16 years, 5 months

1
0
0 / 0

[JBoss ESB Development] - Re: SAML Token Support

by anil.saldhana＠jboss.com

"beve" wrote : Just to avoid any confusion that here.... The validation is only performed through the JBossSTSLoginModule which is a JAAS Login module. | And the JBossSTSAction only performs issue request to JBossSTS and does not have methods for validating a security token. | | Sorry if this was already understood. | | /Dan Dan, I think that strategy is correct. Validation has to happen through pluggable login modules. Toward this, the STS login module seems appropriate. When the ESB layer has to generate SAML tokens, it needs to contact the STS. Hence it needs some integration logic (satisfied by the STS Action). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261281#4261281 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261281

16 years, 5 months

1
0
0 / 0

[JBoss ESB Development] - Re: SAML Token Support

by beve

Just to avoid any confusion that here.... The validation is only performed through the JBossSTSLoginModule which is a JAAS Login module. And the JBossSTSAction only performs issue request to JBossSTS and does not have methods for validating a security token. Sorry if this was already understood. /Dan View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261279#4261279 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261279

16 years, 5 months

1
0
0 / 0

[JBoss ESB Development] - Re: SAML Token Support

by beve

anonymous wrote : Well login modules have two aspects to them, authentication is the first. The second stage is to associate Principals/Credentials with the current security context. | The generation of the SAML context could be handled by this mechanism. | By generation, do you mean that the requesting of the STS to issue a security token be performed after authentication has been performed by another login module (these modules being stacked that is)? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261276#4261276 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261276

16 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor

by jesper.pedersen

anonymous wrote : | Papaki should actually be more minimal than it is. The indexes should be built by directly examining the file. Think about it - possibly every class in every JAR that is ever deployed may end up being read by this. There is absolutely no way that reflection is going to cut it performance-wise, nor do I think Javassist will suffice. | The indexer in Papaki builds an index over where annotations are located within the .class or .jar file. If the indexer is present, but is empty the framework will skip the entire annotation parsing stage. If an index is present, but contains annotation metadata only the part of the .class file where the annotation is located is scanned. The annotations themself can't be located in the metadata as they are not serializable, but the all the metadata about them can. Furthermore the scanner can be configured to only scan the part of the classes you are interested in - f.ex. if an annotation only can be located on a public class - at class level - then all non-public classes, all fields, all constructor, all methods and all parameters are skipped. HTH View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261275#4261275 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261275

16 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor

by david.lloyd＠jboss.com

So - we are taking a small project, adding dependencies and making it more complex? Papaki should actually be more minimal than it is. The indexes should be built by directly examining the file. Think about it - possibly every class in every JAR that is ever deployed may end up being read by this. There is absolutely no way that reflection is going to cut it performance-wise, nor do I think Javassist will suffice. The two key requirements for Papaki are: speed of execution and compactness/efficiency of indexing. If it doesn't hit both of these out of the park, we're going to be taking a step backwards in terms of performance. I don't see why it's anything more than a highly string-optimized map implementation (patricia trie perhaps) plus a tuned byte scanner. Adding dependencies is a bad idea. Projects should as a rule have the minimum number of runtime dependencies possible. Having lots of dependencies just makes it harder to refactor later. If you have a large web of dependencies between a set of projects, that's a big indicator that they ought to be one big project anyway, or at least split up differently. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261273#4261273 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261273

16 years, 5 months

1
0
0 / 0

[JBoss Transactions Development] - Re: beanifying the config

by mark.little＠jboss.com

Junk it. Time moves on and requirements change. What is there needs to be changed :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261268#4261268 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261268

16 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor

by jesper.pedersen

anonymous wrote : | The use case is the example from JIRA issue. | | e.g. | All our restrictions are held in Module, but that's mostly impl detail. | The way we expose that is via proper visitor pattern. | | e.g. | A user can provide ScanningMetaData on-the-fly, | and we should take that in account when: | * re-creating old serialized AR | * creating AR at runtime | | Not to mention resources lookup is *the* use-case where you need to apply visitor pattern. | That is a finer grained API than the current API - and some of it will be in a SPI. But this also implies a more dynamic annotation model - which is maybe something for a 1.1 release based on feedback from the community. anonymous wrote : | That's too simplistic. | You should have a proper abstraction. | Creating the needed metadata is an assembly time operation - so it only need to be done once. And yes, supporting additional methods of reading existing metadata could benefit the indexer. anonymous wrote : | I don't like to say this, but I'll still go ahead, | Papaki as it's currently in the trunk, is complete re-invent of the wheel. | Standalone argument doesn't convince me. | | And I spent the whole weekend looking at it and thinking about it how to best integrate it with Deployers, | only to realize that complete re-write is what we should do. | | Here is my version of it, which can be quite easily integrated with Deployers, | plus it uses all of the abstraction that are already under JBoss umbrella: | * Reflect -- abstraction between JDK Introspection and Javassist | * MDR - simplifying lookup via Signature | * VFS - resources lookup abstraction and visitor pattern | * ClassLoading - exact class resources visitor pattern | | Location: http://anonsvn.jboss.org/repos/jbossas/projects/annotations/branches/AnnEnv/ | The goal of Papaki is to provide a simple API for developers and thereby being able to deploy the library in any environment (like one of the current users on WebSphere). If the current API and scope of the project doesn't fit into the MC project I welcome a fork of the code into a new project where we can share ideas across the projects. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261265#4261265 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261265

16 years, 5 months

1
0
0 / 0

[JBoss ESB Development] - Re: SAML Token Support

by Kevin.Conner＠jboss.com

"beve" wrote : I can't really say that this was a technical reason for this. It just seemed appropriate that the LoginModule should only do one thing and that was to validate an existing token from a calling client. Well login modules have two aspects to them, authentication is the first. The second stage is to associate Principals/Credentials with the current security context. The generation of the SAML context could be handled by this mechanism. "beve" wrote : Sorry, I'm not following your suggested solution here. Could you expand on what you mean for this to be handled indirectly with javax.security. JAAS. Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261260#4261260 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261260

16 years, 5 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 October 2009