Fwd: Porting SVN Projects to Git
by Kabir Khan
Begin forwarded message:
> From: Jaikiran Pai <jpai(a)redhat.com>
> Date: 16 July 2010 10:53:42 GMT+01:00
> To: Kabir Khan <kabir.khan(a)jboss.com>
> Subject: Re: [jboss-dev] Porting SVN Projects to Git
> Reply-To: jpai(a)redhat.com
>
> Thinking about it, would that wiki page turn out to be a jackpot for spammers trying to harvest email ids? And would everyone be OK with their email ids becoming publicly visible?
As pointed out by Jaikiran this might be a bad idea, I've deleted the original and put it on idocspace instead
https://docspace.corp.redhat.com/docs/DOC-43448
>
> -Jaikiran
> On Friday 16 July 2010 02:51 PM, Kabir Khan wrote:
>> I've put what I have in my svn username - git author mapping file for the projects I have imported so far here: http://community.jboss.org/wiki/Git-SvnAuthorMappings
>>
>> If we keep it up to date it means less work when importing your next project. Although it displays an icon next to the email addresses, for me the disappears when I copy and paste into a text editor.
15 years, 10 months
Re: [jboss-dev] pluggable auth-method
by Sergey Beryozkin
Thanks for the links.
I checked a JBossAS Tomcat integration module earlier on,
at https://svn.jboss.org/repos/jbossas/tomcat
and saw the references to jbossweb on forums, but still thought catalina.jar was used somehow internally, thus was curious what the corresponding version was.
At the moment I'm just doing a 'provided' scope dependency on catalina 6.0.28, and I'm assuming it will just work in JBoss but I guess the demo will be better off with depending on jbossweb.
cheers, Sergey
----- "Brian Stansberry" <brian.stansberry(a)redhat.com> wrote:
> JBoss AS uses JBoss Web (derived from Tomcat), not Tomcat itself.
>
> https://repository.jboss.org/nexus/content/repositories/public-jboss/org/...
>
> is the location of the version currently used in AS trunk.
>
> https://svn.jboss.org/repos/jbossas/trunk/component-matrix/pom.xml is
>
> the file in the AS trunk that defines that dependency.
>
> On 7/15/10 10:23 AM, Sergey Beryozkin wrote:
> > Well, this is quite obvious, I can quess that one :-)
> > Which version of Catalina ? Though probably any in the 5.x range
> will do, just not sure if AS 6.0 uses Catalina 6.x or not
> >
> > Cheers, Sergey
> >
> > ----- "Anil Saldhana"<Anil.Saldhana(a)redhat.com> wrote:
> >
> >> Sergey,
> >> extend Tomcat AuthenticatorBase class for your authenticator.
> It
> >> should have available in the catalina jar.
> >>
> >> Cheers.
> >>
> >> On 07/15/2010 09:20 AM, Sergey Beryozkin wrote:
> >>> Hi Anil
> >>>
> >>>
> >>> ----- "Anil Saldhana"<Anil.Saldhana(a)redhat.com> wrote:
> >>>
> >>>
> >>>> The login modules happen late in the container security sequence
> >> and
> >>>> have limited access to the network message etc. They can only
> say
> >>>> yes/no to authentication. But they cannot do some of the
> redirects
> >> or
> >>>>
> >>>> other extra steps that are needed in mechanisms outside of the
> >> servlet
> >>>>
> >>>> spec mechanisms (form, client-cert, basic,digest). SAML,
> >>>> OpenID/OAuth
> >>>> etc may need access to the network message (http message) and
> may
> >> have
> >>>>
> >>>> to redirect the request to an external identity provider. In
> >> these
> >>>> situations, you do container integration (in the case of tomcat,
> it
> >> is
> >>>>
> >>>> via authenticators).
> >>>>
> >>>> Ideally, you should be doing JSR-196 which will provide you the
> >>>> pluggable server authentication modules and can stack modules
> just
> >> as
> >>>>
> >>>> you do with login modules.
> >>>>
> >>>> We have support for JSR-196 in AS6 which needs to be taken
> further
> >>>> before EE6 certification.
> >>>> http://anil-identity.blogspot.com/search/label/jsr-196
> >>>>
> >>>>
> >>> thanks for all the info, I will experiment with Athenticators, no
> >> redirection will be needed in cases where they should
> >>> enforce that a given OAuth consumer is a valid one, but I'd like
> to
> >> try them too...
> >>>
> >>> How to figure out which catalina/tomcat dependency should be used
> >> for writing a custom Authenticator to be used in JBossAS 6.0
> >> deployments ?
> >>>
> >>> thanks, Sergey
> >>>
> >>>
> >>>
> >>>> On 07/14/2010 11:17 AM, Sergey Beryozkin wrote:
> >>>>
> >>>>> Hi
> >>>>>
> >>>>>
> >>>>>
> >>>>>> For OAuth there are a few issues:
> >>>>>>
> >>>>>> 1. It has specific headers.
> >>>>>> 2. You create "secrets" on the fly which are used to
> >> authenticate
> >>>>>>
> >>>> and
> >>>>
> >>>>>> authorize requests.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> Regarding 2: This is just one approach which the RestEasy
> >>>>>
> >>>> oauth-push-messaging takes, but one can imagine
> >>>>
> >>>>> the administrator registering the OAuth consumers representing
> >> say
> >>>>>
> >>>> messaging services in advance.
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Maybe its best to first iterate on an Authenticator, then move
> >>>>>>
> >>>> logic
> >>>>
> >>>>>> up
> >>>>>> the stack once you get a prototype going? I don't know how
> >> Sergey
> >>>>>> likes
> >>>>>> to work :)
> >>>>>>
> >>>>>>
> >>>>> Well, my own problem so far is that I doubt the necessity of
> >>>>>
> >>>> introducing a role-based
> >>>>
> >>>>> control access in a push-messaging case given the way the
> current
> >>>>>
> >>>> solution works.
> >>>>
> >>>>> Specifically, a subscriber needs to grant the messaging service
> a
> >>>>>
> >>>> permission to access a destination URI using a (domain)
> >> admin-level
> >>>> invocation on the message receiver; in other words the
> subscriber
> >> can
> >>>> not just tell the messaging service to push to some arbitrary
> >> server,
> >>>> the subscriber needs to control that specific URI space on that
> >>>> server; it is really the subscriber's space in the end of the
> day.
> >>>>
> >>>>> So it is an admin-level decision which is enforced by the OAuth
> >>>>>
> >>>> filter anyway - by authenticating (by ensuring current OAuth
> >> client_id
> >>>> matches the records and checking the signature the secret) and
> >>>> validating that the request URI matches the one specified by the
> >> admin
> >>>> (subscriber) at the previous step.
> >>>>
> >>>>> Thus it is not obvious to me why it is worth introducing
> another
> >>>>>
> >>>> authorization layer, at least given the way the push-messaging
> >> demo
> >>>> works at the moment. And when I'm in doubt I'm really working
> very
> >>>> slowly, sorry, probably not a good thing to say publicly :-)
> >>>>
> >>>>> Where I can see the login modules may be introduced is when we
> >> have
> >>>>>
> >>>> OAuth consumers registered well in advance and say the
> >> administrator
> >>>> allocates roles to various consumers using nice UI and then we
> have
> >> a
> >>>> case where some consumers may access one (resource) service
> method
> >> and
> >>>> some other consumers can access some other method only. It is
> not
> >> the
> >>>> case with the push-messaging demo though.
> >>>>
> >>>>> cheers, Sergey
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Chris Bredesen wrote:
> >>>>>>
> >>>>>>
> >>>>>>> Yes.
> >>>>>>>
> >>>>>>> Authenticator is a Catalina/Web construct that delegates to a
> >>>>>>>
> >>>> Realm
> >>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> (Catalina construct) that, in JBAS is backed by LoginModules
> >>>>>>>
> >>>> (JAAS
> >>>>
> >>>>>>> constructs, JBoss implementations).
> >>>>>>>
> >>>>>>> JAAS LoginModules are constrained by their own API which
> means
> >>>>>>>
> >>>> they
> >>>>
> >>>>>>>
> >>>>>>>
> >>>>>> get
> >>>>>>
> >>>>>>
> >>>>>>> access to only certain callbacks (username, password, etc)
> and
> >>>>>>>
> >>>> have
> >>>>
> >>>>>>>
> >>>>>>>
> >>>>>> no
> >>>>>>
> >>>>>>
> >>>>>>> knowledge of the Servlet API. You can do authentication in
> an
> >>>>>>> Authenticator but that's not portable to other non-Tomcat/JBW
> >>>>>>> environments. The naming is a bit confusing IMO. It made
> >> sense
> >>>>>>>
> >>>> for
> >>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Tomcat but adds confusion in JBAS.
> >>>>>>>
> >>>>>>> You don't need to worry about writing an Authenticator unless
> >> you
> >>>>>>>
> >>>>>>>
> >>>>>> need
> >>>>>>
> >>>>>>
> >>>>>>> access to something that you don't already get from the
> >> existing
> >>>>>>> Authenticators, such as cookies, etc.
> >>>>>>>
> >>>>>>> -CB
> >>>>>>>
> >>>>>>> On 07/14/2010 10:53 AM, Bill Burke wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> Just guessing,
> >>>>>>>>
> >>>>>>>> Isn't the login module responsible for the actual
> >> authentication
> >>>>>>>>
> >>>>>>>>
> >>>>>> and
> >>>>>>
> >>>>>>
> >>>>>>>> authorization? Tomcat authenticator is just responsible for
> >>>>>>>>
> >>>>>>>>
> >>>>>> extracting
> >>>>>>
> >>>>>>
> >>>>>>>> header info?
> >>>>>>>>
> >>>>>>>> Sergey Beryozkin wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Hi
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> You can achieve by writing a tomcat authenticator and
> >> putting
> >>>>>>>>>>
> >>>> it
> >>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>> in
> >>>>>>
> >>>>>>
> >>>>>>>>>> WEB-INF/context.xml (JBAS) or META-INF/context.xml
> (tomcat).
> >>>>>>>>>>
> >>>>>>>>>> The auth-name is a string defined in the servlet spec.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> thanks for the tip.
> >>>>>>>>>
> >>>>>>>>> What is the difference between writing a custom Tomcat
> >>>>>>>>>
> >>>>>>>>>
> >>>>>> authenticator and a custom LoginModule, example,
> >>>>>>
> >>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>
> >>
> org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule
> >>>>
> >>>>>> ?
> >>>>>>
> >>>>>>
> >>>>>>>>> My understanding is that having custom login modules :
> >>>>>>>>> - makes it easy to stack together different modules,
> as
> >>>>>>>>>
> >>>> shown
> >>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>> for ex at [1]
> >>>>>>
> >>>>>>
> >>>>>>>>> - but requires the explicit loading of (JBoss
> Security)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>> AuthenticationManager (at least when services are POJOs)
> >>>>>>
> >>>>>>
> >>>>>>>>> cheers, Sergey
> >>>>>>>>>
> >>>>>>>>> [1]
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>
> >>
> http://community.jboss.org/wiki/SAMLEJBIntegrationwithPicketLinkSTS
> >>>>
> >>>>>>
> >>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On 07/13/2010 11:35 AM, Bill Burke wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Remy, Anil,
> >>>>>>>>>>>
> >>>>>>>>>>> (I'm cc'ing jboss-dev for archive purposes)
> >>>>>>>>>>>
> >>>>>>>>>>> Sergey , a new web services/resteasy hire, has done some
> >>>>>>>>>>>
> >>>> great
> >>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>> work
> >>>>>>
> >>>>>>
> >>>>>>>>>>> around OAuth lately. I'm interested in taking his stuff
> to
> >>>>>>>>>>>
> >>>> the
> >>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>> next
> >>>>>>
> >>>>>>
> >>>>>>>>>>> level and make it consumable in a way JBoss AS users are
> >> used
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>> to
> >>>>>>
> >>>>>>
> >>>>>>>>>>> configuring security.
> >>>>>>>>>>>
> >>>>>>>>>>> Specifically, I'm interested in defining a OAuth
> >>>>>>>>>>> login-config/auth-method within web.xml i.e.
> >>>>>>>>>>>
> >>>>>>>>>>> <login-config>
> >>>>>>>>>>> <auth-name>OAuth</auth-name>
> >>>>>>>>>>> <realm-name>...</realm-name>
> >>>>>>>>>>> </login-config>
> >>>>>>>>>>>
> >>>>>>>>>>> This would be an initial step, eventually I'd like to be
> >> able
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>> to
> >>>>>>
> >>>>>>
> >>>>>>>>>>> configure a web app to support multiple authentication
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>> mechanisms,
> >>>>>>
> >>>>>>
> >>>>>>>>>> so
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> that one URL could support both OAuth and traditional
> >>>>>>>>>>>
> >>>> clients.
> >>>>
> >>>>>>>>>>> Is JSR 196 the way to do this? Do we support in AS6? Is
> >>>>>>>>>>>
> >>>> there
> >>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>> doco
> >>>>>>
> >>>>>>
> >>>>>>>>>>> someplace? (I couldn't find with a search).
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>>
> >>>>>>>>>>> Bill
> >> _______________________________________________
> >> jboss-development mailing list
> >> jboss-development(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/jboss-development
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-development
>
>
> --
> Brian Stansberry
> Lead, AS Clustering
> JBoss by Red Hat
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
15 years, 10 months
Re: [jboss-dev] pluggable auth-method
by Sergey Beryozkin
Hi
> For OAuth there are a few issues:
>
> 1. It has specific headers.
> 2. You create "secrets" on the fly which are used to authenticate and
>
> authorize requests.
>
Regarding 2: This is just one approach which the RestEasy oauth-push-messaging takes, but one can imagine
the administrator registering the OAuth consumers representing say messaging services in advance.
> Maybe its best to first iterate on an Authenticator, then move logic
> up
> the stack once you get a prototype going? I don't know how Sergey
> likes
> to work :)
Well, my own problem so far is that I doubt the necessity of introducing a role-based
control access in a push-messaging case given the way the current solution works.
Specifically, a subscriber needs to grant the messaging service a permission to access a destination URI using a (domain) admin-level invocation on the message receiver; in other words the subscriber can not just tell the messaging service to push to some arbitrary server, the subscriber needs to control that specific URI space on that server; it is really the subscriber's space in the end of the day.
So it is an admin-level decision which is enforced by the OAuth filter anyway - by authenticating (by ensuring current OAuth client_id matches the records and checking the signature the secret) and validating that the request URI matches the one specified by the admin (subscriber) at the previous step.
Thus it is not obvious to me why it is worth introducing another authorization layer, at least given the way the push-messaging demo works at the moment. And when I'm in doubt I'm really working very slowly, sorry, probably not a good thing to say publicly :-)
Where I can see the login modules may be introduced is when we have OAuth consumers registered well in advance and say the administrator allocates roles to various consumers using nice UI and then we have a case where some consumers may access one (resource) service method and some other consumers can access some other method only. It is not the case with the push-messaging demo though.
cheers, Sergey
>
> Chris Bredesen wrote:
> > Yes.
> >
> > Authenticator is a Catalina/Web construct that delegates to a Realm
>
> > (Catalina construct) that, in JBAS is backed by LoginModules (JAAS
> > constructs, JBoss implementations).
> >
> > JAAS LoginModules are constrained by their own API which means they
> get
> > access to only certain callbacks (username, password, etc) and have
> no
> > knowledge of the Servlet API. You can do authentication in an
> > Authenticator but that's not portable to other non-Tomcat/JBW
> > environments. The naming is a bit confusing IMO. It made sense for
>
> > Tomcat but adds confusion in JBAS.
> >
> > You don't need to worry about writing an Authenticator unless you
> need
> > access to something that you don't already get from the existing
> > Authenticators, such as cookies, etc.
> >
> > -CB
> >
> > On 07/14/2010 10:53 AM, Bill Burke wrote:
> >> Just guessing,
> >>
> >> Isn't the login module responsible for the actual authentication
> and
> >> authorization? Tomcat authenticator is just responsible for
> extracting
> >> header info?
> >>
> >> Sergey Beryozkin wrote:
> >>> Hi
> >>>
> >>>> You can achieve by writing a tomcat authenticator and putting it
> in
> >>>> WEB-INF/context.xml (JBAS) or META-INF/context.xml (tomcat).
> >>>>
> >>>> The auth-name is a string defined in the servlet spec.
> >>>>
> >>> thanks for the tip.
> >>>
> >>> What is the difference between writing a custom Tomcat
> authenticator and a custom LoginModule, example,
> >>>
> org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule
> ?
> >>>
> >>> My understanding is that having custom login modules :
> >>> - makes it easy to stack together different modules, as shown
> for ex at [1]
> >>> - but requires the explicit loading of (JBoss Security)
> AuthenticationManager (at least when services are POJOs)
> >>>
> >>> cheers, Sergey
> >>>
> >>> [1]
> http://community.jboss.org/wiki/SAMLEJBIntegrationwithPicketLinkSTS
> >>>
> >>>
> >>>> On 07/13/2010 11:35 AM, Bill Burke wrote:
> >>>>> Remy, Anil,
> >>>>>
> >>>>> (I'm cc'ing jboss-dev for archive purposes)
> >>>>>
> >>>>> Sergey , a new web services/resteasy hire, has done some great
> work
> >>>>> around OAuth lately. I'm interested in taking his stuff to the
> next
> >>>>> level and make it consumable in a way JBoss AS users are used
> to
> >>>>> configuring security.
> >>>>>
> >>>>> Specifically, I'm interested in defining a OAuth
> >>>>> login-config/auth-method within web.xml i.e.
> >>>>>
> >>>>> <login-config>
> >>>>> <auth-name>OAuth</auth-name>
> >>>>> <realm-name>...</realm-name>
> >>>>> </login-config>
> >>>>>
> >>>>> This would be an initial step, eventually I'd like to be able
> to
> >>>>> configure a web app to support multiple authentication
> mechanisms,
> >>>> so
> >>>>> that one URL could support both OAuth and traditional clients.
> >>>>>
> >>>>> Is JSR 196 the way to do this? Do we support in AS6? Is there
> doco
> >>>>> someplace? (I couldn't find with a search).
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Bill
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-development
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
15 years, 10 months
osgi profile boot exception in AS trunk
by Dimitris Andreadis
just spotted this:
DEPLOYMENTS IN ERROR:
Deployment "OSGiDeploymentMetaDataDeployer" is in error due to the following r
eason(s): java.lang.ClassNotFoundException: org.jboss.deployers.plugins.classloa
ding.DeploymentMetaData from BaseClassLoader@12929b2{vfs:///X:/svn/jboss-trunk/b
uild/target/jboss-6.0.0-SNAPSHOT/server/osgi/deployers/osgi.deployer}
Deployment "vfs:///X:/svn/jboss-trunk/build/target/jboss-6.0.0-SNAPSHOT/server
/osgi/deploy/osgi/jboss-osgi-jaxb.jar" is in error due to the following reason(s
): java.lang.reflect.GenericSignatureFormatError
at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(Dep
loyersImpl.java:1228) [:2.2.0.Alpha6]
at org.jboss.osgi.framework.deployers.OSGiDeployersWrapper.checkComplete
(OSGiDeployersWrapper.java:189) [:1.0.0.Alpha4]
at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainD
eployerImpl.java:905) [:2.2.0.Alpha6]
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.c
heckComplete(MainDeployerPlugin.java:87) [:6.0.0-SNAPSHOT]
at org.jboss.profileservice.deployment.ProfileDeployerPluginRegistry.che
ckAllComplete(ProfileDeployerPluginRegistry.java:118) [:0.1.0.Alpha1]
at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceB
ootstrap.start(BasicProfileServiceBootstrap.java:133) [:6.0.0-SNAPSHOT]
at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceB
ootstrap.start(BasicProfileServiceBootstrap.java:56) [:6.0.0-SNAPSHOT]
at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(A
bstractServer.java:827) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.r
un(AbstractServer.java:417) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_16]
15 years, 10 months
Re: [jboss-dev] pluggable auth-method
by Sergey Beryozkin
Hi
> You can achieve by writing a tomcat authenticator and putting it in
> WEB-INF/context.xml (JBAS) or META-INF/context.xml (tomcat).
>
> The auth-name is a string defined in the servlet spec.
>
thanks for the tip.
What is the difference between writing a custom Tomcat authenticator and a custom LoginModule, example,
org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule ?
My understanding is that having custom login modules :
- makes it easy to stack together different modules, as shown for ex at [1]
- but requires the explicit loading of (JBoss Security) AuthenticationManager (at least when services are POJOs)
cheers, Sergey
[1] http://community.jboss.org/wiki/SAMLEJBIntegrationwithPicketLinkSTS
> On 07/13/2010 11:35 AM, Bill Burke wrote:
> > Remy, Anil,
> >
> > (I'm cc'ing jboss-dev for archive purposes)
> >
> > Sergey , a new web services/resteasy hire, has done some great work
>
> > around OAuth lately. I'm interested in taking his stuff to the next
>
> > level and make it consumable in a way JBoss AS users are used to
> > configuring security.
> >
> > Specifically, I'm interested in defining a OAuth
> > login-config/auth-method within web.xml i.e.
> >
> > <login-config>
> > <auth-name>OAuth</auth-name>
> > <realm-name>...</realm-name>
> > </login-config>
> >
> > This would be an initial step, eventually I'd like to be able to
> > configure a web app to support multiple authentication mechanisms,
> so
> > that one URL could support both OAuth and traditional clients.
> >
> > Is JSR 196 the way to do this? Do we support in AS6? Is there doco
>
> > someplace? (I couldn't find with a search).
> >
> > Thanks,
> >
> > Bill
15 years, 10 months
AS jars from maven repository
by Bill Burke
I've made a small change to jboss-classloading-vfs in my working copy so
that you can define a <maven-artifact> within a beans <classloader>
declaration, i.e.:
<classloader name="resteasy-classloader"
xmlns="urn:jboss:classloader:1.0" export-all="NON_EMPTY" import-all="true">
<maven-artifact>org.jboss.resteasy:resteasy-jaxrs:2.0-RC1</maven-artifact>
<maven-artifact>org.jboss.resteasy:async-http-servlet-3.0:2.0-RC1</maven-artifact>
</classloader>
It has no dependency on the profile service (not sure why Scott/Julien
wanted to do it that way anyways), just a simple change to the
VFSClassLoaderPolicyModule and XML metadata classes.
I currently have it hardcoded to look in $HOME/.m2/repository for maven
artifacts, and it assumes the .jar name can be discovered from the
artifact URI.
Any interest and moving this forward at all? The idea would be to look
for artifacts in this order:
1. $JBOSS_MAVEN_REPOSITORY
2. $JBOSS_HOME/maven-repository
3. $HOME/.m2/repository
The repository would have to be on local disk. This would greatly
reduce our distribution size as there would be no copies of jars
anywhere. It would also help development as you would not have to keep
rebuilding the AS distribution, or manually copying jar files to test
individual work you are doing. It would just be a change to the
artifact declaration.
The work would be in creating a <classloader> entry in each deployment
and creating the $JBOSS_HOME/maven-repository. A maven plugin could be
written to create a beans file with classloader info in it. The only
problem I see with that is some deployment units have multiple beans.xml
files and I don't know if <classloader> is processed in all beans.xml
first before the bean metadata.
I also might need some help if there are any scoping issues as the
classloader code is a spaghetti mess.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
15 years, 10 months
pluggable auth-method
by Bill Burke
Remy, Anil,
(I'm cc'ing jboss-dev for archive purposes)
Sergey , a new web services/resteasy hire, has done some great work
around OAuth lately. I'm interested in taking his stuff to the next
level and make it consumable in a way JBoss AS users are used to
configuring security.
Specifically, I'm interested in defining a OAuth
login-config/auth-method within web.xml i.e.
<login-config>
<auth-name>OAuth</auth-name>
<realm-name>...</realm-name>
</login-config>
This would be an initial step, eventually I'd like to be able to
configure a web app to support multiple authentication mechanisms, so
that one URL could support both OAuth and traditional clients.
Is JSR 196 the way to do this? Do we support in AS6? Is there doco
someplace? (I couldn't find with a search).
Thanks,
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
15 years, 10 months
Problems with Async Servlet (didn't have before)
by Bill Burke
Hoping Remy will respond:
I'm getting this. It worked before. Is there some interface I'm not
implementing for my Filter class?
Thanks,
Bill
Caused by: java.lang.IllegalStateException: The servlet or filters that
are being used by this request do not support async operation
at org.apache.catalina.connector.Request.startAsync(Request.java:3103) [:]
at
org.apache.catalina.connector.RequestFacade.startAsync(RequestFacade.java:1001)
[:]
at
org.jboss.resteasy.plugins.server.servlet.Servlet3AsyncHttpRequest.createAsynchronousResponse(Servlet3AsyncHttpRequest.java:39)
[:]
at
org.jboss.resteasy.core.SuspendInjector.inject(SuspendInjector.java:30) [:]
at
org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:114)
[:]
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
15 years, 10 months
Testing Deployers Outside AS
by Andrew Lee Rubinger
I haven't made too much noise about this yet, but now that it's released:
The Arquillian testing framework, as of 1.0.0.Alpha2, has a backing
container integration for JBoss Reloaded. Carlo's originally defined
"Reloaded" as the component which brings together a minimally-running
Virutal Deployment Framework, MC, and jboss-bootstrap:
http://community.jboss.org/docs/DOC-13453
The take-home that our Arquillian adaptor provides is an ultra-slim way
to bring up MC/VDF without any explicit coding and enables testing of
bits like Deployers and other MC beans in a slim manner, outside of AS.
For instance, I check the postcondition that one of my deployers adds an
attachment to the DeploymentUnit:
http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/components/async/tru...
In this way we can precertify that our projects' VDF components are
working before they hit AS. The test above runs in under 2s.
I recommend to projects using VDF that we start to use Arquillian as
outlined above. This is also possible via manual setup, but the
Reloaded APIs are still under change/flux, and hiding behind Arquillian
to do the wiring gives you a much smaller API to manage (not to mention
that it saves you from setting up jboss-bootstrap/MC on your own).
S,
ALR
15 years, 11 months
Re: [jboss-dev] [infinispan-dev] DataGrid Profile in JBoss AS
by Manik Surtani
On 2 Jul 2010, at 16:48, Galder Zamarreño wrote:
>>
>> Hmmm, I disagree actually. If this is code/configuration to integrate with AS/EAP, it should live in AS/EAP. JBoss Transactions used to AS integration within their code and this caused several issues to the AS team.
>
> Besides, think about testing. How are you gonna make sure the datagrid profile works fine if it lives within Infinispan source code? What about integration tests? You still gonna need to add those to the AS/EAP testsuite.
Yeah we have agreed that this will be in the AS src tree.
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
15 years, 11 months
