[JBoss-dev] Off Topic: New JBoss Manual SDocbook Src/XSL
Are these available somewhere - I'm trying to get started using docbook (instead of LaTeX and tth) and some xslt examples would be v. useful. Not surprisingly they don't appear to be in the newsite module, but I was wondering if they were online elsewhere. The new site Looks v. good by the way ... Luke. -- Luke Taylor. PGP Key ID: 0x57E9523C ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Apparent bug in Verifier - static inner classes as valid RMI/IIOP types
Dain Sundstrom wrote: Luke, In general, it is not really to use an innerclass as a type in a public api. In EJB it is a worse Idea. I think the verifier is complaining that your class is not serializable. On page 217 of Josh Block's book Effective Java her states Inner classes should rarely, if ever, implement Serializable. He then goes on to explain the synthetic fields generated by the compiler, and concludes with Therefore, the default serialized form of an inner class is ill-defined. A static memeber class can, however, implement Serializable [because it doesn't have synthetic fields] I looks like you are implementing the Value Object Pattern, and I would recomend sepperate class for the Value Object. If you leave it in your bean impl class you will have to distribute the bean impl to all you clients, and you will be unable to swap a new implementation into your app. Hmmm. I'm not sure I agree entirely: 1. the value object is effectively part of the interface because it is what is returned by the getData methods etc. So the client has to have access to it and I don't see anything drastically wrong with having the data bean as an inner class of the remote *interface* since it is inherently linked to it and used - I didn't say anything about it being part of the bean impl class. 2. The class is static and serializable - all I did was move an existing value object into the interface, as a housekeeping issue to avoid excessive clutter in my interfaces package. It works fine even with a standalone client (i.e. not just from an in-process web container where serialization may not be necessary). 3. In any case, whatever the arguments about the design issues, the comment in AbstractVerifier says it is checking If class is a *non*-static inner class then ... but the code applies the condition if isStatic(type) is true, so my comments about the possible bug here still seem valid ... Luke. Hi all, Can't get any access to Sourceforge so posting here instead... I tried moving a value data bean (AgentData) into the interface for the entity bean that it represents and the verifier (jboss_2.2.2_tomcat_2.2.2) doesn't seem to approve, with messages along the lines of: [Verifier] Bean : UserManager Method : public abstract Agent$Data getAgentData(String) throws RemoteException Section: 6.10.5 Warning: The method return values in the remote interface must be of valid types for RMI/IIOP. I think it must be falling foul of the following lines in AbstractVerifier.java: /* * If class is a non-static inner class then its containing class must * also be a conforming RMI/IDL value type. * * Spec 2.8.4 (3) */ if (type.getDeclaringClass() != null isStatic(type)) if (!isRMIIDLValueType(type.getDeclaringClass())) return false; which, if the comment is correct should probably read !isStatic(type) instead ??? Luke. -- Neu: sunrise hat jetzt noch günstigere Surfpreise! Sofort profitieren! http://go.sunrise.ch/de/promo1 -- Luke Taylor. PGP Key ID: 0x57E9523C ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Apparent bug in Verifier - static inner classes as valid RMI/IIOP types
Dain Sundstrom wrote: I stand corrected. I just assumed that you defined the class in the bean impl. I still wouldn't recoment it just because if find it anoying to type Parrent.InnerClass return type. Hey, it's not so bad - now I just have to write Agent.Data instead of AgentData :-). My main reasoning for it was that my class diagrams in Together were getting cluttered up with too many data beans which were generally only used through the one interface anyway. So it seemed like a good idea at the time. It looks like the verifier is wrong in this case, but I cant be certain as I have not read the 1.1 spec in detail. I think so - it makes sense that the check should only be applied to non-static inner classes. Static ones are pretty much the same as normal ones anyway apart from the '$' in the name, are they not?. Initially I assumed that might be screwing up IIOP naming conventions or something... Of course it may well still screw up in practice. Luke. -- Luke Taylor. PGP Key ID: 0x57E9523C ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] security exception in 2.4 final
Schouten, Andreas wrote: Hello, today I upgradet from 2.4.0.23 to 2.4.0 (file JBoss-2.4.0_Tomcat-3.2.3.zip). We use integated tomcat and jaas security. The first login is successful also calling a stateless session bean is successful. But when a second instance of this bean is created a security exception occur. The username seams to be lost. (The same ear works under 2.4.0.23) This sounds very similar to the problem I posted to the security forum yesterday. I get exactly the same exception, but in my case it isn't losing the username - it throws the exception before the login occurs and before the principal has been set. As soon as the user attempts to access a web URL which has a security contraint applied, the exception occurs and then the login goes ahead. Thereafter everything proceeds as normal - I can make as many requests as I want without any further problems ... Luke. [Default] Found StatelessSessionHome // after lookup the home interface [Default] javax.security.auth.login.FailedLoginException: No matching username found in Principals [Default] at org.jboss.security.auth.spi.DatabaseServerLoginModule.getUsersPassword(Datab aseServerLoginModule.java :96) ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] requirements for build
Dan - Blue Lotus Software wrote: -You need v1.4beta of Ant. The current release is v1.4beta2. -Copy the jar file from your_jboss_dir/tools/buildmagic-tasks.jar into the lib directory under Ant. It should work OK out of the box. I was in the same position last night - I hadn't done a build since 2.* and I spent ages messing about doing all sorts of unnecessary stuff trying to get it working - installing ant, hacking about with scripts, modifying paths in cygwin etc. etc. However, after a quick check through recent mails in the list (should've done that first, obviously :-), I worked out that ant is actually still included in the build - just do a cvs get jboss-all and run build/build.sh (use Cygwin on Windows as suggested). It's included in the tools package and the scripts find it OK, even with Cygwin. So I was able to delete my draft why isn't there a self-contained build anymore mails. I reckon the build.bat file will still have to work though, to avoid lots of user queries. Seems pretty impressive so far Luke. -- Luke Taylor. PGP Key ID: 0x57E9523C ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] FAQ
marc fleury wrote: We have one under the developer links, I think it could go back under the user links. One of the problems is that few people maintain it so it tends to get out of whack. If you have some time you could prune it and I will gladly reinstate it. marcf I'd be happy to contribute to this. If you like, I could have a go at putting together a more datailed FAQ, based on the current one. It would be a useful way of gathering together what I've learned about JBoss so far, and also help to consolidate other stuff (I'm generally very lazy about learning stuff unless I have a specific task in hand). I think numbering (e.g. docbook generated) would be a good start in terms of maintenance - at least then someone can register the fact tha FAQ x.y.z is no longer accurate... Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] First Iteration of the JBoss Farm
Hi Andreas, FarmAutoDeployer and FarmAutoDeployerMBean seem to be in the wrong package... Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Build and test procedure questions etc.
Hi, I want to check in some minor changes for a bugfix but I have one or two questions first before I screw things up :-)... 1. What's the situation with the test suite on different platforms. I get a more errors than the number in the standard automated report? I'm running on NT - do some of the tests only work on Linux? 2. The bug was reported on version the version 2.4.x branch. Should I change the code here as well as in the main branch? If so is there some way of doing this other than checking both trees out of cvs and making the changes in both of them separately? 3. Does anyone know if it's possible to configure Together to apply the JBoss code guidelines on indentation - it only seems possible to get it to use a fixed indentation width. cheers, Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build and test procedure questions etc.
Hi David, Thanks for your help... David Jencks wrote: ... 1. What's the situation with the test suite on different platforms. I get a more errors than the number in the standard automated report? I'm running on NT - do some of the tests only work on Linux? My understanding is that Chris only can run the tests on his linux system. I for one would be delighted if someone could run a nightly test on each other platform (hint hint;-) That could be possible. I've ordered a new machine and a DSL connection for the house (always used to slag off companies that skimped on infrastructure costs :-). I was planning on running linux on it though, as long as I can get it to talk to BT's dumb USB modem. Still on the testsuite, is there any procedure or are there guidelines for adding new tests or adding bits to existing ones? ... It may be easier to apply the changes by hand if they are small and this comfuses you as much as it did me. You might also want to check a manual to make sure I got this correct. Ok, thanks, I'm suitably confused :-)... I would understand this as being used when you want to merge updates that you don't have yet into your code (e.g. if you know that the changes are only stable up to a certain version). But I have the latest version of the main tree checked out and want to also apply the changes to the 2.4 branch... Having looked at the cvs manual, it seems I can use -j to go backwards too, thus removing previous version changes from my working copy. But it's giving me a sore head thinking about it so I think I'll just check the 2.4 branch out and commit it separately... Thanks, Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp/interfaces StatefulHandleImpl.java
User: negaton Date: 01/10/27 07:34:17 Modified:src/main/org/jboss/ejb/plugins/jrmp/interfaces StatefulHandleImpl.java Log: Fix for bug 474134. Security context wasn't being propagated during call to getEJBObject(). (For Entity and Stateless beans the invocation is made through the home proxy so this happens automatically). Added the current principal and credential (as obtained from SecurityAssociation) to the method invocation. Revision ChangesPath 1.10 +14 -1 jboss/src/main/org/jboss/ejb/plugins/jrmp/interfaces/StatefulHandleImpl.java Index: StatefulHandleImpl.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jrmp/interfaces/StatefulHandleImpl.java,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- StatefulHandleImpl.java 2001/09/01 19:50:31 1.9 +++ StatefulHandleImpl.java 2001/10/27 14:34:17 1.10 @@ -15,6 +15,7 @@ import javax.ejb.EJBObject; import javax.naming.InitialContext; +import org.jboss.security.SecurityAssociation; /** * An EJB stateful session bean handle. @@ -22,7 +23,7 @@ * @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a. * @author a href=mailto:[EMAIL PROTECTED]Marc Fleury/a * @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a - * @version $Revision: 1.9 $ + * @version $Revision: 1.10 $ */ public class StatefulHandleImpl extends AbstractHandle @@ -80,6 +81,14 @@ /** * Handle implementation. * + * This differs from Stateless and Entity handles which just invoke standard methods + * (ttcreate/tt and ttfindByPrimaryKey/tt respectively) on the Home interface (proxy). + * There is no equivalent option for stateful SBs, so a direct invocation on the container has to + * be made to locate the bean by its id (the stateful SB container provides an implementation of + * ttgetEJBObject/tt). + * + * This means the security context has to be set here just as it would be in the Proxy. + * * @return ttEJBObject/tt reference. * * @throws ServerExceptionCould not get EJBObject. @@ -117,6 +126,10 @@ // is the credential thread local? (don't think so... but...) //rmi.setPrincipal( getPrincipal() ); // rmi.setCredential( getCredential() ); + +// LT: added next two lines as fix for bug 474134 (26/10/01). Not sure which of the above comments are relevant... +rmi.setPrincipal(SecurityAssociation.getPrincipal()); +rmi.setCredential(SecurityAssociation.getCredential()); // Invoke on the remote server, enforce marshalling MarshalledObject mo = new MarshalledObject(rmi); ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp/interfaces StatefulHandleImpl.java
User: negaton Date: 01/10/27 07:51:50 Modified:src/main/org/jboss/ejb/plugins/jrmp/interfaces Tag: Branch_2_4 StatefulHandleImpl.java Log: Fix for bug 474134, as commited to main. Revision ChangesPath No revision No revision 1.6.4.1 +6 -2 jboss/src/main/org/jboss/ejb/plugins/jrmp/interfaces/StatefulHandleImpl.java Index: StatefulHandleImpl.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jrmp/interfaces/StatefulHandleImpl.java,v retrieving revision 1.6 retrieving revision 1.6.4.1 diff -u -r1.6 -r1.6.4.1 --- StatefulHandleImpl.java 2001/05/02 03:04:14 1.6 +++ StatefulHandleImpl.java 2001/10/27 14:51:49 1.6.4.1 @@ -15,6 +15,7 @@ import javax.ejb.EJBObject; import javax.naming.InitialContext; +import org.jboss.security.SecurityAssociation; import org.jboss.logging.Logger; /** @@ -23,7 +24,7 @@ * @author Rickard Öberg ([EMAIL PROTECTED]) * @author a href=mailto:[EMAIL PROTECTED]Marc Fleury/a * @author Jason Dillon a href=mailto:[EMAIL PROTECTED];lt;[EMAIL PROTECTED]gt;/a - * @version $Revision: 1.6 $ + * @version $Revision: 1.6.4.1 $ */ public class StatefulHandleImpl extends AbstractHandle @@ -118,7 +119,10 @@ // is the credential thread local? (don't think so... but...) //rmi.setPrincipal( getPrincipal() ); // rmi.setCredential( getCredential() ); - + +// LT: added next two lines as fix for bug 474134 (26/10/01). Not sure which of the above comments are relevant... +rmi.setPrincipal(SecurityAssociation.getPrincipal()); +rmi.setCredential(SecurityAssociation.getCredential()); // Invoke on the remote server, enforce marshalling MarshalledObject mo = new MarshalledObject(rmi); return (EJBObject)container.invokeHome(mo).get(); ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build and test procedure questions etc.
Scott M Stark wrote: Main and 2.4 are in general too far apart to make merging changes between branches doable. You have to treat them as independent versions and apply fixes to both branches using seperate cvs working versions. That makes sense. I've one more question, which David has given me some help on but I want to clear up the exact procedure. Do the CVS admin guidelines on tagging apply? I just (admittedly belatedly) tried to set the tag for the 2_4 branch to Rel_2_4_4_5, but got a warning that it already existed on two files: W src/main/org/jboss/ejb/plugins/BMPPersistenceManager.java : Rel_2_4_4_5 already exists on version 1.22.4.2 : NOT MOVING tag to version 1.22.4.1 W src/main/org/jboss/ejb/plugins/MessageDrivenTxInterceptorBMT.java : Rel_2_4_4_5 already exists on version 1.4.6.1 : NOT MOVING tag to version 1.4 Presumably because these files had changed and I forgot to do an update beforehand. The guidelines say to check the current tags on a single file to work out the next one, so I looked at build.xml and chose the 2.4.4.5 as the next build version. Shouldn't the release tags be applied across the whole codebase? Or am I missing something due to my lack of cvs experience (more than likely)? Also, why is tagging the main branch optional if committing directly to it but required if merging changes from another branch? cheers, Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/verifier/strategy AbstractVerifier.java
User: negaton
Date: 01/10/29 05:24:33
Modified:src/main/org/jboss/verifier/strategy AbstractVerifier.java
Log:
Fix for bug #448723. Static inner classes being reported as invalid RMI/IIOP types.
Revision ChangesPath
1.22 +4 -4 jboss/src/main/org/jboss/verifier/strategy/AbstractVerifier.java
Index: AbstractVerifier.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/verifier/strategy/AbstractVerifier.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- AbstractVerifier.java 2001/10/05 18:22:00 1.21
+++ AbstractVerifier.java 2001/10/29 13:24:32 1.22
@@ -19,7 +19,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* This package and its source code is available at www.jboss.org
- * $Id: AbstractVerifier.java,v 1.21 2001/10/05 18:22:00 starksm Exp $
+ * $Id: AbstractVerifier.java,v 1.22 2001/10/29 13:24:32 negaton Exp $
*/
// standard imports
@@ -62,7 +62,7 @@
* @author Aaron Mulder ([EMAIL PROTECTED])
* @author Vinay Menon ([EMAIL PROTECTED])
*
- * @version $Revision: 1.21 $
+ * @version $Revision: 1.22 $
* @sinceJDK 1.3
*/
public abstract class AbstractVerifier implements VerificationStrategy {
@@ -991,9 +991,9 @@
* If class is a non-static inner class then its containing class must
* also be a conforming RMI/IDL value type.
*
- * Spec 2.8.4 (3)
+ * Spec 28.2.4 (3)
*/
-if (type.getDeclaringClass() != null isStatic(type))
+if (type.getDeclaringClass() != null !isStatic(type))
if (!isRMIIDLValueType(type.getDeclaringClass()))
return false;
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/verifier/strategy AbstractVerifier.java
User: negaton
Date: 01/10/29 05:26:12
Modified:src/main/org/jboss/verifier/strategy Tag: Branch_2_4
AbstractVerifier.java
Log:
Backport of fix for bug #448723. Static inner classes not being reported as valid
RMI/IIOP types.
Revision ChangesPath
No revision
No revision
1.18.4.1 +4 -4 jboss/src/main/org/jboss/verifier/strategy/AbstractVerifier.java
Index: AbstractVerifier.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/verifier/strategy/AbstractVerifier.java,v
retrieving revision 1.18
retrieving revision 1.18.4.1
diff -u -r1.18 -r1.18.4.1
--- AbstractVerifier.java 2001/06/07 21:27:06 1.18
+++ AbstractVerifier.java 2001/10/29 13:26:12 1.18.4.1
@@ -19,7 +19,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* This package and its source code is available at www.jboss.org
- * $Id: AbstractVerifier.java,v 1.18 2001/06/07 21:27:06 kvvinaymenon Exp $
+ * $Id: AbstractVerifier.java,v 1.18.4.1 2001/10/29 13:26:12 negaton Exp $
*/
// standard imports
@@ -62,7 +62,7 @@
* @author Aaron Mulder ([EMAIL PROTECTED])
* @author Vinay Menon ([EMAIL PROTECTED])
*
- * @version $Revision: 1.18 $
+ * @version $Revision: 1.18.4.1 $
* @sinceJDK 1.3
*/
public abstract class AbstractVerifier implements VerificationStrategy {
@@ -987,9 +987,9 @@
* If class is a non-static inner class then its containing class must
* also be a conforming RMI/IDL value type.
*
- * Spec 2.8.4 (3)
+ * Spec 28.2.4 (3)
*/
-if (type.getDeclaringClass() != null isStatic(type))
+if (type.getDeclaringClass() != null !isStatic(type))
if (!isRMIIDLValueType(type.getDeclaringClass()))
return false;
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Testsuite on Windows NT - Problems
javax.security.auth.login.LoginException: java.lang.NoSuchMethodError at org.jboss.security.auth.spi.UsernamePasswordLoginModule.getUsernameAndPassword(UsernamePasswordLoginModule.java:159) at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:94) at org.jboss.security.auth.spi.UsersRolesLoginModule.login(UsersRolesLoginModule.java:110) at java.lang.reflect.Method.invoke(Native Method) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:664) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:129) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:599) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:596) at javax.security.auth.login.LoginContext.login(LoginContext.java:523) at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:385) at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:352) at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:208) at org.jboss.jetty.JBossUserRealm$User.authenticate(JBossUserRealm.java:64) I've done several clean builds with recent source but can't seem to improve the figures any... Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Testsuite on Windows NT - Problems
marc fleury wrote: ... I will try to run it myself, the build is pissing me off as I can run one by one without heavy modification. I want to finish the JMX invoker first (did the detaching last week) and then work on that suite, stay tuned, I will need your help. Running the tests-security-basic-unit target in the testsuite module is enough to screw things up sufficiently to illustrate the problem. FYI the code you want to look at is the ServiceLibraries and URLCl, but just wait for me, it can get confusing. OK, thanks Marc, I'll look a bit further (without rushing :). So is it OK that the classloader that is loading the app resources only has jmx-rmi-adaptor.sar in its URL list, or is that a bug? Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/xdocs designnotes.xml
User: luke_t Date: 01/11/16 17:27:26 Modified:src/xdocs designnotes.xml Log: addition of id attributes for reference from FAQ Revision ChangesPath 1.2 +2 -2 manual/src/xdocs/designnotes.xml Index: designnotes.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/designnotes.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- designnotes.xml 2001/08/29 09:19:36 1.1 +++ designnotes.xml 2001/11/17 01:27:26 1.2 @@ -1,5 +1,5 @@ ?xml version = 1.0 encoding = UTF-8? -chapter +chapter id=design titleContainer architecture - design notes/title paraAuthor:author firstnameVladimir/firstname @@ -234,7 +234,7 @@ server side. Consult RMI specification for more info./para /section /section - section + section id=design.jmx titleJMX - foundation of JBoss infrastructure/title section titleIntroduction/title ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/xdocs faq.xml
User: luke_t Date: 01/11/16 17:28:10 Modified:src/xdocs faq.xml Log: more basic knocking into shape Revision ChangesPath 1.2 +69 -51manual/src/xdocs/faq.xml Index: faq.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/faq.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- faq.xml 2001/11/15 22:03:59 1.1 +++ faq.xml 2001/11/17 01:28:10 1.2 @@ -1,15 +1,16 @@ ?xml version=1.0 encoding=UTF-8? -!-- !DOCTYPE article PUBLIC -//OASIS//DTD DocBook XML V4.1.2//EN docbookx/docbookx.dtd -- +!-- DOCTYPE article SYSTEM ../../../ThirdParty/oasis/docbook-xml/docbookx.dtd -- + article class=faq articleinfo titleJBoss FAQ/title - releaseinfo$Revision: 1.1 $, $Date: 2001/11/15 22:03:59 $/releaseinfo + releaseinfo$Revision: 1.2 $, $Date: 2001/11/17 01:28:10 $/releaseinfo !--revhistory revision - revnumber$Revision: 1.1 $/revnumber - date$Date: 2001/11/15 22:03:59 $/date + revnumber$Revision: 1.2 $/revnumber + date$Date: 2001/11/17 01:28:10 $/date /revision /revhistory -- @@ -32,7 +33,7 @@ qandaentry id=faq.intro.version questionparaWhat is the version of this FAQ and when was it last updated?/para/question answer - paraThis is $Revision: 1.1 $ of the FAQ. The last update was made on $Date: 2001/11/15 22:03:59 $./para + paraThis is $Revision: 1.2 $ of the FAQ. The last update was made on $Date: 2001/11/17 01:28:10 $./para /answer /qandaentry @@ -41,12 +42,12 @@ answer paraEverybody :)./para paraTODO: list original creators and maintainers.../para -!-- -The first version of the JBoss FAQ was created by Kunle Odutola in March 2000. The second version of the FAQ was a rewrite by Jeremiah Johnson in August 2000 with maintenance by Kunle Odutola. The current version is maintained by Dewayne McNair. + !-- + The first version of the JBoss FAQ was created by Kunle Odutola in March 2000. The second version of the FAQ was a rewrite by Jeremiah Johnson in August 2000 with maintenance by Kunle Odutola. The current version is maintained by Dewayne McNair. -Most of the wisdom contained in the answers presented here however comes from the collective insights and diligence of the many others who inhabit the JBoss mailing list(s) and the EJB world-at-large. + Most of the wisdom contained in the answers presented here however comes from the collective insights and diligence of the many others who inhabit the JBoss mailing list(s) and the EJB world-at-large. --- + -- /answer /qandaentry @@ -70,26 +71,23 @@ The Java 2 Platform Enterprise Edition (J2EE) is the platform for developing, deploying and managing n-tiered information systems using Java technologies. The platform encourages the development of enterprise systems with the ability to run emphasisanywhere/emphasis across a wide range of operating systems. J2EE extends the Java 2 Platform to cater for the server-side processing needs of the enterprise with key technologies including the following: itemizedlist - !-- TODO: Add links to java.sun.com etc. here -- - listitemparaEnterprise JavaBeans (EJB)/para/listitem - - listitemparaJava Naming and Directory Interface (JNDI)/para/listitem + listitemparaEnterprise JavaBeans (ulink url=http://java.sun.com/products/ejb/index.html;EJB/ulink)/para/listitem - listitemparaJDBC data access API/para/listitem + listitemparaJava Naming and Directory Interface (ulink url=http://java.sun.com/products/jndi/index.html;JNDI/ulink)/para/listitem - listitemparaJava Servlets/para/listitem + listitemparaulink url=http://java.sun.com/products/jdbc/index.html;JDBC/ulink data access API/para/listitem - listitemparaJavaServer Pages (JSP)/para/listitem + listitemparaJava ulink url=http://java.sun.com/products/servlet/index.html;Servlets/ulink/para/listitem - listitemparaJava Transaction API (JTA)/para/listitem + listitemparaJavaServer Pages (ulink url=http://java.sun.com/products/jsp/index.html;JSP/ulink)/para/listitem - listitemparaJava Transaction Service (JTS)/para/listitem +
Re: [JBoss-dev] [ANN] JBoss 3.0 alpha is out
Adam Heath wrote: On Sun, 25 Nov 2001, marc fleury wrote: Such nice, friendly emails from you. Makes one just want to pitch in and help. Hmmm. Perhaps you should take a look back at your own emails over the last week or so. You sound like a spoilt child stamping his feet and demanding stuff. First all that business with the build and debian and now Where is the tomcat integration? I hope that's just an honest oversite sic on your part, followed by a rather smug reference to it's being the reference implementation for java servlets which I'm sure everyone is already aware of ... These kinds of emails are not the ones that make people want to flock to program for JBoss. Given previous form, I'd say you got off lightly :-). Luke. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/xdocs jbossintro.xml
User: luke_t Date: 01/11/28 05:59:23 Modified:src/xdocs jbossintro.xml Log: corrected bad ulink to jbossgroup support. Revision ChangesPath 3.1 +7 -7 manual/src/xdocs/jbossintro.xml Index: jbossintro.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/jbossintro.xml,v retrieving revision 3.0 retrieving revision 3.1 diff -u -r3.0 -r3.1 --- jbossintro.xml2001/11/18 20:10:57 3.0 +++ jbossintro.xml2001/11/28 13:59:23 3.1 @@ -1,6 +1,6 @@ ?xml version = 1.0 encoding = UTF-8? chapter - titleFirst steps/title + titleFirst steps/title paraAuthors:author firstnameKevin/firstname surnameBoone/surname @@ -52,12 +52,12 @@ this starts up automatically with the server (J2EE ships with the CloudScape SQL server, which has to be started separately). /para paraOne of the nicest features of JBoss is its support for `hot' -deployment. What this means is that deploying a Bean is a simple as copying its -JAR file into the deployment directory. If this is done while the Bean is -already loaded, JBoss automatically unloads it, then loads the new -version. Contrast this with the rigmarole that other J2EE server makes us go through... -JBoss is distributed under the LGPL, which means that it's free, even for commercial -work, and the LGPL ensures that it remains that way. Id you need support, look at the JBoss website for the various forums. If you want to pay for the support then contact the ulink url = http://www.jboss.org/JBG/support.jsp;JBossGroup LLC/ulink./para + deployment. What this means is that deploying a Bean is a simple as copying its + JAR file into the deployment directory. If this is done while the Bean is + already loaded, JBoss automatically unloads it, then loads the new + version. Contrast this with the rigmarole that other J2EE server makes us go through... + JBoss is distributed under the LGPL, which means that it's free, even for commercial + work, and the LGPL ensures that it remains that way. Id you need support, look at the JBoss website for the various forums. If you want to pay for the support then contact the ulink url = http://www.jboss.org/jbossgroup/services.jsp;JBossGroup LLC/ulink./para paraThis chapter helps get you started using JBoss by describing step-by-step how a simple EJB can be created, deployed and tested on the JBoss server. /para ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: on the use of final
Dain Sundstrom wrote: There are like five hundred rules on that page. What is it specifically flagging as a bad practice? I am actually interested. I had a look at the page too (try searching for the word final :-). But it doesn't really seem say more than the obvious Helps compiler optimization and more clearly documents the use of classes ... So it can be helpful for people reading the code to know that it has no subclases, but it's not really a big deal. Together also has some QA rules relating to the use of final. One is that *all* instantiated classes should be final. The others just seem to relate to constant attributes which seems fair enough. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: on the use of final
danch wrote: ... Snort! Cocaine? Late night coding again ... -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Book. Was Re: [JBoss-dev] /. - want you to tell about my fears ....
Scott Stark wrote: So if this 400 page book I have in front of me, which is undergoing author review through Sams and will be released to Flashline next week doesn't constitute active maintenance, what does? Hi Scott, Does the book cover any of the new JBoss 3.0 stuff? I'm trying to write sensible FAQ questions and realising that I don't know JBoss 3 answers myself yet. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Book. Was Re: [JBoss-dev] /. - want you to tell about my fears ....
marc fleury wrote: The model for the book and documentation is that we are going to only support the professional documentation. Free documentation is just too hard, the guys who write it usually do it and leave, it comes under heavy criticism still today (see theserverside.com thread) and generally has been a pain. I have had enough of it. We are going to a model where you pay for the documentation, the free doco is just going to die. I don't think I will even distribute it any more. OK. I see. I wasn't aware of this - I've been converting the FAQ to docbook to go along with the manual and attempting to extend its coverage, but it seems this will be a bit of a pointless exercise if the online docmumentation is to be scrapped. I thought the documentation trees had just been branched recently with a view to providing separate docs for 2 and 3? This is a simple way to make some money FOR THE DEVELOPERS OF THE FEATURES and grow professionally. Don't you think it is also in the interest of the developers to maintain a few FAQs to keep people off their backs too. I think it was Dain who asked whether there was a FAQ a while back because he was getting fed up with people posting questions about EJB 2.0 CMP. If the guys reading the statement are too cheap to shell out $10 for the documentation I am really not going to worry about them, I am not very concerned about them. In fact I want them gone, That's fair enough - if people want to use JBoss seriously then they should be prepared to do this. But for someone who's having a look for the first time, to see what it is and how it works, the first thing they're going to look for is some documentation, howtos etc. Either that or they'll start posting unnecessarily in the forums. Perhaps the scope of the online stuff should be cut down but you should keep the basic howto's on getting started, setting up datasources and so on. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/xdocs faq.xml
User: luke_t Date: 01/11/29 18:50:06 Modified:src/xdocs faq.xml Log: more faq filling ... Revision ChangesPath 3.1 +162 -89 manual/src/xdocs/faq.xml Index: faq.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/faq.xml,v retrieving revision 3.0 retrieving revision 3.1 diff -u -r3.0 -r3.1 --- faq.xml 2001/11/18 20:10:57 3.0 +++ faq.xml 2001/11/30 02:50:06 3.1 @@ -6,11 +6,11 @@ articleinfo titleJBoss FAQ/title - releaseinfo$Revision: 3.0 $, $Date: 2001/11/18 20:10:57 $/releaseinfo + releaseinfo$Revision: 3.1 $, $Date: 2001/11/30 02:50:06 $/releaseinfo !--revhistory revision - revnumber$Revision: 3.0 $/revnumber - date$Date: 2001/11/18 20:10:57 $/date + revnumber$Revision: 3.1 $/revnumber + date$Date: 2001/11/30 02:50:06 $/date /revision /revhistory -- @@ -33,7 +33,7 @@ qandaentry id=faq.intro.version questionparaWhat is the version of this FAQ and when was it last updated?/para/question answer - paraThis is $Revision: 3.0 $ of the FAQ. The last update was made on $Date: 2001/11/18 20:10:57 $./para + paraThis is $Revision: 3.1 $ of the FAQ. The last update was made on $Date: 2001/11/30 02:50:06 $./para /answer /qandaentry @@ -41,26 +41,28 @@ questionparaWho is responsible for this FAQ?/para/question answer paraEverybody :)./para - paraTODO: list original creators and maintainers.../para - !-- - The first version of the JBoss FAQ was created by Kunle Odutola in March 2000. The second version of the FAQ was a rewrite by Jeremiah Johnson in August 2000 with maintenance by Kunle Odutola. The current version is maintained by Dewayne McNair. - - Most of the wisdom contained in the answers presented here however comes from the collective insights and diligence of the many others who inhabit the JBoss mailing list(s) and the EJB world-at-large. - - -- + paraThe original JBoss FAQ was created by Kunle Odutola in March 2000. The second version of the FAQ was a rewrite by Jeremiah Johnson in August 2000 with maintenance by Kunle Odutola. Maintenance subsequently passed on to Dewayne McNair... The current version has been ulink url=http://www.docbook.org;docbookified/ulink and will be maintained as part of the ulink url=http://www.jboss.org/online-manual/HTML/;online manual/ulink. + /para /answer /qandaentry qandaentry questionparaWhere can I get the latest version of this FAQ?/para/question answer - paraThis incarnation of the JBoss FAQ is intended to provide a more comprehensive set of entry points into the online manual as well as being a single, condensed source of information on JBoss. As such, it can be found along with the manual on the ulink url=http://www.jboss.org;JBoss website./ulink/para !-- TODO: more exact link -- + paraThis incarnation of the JBoss FAQ is intended to provide a more comprehensive set of entry points into the online manual as well as being a single, condensed source of information on JBoss. As such, it can be found along with the manual on the ulink url=http://www.jboss.org/online-manual/HTML/;JBoss website./ulink/para /answer /qandaentry + qandaentry + questionparaWhat other documentation is available apart from this FAQ?/para/question + answer + paraYou can browse the ulink url=http://www.jboss.org/online-manual/HTML/;online manual/ulink. However this is not intended as an in-depth source of information, but rather to get you up and running./para + paraYou are encouraged to purchase the full ulink url=http://www.jboss.org/doco.jsp;documentation/ulink which is up to date, written by the developers and is available at minimal cost. This also supports future development./para + /answer + /qandaentry /qandadiv - +!-- General J2EE -- qandadiv id=faq.general titleGeneral/title paraBasic questions about J2EE./para @@ -168,8 +170,22 @@ /answer /qandaentry + qandaentry + questionparaWhat else should I take a look at if I want more in-depth general information?/para/question + answer + itemizedlist + listitem + paraThe ulink url=http://java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf;J2EE Specification/ulink./para + /listitem + /itemizedlist + + /answer +
Re: [JBoss-dev] OracleLoginModule
Sonnek, Ryan wrote: out of curiosity, could you say how you did this? i'm assuming that you're authenticating to the DBA_USERS and DBA_USER_ROLES tables, and this is something that i tried a while back. i got stuck being able to hash my login modules password to match oracles. there was no documentation on what algorithm they were using, and so after trying a few, i gave up. this is something that i am HIGHLY interested in, and would love to take a look at. Can't you just get Oracle to handle this, by using the getConnection(name, pw) method on the datasource (as David mentioned) to authenticate the user? Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jbosscx rfe 677512
Bill Burke wrote: I am not sure I understand your problem. In RFE you are saying cached prepared statements stay alive and cause this error. What caches prepared statements? Did you explicitly enabled statement caching on oracle connections? I remember seeing this error message but it turned to be a problem in one of my SSBs which did not explicitly close java.sql.[Prepared]Statement. Well, strictly speaking it is a known JBoss bug/limitation -- Connection.close() does not close all opened [Prepared]Statement as it is supposed to -- but is has a reasonable workaround. Igor is correct. You are probably not closing your statements and/or ResultSets. You can get what sql statements are being leaked from Oracle. Backtrack in your code to find out where you are not closing your statements. You should also be able to work out where the problem is by checking with Oracle - there's a system table called v$open_cursors or something like that and it is sometimes possible to work out which SQL call is causing the problem from there and tidy up your closing code. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TxInterceptor split is still the best thing sincesliced bread
David Jencks wrote: Maybe we're confusing 2 issues here: 1. writing a maintainable usable jboss dtm 2. supporting corba etc. Does anyone actually use CORBA clients agains JBoss - from Java even, never mind C++. I can understand the desire to use CORBA the other way - i.e. calling out to access a legacy system, but is there any reason why anone would choos to use CORBA clients. Maybe supporting them isn't really so important. At one point CORBA was intended to support interceptors (client and server side) in a standard way, but I've no idea if the spec. was ever completed - they always seemed to be arguing about it and that was years ago. If it was, you could probably supply a set of JBoss CORBA interceptors which did the same job as the custom Java ones. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Maven rumour
Someone pointed out a post today on the Maven-dev list which said that JBoss wants to move to Maven. Is there any truth in this and if so, any idea of how the move is going to be made? I've been looking at Maven a bit recently and my guess is that the move might not be entirely painless. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DTD hell
Scott M Stark wrote: ... !ELEMENT loader-repository-config (ANY) Does it make any difference if you leave the brackets off the ANY ? http://www.w3.org/TR/REC-xml#NT-elementdecl -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Regarding JBoss site
Juha-P Lindfors wrote: It's not the new look that is bad (the red bar and the menu) its all the other stuff that blinks worse than your average porn site. An eyesore. Too much stuff that just bounces around. You a regular average porn site browser, Juha? I agree though, there's too much flashing stuff, and I don't see why the main logo uses flash - I always have it killed off in Mozilla and all I get is an empty box. Why not just have a plain image? Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: AW: [JBoss-dev] jboss-head/testsuite/build has 100 errors forme
Jung , Dr. Christoph wrote: Have you checked that all relevant thirdparty modules have been obtained through cvs? BTW: I got no jdo.jar on my workspace either ... Must be some recent addition, I guess. sun-jdo? The javax.jdo classes should be in the source tree, so I don't think there's any need for a thirdparty jar. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ManagementBean and RemoteMbeanServer
Adrian Brock wrote: Hi Luke, In head, the plan is to use jsr160 and the MBeanServerConnection interface from jmx1.2 OK, thanks Adrian. I'll have a look at that. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ManagementBean and RemoteMbeanServer
Luke Taylor wrote: Adrian Brock wrote: Hi Luke, In head, the plan is to use jsr160 and the MBeanServerConnection interface from jmx1.2 OK, thanks Adrian. I'll have a look at that. I've used an MBeanServer instance for the time being 'cos that compiles OK and I'm not sure exactly what the future plans are. Otherwise I'd have to put in lots of catch blocks for IOExceptions which the connection interface throws. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ManagementBean and RemoteMbeanServer
Luke Taylor wrote: Adrian Brock wrote: Hi Luke, In head, the plan is to use jsr160 and the MBeanServerConnection interface from jmx1.2 OK, thanks Adrian. I'll have a look at that. I've used an MBeanServer instance for the time being 'cos that compiles OK and I'm not sure exactly what the future plans are. Otherwise I'd have to put in lots of catch blocks for IOExceptions which the connection interface throws. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Naming service startup problem...
I've got a problem with my Maven build. I've pretty much build a replica of the JBoss server as it stands with the current build, but during startup, the naming service appears to be trying to use tyrex classes instead of the jnp ones and I've no idea where it's getting the idea from. The jndi.properties file is in the conf directory (I assume that's where it bootstraps from) but I get the following exception in the log during startup (and things naturally screw up from then on): log 2003-06-18 19:06:35,218 DEBUG [org.jboss.system.ServiceController] starting service jboss:service=Naming 2003-06-18 19:06:35,218 INFO [org.jboss.naming.NamingService] Starting 2003-06-18 19:06:35,265 DEBUG [org.jboss.naming.NamingService] System.setProperty, key=java.naming.factory.initial, value=tyrex.naming.MemoryContextFactory 2003-06-18 19:06:35,281 DEBUG [org.jboss.naming.NamingService] System.setProperty, key=java.naming.provider.url, value= 2003-06-18 19:06:35,281 DEBUG [org.jboss.naming.NamingService] System.setProperty, key=java.naming.factory.url.pkgs, value=tyrex.naming 2003-06-18 19:06:35,281 INFO [org.jboss.naming.NamingService] Starting jnp server 2003-06-18 19:06:35,531 DEBUG [org.jboss.naming.NamingService] NamingServer stub: org.jnp.server.NamingServer_Stub[RemoteStub [ref: [endpoint:[217.39.46.22:1978](local),objID:[0 2003-06-18 19:06:35,703 INFO [org.jboss.naming.NamingService] Started jnpPort=1099, rmiPort=0, backlog=50, bindAddress=null, Client SocketFactory=null, Server SocketFactory=null 2003-06-18 19:06:35,859 DEBUG [org.jboss.naming.NamingService] InitialContext Environment: 2003-06-18 19:06:35,859 DEBUG [org.jboss.naming.NamingService] key=java.naming.factory.initial, value=tyrex.naming.MemoryContextFactory 2003-06-18 19:06:35,859 DEBUG [org.jboss.naming.NamingService] key=java.naming.provider.url, value= 2003-06-18 19:06:35,875 DEBUG [org.jboss.naming.NamingService] key=java.naming.factory.url.pkgs, value=tyrex.naming:tyrex.naming:org.jboss.naming:org.jnp.interfaces 2003-06-18 19:06:35,875 WARN [org.jboss.naming.NamingService] Context.PROVIDER_URL in server jndi.properties, url= 2003-06-18 19:06:36,140 ERROR [org.jboss.naming.NamingService] Starting failed: javax.naming.OperationNotSupportedException: Context is read-only 2003-06-18 19:06:36,156 WARN [org.jboss.system.ServiceController] Problem starting service jboss:service=Naming javax.naming.OperationNotSupportedException: Context is read-only at tyrex.naming.EnvContext.rebind(EnvContext.java:345) at org.jboss.naming.NamingService.startService(NamingService.java:189) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:233) /log Anyone any ideas why it would be picking up the wrong classes? Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Naming service startup problem...
Luke Taylor wrote: Anyone any ideas why it would be picking up the wrong classes? I can get round the problem by deleting the jndi.properties file from the tyrex jar, so I guess the question can be reduced to: Why might the tyrex jar end up listed before the 'conf' directory in the classloader the naming service is using? -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] www.jboss.org: developers - source code
Hi all, Couple of small problems with the web site: The Quick Start Guide link (http://www.jboss.org/developers/guide/quickstart.jsp) on this page is broken. And the image is missing from the CVS Admin page: http://www.jboss.org/developers/guides/cvs-admin.jsp Also, the nightly snapshots seem to be from April so maybe this section should be dropped unless there are plans to reinstate them. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/xdocs faq.xml
User: luke_t Date: 01/12/04 18:07:57 Modified:src/xdocs faq.xml Log: added link to juha's book and some CMP stuff with ref to Dain's CMP 2.0 docs. Revision ChangesPath 3.2 +20 -18manual/src/xdocs/faq.xml Index: faq.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/faq.xml,v retrieving revision 3.1 retrieving revision 3.2 diff -u -r3.1 -r3.2 --- faq.xml 2001/11/30 02:50:06 3.1 +++ faq.xml 2001/12/05 02:07:56 3.2 @@ -6,11 +6,11 @@ articleinfo titleJBoss FAQ/title - releaseinfo$Revision: 3.1 $, $Date: 2001/11/30 02:50:06 $/releaseinfo + releaseinfo$Revision: 3.2 $, $Date: 2001/12/05 02:07:56 $/releaseinfo !--revhistory revision - revnumber$Revision: 3.1 $/revnumber - date$Date: 2001/11/30 02:50:06 $/date + revnumber$Revision: 3.2 $/revnumber + date$Date: 2001/12/05 02:07:56 $/date /revision /revhistory -- @@ -24,7 +24,7 @@ /abstract -- - qandaset defaultlabel=number + qandaset qandadiv id=faq.intro titleIntroduction/title @@ -33,7 +33,7 @@ qandaentry id=faq.intro.version questionparaWhat is the version of this FAQ and when was it last updated?/para/question answer - paraThis is $Revision: 3.1 $ of the FAQ. The last update was made on $Date: 2001/11/30 02:50:06 $./para + paraThis is $Revision: 3.2 $ of the FAQ. The last update was made on $Date: 2001/12/05 02:07:56 $./para /answer /qandaentry @@ -153,12 +153,14 @@ answer paraWith respect to Enterprise JavaBeans (EJBs), persistence is a term that describes the process whereby the the state of an active (stateful?) EJB is stored (usually to a database) in such a way that the EJB can be reactivated later. It is serialization for EJBs if you like./para - paraThere are two flavours of persistence in EJB - Bean-Managed Persistence (BMP) and Container-Managed Persistence (CMP). The main difference between the two flavours is who is responsible for emphasisactually/emphasis persisting the EJB. In BMP the bean developer is responsible for writing the code that persists the beans state (maybe using JDBC?) while in CMP, the container is reponsible. In CMP a bean developer might not even emphasisknow/emphasis what object-relational database persistence is let alone how it works?. Pretty neat./para + paraThere are two flavours of persistence in EJB - Bean-Managed Persistence (BMP) and Container-Managed Persistence (CMP). The main difference between the two flavours is who is responsible for emphasisactually/emphasis persisting the EJB. In BMP the bean developer is responsible for writing the code that persists the bean's state (maybe using JDBC?) while in CMP, the container is reponsible./para paraA relevant excerpt from the ulink url=http://java.sun.com/products/ejb/docs.html;EJB 1.1. specification/ulink itself, on page 100: blockquoteparaThe entity bean component protocol allows the entity Bean Provider either to implement the entity bean's persistence directly in the entity bean class or in one or more helper classes provided with the entity bean class (bean-managed persistence), or to delegate the entity bean's persistence to the Container Provider tools used at deployment time (container-managed persistence)./para/blockquote /para + + paraFor more on CMP with JBoss, see xref linkend=faq.cmp//para. /answer /qandaentry @@ -166,7 +168,7 @@ questionparaWhat are these MBeans and JMX that I keep hearing about?/para/question answer paraquoteManaged Beans/quote are part of the Java Management Extensions Specificationulink url=http://java.sun.com/products/JavaManagement/;(JMX)/ulink (formerly JMAPI). This provides an architecture and API for application management using Java. JBoss has made JMX its own and it forms the basis of the entire JBoss infrastructure. JBoss is basically a series of MBean service components plugged together using JMX as the bus. See the link linkend=design.jmxdesign notes/link for more information./para - paraFor an in-depth explanation of JMX and its potential uses, see the forthcoming book by Juha Lindfors FIXME ref, date./para + paraFor an in-depth explanation of JMX and its potential uses, see the forthcoming book ulink url=http://www.samspublishing.com/detail_sams.cfm?item=0672322889;JMX: Managing J2EE with Java Management Extensions/ulink by Juha Lindfors./para /answer /qandaentry @@ -178,7 +180,6 @@ paraThe ulink
Re: [JBoss-dev] RE: JBoss 3.0 Demo App
Tilly, Jesse wrote: JBoss examples would probably do well trying to show how to best use JBoss in particular instances. This would help would-be JBoss developers better understand the nuances of the application server. I would agree that it's better to have small examples that demonstrate key features. Preferrably you want something you can drop into the deploy directory of a fresh JBoss install and see it working almost right away. Then you can build from there. When people are trying to find out about something - be it basic EJB, CMP, security, whatever, they want something that is does the job without unnecessary complication. Or at least I do - I always found the pet store application really irritating. You can see what it does but there's also a load of design guff which prevents you from seeing how it does it. You can't see the trees for the wood, so to speak :). Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ANN JBossMX a JMX implementation in JBoss
Great. Is it included as part of jboss-all, or a separate module in CVS? Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
Bill Burke wrote: Guys, You all may or may not agree, but the current structure of mbean xml files is really confusing. Ah. I'm glad someone else has some reservations. I assumed I was just lagging behind (probably true anyway) and that everyone else knew exactly what was going on from all the discussions on sars and services so it's good to hear a mildly dissenting voice with some clout. Could somone possibly supply a v. brief summary of the current situation and what the final plan is? Some things it would be useful to know: 1. I take it jboss-service.xml is loaded first - would it work if I put other (independent) services in here, even though it says not to ? 2. Is the boot-server configuration only used for booting over the network - can we try this out just now, and how do you decide what configuration it obtains/supplies?? 3. Why does the jetty mbean in the jboss-service.xml (in boot-server) refer to two files which don't exist (at least not in the current build): Configuration../conf/boot-server/jetty.xml/attribute WebDefault../conf/boot-server/webdefault.xml/attribute 4. Do all my other services go in the deploy directory rather than conf/blah? This seems to make it a bit harder to set up several different static configurations (as you would do previously by just creating new dirs in jboss/conf). I guess the hot-deploy of services makes this less of an issue. 5. Should they be sars, or plain xml files, or does it matter. Are the sars only necessary if I want to supply additonal jar files without putting them in lib/ext? I'll have a go at redoing the simple mbean lab we did in London to see if I can clear things up, but any information on the basic setup these days would be very useful. thanks, Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
David Jencks wrote: On 2001.12.06 12:46:21 -0500 Luke Taylor wrote: Ah. I'm glad someone else has some reservations. I assumed I was just lagging behind (probably true anyway) and that everyone else knew exactly what was going on from all the discussions on sars and services so it's good to hear a mildly dissenting voice with some clout. On the other hand, I think quite a few people have said it was confusing at first and useful when they got used to it. I'm sure it's v. useful and I wasn't intending to make any criticisms one way or the other. It's just that there have been tons of discussions where I haven't had a clue what was going on. I'm not even sure that having a single file is necessarily less confusing than multiple files, one for each service. I like the idea of being able to just drop an encapsulated service description into a running server and having it deployed in the same way as an application. The fact that other servers use a single configuration file isn't really an argument in itself. This system also makes configuration less of an issue - you can just supply someope with the appropriate sar files along with your app and tell them to drop them into the deploy directory. I'm just not quite clear on how it's all fitting together, but thanks for your answers. I can already see the fog lifting ... Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
marc fleury wrote: I think this is an obsolete antique. yes, ok I will remove it Marc, could you shed some light on what the boot-server config. does and how it works? Is it all outdated or is that still part of the web-booting infrastructure? David says he doesn't know what this is for which surprised me, so I think it would be useful to know. ok I will again go to your defense (against yourself it seems). THE SITUATION IS IDEAL, I'd just like to clarify again that I'm not in a position to criticise anything - I'm just trying to work out what the differencs are at the moment :). Luke. P.S. I do think the idea of keeping it the same as 2.4.* but with the new features still available sounds good. Then nobody has to worry about them unnecessarily. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
marc fleury wrote: 2. Is the boot-server configuration only used for booting over the network - can we try this out just now, and how do you decide what configuration it obtains/supplies?? That I really don't know what it is doing there, see my previous mail on jetty here http://www.jboss.org/forums/thread.jsp?forum=66=4975 This draws a blank when I try to browse it... It's gone unless I hear from Jules in the next 30 seconds. OK. I won't lose any sleep over it then :). Is the net booting stuff still active? I HAD BUILD THAT SUPPORT IN THE FIRST VERSION ON RH I will make sure it is still there (I think it is actually). Then the *preferred* way is to just drop the xml snippet or add it to the base jboss-service.xml if you know it is going to be part of the server always. The only advantage of doing the snippet would be monitoring and reconfiguring the service based on this. Could be useful. Can't you monitor and reconfigure the services which are always deployed too? Do you mean that the snippet files would be rewritten (a la jboss-auto.jcml) to reflect changes in the configuration? I'll have a go at redoing the simple mbean lab we did in London to see if I can clear things up, but any information on the basic setup these days would be very useful. The London lab covers the creation of a standard mbean with the xml file format, it was quite simple but required a server restart everytime you changed the class or the configuration jcml. What we are talking about here is the capacity to hot-deploy these guys. So the next London lab will probably focus on the ability to change that separate snippet and develop the class live, s easy for development. OK. So to clarify - what's the current situation if I update the snippet file - how do you determine which classes need reloaded? You mentioned that you *could* monitor lib/ext but presumably that doesn't happen currently. Where do I specify which classes my service needs and how are they reloaded? forget the SAR *packaging* madness for now. The features are really nice, but (french saying) we are butt-fucking flies :O over silly packaging issues. Is this clear? It's much clearer. Once I've tried it out I should get that warm glow for a while... I think the stuff about where my service classes should go in order to be dynamically reloaded should clinch it... As far as I can see all the current services all have classpaths which point to files which are exclusively in lib/ext. Butt-fucking flies is pretty clear and sounds like a useful French phrase to know - what is the original enculer des mouches or something like that?? I know the Chinese would say taking trousers down to fart which is equally appropriate and is a bit less vulgar :). Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Digest authentication
Hi all, I just got a mail from a guy asking about digest authentication and if it would be possible to include an extra login module which provides this. It would be useful to have this available without having to supply a different login module, so can anyone think of any reasons for not modifying the existing UsernamePasswordLoginModule to optionally allow you to use hashed passwords by supplying an extra flag and or algorithm? The storage format could be either base-64 or hex strings (like catalina uses) or the whole hashing algorithm could be pluggable... Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Digest authentication
Scott M Stark wrote: It would be good to add a hash of the password, but this is not digest authentication as in HTTP digest authentication. Ah yes, of course. I only meant storing digests of the passwords, nothing to do with HTTP authentication protocols. I don't know why I said digest authentication, because that's obviously something competely different. I'll have a go at modifying UsernamePasswordLoginModule accordingly... On another topic - we spoke previously about mods to the security proxy stuff to throw an exception in cases where the proxy delegate doesn't provide a matching method for all those in the remote interface. Do you think it would be worth changing AbstractSecurityProxy to make this the default in JBoss 3? Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Digest authentication
Scott M Stark wrote: I'll have a go at modifying UsernamePasswordLoginModule accordingly... That's fine. This should be done using the java.security.MessageDigest class so that additional one-way hash algorigthms may be introduced using java.security.MessageDigestSpi subclasses. But isn't that part of the JCA* stuff - you should only have to specify an algorithm name to MessageDigest.getInstance, no? The Spi stuff is all hidden. If you want to make the algorithm completely pluggable (e.g. to use salting or some other guff to prevent dictionary attacks) then you would have to provide your own password hashing interface. This would also allow you to modify the way the hash string was formed for storing and comparing (base 64 etc). I was thinking of allowing either a hash algorithm to be specified as an option - SHA, MD5 whatever, with a default string format (hex), or a separate hash implementation class (or both). Do you think it would be worth changing AbstractSecurityProxy to make this the default in JBoss 3? Sure. The behavior controlled by a flag that defaults to the case of not allowing access to missing methods. You mean a) check on each invocation and only crack up if a method is called which doesn't have a corresponding proxy method rather than b) check for all methods on initialization (when constructing the method maps) and throw an exception if the proxy doesn't match. Luke. * 'C' for cryptography not connector - I get confused when people start recycling acronyms... -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Digest authentication
Scott M Stark wrote: ... No, java.security.MessageDigest is standard in JDK 1.3. MACs are part of JCA. You add new digest algorithms by supplying a MessageDigestSpi implementation and registering it using the standard security provider mechanism. OK. I think we're talking at cross purposes and saying the same thing. I wasn't talking about whether to use MessageDigest or whether it was available in the standard JDK - I thought you were talking about making use of the Spi stuff directly. I probably shouldn't come home at 6am and read my mail :). When I last used this stuff extensively, the part that was exportable and came with the JDK was called the JCA (and included MessageDigest), the non-exportable javax.crypto.* stuff was the JCE (which includes MACs). Formatting the digest into a string is another dimension that we would have to provide. The hash algorithm should be one login module option, and the representation of the digest another. This should include 'raw' for the raw digest byte[], 'base64' and 'hex'. Won't the 'raw' option cause problems with the current interfaces which all use Strings? You mean a) check on each invocation and only crack up if a method is called which doesn't have a corresponding proxy method rather than b) check for all methods on initialization (when constructing the method maps) and throw an exception if the proxy doesn't match. a, b and c) 'only validate invocations that have a corresponding proxy method and allow all others' should be the behaviors configurable based on a checkPolicy attribute of the interceptor. I was envisaging that it would just be an on or off strict flag in AbstractSecurityProxy with on being b) and off being c, with the default being on. If you're expected to provide your own proxy implementation by subclassing this, then you would set the flag there, and could provide more complex behaviour if you wanted. I don't see how you could configure the security proxy interceptor or pass such information to the proxy without a lot of changes. And it seems like excessive extra configuration information for such a small difference. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Digest authentication
Scott M Stark wrote: 'raw' for the raw digest byte[], 'base64' and 'hex'. Won't the 'raw' option cause problems with the current interfaces which all use Strings? Yes, it would have to be returned as a String(byte[]). I don't think that will work, because it will depend on the encoding that is in use for the conversion to unicode. You can't guarantee that any random byte as returned as part of a MessageDigest will have a valid representation in the current encoding. If it doesn't then you'll get an exception when you try to convert it to a String, or the offending character will be replaced with standard padding. I'll stick with base64 and hex for the time being... Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/auth/spi UsernamePasswordLoginModule.java
User: luke_t
Date: 01/12/16 16:07:44
Modified:src/main/org/jboss/security/auth/spi
UsernamePasswordLoginModule.java
Log:
Added javadoc formatting and removed spurious references to getUsersRoles method.
Revision ChangesPath
1.7 +52 -36
jbosssx/src/main/org/jboss/security/auth/spi/UsernamePasswordLoginModule.java
Index: UsernamePasswordLoginModule.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/auth/spi/UsernamePasswordLoginModule.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- UsernamePasswordLoginModule.java 2001/11/24 21:52:33 1.6
+++ UsernamePasswordLoginModule.java 2001/12/17 00:07:44 1.7
@@ -4,6 +4,7 @@
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
+
package org.jboss.security.auth.spi;
import java.io.IOException;
@@ -22,33 +23,41 @@
import org.jboss.security.auth.spi.AbstractServerLoginModule;
-/** An abstract subclass of AbstractServerLoginModule that imposes a
- an identity == String username, credentials == String password view on
- the login process. Subclasses override the getUsersPassword()
- and getUsersRoles() methods to return the expected password and roles
- for the user.
-
- @see #getUsername()
- @see #getUsersPassword()
- @see #getUsersRoles()
-
- @author [EMAIL PROTECTED]
- @version $Revision: 1.6 $
+/**
+ * An abstract subclass of AbstractServerLoginModule that imposes
+ * an identity == String username, credentials == String password view on
+ * the login process.
+ * p
+ * Subclasses override the codegetUsersPassword()/code
+ * and codegetRoleSets()/code methods to return the expected password and roles
+ * for the user.
+ *
+ * @see #getUsername()
+ * @see #getUsersPassword()
+ * @see #getRoleSets()
+ *
+ * @author [EMAIL PROTECTED]
+ * @version $Revision: 1.7 $
*/
public abstract class UsernamePasswordLoginModule extends AbstractServerLoginModule
{
/** The login identity */
private Principal identity;
+
/** The proof of login identity */
private char[] credential;
+
/** the principal to use when a null username and password are seen */
private Principal unauthenticatedIdentity;
- /** Override the superclass method to look for a unauthenticatedIdentity
-property. This method first invokes the super version.
-@param options,
-@option unauthenticatedIdentity: the name of the principal to asssign
-and authenticate when a null username and password are seen.
+ /**
+* Override the superclass method to look for an emunauthenticatedIdentity/em
+* property. This is the name of the principal to assign and authenticate
+* when a null username and password are seen.
+* p
+* This method first invokes the super version.
+*
+* @param options the map of paramers passed to this login module.
*/
public void initialize(Subject subject, CallbackHandler callbackHandler, Map
sharedState, Map options)
{
@@ -59,8 +68,7 @@
unauthenticatedIdentity = new SimplePrincipal(name);
}
- /**
-*/
+ /** */
public boolean login() throws LoginException
{
// See if shared credentials exist
@@ -98,14 +106,14 @@
String expectedPassword = getUsersPassword();
if( validatePassword(password, expectedPassword) == false )
{
-System.out.println(Bad password for username=+username);
+System.out.println(Bad password for username= + username);
throw new FailedLoginException(Password Incorrect/Password Required);
}
}
System.out.print(User ' + identity + ' authenticated.\n);
if( getUseFirstPass() == true )
- {// Add the username and password to the shared state map
+ { // Add the username and password to the shared state map
sharedState.put(javax.security.auth.login.name, username);
sharedState.put(javax.security.auth.login.password, credential);
}
@@ -116,6 +124,7 @@
{
return identity;
}
+
protected Principal getUnauthenticatedIdentity()
{
return unauthenticatedIdentity;
@@ -125,15 +134,18 @@
{
return credential;
}
+
protected String getUsername()
{
return getIdentity().getName();
}
- /** Called by login() to acquire the username and password strings for
-authentication. This method does no validation of either.
-@return String[], [0] = username, [1] = password
-@exception LoginException thrown if CallbackHandler is not set or fails.
+ /**
+* Called by login() to acquire the username and password
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/auth/spi AbstractServerLoginModule.java AnonLoginModule.java DatabaseServerLoginModule.java IdentityLoginModule.java LdapLoginModule.java ProxyLoginModule.java SimpleServerLoginModule.java UsersRolesLoginModule.java
User: luke_t
Date: 01/12/16 16:47:23
Modified:src/main/org/jboss/security/auth/spi
AbstractServerLoginModule.java AnonLoginModule.java
DatabaseServerLoginModule.java
IdentityLoginModule.java LdapLoginModule.java
ProxyLoginModule.java SimpleServerLoginModule.java
UsersRolesLoginModule.java
Log:
improved javadoc and applied jboss-style code template
Revision ChangesPath
1.4 +208 -183
jbosssx/src/main/org/jboss/security/auth/spi/AbstractServerLoginModule.java
Index: AbstractServerLoginModule.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/auth/spi/AbstractServerLoginModule.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- AbstractServerLoginModule.java2001/11/24 21:52:33 1.3
+++ AbstractServerLoginModule.java2001/12/17 00:47:22 1.4
@@ -4,6 +4,7 @@
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
+
package org.jboss.security.auth.spi;
import java.util.*;
@@ -19,201 +20,225 @@
import org.jboss.security.NestableGroup;
import org.jboss.security.SimpleGroup;
-/** This class implements the common functionality required for a JAAS
-server side LoginModule and implements the JBossSX standard Subject usage
-pattern of storing identities and roles. Subclass this module to create your
-own custom LoginModule and override the login(), getRoleSets() and getIdentity()
-methods.
-
-You may also wish to override
-public void initialize(Subject subject, CallbackHandler callbackHandler, Map
sharedState, Map options)
-
-In which case the first line of your initialize() method should be:
-super.initialize(subject, callbackHandler, sharedState, options);
-You may also wish to override
-public boolean login() throws LoginException
-In which case the last line of your login() method should be
-return super.login();
-
-@author a href=[EMAIL PROTECTED]Edward Kenworthy/a, 12th Dec
2000
-@author [EMAIL PROTECTED]
-@version $Revision: 1.3 $
-*/
+/**
+ * This class implements the common functionality required for a JAAS
+ * server side LoginModule and implements the JBossSX standard Subject usage
+ * pattern of storing identities and roles. Subclass this module to create your
+ * own custom LoginModule and override the login(), getRoleSets() and getIdentity()
+ * methods.
+ * p
+ * You may also wish to override
+ * pre
+ *public void initialize(Subject subject, CallbackHandler callbackHandler, Map
sharedState, Map options)
+ * /pre
+ * In which case the first line of your initialize() method should be:
+ * pre
+ *super.initialize(subject, callbackHandler, sharedState, options);
+ * /pre
+ * p
+ * You may also wish to override
+ * pre
+ *public boolean login() throws LoginException
+ * /pre
+ * In which case the last line of your login() method should be
+ * pre
+ *return super.login();
+ * /pre
+ *
+ *@author a href=[EMAIL PROTECTED]Edward Kenworthy/a, 12th
Dec 2000
+ *@author [EMAIL PROTECTED]
+ *@version $Revision: 1.4 $
+ */
public abstract class AbstractServerLoginModule implements LoginModule
{
-protected Subject subject;
-protected CallbackHandler callbackHandler;
-protected Map sharedState;
-protected Map options;
+ protected Subject subject;
+ protected CallbackHandler callbackHandler;
+ protected Map sharedState;
+ protected Map options;
-/** Flag indicating if the shared credential should be used */
-protected boolean useFirstPass;
+ /** Flag indicating if the shared credential should be used */
+ protected boolean useFirstPass;
//--- Begin LoginModule interface methods
-/** Initialize the login module. This stores the subject, callbackHandler
-and sharedState and options for the login session. Subclasses should
override
-if they need to process their own options. A call to super.initialize(...)
-must be made in the case of an override.
-@param subject, the Subject to update after a successful login.
-@param callbackHandler, the CallbackHandler that will be used to obtain the
-the user identity and credentials.
-@param sharedState, a Map shared between all configured login module instances
-@param options,
-@option password-stacking: if true, the login identity will be taken from
the
-javax.security.auth.login.name value of the sharedState map, and
-the proof of identity from the javax.security.auth.login.password
-value of the sharedState map.
-*/
-public void initialize(Subject subject, CallbackHandler callbackHandler, Map
Re: [JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/auth/spi AbstractServerLoginModule.java AnonLoginModule.java DatabaseServerLoginModule.java IdentityLoginModule.java LdapLoginModule.java ProxyLoginModule.java SimpleServerLoginModule.java UsersRolesLoginModule.java
David Jencks wrote: Are you using an automated code formatter? If so what is it? I'm using Together's formatting. It has a few irritations - like some things it insists on changing and you can't tell it to leave them as they are. I added the tags in the javadoc myself obviously :). Why, has it screwed up somewhere? Luke. Log: improved javadoc and applied jboss-style code template -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security Base64Encoder.java
User: luke_t
Date: 01/12/18 13:31:49
Added: src/main/org/jboss/security Base64Encoder.java
Log:
Base64Encoder utility, based on w3c implementation. Currently intended for password
hashing. May be better located elsewhere eventually.
Revision ChangesPath
1.1 jbosssx/src/main/org/jboss/security/Base64Encoder.java
Index: Base64Encoder.java
===
package org.jboss.security; // for the time being ...
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.PrintStream;
import java.io.UnsupportedEncodingException;
/**
* BASE64 encoder implementation.
* Provides encoding methods, using the BASE64 encoding rules, as defined
* in the MIME specification, a href=http://ietf.org/rfc/rfc1521.txt;rfc1521/a.
*
*
* This class is a modified version based on code
* obtained from the w3 consortium website,
* which is subject to their generic copyright notice:
*
* dl
* dda href=http://www.w3.org/Consortium/Legal/;Copyright/a ©
[$date-of-software] a
* HREF=http://www.w3.org/;World Wide Web Consortium/a, (a
* HREF=http://www.lcs.mit.edu/;Massachusetts Institute of Technology/a, a
* HREF=http://www.inria.fr/;Institut National de Recherche en Informatique et en
* Automatique/a, a HREF=http://www.keio.ac.jp/;Keio University/a). All Rights
*Reserved. This program is distributed under the a
* HREF=http://www.w3.org/Consortium/Legal/copyright-software-19980720.html;W3C's
Software
*Intellectual Property License/a. This program is distributed in the hope
that it will be
* useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See W3C License a
*
href=http://www.w3.org/Consortium/Legal/;http://www.w3.org/Consortium/Legal//a for
*more details. /dd
*/dl
*
*
*/
public final class Base64Encoder
{
private static final int BUFFER_SIZE = 1024 ;
private static final byte encoding[] =
{
(byte) 'A', (byte) 'B', (byte) 'C', (byte) 'D',
(byte) 'E', (byte) 'F', (byte) 'G', (byte) 'H', // 0-7
(byte) 'I', (byte) 'J', (byte) 'K', (byte) 'L',
(byte) 'M', (byte) 'N', (byte) 'O', (byte) 'P', // 8-15
(byte) 'Q', (byte) 'R', (byte) 'S', (byte) 'T',
(byte) 'U', (byte) 'V', (byte) 'W', (byte) 'X', // 16-23
(byte) 'Y', (byte) 'Z', (byte) 'a', (byte) 'b',
(byte) 'c', (byte) 'd', (byte) 'e', (byte) 'f', // 24-31
(byte) 'g', (byte) 'h', (byte) 'i', (byte) 'j',
(byte) 'k', (byte) 'l', (byte) 'm', (byte) 'n', // 32-39
(byte) 'o', (byte) 'p', (byte) 'q', (byte) 'r',
(byte) 's', (byte) 't', (byte) 'u', (byte) 'v', // 40-47
(byte) 'w', (byte) 'x', (byte) 'y', (byte) 'z',
(byte) '0', (byte) '1', (byte) '2', (byte) '3', // 48-55
(byte) '4', (byte) '5', (byte) '6', (byte) '7',
(byte) '8', (byte) '9', (byte) '+', (byte) '/', // 56-63
(byte) '='// 64
};
/**
* Encodes data from supplied input to output.
* @param in The input stream to be encoded.
* @param out The output stream, to write encoded data to.
*/
public static void encode(InputStream in, OutputStream out) throws IOException
{
process(in, out);
}
/**
* Encode the supplied byte array and write the encoded
* data to the OutputStream iout/i.
*/
public static void encode(byte input[], OutputStream out) throws IOException
{
ByteArrayInputStream in = new ByteArrayInputStream(input);
process(in, out);
}
/**
* Encode the given string,and return the encoded version as a string.
*
* @return A String, representing the encoded content of the input String.
*/
public static String encode(String input) throws IOException
{
byte bytes[] ;
bytes = input.getBytes(ISO-8859-1);
return encode (bytes);
}
/**
* Encode the given byte array and return the result as a string.
*/
public static String encode(byte bytes[]) throws IOException
{
ByteArrayInputStream in = new ByteArrayInputStream(bytes);
ByteArrayOutputStream out = new ByteArrayOutputStream();
process(in, out);
return out.toString(ISO-8859-1);
}
/**
* Testing the encoder.
* Run with one argument, prints the encoded version of it.
* With two, the second is assumed to be the name of a MessageDigest to
* be applied to the string before encoding (useful for generating
* password hashes).
*/
public static void main
[JBoss-dev] CVS update: jbosstest/src/resources/security auth.conf
User: luke_t
Date: 01/12/18 18:14:20
Modified:src/resources/security auth.conf
Log:
added configurations for password hash tests. Also modified the configurations for
LoginContextUnitTestCase which was using the deprecated versions. It currently ignores
these anyway as it sets up its own JAAS configuration in code. In any case it will
fail currently as the deprecated RolesLoginModule doesn't require a CallbackHandler
but UserRolesLoginModule requires one (because its parent class
UsernamePasswordLoginModule does).
Revision ChangesPath
1.4 +18 -2 jbosstest/src/resources/security/auth.conf
Index: auth.conf
===
RCS file: /cvsroot/jboss/jbosstest/src/resources/security/auth.conf,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- auth.conf 2001/03/27 06:47:53 1.3
+++ auth.conf 2001/12/19 02:14:20 1.4
@@ -6,16 +6,32 @@
org.jboss.security.ClientLoginModule required
;
};
+
spec-test {
org.jboss.security.ClientLoginModule required
;
};
+
LoginContext {
-org.jboss.security.plugins.samples.IdentityLoginModule required
+org.jboss.security.auth.spi.IdentityLoginModule required
principal=scott
;
-org.jboss.security.plugins.samples.RolesLoginModule required
+org.jboss.security.auth.spi.UsersRolesLoginModule required
;
+};
+
+pass-hash1 {
+org.jboss.security.auth.spi.UsersRolesLoginModule required
+ hashAlgorithm=SHA
+ hashEncoding=base64
+ ;
+};
+
+pass-hash2 {
+org.jboss.security.auth.spi.UsersRolesLoginModule required
+ hashAlgorithm=MD5
+ hashEncoding=hex
+ ;
};
other {
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/security users.properties
User: luke_t Date: 01/12/18 18:20:37 Modified:src/resources/security users.properties Log: added users with hashed and encoded passwords Revision ChangesPath 1.2 +5 -0 jbosstest/src/resources/security/users.properties Index: users.properties === RCS file: /cvsroot/jboss/jbosstest/src/resources/security/users.properties,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- users.properties 2001/03/05 10:11:44 1.1 +++ users.properties 2001/12/19 02:20:37 1.2 @@ -1,2 +1,7 @@ scott=echoman stark=javaman +# Base64 encoded SHA of password password. +luke=W6ph5Mm5Pz8GgiULbPgzG37mj9g= +# Hex encoded MD5 of password password +joe=5f4dcc3b5aa765d61d8327deb882cf99 + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/security/test PasswordHashLoginUnitTestCase.java
User: luke_t
Date: 01/12/18 18:18:09
Added: src/main/org/jboss/test/security/test
PasswordHashLoginUnitTestCase.java
Log:
tests for login using hashed passwords.
Revision ChangesPath
1.1
jbosstest/src/main/org/jboss/test/security/test/PasswordHashLoginUnitTestCase.java
Index: PasswordHashLoginUnitTestCase.java
===
package org.jboss.test.security.test;
import javax.security.auth.login.LoginContext;
import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.PasswordCallback;
import javax.security.auth.callback.NameCallback;
import javax.security.auth.callback.UnsupportedCallbackException;
import org.jboss.test.JBossTestCase;
/**
* Tests for logins with password hashes.
* The configurations are taken from the resources
*
* @author [EMAIL PROTECTED]
* @version $Revision: 1.1 $
*/
public class PasswordHashLoginUnitTestCase extends JBossTestCase
{
public PasswordHashLoginUnitTestCase(String name)
{
super(name);
}
// JAAS CallbackHandler for logins.
static class TestCallbackHandler implements CallbackHandler
{
private String _username;
private String _password;
public TestCallbackHandler(String username, String password)
{
_username = username;
_password = password;
}
public void handle(Callback[] callbacks) throws UnsupportedCallbackException
{
for (int i = 0; i callbacks.length; i++)
{
Callback cb = callbacks[i];
if (cb instanceof NameCallback)
{
((NameCallback)cb).setName(_username);
}
else if (cb instanceof PasswordCallback)
{
((PasswordCallback)cb).setPassword(_password.toCharArray());
}
else
{
throw new UnsupportedCallbackException(callbacks[i], Unsupported
Callback Type + cb.getClass().getName());
}
}
}
}
public void testPassHashLogin1() throws Exception
{
LoginContext lc = new LoginContext(pass-hash1, new
TestCallbackHandler(luke,password));
lc.login();
}
public void testPassHashLogin2() throws Exception
{
LoginContext lc = new LoginContext(pass-hash2, new
TestCallbackHandler(joe,password));
lc.login();
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] HttpClient test class
Hi all, I've noticed that this class (org.jboss.test.web.test.HttpClient) is used in the WebIntegrationUnitTestCase. It references the class sun.misc.BASE64Encoder which only come with the Sun JDK. Is this test normally run? If so it might explain some discrepancies on other JVMs. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/auth/spi AbstractServerLoginModule.java
User: luke_t
Date: 01/12/18 18:29:39
Modified:src/main/org/jboss/security/auth/spi
AbstractServerLoginModule.java
Log:
added jboss logger
Revision ChangesPath
1.5 +9 -6
jbosssx/src/main/org/jboss/security/auth/spi/AbstractServerLoginModule.java
Index: AbstractServerLoginModule.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/auth/spi/AbstractServerLoginModule.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- AbstractServerLoginModule.java2001/12/17 00:47:22 1.4
+++ AbstractServerLoginModule.java2001/12/19 02:29:39 1.5
@@ -20,6 +20,8 @@
import org.jboss.security.NestableGroup;
import org.jboss.security.SimpleGroup;
+import org.jboss.logging.Logger;
+
/**
* This class implements the common functionality required for a JAAS
* server side LoginModule and implements the JBossSX standard Subject usage
@@ -47,7 +49,7 @@
*
*@author a href=[EMAIL PROTECTED]Edward Kenworthy/a, 12th
Dec 2000
*@author [EMAIL PROTECTED]
- *@version $Revision: 1.4 $
+ *@version $Revision: 1.5 $
*/
public abstract class AbstractServerLoginModule implements LoginModule
{
@@ -59,6 +61,8 @@
/** Flag indicating if the shared credential should be used */
protected boolean useFirstPass;
+ protected final Logger log = Logger.getLogger(getClass().getName());
+
//--- Begin LoginModule interface methods
/**
@@ -118,7 +122,6 @@
e.printStackTrace();
}
}
-
return false;
}
@@ -152,7 +155,7 @@
subjectGroup.addMember(tmp);
subjectGroup = tmp;
}
-// Copy the group members to the Subject group
+ // Copy the group members to the Subject group
Enumeration members = group.members();
while(members.hasMoreElements())
{
@@ -178,11 +181,11 @@
*/
public boolean logout() throws LoginException
{
-// Remove the user identity
+ // Remove the user identity
Principal identity = getIdentity();
Set principals = subject.getPrincipals();
principals.remove(identity);
-// Remove any added Groups...
+ // Remove any added Groups...
return true;
}
//--- End LoginModule interface methods
@@ -233,7 +236,7 @@
break;
}
}
- // If we did not find a group create one
+ // If we did not find a group create one
if(roles == null)
{
roles = new NestableGroup(name);
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/auth/spi UsernamePasswordLoginModule.java
User: luke_t
Date: 01/12/18 18:47:02
Modified:src/main/org/jboss/security/auth/spi
UsernamePasswordLoginModule.java
Log:
password hashing functionality added. Hasn't been checked thouroughly for
compatibily with external tools yet, but shoudn't break any existing code.
Revision ChangesPath
1.8 +147 -6
jbosssx/src/main/org/jboss/security/auth/spi/UsernamePasswordLoginModule.java
Index: UsernamePasswordLoginModule.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/auth/spi/UsernamePasswordLoginModule.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- UsernamePasswordLoginModule.java 2001/12/17 00:07:44 1.7
+++ UsernamePasswordLoginModule.java 2001/12/19 02:47:02 1.8
@@ -8,8 +8,11 @@
package org.jboss.security.auth.spi;
import java.io.IOException;
+import java.io.UnsupportedEncodingException;
import java.util.Map;
import java.security.Principal;
+import java.security.MessageDigest;
+import java.security.NoSuchAlgorithmException;
import javax.security.auth.Subject;
import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
@@ -20,6 +23,8 @@
import javax.security.auth.login.FailedLoginException;
import org.jboss.security.SimplePrincipal;
+import org.jboss.security.Util;
+import org.jboss.security.Base64Encoder;
import org.jboss.security.auth.spi.AbstractServerLoginModule;
@@ -37,7 +42,8 @@
* @see #getRoleSets()
*
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.7 $
+ * @author [EMAIL PROTECTED]
+ * @version $Revision: 1.8 $
*/
public abstract class UsernamePasswordLoginModule extends AbstractServerLoginModule
{
@@ -50,13 +56,34 @@
/** the principal to use when a null username and password are seen */
private Principal unauthenticatedIdentity;
+ /** the message digest algorithm used to hash passwords. If null then plain
passwords will be used. */
+ private String hashAlgorithm = null;
+ /**
+ * the name of the charset/encoding to use when converting the password String to
a byte array.
+ * Default is the platform's default encoding.
+ */
+ private String hashCharset = null;
+ /** the string encoding format to use. Defaults to base64. */
+ private String hashEncoding = null;
+
/**
* Override the superclass method to look for an emunauthenticatedIdentity/em
* property. This is the name of the principal to assign and authenticate
* when a null username and password are seen.
* p
+* The options map will also be checked for the parameter emhashAlgorithm/em
+* to see if password hashing should be used instead of plain passwords.
+* If you set this parameter, passwords will be hashed using the specified
+* algorithm (for example SHA or MD5) and will be encoded as strings.
+* p
+* The string encoding format is set using the optional parameter
+* emhashEncoding/em. Currently supported are MIME BASE64 encoded
+* strings as defined in
+* (a href=http://ietf.org/rfc/rfc1521.txt;rfc1521/a)
+* or HEX encoded strings. BASE64 is the default if omitted.
+* p
* This method first invokes the super version.
-*
+*
* @param options the map of paramers passed to this login module.
*/
public void initialize(Subject subject, CallbackHandler callbackHandler, Map
sharedState, Map options)
@@ -66,13 +93,28 @@
String name = (String) options.get(unauthenticatedIdentity);
if( name != null )
unauthenticatedIdentity = new SimplePrincipal(name);
+
+ // Check to see if password hashing has been enabled.
+ // If an algorithm is set, check for a format and charset.
+ hashAlgorithm = (String) options.get(hashAlgorithm);
+ if(hashAlgorithm != null)
+ {
+ hashEncoding = (String) options.get(hashEncoding);
+ if(hashEncoding == null)
+hashEncoding = BASE64;
+ hashCharset = (String) options.get(hashCharset);
+ if(log.isDebugEnabled())
+ {
+log.debug(Passworg hashing activated: algorithm = + hashAlgorithm +
+ , encoding = + hashEncoding+ (hashCharset == null ? : charset
= + hashCharset));
+ }
+ }
}
- /** */
public boolean login() throws LoginException
{
// See if shared credentials exist
- if( super.login() == true )
+ if( super.login() )
{
// Setup our view of the user
Object username = sharedState.get(javax.security.auth.login.name);
@@ -102,15 +144,19 @@
if( identity == null )
{
identity = new SimplePrincipal(username);
+
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security Base64Encoder.java
User: luke_t
Date: 01/12/19 16:58:34
Modified:src/main/org/jboss/security Base64Encoder.java
Log:
reinstated usage msg in main (accidentally deleted).
Revision ChangesPath
1.2 +9 -1 jbosssx/src/main/org/jboss/security/Base64Encoder.java
Index: Base64Encoder.java
===
RCS file: /cvsroot/jboss/jbosssx/src/main/org/jboss/security/Base64Encoder.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Base64Encoder.java2001/12/18 21:31:49 1.1
+++ Base64Encoder.java2001/12/20 00:58:34 1.2
@@ -105,11 +105,15 @@
}
/**
- * Testing the encoder.
* Run with one argument, prints the encoded version of it.
* With two, the second is assumed to be the name of a MessageDigest to
* be applied to the string before encoding (useful for generating
* password hashes).
+ * p
+ * Alternatively, use the openssl utility, for example:
+ * p
+ * echo -n password | openssl dgst -sha1 -binary | openssl base64
+ *
*/
public static void main (String args[]) throws Exception
{
@@ -123,6 +127,10 @@
{
byte[] hash =
java.security.MessageDigest.getInstance(args[1]).digest(args[0].getBytes());
System.out.println ([+ Base64Encoder.encode(hash)+]);
+ }
+ else
+ {
+ System.out.println(Usage: Base64Encoder string optional hash
algorithm);
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp12 package.html
User: luke_t Date: 02/01/05 16:26:08 Removed: src/main/org/jboss/ejb/plugins/jrmp12 package.html Log: remove defunct files (to make cvs co -P work) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp12/server package.html server.dfPackage
User: luke_t Date: 02/01/05 16:26:09 Removed: src/main/org/jboss/ejb/plugins/jrmp12/server package.html server.dfPackage Log: remove defunct files (to make cvs co -P work) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp12/interfaces interfaces.dfPackage package.html
User: luke_t Date: 02/01/05 16:26:08 Removed: src/main/org/jboss/ejb/plugins/jrmp12/interfaces interfaces.dfPackage package.html Log: remove defunct files (to make cvs co -P work) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp/interfaces package.html
User: luke_t Date: 02/01/05 16:29:01 Removed: src/main/org/jboss/ejb/plugins/jrmp/interfaces package.html Log: removed unused package.html files ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp package.html
User: luke_t Date: 02/01/05 16:29:01 Removed: src/main/org/jboss/ejb/plugins/jrmp package.html Log: removed unused package.html files ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp/server package.html
User: luke_t Date: 02/01/05 16:29:01 Removed: src/main/org/jboss/ejb/plugins/jrmp/server package.html Log: removed unused package.html files ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp13/server package.html
User: luke_t Date: 02/01/05 16:30:53 Removed: src/main/org/jboss/ejb/plugins/jrmp13/server package.html Log: removed unused package.html files ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp13/interfaces package.html
User: luke_t Date: 02/01/05 16:30:53 Removed: src/main/org/jboss/ejb/plugins/jrmp13/interfaces package.html Log: removed unused package.html files ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp13 package.html
User: luke_t Date: 02/01/05 16:30:52 Removed: src/main/org/jboss/ejb/plugins/jrmp13 package.html Log: removed unused package.html files ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp12 jrmp.dfPackage
User: luke_t Date: 02/01/05 16:37:22 Removed: src/main/org/jboss/ejb/plugins/jrmp12 jrmp.dfPackage Log: remove outdated file ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata XmlFileLoader.java
User: luke_t
Date: 02/01/05 19:28:55
Modified:src/main/org/jboss/metadata Tag: Branch_2_4
XmlFileLoader.java
Log:
Added logging of exceptions thrown during getDocument(), to enable stacktrace to be
obtained.
Revision ChangesPath
No revision
No revision
1.15.2.5 +43 -42jboss/src/main/org/jboss/metadata/XmlFileLoader.java
Index: XmlFileLoader.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/XmlFileLoader.java,v
retrieving revision 1.15.2.4
retrieving revision 1.15.2.5
diff -u -r1.15.2.4 -r1.15.2.5
--- XmlFileLoader.java2001/12/10 02:52:03 1.15.2.4
+++ XmlFileLoader.java2002/01/06 03:28:55 1.15.2.5
@@ -37,7 +37,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Wolfgang Werner/a
* @author a href=mailto:[EMAIL PROTECTED];Darius Davidavicius/a
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
- * @version $Revision: 1.15.2.4 $
+ * @version $Revision: 1.15.2.5 $
*
* Revisions:
* 20010620 Bill Burke: Print an error message when failing to load
standardjboss.xml
@@ -48,13 +48,13 @@
{
private static Logger log = Logger.getLogger(XmlFileLoader.class);
// Constants -
-
+
// Attributes
private static boolean defaultValidateDTDs = false;
private ClassLoader classLoader;
private ApplicationMetaData metaData;
private boolean validateDTDs;
-
+
// Static
public static boolean getDefaultValidateDTDs()
{
@@ -64,7 +64,7 @@
{
defaultValidateDTDs = validate;
}
-
+
// Constructors --
public XmlFileLoader()
{
@@ -74,13 +74,13 @@
{
this.validateDTDs = validateDTDs;
}
-
+
// Public
public ApplicationMetaData getMetaData()
{
return metaData;
}
-
+
/**
Set the class loader
@param ClassLoader cl - class loader
@@ -89,7 +89,7 @@
{
classLoader = cl;
}
-
+
/**
Gets the class loader
@return ClassLoader - the class loader
@@ -98,7 +98,7 @@
{
return classLoader;
}
-
+
/** Get the flag indicating that ejb-jar.dtd, jboss.dtd
jboss-web.dtd conforming documents should be validated
against the DTD.
@@ -115,7 +115,7 @@
{
this.validateDTDs = validate;
}
-
+
/**
* load()
*
@@ -129,40 +129,40 @@
{
// create the metadata
metaData = new ApplicationMetaData();
-
+
// Load ejb-jar.xml
-
+
// we can always find the files in the classloader
URL ejbjarUrl = getClassLoader().getResource(META-INF/ejb-jar.xml);
-
+
if (ejbjarUrl == null)
{
throw new DeploymentException(no ejb-jar.xml found);
}
-
+
Document ejbjarDocument = getDocumentFromURL(ejbjarUrl);
-
+
// the url may be used to report errors
metaData.setUrl(ejbjarUrl);
metaData.importEjbJarXml(ejbjarDocument.getDocumentElement());
-
+
// Load jbossdefault.xml from the default classLoader
// we always load defaults first
// we use the context classloader, because this guy has to know where
// this file is
URL defaultJbossUrl =
Thread.currentThread().getContextClassLoader().getResource(standardjboss.xml);
-
+
if (defaultJbossUrl == null)
{
throw new DeploymentException(no standardjboss.xml found);
}
-
+
Document defaultJbossDocument = null;
-
+
try
{
defaultJbossDocument = getDocumentFromURL(defaultJbossUrl);
-
+
metaData.setUrl(defaultJbossUrl);
metaData.importJbossXml(defaultJbossDocument.getDocumentElement());
}
@@ -176,12 +176,12 @@
try
{
URL jbossUrl = getClassLoader().getResource(META-INF/jboss.xml);
-
+
if (jbossUrl != null)
{
// Logger.debug(jbossUrl.toString() + found.
Overriding defaults);
Document jbossDocument = getDocumentFromURL(jbossUrl);
-
+
metaData.setUrl(jbossUrl);
metaData.importJbossXml(jbossDocument.getDocumentElement());
}
@@ -191,10 +191,10 @@
log.error(failed to load jboss.xml. There could be a syntax
Re: [JBoss-dev] Re: preserve exception backtrace for client
Richard Kilgore wrote: On Wed, Jan 09, 2002 at 01:29:30PM +0100, Jung , Dr. Christoph wrote: Hi Richard ... AFAIK, if you serialise an exception, the stacktrace is serialised, too. So I do not understand your point ... CGJ No, this is a pretty well-known obstacle in debugging RMI apps. The backtrace member of Throwable is transient, so what you get back on the client side doesn't tell you anything about where the error occurred. I suppose that in most cases, diagnosing the error on the server side is the solution, but there are two cases where this does not work out: 1. the error is some unexpected exception, possibly a run-time NullPointerException or the like. 2. knowledge of the fact that a given exception represents a true error condition requires knowledge that only the client possesses, so the server app does not print a stack trace (this happens). In most cases of distributed apps, the client shouldn't know anything about the internal workings of the server. If it's just for debugging purposes then the stack traces of unexpected execeptions (like NullPointerException) should be reported in the server anyway. If they're not, it's an oversight in the server code. Your case 2 above, presumably only applies to user-defined exceptions which are listed in your interface, no? Again I would say that the client's knowledge shouldn't go beyond this in practice. The server (either your app or JBoss) should log any exceptions that occur IMHO, otherwise tracking problems is a nightmare. Also, server debugging is pretty straightforward, using the JPDA stuff (see JDK docs). You just start JBoss with the appropriate command line and connect with a tool that supports it (netbeans, Together, JBuilder, whatever). Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] org/jboss/web/catalina ajp13connector support
Coetmeur, Alain wrote: by the way your ideas seems good, and moreover to help people whou want to explicitly configure each of their catalina connector (like the people tryin to have both http and https), the type none could be added with the only changes at if( type.equals(http) == false type.equals(warp) == false type.equals(ajp)==false type.equals(none) ) what about just using if(type.equals(none)) :) -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty3.1.5, Axis Basic Authentication Problem
Jung , Dr. Christoph wrote: Experimenting with an unauthenticatedPrincipal nobody in the loginmodule instead of a NONE-role also did not work, because Jetty then refuses Hi, I'm not an expert on this web stuff (or anything for that matter :), but I take it the NONE role means don't let anyone access this. Is that correct? Is this a jetty specific thing 'cos I wasn't aware of its existence? I've only seen NONE used as an option for the transport-guarantee tag. If you want to let authenticated users with any role (as understood by the axis webapp) access the service (and perform access control later), then maybe you could try auth-constraint role-name*/role-name /auth-constraint which *should* do this... Or am I way off the mark? I would say that I haven't been able to get some security stuff working with JBoss/Jetty that has worked fine with Tomcat. I understand the security in Jetty is a relatively recent addition and there've been one or two hiccups, so it could be a problem with Jetty. Can you deploy the same stuff in another container, or is it tied to JBoss 3? Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] Re: [JBoss-dev] Jetty3.1.5, Axis Basic Authentication Problem
Greg Wilkins wrote: Cristoph, Eitherway, you do not want the semantics of NONE, you want the user to be authenticated, but you do not care what group they are in. Again, Jetty has an extension to the spec to support this. All users are in the role org.mortbay.http.User. However this is implemented in the HashUserRealm which is not used by JBoss. So for now, you must define a role that all your JBoss users are in and specify an AuthConstraint for that role. Hi Greg, Wouldn't this be the same as using * for the role-name? I had a brief look at the servlet 2.3 spec before replying previously and that's the syntax it uses for all roles. So it should then perform authentication and allow any user who has a role recognised by the application. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] Re: [JBoss-dev] Jetty3.1.5, Axis Basic Authentication Problem
Hi Greg, Regarding the session key stuff we discussed briefly recently, you just mentioned that JBoss doesn't use the HashUserRealm? Does this mean that it uses a different way of generating session IDs? If so, can someone point out the class? cheers, Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TODO: client side interceptors
marc fleury wrote: Bill got my hear yesterday (and today is talking to microsoft about his love for open source :) where he pitched the interceptor design on the 3.0 client side. Instant love. Sounds pretty interesting (the interceptor design that is :). I'm vaguely familiar with using client-side interceptors with CORBA in the past but the situation here is much less static. Can you clear up one or two things? We are not that far from it in fact, it a bit of renaming and factory game on the server. Essentially the client does Generic Proxy - Handler - EJB behavior - Transport In the transport layer we extract the Tx and Security information. OK. So that's the current state? What's the Handler in this context - is that the JRMPInvokerProxy, for example? The pitch was simple it had to do with moving GP-Handler-interceptor 1 (EJB behavior for example) -interceptor 2 (Tx extraction) - interceptor 3 (Security) - Transport (invoker). So this is basically just moving the code that sets the security and transaction contexts from the JRMPInvokerProxy and setting them in the appropriate interceptors instead? What is the current situation with the IIOP transport and how will that fit in with the generic proxy stuff and this stack of interceptors? Presumably there will just be an IIOPInvoker instead, which will perform the invocation via the chosen client orb (rather than formatting its own IIOP message). How will it insert the security and transaction contexts into the IIOP buffer as it won't have access to it at this stage? Or is there some other way to do this? The application could specify a jboss.xml that describes the client side interceptor like the server side does ejb tx security jrmp/iiop would be a way to declare a given client (in this case EJB behavior (local calls fielded). The factorization right behind it is on the server side. Where we expose the ProxyFactory (already there in a primitive form) and that PF can export any combination of (interfaces, stack of client interceptors, transport) and generates the client for it. Do you mean the proxy.ejb.ProxyFactory? So this would provide a return a proxy object which contained the appropriate client-side invocation stack, based on the above jboss.xml configuration? Would you be able to have multiple client-invocation stacks per container? This way for ANY MBean SAR that you deploy on the server you can create proxies that exposes a pluggable behavior example you would deploy your SAR and create clients with my proxy behavior that I wrote for my client security ... no tx soap and the connectors on the server side will know to route your message to the right mbean with the right security integration and no tx for example. Voila instant framework distribution. Ummm. So here you're talking about deploying Mbeans as server components which can be invoked by a remote client? I don't quite understand what the advantage is. Why would you want to remotely invoke an Mbean rather than just using an existing technology such as EJB to wrap it? What is missing here is the location of the objects and the finders for these objects... this is where and EJB like semantic would be handy... Won't binding them into JNDI be sufficient? Are you likely to need finders for MBeans? Are there many situations where you would have keyed MBeans? I thought they were basically services - though I'm sure Juha can come up with many other uses for them :). Sorry for all the questions, but I usually need things spelt out to get an understanding of what's going on. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TODO: client side interceptors
olger Engels wrote: I'm glad to see, that jboss will support pluggable interceptors on the client side, now. You can do cool things with that. Think of: ... o caching interceptor (for getters) How will that work in practice? Aren't the interceptors stateless, without being specific to a particular EJB/component instance? o invocation bundeling (send an array of method invocations and return an array of results .. all that in one user transaction) I don't quite get that either - interceptors are meant to be transparent to the client code. So how could a client make multiple (sequential) invocations and have them bundled into a single request? ... o mobility !!! if the caller is a sessionbean, serialize it, move it to a container on the target, do local calls, return to the originating container Eeek! ... o encryption / signing If the proxies and interceptor stack are dynamically downloaded, how is the security of the downloaded classes assured? Can the classes be loaded over SSL? Or can they be signed so the client can verify their origin? Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TODO: client side interceptors
Holger Engels wrote: On Thu, 31 Jan 2002, Bill Burke wrote: You're right here. EJBs have no asynchronous interface like CORBA object do. Arrgh! You mean the dreaded oneway keyword? I'd forgotten all about that. Plus, in EJB the request is not exposed like in CORBA as well. Some interceptors are transparent, others are not .. I think interceptors are transparent by definition. They modify the call after the client code has made it, or before it is received by the application code on the server side. Let the dynamic proxy implement the remote interface and all additional interfaces of all interceptors, that add non transparent behaviour to the component. We have already three additional apis: o SecurityAssociation o UserTransaction o ejb methods only the last one is directly implemented by the dynamic proxy. security and transactions are somewhat transcendent/magic. But the use of these takes place through standard interfaces on the client side and is again transparent to the client code, no? -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] EntityMetaData and read-only tag in jboss.xml
Hi all,
The importJbossXml function in this class seems to be looking for a
read-only tag in my jboss.xml file when deploying an entity:
if (readOnlyString != null)
{
readOnly = Boolean.valueOf(readOnlyString).booleanValue();
System.out.println(read-only set to + readOnly);
}
else
{
System.out.println(read-only element NOT found);
}
but this isn't in the DTD?
Is this meant to be here?
Luke.
--
Luke Taylor. Monkey Machine Ltd.
PGP Key ID: 0x57E9523Chttp://www.mkeym.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/plugins JaasSecurityManagerService.java
User: luke_t
Date: 02/02/03 13:10:50
Modified:src/main/org/jboss/security/plugins
JaasSecurityManagerService.java
Log:
added log warning msg if cache policy lookup in JNDI fails.
Applied code formatting.
Revision ChangesPath
1.10 +343 -323
jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManagerService.java
Index: JaasSecurityManagerService.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManagerService.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- JaasSecurityManagerService.java 2001/11/26 03:24:54 1.9
+++ JaasSecurityManagerService.java 2002/02/03 21:10:50 1.10
@@ -1,323 +1,343 @@
-/*
- * JBoss, the OpenSource EJB server
- *
- * Distributable under LGPL license.
- * See terms of license at gnu.org.
- */
-
-package org.jboss.security.plugins;
-
-import java.lang.reflect.Constructor;
-import java.lang.reflect.InvocationHandler;
-import java.lang.reflect.Method;
-import java.lang.reflect.Proxy;
-import java.util.Enumeration;
-import java.util.Hashtable;
-
-import javax.naming.InitialContext;
-import javax.naming.Context;
-import javax.naming.Reference;
-import javax.naming.RefAddr;
-import javax.naming.StringRefAddr;
-import javax.naming.Name;
-import javax.naming.NameClassPair;
-import javax.naming.NameParser;
-import javax.naming.NamingEnumeration;
-import javax.naming.NamingException;
-import javax.naming.OperationNotSupportedException;
-import javax.naming.spi.ObjectFactory;
-import javax.naming.CommunicationException;
-import javax.security.auth.Subject;
-
-import javax.management.MalformedObjectNameException;
-import javax.management.MBeanServer;
-import javax.management.ObjectName;
-
-import org.jboss.logging.Logger;
-import org.jboss.security.SecurityAssociation;
-import org.jboss.security.SecurityProxyFactory;
-import org.jboss.security.SubjectSecurityManager;
-import org.jboss.util.CachePolicy;
-import org.jboss.system.ServiceMBeanSupport;
-
-/**
- * This is a JMX service which manages JAAS based SecurityManagers.
- *JAAS SecurityManagers are responsible for validating credentials
- *associated with principals. The service defaults to the
- *org.jboss.security.plugins.JaasSecurityManager implementation but
- *this can be changed via the securityManagerClass property.
- *
- * @see JaasSecurityManager
- * @see SubjectSecurityManager
- * @author a href=[EMAIL PROTECTED]Oleg Nitz/a
- * @author a href=[EMAIL PROTECTED]Rickard Oberg/a
- * @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
- */
-public class JaasSecurityManagerService
- extends ServiceMBeanSupport
- implements JaasSecurityManagerServiceMBean
-{
- /** The logging interface */
- private static Logger theLog;
- /** The class that provides the security manager implementation */
- private static String securityMgrClassName =
org.jboss.security.plugins.JaasSecurityManager;
- /** The loaded securityMgrClassName */
- private static Class securityMgrClass;
- /** The security credential cache policy, shared by all security mgrs */
- private static CachePolicy cachePolicy;
- private static String cacheJndiName;
- /** The class that provides the SecurityProxyFactory implementation */
- private static String securityProxyFactoryClassName =
org.jboss.security.SubjectSecurityProxyFactory;
- private static Class securityProxyFactoryClass =
org.jboss.security.SubjectSecurityProxyFactory.class;
-
- private static Hashtable jsmMap = new Hashtable();
- private static NameParser parser;
-
- static
- {
- // use thread-local principal and credential propagation
- SecurityAssociation.setServer();
- // Get a theLog interface
- theLog = Logger.getLogger(JaasSecurityManagerService.class);
- }
-
- /** The constructor does nothing as the security manager is created
-on each lookup into java:/jaas/xxx. This is also why all variables
-in this class are static.
-*/
- public JaasSecurityManagerService()
- {
- }
-
- public String getSecurityManagerClassName()
- {
- return securityMgrClassName;
- }
- public void setSecurityManagerClassName(String className)
- throws ClassNotFoundException
- {
- securityMgrClassName = className;
- ClassLoader loader = Thread.currentThread().getContextClassLoader();
- securityMgrClass = loader.loadClass(securityMgrClassName);
- }
- public String getSecurityProxyFactoryClassName()
- {
- return securityProxyFactoryClassName;
- }
- public void setSecurityProxyFactoryClassName(String className)
- throws
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/plugins JaasSecurityManager.java
User: luke_t
Date: 02/02/03 13:18:19
Modified:src/main/org/jboss/security/plugins JaasSecurityManager.java
Log:
code formatting
Revision ChangesPath
1.18 +512 -498
jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManager.java
Index: JaasSecurityManager.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManager.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- JaasSecurityManager.java 2001/12/18 21:35:35 1.17
+++ JaasSecurityManager.java 2002/02/03 21:18:19 1.18
@@ -1,498 +1,512 @@
-/*
- * JBoss, the OpenSource EJB server
- *
- * Distributable under LGPL license.
- * See terms of license at gnu.org.
- */
-package org.jboss.security.plugins;
-
-import java.io.Serializable;
-import java.util.Arrays;
-import java.util.Enumeration;
-import java.util.HashSet;
-import java.util.Iterator;
-import java.util.Set;
-
-import java.security.Principal;
-import java.security.acl.Group;
-import javax.naming.InitialContext;
-import javax.naming.NamingException;
-import javax.security.auth.Subject;
-import javax.security.auth.login.LoginContext;
-import javax.security.auth.login.LoginException;
-import javax.security.auth.callback.CallbackHandler;
-
-import org.jboss.logging.Logger;
-import org.jboss.security.AppPolicy;
-import org.jboss.security.RealmMapping;
-import org.jboss.security.SecurityPolicy;
-import org.jboss.security.SubjectSecurityManager;
-import org.jboss.security.auth.callback.SecurityAssociationHandler;
-import org.jboss.util.CachePolicy;
-import org.jboss.util.TimedCachePolicy;
-
-/** The JaasSecurityManager is responsible both for authenticating credentials
- associated with principals and for role mapping. This implementation relies
- on the JAAS LoginContext/LoginModules associated with the security
- domain name associated with the class for authentication,
- and the context JAAS Subject object for role mapping.
-
- @see #isValid(Principal, Object)
- @see #Principal getPrincipal(Principal)
- @see #doesUserHaveRole(Principal, Set)
-
- @author a href=[EMAIL PROTECTED]Oleg Nitz/a
- @author [EMAIL PROTECTED]
- @version $Revision: 1.17 $
-*/
-public class JaasSecurityManager implements SubjectSecurityManager, RealmMapping
-{
- /** The authentication cache object.
-*/
- public static class DomainInfo
- {
- Subject subject;
- Object credential;
- Principal callerPrincipal;
- Group roles;
- }
-
- /** The current authenticate()d subject.
-*/
- private static ThreadLocal activeSubject = new ThreadLocal();
- /** The log4j category for the security manager domain
-*/
- private Logger log;
- /** The name of the domain this instance is securing. It is used as
-the appName into the SecurityPolicy.
-*/
- private String securityDomain;
- /** A cache of DomainInfo objects keyd by Principal.
-*/
- private CachePolicy domainCache;
- /** The custom JAAS policy. This may be null if a custom
-policy is not being used.
-*/
- private SecurityPolicy securityPolicy;
- /** Used in the absence of a SecurityPolicy specific CallbackHandler
-to pass credential info to the LoginModule associated with the
-securityDomain name.
-*/
- private SecurityAssociationHandler handler = new SecurityAssociationHandler();
-
- /** Get the currently authenticated Subject in securityDomain.
-@return The Subject for securityDomain if one exists, false otherwise.
-*/
- public static Subject getActiveSubject(String securityDomain)
- {
- Subject subject = null;
- try
- {
- InitialContext ctx = new InitialContext();
- String jsmName = jaas:/+securityDomain;
- JaasSecurityManager jsm = (JaasSecurityManager) ctx.lookup(jsmName);
- subject = jsm.getActiveSubject();
- }
- catch(NamingException e)
- {
- }
- return subject;
- }
- /** Create a LoginContext for the currently authenticated Subject in
-securityDomain.
-*/
- public static LoginContext getActiveSubjectLoginContext(String securityDomain,
CallbackHandler handler)
- throws LoginException
- {
- LoginContext lc = null;
- Subject subject = getActiveSubject(securityDomain);
- if( subject == null )
- throw new LoginException(No active subject found in securityDomain:
+securityDomain);
-
- if( handler != null )
- lc = new LoginContext(securityDomain, subject, handler);
- else
- lc = new LoginContext(securityDomain, subject);
-
- return lc;
- }
-
- /** Creates a default JaasSecurityManager for
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/plugins JaasSecurityManager.java
User: luke_t
Date: 02/02/03 13:58:30
Modified:src/main/org/jboss/security/plugins JaasSecurityManager.java
Log:
simplified if/else logic in validateCache method.
Revision ChangesPath
1.19 +2 -4
jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManager.java
Index: JaasSecurityManager.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManager.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- JaasSecurityManager.java 2002/02/03 21:18:19 1.18
+++ JaasSecurityManager.java 2002/02/03 21:58:30 1.19
@@ -45,7 +45,7 @@
*
* @author a href=[EMAIL PROTECTED]Oleg Nitz/a
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.18 $
+ * @version $Revision: 1.19 $
*/
public class JaasSecurityManager implements SubjectSecurityManager, RealmMapping
{
@@ -403,9 +403,7 @@
isValid = subjectCredential == null;
}
// See if the credential is assignable to the cache value
- else if(subjectCredential.getClass().isAssignableFrom(credential.getClass())
== false)
- isValid = false;
- else
+ else if (subjectCredential.getClass().isAssignableFrom(credential.getClass()))
{
/* Validate the credential by trying Comparable, char[], byte[],
and finally Object.equals()
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/bin run.bat
User: luke_t Date: 02/02/04 18:23:44 Modified:src/bin run.bat Log: Added (commented out) JPDA options to run.bat. Saves having to add them after every build. Revision ChangesPath 1.28 +3 -0 jboss/src/bin/run.bat Index: run.bat === RCS file: /cvsroot/jboss/jboss/src/bin/run.bat,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- run.bat 2002/01/03 04:00:56 1.27 +++ run.bat 2002/02/05 02:23:44 1.28 @@ -10,6 +10,9 @@ REM Setup JBoss sepecific properties set JAVA_OPTS=%JAVA_OPTS% -Djboss.boot.loader.name=run.bat +REM JPDA options. Uncomment and modify as appropriate to enable remote debugging. +REM set JAVA_OPTS=%JAVA_OPTS% -classic -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y + REM Set the JAXP factory names REM Crimson parser JAXP setup(default) set JAXP=-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.crimson.jaxp.DocumentBuilderFactoryImpl ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] deprecations
[EMAIL PROTECTED] wrote: Hi all, I notice when compiling the HEAD branch out of CVS, there are quite a few deprecation warnings. Is this anything anybody cares about? If so, I'd be happy to have a go at fixing these -- If these are things in the core java.*/javax.* API that have been deprecated since J2SE 1.2.x, I think we can go ahead and upgrade them, since RH requires 1.3.x, right? -jason I think some of them at least (the security Identity ones) are because JBoss still has to support a deprecated API itself to be compliant. So they can't be removed until the API is changed. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security Util.java
Hi Scott, I was looking at this class a while ago and most of the functionality seems related to the SRP module, and the base64 encodings it uses aren't standard format. Do you think it would be worth moving it into the srp package (possibly renaming it SRPUtil)? Then you could have a separate generally applicable Util class which was less cluttered ? Luke. Scott M Stark wrote: User: starksm Date: 02/02/06 11:59:45 Modified:src/main/org/jboss/security Tag: Branch_2_4 Util.java Log: Add a createPasswordHash utility method for creating string encodings of MessageDigest hashes. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/verifier/strategy AbstractVerifier.java
User: luke_t
Date: 02/02/10 09:02:50
Modified:src/main/org/jboss/verifier/strategy AbstractVerifier.java
Log:
Fix for verifier bug 489554.
Revision ChangesPath
1.25 +20 -5 jboss/src/main/org/jboss/verifier/strategy/AbstractVerifier.java
Index: AbstractVerifier.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/verifier/strategy/AbstractVerifier.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- AbstractVerifier.java 28 Nov 2001 00:27:14 - 1.24
+++ AbstractVerifier.java 10 Feb 2002 17:02:50 - 1.25
@@ -19,7 +19,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* This package and its source code is available at www.jboss.org
- * $Id: AbstractVerifier.java,v 1.24 2001/11/28 00:27:14 juhalindfors Exp $
+ * $Id: AbstractVerifier.java,v 1.25 2002/02/10 17:02:50 luke_t Exp $
*/
// standard imports
@@ -62,6 +62,7 @@
* @author Aaron Mulder ([EMAIL PROTECTED])
* @author Vinay Menon ([EMAIL PROTECTED])
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a
+ * @author a href=mailto:[EMAIL PROTECTED];Luke Taylor/a
*
* pbRevisions:/b/p
* pb20011101: Andy/b
@@ -69,8 +70,14 @@
* liChanged the throwRemoteException() method to check accordingly to the RMI
spec./li
* /ul
* /p
+ * pb20020210: luke/b
+ * ul
+ * liChanged hasRemoteReturnType() to use isAssignableFrom() rather than just
compare strings.
+ * See Bug 489554 (sub-classed remote return types should be OK)/li
+ * /ul
+ * /p
*
- * @version $Revision: 1.24 $
+ * @version $Revision: 1.25 $
* @sinceJDK 1.3
*/
public abstract class AbstractVerifier implements VerificationStrategy {
@@ -261,7 +268,7 @@
}
/*
- * checks if a class's memeber (method, constructor or field) has a 'public'
+ * checks if a class's member (method, constructor or field) has a 'public'
* modifier.
*/
public boolean isPublic(Member member) {
@@ -316,7 +323,15 @@
* checks the return type of method matches the bean's remote interface
*/
public boolean hasRemoteReturnType(BeanMetaData bean, Method m) {
-return (m.getReturnType().getName().equals(bean.getRemote()));
+try {
+ Class clazz = classloader.loadClass(bean.getRemote());
+ System.out.println(Bean remote +bean.getRemote()+ , return type +
m.getReturnType().getName());
+ return m.getReturnType().isAssignableFrom(clazz);
+} catch(Exception e) {
+ e.printStackTrace();
+ return false;
+}
+//return (m.getReturnType().getName().equals());
}
/*
@@ -983,7 +998,7 @@
// exception classes, are assumed to be mapped to the implicit
// CORBA system exception, and are therefore not explicitly
// declared in OMG IDL.
-//
+//
//if (RuntimeException.class.isAssignableFrom(type))
//return false;
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/verifier/strategy AbstractVerifier.java
User: luke_t
Date: 02/02/10 09:19:51
Modified:src/main/org/jboss/verifier/strategy AbstractVerifier.java
Log:
Oops! Removed tracing println.
Revision ChangesPath
1.26 +2 -3 jboss/src/main/org/jboss/verifier/strategy/AbstractVerifier.java
Index: AbstractVerifier.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/verifier/strategy/AbstractVerifier.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- AbstractVerifier.java 10 Feb 2002 17:02:50 - 1.25
+++ AbstractVerifier.java 10 Feb 2002 17:19:50 - 1.26
@@ -19,7 +19,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* This package and its source code is available at www.jboss.org
- * $Id: AbstractVerifier.java,v 1.25 2002/02/10 17:02:50 luke_t Exp $
+ * $Id: AbstractVerifier.java,v 1.26 2002/02/10 17:19:50 luke_t Exp $
*/
// standard imports
@@ -77,7 +77,7 @@
* /ul
* /p
*
- * @version $Revision: 1.25 $
+ * @version $Revision: 1.26 $
* @sinceJDK 1.3
*/
public abstract class AbstractVerifier implements VerificationStrategy {
@@ -325,7 +325,6 @@
public boolean hasRemoteReturnType(BeanMetaData bean, Method m) {
try {
Class clazz = classloader.loadClass(bean.getRemote());
- System.out.println(Bean remote +bean.getRemote()+ , return type +
m.getReturnType().getName());
return m.getReturnType().isAssignableFrom(clazz);
} catch(Exception e) {
e.printStackTrace();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss Code Style Guide
Together's code formatter can do it OK. It can do all the indentation, brackets, javadoc formatting and removing unwanted and unused imports OK. On the if, for, catch ( blah ) parenthesis stuff it's not so flexible though. Maybe this isn't too important anyway (there should probably be some flexibility on the part of the reader too :). Luke. Dain Sundstrom wrote: Hi all, I wrote the JBossCMP code before I was aware the JBoss Code Style Guide, so I now I want to run a beautifier to correct my code. Does any one use a free beautifier that they have setup for JBoss? I found one called jacobe which seems to do the trick, but I have some questions about the style guide. In class or interface declarations should I put a line terminator before extends and implements as in the example code? Should I put a space between if and the open parenthesis? (There is not one in the sample.) Should I put a space between catch and the open parenthesis? (There is one in the sample.) Should I put a space between for and the open parenthesis? (There is one in the sample.) I'm not going to update the code until after DR1 in case it introduces errors. thanks -dain -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is it necessary to store Proxies in serialized form in jndi? (jboss 3)
Bill Burke wrote: In my experience so far, Home's are looked up only once on the client and cached, so I agree with you David. Proxies shouldn't be serialized into JNDI. I was looking at this recently while trying to work out whether JNDI has anything to say about it itself. Isn't this done in the ProxyFactory code? As far as I can see it just passes a reference to the EJBHome object to the rebind function. Where does it get serialized? Do you guys know if there any constraints on how a JNDI implementation should handle storing java objects - e.g. are they supposed to be serialized or is it just left to the implementation? Luke. Bill -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is it necessary to store Proxies in serialized form in jndi? (jboss 3)
David Jencks wrote:
On 2002.02.14 13:35:56 -0500 Luke Taylor wrote:
naming module, org.jnp.interfaces.NamingContext.rebind
I put the println in
if (!(obj instanceof Reference))
{
className = obj.getClass ().getName ();
// Normal object - serialize
System.out.println(rebinding serializable Object at: + name
+ , class: + obj.getClass() + , classloader: +
obj.getClass().getClassLoader());
obj = new MarshalledObject (obj);
and it get called when ProxyFactory does the rebind.
Ah, OK, does this mean that all local objects in JNDI are being
serialized, or is the local namespace stuff (as used by the security)
implemented differently? I guess it must be... no?
Luke.
--
Luke Taylor. Monkey Machine Ltd.
PGP Key ID: 0x57E9523Chttp://www.mkeym.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Question for win32 batch file gurus
Jason Dillon wrote: That was what I was shooting for. Wanted to make the .bat files not dependent on users running them from the directory they live in (for build.bat as well as all the bin/*.bat files). It used to work that way, but someone's removed it. It's hideously convoluted (about 5 lines of obscure scripting). Also I don't know if it works on all Windows versions. Check through older build.bat versions in CVS or look in the archives of jboss-dev. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JPDA support on JBoss beta
Ignacio Coloma wrote: Could someone please put 'suspend=n' instead of 'y' in the run.bat file? The whole line should be commented out anyway, and if someone wants to enable it they will likely have to alter the port setting and location so they can remove suspend if they want. If not, execution is halted from the very beginning, which I suppose is not the normal use of remote debugging. I only added it because it's a drag to remember the syntax whenever you want to use it. I think it's equally useful having suspend, if you want to catch the server as it's setting stuff up and deploying applications. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-user] Re: [JBoss-dev] Tshirts at JavaOne FREE TRAINING
Bill Burke wrote: Never was much of a gaming freak. I guess you have to be under 22 years old to appreciate this? I haven't played a video game in 10 years. Aimed at the geeks I guess, rather than the managers. Still could've been worse - might've been from Star Wars/Trek... Hey wait a minute... did I hear someone say use the sauce ? -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Security problem in authentication model.
Scott M Stark wrote: This is why the Catalina security integration implements both the Realm and Valve interfaces. The Realm callbacks establish the authentication and the Valve limits the scope of the information to the duration of the request. The thread of control returns to the Catalina pool with no thread local association. The Tomcat 3.2 security integration does the same thing, but it a lot more work because the integration interface is not as clean. Scott, Talking of Catalina security - there have been quite a few posts in the forums about how to use Catalina security with standalone JBoss, as is possible in Tomcat 3.2. There doesn't seem to be an obvious way of getting hold of the current security information (username/password) from a Valve in order to set up the security association with JBoss. I'm not even sure if it's possible at all, as it seems likely that the Catalina authenticators will junk the password once the user's been authenticated, and it won't be available to subsequent requests. Do you have any ideas from your work on the integrated security? Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] AAAHOOO JBoss in London!
marc fleury wrote: Ok, yes, it sounds like a corny song from the late 70's ... Hey don't knock it - Lee Ho Fooks actually had it in their window in Chinatown last time I looked: As featured in Warren Zevon's 'Werewolves of London'. Maybe you could hold your JBoss meal there this time ... Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: [JBoss-user] JBOSS 3.x FINAL
David Jencks wrote: ... In order to support the development of JBoss and ensure that the documentation remains up to date, we offer a PDF version of the JBoss book to be published by SAMS publishing. Following the link also brings you to the Comperehensive Documentation Subscription at the very top of the page, really hard to miss. Precisely - this documentation business keeps coming up and the bottom line is that the PDF of Scott's book is a pretty comprehensive document and guide to JBoss 2.4 and if people want documentation for 2.4 they should buy it (or the book itself). Trying to maintain any other sort of serious documentation project is just duplicating the effort and is a waste of time, though I'm still in favour of retaining a basic getting started guide. I think the online manual should be mostly JBoss 3 specific - trying to have two copies won't be feasible. It's out of date as it is. It should also be pretty basic and refer to the pay-for docs as necessary. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Maven Build
Hi all, I've completed a basic Maven build for JBoss which builds something approximately the same as the current build, and which appears to run pretty similarly, though I haven't done any serious tests. If anyone wants to take a look at the files then they can be downloaded from http://www.monkeymachine.ltd.uk/jbossmaven.zip And an example generated site, roughly copied from the Maven one, is running at http://monkeymachine.ath.cx/jboss (on a laptop on a dodgy BT ppp connection so no guarantees on reliability). If you're reasonably familiar with Maven, then it shouldn't be too difficult to get it working - it builds the current version of HEAD without any errors (on JDK 1.4+). Anything earlier will probably break. There are numerous jar files which you will have to add to the repository manually at the moment, but that should hopefully change. I will ask the Maven guys to upload some of the necessary stuff. I've been using versions of both xdoclet and maven out of CVS so again there are no guarantees that it will work with earlier versions. Maven B-10 should be OK. If anyone wants any further information on getting it to work let me know. There's still a lot to be done - optimization, testing, jar manifest information and generally making sure there isn't anything missing, though I think there may be quite a lot of dead stuff hanging about in the current build. Any suggestions for improvements are of course welcome. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Exception when invoking shutdown via console
occurred in the container during the request processing java.lang.OutOfMemoryError 2003-09-18 17:18:07,921 INFO [org.jboss.web.tomcat.tc4.EmbeddedTomcatService] Destroying 2003-09-18 17:18:07,921 INFO [org.jboss.web.tomcat.tc4.EmbeddedTomcatService] Destroyed -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
