[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/securitymgr/test EJBSpecUnitTestCase.java
User: starksm
Date: 02/02/25 00:11:21
Added: src/main/org/jboss/test/securitymgr/test
EJBSpecUnitTestCase.java
Log:
Unit tests for running JBoss under a security manager
Revision ChangesPath
1.1
jbosstest/src/main/org/jboss/test/securitymgr/test/EJBSpecUnitTestCase.java
Index: EJBSpecUnitTestCase.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.test.securitymgr.test;
import java.io.IOException;
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.management.ObjectName;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import org.jboss.test.securitymgr.interfaces.IOSession;
import org.jboss.test.securitymgr.interfaces.IOSessionHome;
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
import org.jboss.test.JBossTestCase;
import org.jboss.test.JBossTestSetup;
/** Tests of the programming restrictions defined by the EJB spec. The JBoss
server must be running under a security manager. The securitymgr-ejb.jar
should be granted only the following permission:
grant securitymgr-ejb.jar {
permission java.util.PropertyPermission *, read;
permission java.lang.RuntimePermission queuePrintJob;
permission java.net.SocketPermission *, connect;
};
@author [EMAIL PROTECTED]
@version $Revision: 1.1 $
*/
public class EJBSpecUnitTestCase
extends JBossTestCase
{
org.apache.log4j.Category log = getLog();
public EJBSpecUnitTestCase(String name)
{
super(name);
}
/** Test that a bean cannot access the filesystem using java.io.File
*/
public void testFileIO() throws Exception
{
log.debug(+++ testFileIO());
Object obj = getInitialContext().lookup(secmgr.IOSessionHome);
IOSessionHome home = (IOSessionHome) obj;
log.debug(Found secmgr.IOSessionHome);
IOSession bean = home.create();
log.debug(Created IOSession);
try
{
// This should fail because the bean calls File.exists()
bean.read(nofile.txt);
fail(Was able to call IOSession.read);
}
catch(RemoteException e)
{
log.debug(IOSession.read failed as expected);
}
try
{
// This should fail because the bean calls File.exists()
bean.write(nofile.txt);
fail(Was able to call IOSession.write);
}
catch(RemoteException e)
{
log.debug(IOSession.read failed as expected);
}
bean.remove();
}
/**
* Setup the test suite.
*/
public static Test suite() throws Exception
{
return getDeploySetup(EJBSpecUnitTestCase.class, securitymgr-ejb.jar);
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/deployment DeploymentInfo.java
On 2002.02.25 00:17:30 -0500 Scott M Stark wrote: We don't necessarily need to not have xml parsing in the metadata classes. What I don't want to require is that an xml document or its equivalent dom object is required to deploy a component. So I need to be able to create the metadata objects independent of their xml form. Its been a few months since I looked at JAXB so I don't remember how the xml parser fits in. You have to be able to construct jaxb objects not through xml since it is 2 way -- they can write the xml from config as well as create objects from xml. I don't know that this appoach will work for mbean configuration. The one usage we have that goes against this is the arbitrary configuration info that can be passed to an mbean if it supports an attribute of type org.w3c.dom.Element. This is used in supported by the AbstractWebContainer and the Catalina service to pass through config information to the Catalina setup process. Are you grouping deployment metadata together with mbean configuration in your effort or was the container config just an example? Well, my idea was that since Containers are mbeans already, why not transform the dd's to mbean config. I'm still thinking about how to best deal with subsidiary objects. I'm thinking if all the subsidiary objects are javabeans they can be constructed easily from xml, through jaxb or other ways. This is mostly still in the thought stage, I'm working on it a little with my new connectionmanager for rar deployment. david jencks Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, February 24, 2002 6:33 PM Subject: Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/deployment DeploymentInfo.java Glad you brought this up. I was about to embark on rewriting the deployment process and meta data stuff. I was considering using JAXB or equivavlnet to convert xml to objects. JAXB works by generating classes that contain the xml parsing and validation in them. Your classes with real behavior can then subclass these, reading a doc will then generate instances of your subclasses. In this idea, the first step in deployment is transforming the xml using xslt to a form ideally suited to our objects. What I was hoping for, although I haven't even prototyped it yet, is that the classes created from reading the (transformed) xml are the ones that do the work -- so for instance (slightly atypical) the container configuration is an mbean config as we have now in service-xml. Whatever objects are used in cmp2 are created by being read from the xml. Anyway... from what you say it looks like one requirement is that the xml to object creation step should not involve xml parsing in the classes... so jaxb is out, what we have now is also out, we need an external xml reader solution. Is this a consequence of what you are saying here? Or... perhaps we could provide a more code generation and compile time solution whereby one set of classes for use with xml is generated by jaxb + our subclasses, whereas for other non-xml purposes another equivalent set is generated from [unknown base classes specific to the situation] + our same subclasses. Thanks david jencks On 2002.02.24 21:06:24 -0500 Scott M Stark wrote: The metadata stuff in deployment I think should be independent of XML deployment descriptors. What is now in metadata or somewhere else should be the XML to metadata object model mapping. As I indicated in the embedded requirements, some applications of embedding JBoss already have service frameworks equivalent to J2EE and they just want to map existing services onto J2EE compatible APIs. There is no reason to force a packaging and building xml descriptors if one can go directly to the deployment object model. XML is really not a great programming API. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/securitymgr - New directory
User: starksm Date: 02/02/25 00:09:17 jbosstest/src/main/org/jboss/test/securitymgr - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/securitymgr/ejb IOStatelessSessionBean.java
User: starksm
Date: 02/02/25 00:11:21
Added: src/main/org/jboss/test/securitymgr/ejb
IOStatelessSessionBean.java
Log:
Unit tests for running JBoss under a security manager
Revision ChangesPath
1.1
jbosstest/src/main/org/jboss/test/securitymgr/ejb/IOStatelessSessionBean.java
Index: IOStatelessSessionBean.java
===
package org.jboss.test.securitymgr.ejb;
import java.io.File;
import java.io.IOException;
import java.security.Principal;
import javax.ejb.CreateException;
import javax.ejb.EJBException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
import org.apache.log4j.Category;
/** A session bean that attempts I/O operations not allowed by the EJB 2.0
spec as a test of running JBoss with a security manager.
@author [EMAIL PROTECTED]
@version $Revision: 1.1 $
*/
public class IOStatelessSessionBean implements SessionBean
{
Category log = Category.getInstance(getClass());
private SessionContext sessionContext;
public void ejbCreate() throws CreateException
{
}
public void ejbActivate()
{
}
public void ejbPassivate()
{
}
public void ejbRemove()
{
}
public void setSessionContext(SessionContext context)
{
sessionContext = context;
}
/**
*/
public String read(String path) throws IOException
{
log.debug(read, path=+path);
File tstPath = new File(path);
if( tstPath.exists() == false )
path = null;
return path;
}
public void write(String path) throws IOException
{
log.debug(write, path=+path);
File tstPath = new File(path);
tstPath.createNewFile();
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/securitymgr/interfaces IOSession.java IOSessionHome.java
User: starksm
Date: 02/02/25 00:11:21
Added: src/main/org/jboss/test/securitymgr/interfaces
IOSession.java IOSessionHome.java
Log:
Unit tests for running JBoss under a security manager
Revision ChangesPath
1.1
jbosstest/src/main/org/jboss/test/securitymgr/interfaces/IOSession.java
Index: IOSession.java
===
package org.jboss.test.securitymgr.interfaces;
import java.io.IOException;
import java.rmi.RemoteException;
import javax.ejb.EJBObject;
public interface IOSession extends EJBObject
{
/** A method that returns its arg */
public String read(String path) throws IOException, RemoteException;
public void write(String path) throws IOException, RemoteException;
}
1.1
jbosstest/src/main/org/jboss/test/securitymgr/interfaces/IOSessionHome.java
Index: IOSessionHome.java
===
package org.jboss.test.securitymgr.interfaces;
import javax.ejb.*;
import java.rmi.*;
public interface IOSessionHome extends EJBHome
{
public IOSession create() throws RemoteException, CreateException;
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] init/create calls with subpackaging not in the same order
Hello, In the MainDeployer code, when you deploy a package containing sub-packages: - init will be called on the wrapping package first, then on the inside packages - create will be called on the inside packages first, then on the wrapping package Why this logic? I don't mean I consider it to be wrong, it is just that I don't see the rational behind it. Thank you. Cheers, Sacha P.S.: I was reading version 1.22, maybe it has changed since Saturday. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Loading array class object by name
On Sun, Feb 24, 2002 at 09:42:21PM -0600, Dain Sundstrom wrote: Thanks Scott. I thought I tried that one... Now do you know an easy way to convert java.lang.object[] or whatever to the signature style [Ljava.lang.Object; (other then string manipulation)? Otherwise, I'll write a conversion function. Hi, There are some utils to do this included with apache's BCEL, I've submitted a patch to replace the org.jboss.proxy.compiler.* (#519626) which uses them a bit. If you do implement a conversion function you should note that Class.getName() is inconsistent in behaviour (and IMHO doesn't behave as documented) wrt primitive types. There is a bug on bug parade (#4369208) which raises the inconsistency javadoc - implementation. The 'problem' is that e.g. Class.getName(Character.TYPE) returns char rather than C -- regards Neale Swinnerton -dain Scott M Stark wrote: The syntax for obtaining array classes using Class.forName is rather wacked, but it does work. For example, to get the class for an Object[], use Class oaClass = Class.forName([Ljava.lang.Object;); ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Deployer Message
If you use JBoss (instead of developing it) it looks like that: I deploy an EJB jar. After the last table has been created, no more info appears on the console. So I never know whether the deployment has completed successfully (or even hangs). I have to look through the list of ( 30) created tables to check whether all of them have actually been created and whether everything else is there. In general I am very grateful that with Hunter Hillegas somebody well known to the JBoss developer community is looking at the current JBoss version from the user perspective. So I don't feel so lonely any more. BTW: I am totally desparate on this bug (Argument type mismatch after redeploy)? http://sourceforge.net/tracker/index.php?func=detailaid=521058group_id=228 66atid=376685 Could somebody be so kind and have look at it, please? Georg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of danch Sent: Monday, February 25, 2002 04:46 To: Jason Dillon Cc: Hunter Hillegas; JBoss Dev Subject: Re: [JBoss-dev] Deployer Message There's a big difference in granularity between the code in the component being deployed and the component itself: do you suggest that I have a static initializer in all of my beans that logs 'hey, i've been loaded'?. Even picking an arbitrary component (from those that _do_ get their class loaded) is an ugly, ugly hack. An 'INFO' message that an application has been deployed is far better. Better yet might be a JMX notification from the deployer. At any rate, the cost of notifying on deployment is so low that there really isn't a reason for it to not be INFO (IMNSHO). danch Jason Dillon wrote: I probably changed it from info to debug, in that this information is only useful when debugging a deployer problem. Other info level messages should be provided by the component that has been deployed. --jason Hunter Hillegas wrote: Maybe this should be marked as INFO, not DEBUG: 12:11:58,396 DEBUG [MainDeployer] Done deploying someear.ear Seems like useful information that the server is done deploying the ear... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] JBoss/IIOP JBoss/.Net optional - standard
Yes, the optional state has two reasons: - decouple from overall compile/testsuite until module is stable. - mark the module as should be installed via a separate, additional binary dist I think that the current jboss dist is very heavyweight and nearly everybody needs to cut it down to exactly the configuration that is needed ... I prefer having a leaner main dist and several additional (optional) packages, although that was not quite that easy in the past having that central .jcml File ... But now RH rulez! Best, CGJ -Ursprüngliche Nachricht- Von: Scott M Stark [mailto:[EMAIL PROTECTED]] Gesendet: Sonntag, 24. Februar 2002 06:22 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] JBoss/IIOP JBoss/.Net optional - standard Yes, we will always have raw contrib stuff and experiments. It simply should not affect the base compile or tests. If something isn't being supported though we ditch it. May be a good idea to have an experimental group though. For example, the jmx stuff might go there until it has been polished, then migrated to the standard group (or rather core in this case... depending on if it does not have any external depends). --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] JBoss/.Net plugin broken...
Hi there, -Ursprüngliche Nachricht- Von: marc fleury [mailto:[EMAIL PROTECTED]] Gesendet: Samstag, 23. Februar 2002 20:14 An: David Jencks; Jason Dillon Cc: Jung Christoph; jboss-dev Betreff: RE: [JBoss-dev] JBoss/.Net plugin broken... |I think that if any of this has ever worked it should be included in the |main build and whatever tests exist added to the main testsuite. Unless I |get notified by broken tests, I don't know something exists, let alone |whether I broke it. ++1 I don't know that it ever really worked, but we talked with Scott yesterday and this JBoss.net thing must go up there with CMP2.0, clustering and MBoss (JMX). The truth is that we have one of the most complete solutions for .NET development (services talking with webservices) and we should really make some noise. Scott said he wants to become Mr JBoss.NET full time as it is going to be one of our most important features. Bottom line: anything that makes JBoss.NET part of the main line and main tests is ++1. That sounds very reasonable, if you don´t mind, I´d like to nevertheless continue dedicating my very limited time to help you in that issue. Peter Braswell also announced his interest to join the project which I´m quite happy about. Jboss.net and its testsuite work except of a pending commit of mine to the MainDeployer and that little security problem that still exists with the generic AxisServlet (needs some special authentication mode that is not covered by the servlet spec as it seems, I´m in contact with the Jetty-guys about this topic). Axis.jar will be installed under lib/ext by the build script but we could, of course, add it to the jboss-net.sar (but then you need to add it to the client directory as well, that´s why I was reluctant). I try to fix it in this week (the latest deployment changes to the mainline regularly broke the AxisService, because it is an additional deployer). On the same line of thought, do you think integrating the deployers can enable us to put a java file with doclet stuff and get an EJB AND a webservice (by tying the ant to call he axis deployer)? I plan on finishing the unification of invokers next week (with Invocation return and client int) so we could test the shared EJB thingy. That's going to be sweet. If there are no special XML-bindings involved, a simple, xml-based deployment descriptor that installs an EJBProvider pivot in the Axis engine, is enough. Peter, is that one topic interesting enough for you? CGJ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JavaOne T-Shirts...
This is definitely my last contribution to that ridiculous topic: JBoss: Got Balls? BTW: I´d like to order the Star Wars t-shirt suite with pictures of Marc-Wan-Fleurobi, Rickard-Skyberg, Scott Solo, and all those other Ewoks fighting against Bill Darth Gater and his imperial troups. CGJ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/deployment MainDeployer.java
User: d_jencks
Date: 02/02/25 05:52:31
Modified:src/main/org/jboss/deployment MainDeployer.java
Log:
Made start of init and end of start steps a little louder and more explicit in
logging
Revision ChangesPath
1.6 +4 -12 jboss-system/src/main/org/jboss/deployment/MainDeployer.java
Index: MainDeployer.java
===
RCS file:
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/MainDeployer.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- MainDeployer.java 25 Feb 2002 05:29:19 - 1.5
+++ MainDeployer.java 25 Feb 2002 13:52:31 - 1.6
@@ -47,7 +47,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
- * @version $Revision: 1.5 $
+ * @version $Revision: 1.6 $
*/
public class MainDeployer
extends ServiceMBeanSupport
@@ -488,8 +488,6 @@
{
return;
}
-
- log.info(Deploying: + deployment.url.toString());
init(deployment);
create(deployment);
start(deployment);
@@ -505,7 +503,7 @@
*/
private void init(DeploymentInfo deployment) throws DeploymentException
{
- log.debug(init on deployment + deployment.url);
+ log.info(Starting deployment (init step) of package at: + deployment.url);
try
{
@@ -587,10 +585,7 @@
deployment.status=Created;
- if (log.isDebugEnabled())
- {
-log.debug(Done deploying + deployment.shortName);
- }
+ log.debug(Done with create step of deploying + deployment.shortName);
}
catch (Throwable t)
{
@@ -626,10 +621,7 @@
deployment.status=Deployed;
- if (log.isDebugEnabled())
- {
-log.debug(Done deploying + deployment.shortName);
- }
+ log.info(Final (start) deployment step successfully completed on package:
+ deployment.shortName);
}
catch (Throwable t)
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Deployer Message
On 2002.02.25 04:54:04 -0500 Georg Schmid wrote: If you use JBoss (instead of developing it) it looks like that: I deploy an EJB jar. After the last table has been created, no more info appears on the console. So I never know whether the deployment has completed successfully (or even hangs). I have to look through the list of ( 30) created tables to check whether all of them have actually been created and whether everything else is there. I've changed MainDeployer so it infos start of deployment (init) and end of deployment (start) for each package and subpackage. We'll see if it is too loud. In general I am very grateful that with Hunter Hillegas somebody well known to the JBoss developer community is looking at the current JBoss version from the user perspective. So I don't feel so lonely any more. BTW: I am totally desparate on this bug (Argument type mismatch after redeploy)? http://sourceforge.net/tracker/index.php?func=detailaid=521058group_id=228 66atid=376685 Could somebody be so kind and have look at it, please? I think this is the remote version of bugs 516684 and 519699, so it may be fixed only when we use jbossmx. I haven't looked very hard at it however. david jencks Georg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of danch Sent: Monday, February 25, 2002 04:46 To: Jason Dillon Cc: Hunter Hillegas; JBoss Dev Subject: Re: [JBoss-dev] Deployer Message There's a big difference in granularity between the code in the component being deployed and the component itself: do you suggest that I have a static initializer in all of my beans that logs 'hey, i've been loaded'?. Even picking an arbitrary component (from those that _do_ get their class loaded) is an ugly, ugly hack. An 'INFO' message that an application has been deployed is far better. Better yet might be a JMX notification from the deployer. At any rate, the cost of notifying on deployment is so low that there really isn't a reason for it to not be INFO (IMNSHO). danch Jason Dillon wrote: I probably changed it from info to debug, in that this information is only useful when debugging a deployer problem. Other info level messages should be provided by the component that has been deployed. --jason Hunter Hillegas wrote: Maybe this should be marked as INFO, not DEBUG: 12:11:58,396 DEBUG [MainDeployer] Done deploying someear.ear Seems like useful information that the server is done deploying the ear... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-522477 ] no serialized object in cmp field
Bugs item #522477, was opened at 2002-02-25 07:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=522477group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 9 Submitted By: Thomas Hamann (thomash76) Assigned to: Nobody/Anonymous (nobody) Summary: no serialized object in cmp field Initial Comment: win2kpro, jdk1.3.1_02, JBoss 3.0.0beta2 Hi, i deployed a small test application which contains a single entity bean with cmp. There are three cmp fields - a long, a String and a serialized HashMap - in the entity. However, after i connected a test client to the entity beans home interface and performed a lookup (by name) for the bean, a method call on the found instance throws the following exception: (on client side) Unable to load to deserialize result: java.io.StreamCorruptedException: InputStream does not contain a serialized object at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Unknown Source) at sun.rmi.transport.StreamRemoteCall.executeCall(Unknown Source) at sun.rmi.server.UnicastRef.invoke(Unknown Source) at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source) at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:174) at org.jboss.proxy.ejb.GenericProxy.invoke(GenericProxy.java:182) at org.jboss.proxy.ejb.EntityProxy.invoke(EntityProxy.java:132) at $Proxy1.getUserName(Unknown Source) at test.TestUserClient.main(TestUserClient.java:306) java.sql.SQLException: Unable to load to deserialize result: java.io.StreamCorruptedException: InputStream does not cont ain a serialized object no stack trace available (on server side) 16:17:33,952 ERROR [JRMPInvoker] operation failed java.rmi.ServerException: Internal error getting results for field member userProps Embedded Exception Unable to load to deserialize result: java.io.StreamCorruptedException: InputStream does not contain a serialized object ; nested exception is: javax.ejb.EJBException: Internal error getting results for field member userProps Embedded Exception Unable to load to deserialize result: java.io.StreamCorruptedException: InputStream does not contain a serialized object javax.ejb.EJBException: Internal error getting results for field member userProps Embedded Exception Unable to load to deserialize result: java.io.StreamCorruptedException: InputStream does not contain a serialized object at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstra ctCMPFieldBrid ge.java:309) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadInstanceResults(JDBCAbstrac tCMPFieldBrid ge.java:253) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:138 ) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:62) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:409) at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManager.java:380) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java :275) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:189) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:108) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:96) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:167) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:127) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:475) at org.jboss.ejb.Container.invoke(Container.java:668) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:995) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:364) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) at java.lang.Thread.run(Unknown
Re: [JBoss-dev] Yikes... something is broken....
On 2002.02.24 21:59:38 -0500 Jason Dillon wrote: looks like some of the njar changes (not sure what) may have gone sour... --jason I looked at URL and it tries to load the handler with Class.forName and then the system classloader. Does your resource protocol handler get loaded ok? I think we either need to include these in run.jar or write a jboss handler factory for all our protocols and set it early in the startup process. Where should it go? Or I guess we could make an mbean that we can dynamically add handlers to from the UnifiedClassLoaders... Thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-522477 ] no serialized object in cmp field
Bugs item #522477, was opened at 2002-02-25 07:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=522477group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Thomas Hamann (thomash76) Assigned to: Nobody/Anonymous (nobody) Summary: no serialized object in cmp field Initial Comment: win2kpro, jdk1.3.1_02, JBoss 3.0.0beta2 Hi, i deployed a small test application which contains a single entity bean with cmp. There are three cmp fields - a long, a String and a serialized HashMap - in the entity. However, after i connected a test client to the entity beans home interface and performed a lookup (by name) for the bean, a method call on the found instance throws the following exception: (on client side) Unable to load to deserialize result: java.io.StreamCorruptedException: InputStream does not contain a serialized object at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Unknown Source) at sun.rmi.transport.StreamRemoteCall.executeCall(Unknown Source) at sun.rmi.server.UnicastRef.invoke(Unknown Source) at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source) at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:174) at org.jboss.proxy.ejb.GenericProxy.invoke(GenericProxy.java:182) at org.jboss.proxy.ejb.EntityProxy.invoke(EntityProxy.java:132) at $Proxy1.getUserName(Unknown Source) at test.TestUserClient.main(TestUserClient.java:306) java.sql.SQLException: Unable to load to deserialize result: java.io.StreamCorruptedException: InputStream does not cont ain a serialized object no stack trace available (on server side) 16:17:33,952 ERROR [JRMPInvoker] operation failed java.rmi.ServerException: Internal error getting results for field member userProps Embedded Exception Unable to load to deserialize result: java.io.StreamCorruptedException: InputStream does not contain a serialized object ; nested exception is: javax.ejb.EJBException: Internal error getting results for field member userProps Embedded Exception Unable to load to deserialize result: java.io.StreamCorruptedException: InputStream does not contain a serialized object javax.ejb.EJBException: Internal error getting results for field member userProps Embedded Exception Unable to load to deserialize result: java.io.StreamCorruptedException: InputStream does not contain a serialized object at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstra ctCMPFieldBrid ge.java:309) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadInstanceResults(JDBCAbstrac tCMPFieldBrid ge.java:253) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:138 ) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:62) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:409) at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManager.java:380) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java :275) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:189) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:108) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:96) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:167) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:127) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:475) at org.jboss.ejb.Container.invoke(Container.java:668) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:995) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:364) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) at java.lang.Thread.run(Unknown
[JBoss-dev] [JBoss-user] JMS durable Topic subscriptions
If I have a topic with mulitple durable subscriptions and each of these has a message selector. Should the message not be considered delivered if the message is attempted to be delivered but the selector says that the subscriber is not intersted in it? Currently it just seems to stay in the db/jbossmq/file/subscription-id dir indefinately. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Yikes... something is broken....
Anytime I hear connection-manager-factory-loader I pull my gun out. Am I the only one who thinks JCA is over-engineered pompous crappola? KIS (the more stupid the better) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Jencks |Sent: Monday, February 25, 2002 8:05 AM |To: Jason Dillon |Cc: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Yikes... something is broken | | |On 2002.02.24 21:59:38 -0500 Jason Dillon wrote: | looks like some of the njar changes (not sure what) may have gone sour... | | --jason | |I looked at URL and it tries to load the handler with Class.forName and |then the system classloader. | |Does your resource protocol handler get loaded ok? I think we either need |to include these in run.jar or write a jboss handler factory for all our |protocols and set it early in the startup process. Where should it go? | |Or I guess we could make an mbean that we can dynamically add handlers to |from the UnifiedClassLoaders... | |Thanks |david jencks | | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ 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/jaws/jdbc JDBCInitCommand.java
User: danch
Date: 02/02/25 09:18:20
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_4
JDBCInitCommand.java
Log:
made 'table not created' message error rather than debug
Revision ChangesPath
No revision
No revision
1.12.6.6 +182 -172
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCInitCommand.java
Index: JDBCInitCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCInitCommand.java,v
retrieving revision 1.12.6.5
retrieving revision 1.12.6.6
diff -u -r1.12.6.5 -r1.12.6.6
--- JDBCInitCommand.java 9 Dec 2001 00:46:22 - 1.12.6.5
+++ JDBCInitCommand.java 25 Feb 2002 17:18:20 - 1.12.6.6
@@ -1,172 +1,182 @@
-/*
- * JBoss, the OpenSource EJB server
- *
- * Distributable under LGPL license.
- * See terms of license at gnu.org.
- */
-
-package org.jboss.ejb.plugins.jaws.jdbc;
-
-import java.util.Iterator;
-
-import java.sql.Connection;
-import java.sql.PreparedStatement;
-import java.sql.ResultSet;
-import java.sql.SQLException;
-import java.sql.Statement;
-import java.sql.DatabaseMetaData;
-
-
-import org.jboss.ejb.plugins.jaws.JPMInitCommand;
-import org.jboss.ejb.plugins.jaws.metadata.CMPFieldMetaData;
-import org.jboss.ejb.plugins.jaws.metadata.PkFieldMetaData;
-
-/**
- * JAWSPersistenceManager JDBCInitCommand
- *
- * @see related
- * @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
- * @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
- * @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
- * @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @author a href=mailto:[EMAIL PROTECTED];Michel de Groot/a
- * @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
- * @version $Revision: 1.12.6.5 $
- *
- * Revision:
- * 20010621 danch: fixed bug where mapping a PK field to a different column name
- *resulted in an improper PK constraint.
- */
-public class JDBCInitCommand
- extends JDBCUpdateCommand
- implements JPMInitCommand
-{
- // Constructors --
-
- public JDBCInitCommand(JDBCCommandFactory factory)
- {
- super(factory, Init);
-
- // Create table SQL
- String sql = CREATE TABLE + jawsEntity.getTableName() + (;
-
- Iterator it = jawsEntity.getCMPFields();
- boolean first = true;
- while (it.hasNext())
- {
- CMPFieldMetaData cmpField = (CMPFieldMetaData)it.next();
-
- sql += (first ? : ,) +
-cmpField.getColumnName() + +
-cmpField.getSQLType();
-
-
- first = false;
- }
-
- // If there is a primary key field,
- // and the bean has explicitly pk-constrainttrue/pk-constraint in jaws.xml
- // add primary key constraint.
- if (jawsEntity.hasPkConstraint()) {
- sql += ,CONSTRAINT pk+jawsEntity.getTableName()+ PRIMARY KEY (;
- for (Iterator i = jawsEntity.getPkFields();i.hasNext();) {
-String keyCol = ((PkFieldMetaData)i.next()).getColumnName();
-sql += keyCol;
-sql += i.hasNext()?,:;
- }
- sql +=);
- }
-
- sql += );
-
- setSQL(sql);
- }
-
- // JPMInitCommand implementation -
-
- public void execute() throws Exception
- {
- // Create table if necessary
- if (jawsEntity.getCreateTable())
- {
- // first check if the table already exists...
- // (a j2ee spec compatible jdbc driver has to fully
- // implement the DatabaseMetaData)
- boolean created = false;
- Connection con = null;
- ResultSet rs = null;
- try
- {
- con = getConnection();
- DatabaseMetaData dmd = con.getMetaData();
- rs = dmd.getTables(con.getCatalog(), null, jawsEntity.getTableName(),
null);
- if (rs.next ())
-created = true;
-
- rs.close ();
- con.close ();
- }
- catch(Exception e)
- {
-throw e;
- }
- finally
- {
- if(rs != null) try {rs.close(); rs = null;}catch(SQLException e) {}
- if(con != null) try {con.close();con = null;}catch(SQLException e) {}
- }
-
- // Try to create it
- if(created) {
- log.info(Table '+jawsEntity.getTableName()+' already exists);
- } else {
- try
- {
-
- // since we use the pools, we have to do this within a
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/metadata CMPFieldMetaData.java
User: danch
Date: 02/02/25 09:17:39
Modified:src/main/org/jboss/ejb/plugins/jaws/metadata Tag: Branch_2_4
CMPFieldMetaData.java
Log:
made some log messages more informative
Revision ChangesPath
No revision
No revision
1.6.4.3 +523 -516
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/CMPFieldMetaData.java
Index: CMPFieldMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/CMPFieldMetaData.java,v
retrieving revision 1.6.4.2
retrieving revision 1.6.4.3
diff -u -r1.6.4.2 -r1.6.4.3
--- CMPFieldMetaData.java 20 Nov 2001 09:42:51 - 1.6.4.2
+++ CMPFieldMetaData.java 25 Feb 2002 17:17:38 - 1.6.4.3
@@ -1,516 +1,523 @@
-/*
- * JBoss, the OpenSource EJB server
- *
- * Distributable under LGPL license.
- * See terms of license at gnu.org.
- */
-package org.jboss.ejb.plugins.jaws.metadata;
-
-import java.lang.reflect.Field;
-import java.lang.reflect.InvocationTargetException;
-import java.sql.Types;
-import java.util.ArrayList;
-import java.util.Iterator;
-import java.util.StringTokenizer;
-import org.w3c.dom.Element;
-
-import org.jboss.deployment.DeploymentException;
-import org.jboss.metadata.XmlLoadable;
-import org.jboss.metadata.MetaData;
-import org.jboss.metadata.EjbRefMetaData;
-
-import org.jboss.logging.Logger;
-
-/**
- * This class holds all the information jaws needs to know about a CMP field
- * It loads its data from standardjaws.xml and jaws.xml
- *
- * @see related
- * @author a href=[EMAIL PROTECTED]Sebastien Alborini/a
- * @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
- * @author a href=mailto:[EMAIL PROTECTED];Vincent Harcq/a
- * @version $Revision: 1.6.4.2 $
- */
-public class CMPFieldMetaData extends MetaData implements XmlLoadable
-{
- // Constants -
- static Logger log = Logger.getLogger(CMPFieldMetaData.class);
- // Attributes
-
- // the entity this field belongs to
- private JawsEntityMetaData jawsEntity;
-
- // name of the field
- private String name;
-
- // the actual Field in the bean implementation
- private Field field;
-
- // the jdbc type (see java.sql.Types), used in PreparedStatement.setParameter
- private int jdbcType;
- // true if jdbcType has been initialized
- private boolean validJdbcType;
-
- // the sql type, used for table creation.
- private String sqlType;
-
- // the column name in the table
- private String columnName;
-
- private boolean isAPrimaryKeyField;
-
-
- /**
-* We need this for nested field retrieval.
-*/
- private String ejbClassName;
-
- /**
-* We need this for nested fields. We could compute it from ejbClassName on the
fly,
-* but it's faster to set it once and cache it.
-*/
- private Class ejbClass;
-
- /**
-* Is true for fields like data.categoryPK.
-*/
- private boolean isNested;
-
- // Static
-
- // Constructors --
- public CMPFieldMetaData(String name, JawsEntityMetaData jawsEntity) throws
DeploymentException
- {
- this.name = name;
- this.jawsEntity = jawsEntity;
-
- // save the class name for nested fields
- ejbClassName = jawsEntity.getEntity().getEjbClass();
- ejbClassName = jawsEntity.getEntity().getEjbClass();
-
- try
- {
- // save the class for nested fields
- ejbClass =
jawsEntity.getJawsApplication().getClassLoader().loadClass(ejbClassName);
- field = ejbClass.getField(name);
- } catch (ClassNotFoundException e)
- {
- throw new DeploymentException(ejb class not found: + ejbClassName);
- } catch (NoSuchFieldException e)
- {
- // we can't throw an Exception here, because we could have a nested field
- checkField();
- }
-
- // default, may be overridden by importXml
- columnName = getLastComponent(name);
-
- // cannot set defaults for jdbctype/sqltype, type mappings are not loaded yet.
- }
-
-
- // Public
- public String getName()
- { return name; }
-
- public Field getField()
- { return field; }
-
- public int getJDBCType()
- {
- if (! validJdbcType)
- {
- // set the default
- if (field!=null)
-jdbcType =
[JBoss-dev] [ jboss-Change Notes-522530 ] more informative logging
Change Notes item #522530, was opened at 2002-02-25 09:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=522530group_id=22866 Category: JBossCMP Group: v2.4.5 Status: Open Priority: 5 Submitted By: Dan Christopherson (danch) Assigned to: Nobody/Anonymous (nobody) Summary: more informative logging Initial Comment: Added a bit more information to JAWS logging messages in cases of mis-configured beans. Tag Rel_2_4_5_5 -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=522530group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCInitCommand.java
How is it you managed to change every line of these files? Is something wrong in your IDE, or was the file hosed to begin with (and you fixed it)? -dain Dan Christopherson wrote: User: danch Date: 02/02/25 09:18:20 Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_4 JDBCInitCommand.java Log: made 'table not created' message error rather than debug Revision ChangesPath No revision No revision 1.12.6.6 +182 -172 jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCInitCommand.java ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Just bought JMX book
Great job Juha! I talked to the lady at the bookstore and she said that they had 6 copies of the JBoss book on order. It's cool seeing JBoss and you guys in print. This is going to be a great year for jboss. Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] We need more configurations in the distribution
Rather than making less use of the configuration file sets, we need to make more. We should be shipping with at least 3 configs: 1. A minimal config that is just the JMX spine, logging, and JNDI. No ejbs, JAAS security mgr, servlets, etc. 2. A basic J2EE config maybe a little leaner than our current default. 3. A J2EE + web services config. The whole webOS config. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCInitCommand.java
The former. It thoughtfully switched every line end to windoze style for me. Sorry about that. danch Dain Sundstrom wrote: How is it you managed to change every line of these files? Is something wrong in your IDE, or was the file hosed to begin with (and you fixed it)? -dain Dan Christopherson wrote: User: danch Date: 02/02/25 09:18:20 Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_4 JDBCInitCommand.java Log: made 'table not created' message error rather than debug Revision ChangesPath No revision No revision 1.12.6.6 +182 -172 jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCInitCommand.java ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Concrete example of needing the server loader
Here is what I want to do as part of the security unit tests: - Start jboss within Ant with a specified configuration, security manager and policy. The Ant task and security mgr+policy are simple and I have a prototype. The bigger issues is being able to completely specify a config that does not conflict with the default settings. Alternatively, the default config could be started for the standard unit tests, stopped, and then the server config for the security manager tests started. - Stop jboss after the tests. Also a simple custom Ant task I have a prototype of. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test JBossTestServices.java
User: starksm
Date: 02/02/25 11:49:52
Modified:src/main/org/jboss/test JBossTestServices.java
Log:
Do not print out the beancount, iterationcount and threadcount values
in their accessors as if these are as loop bounds the values are
printed N times.
Revision ChangesPath
1.11 +9 -13 jbosstest/src/main/org/jboss/test/JBossTestServices.java
Index: JBossTestServices.java
===
RCS file: /cvsroot/jboss/jbosstest/src/main/org/jboss/test/JBossTestServices.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- JBossTestServices.java29 Jan 2002 21:59:58 - 1.10
+++ JBossTestServices.java25 Feb 2002 19:49:52 - 1.11
@@ -46,7 +46,7 @@
*
* @authora href=mailto:[EMAIL PROTECTED];David Jencks/a
* @authora href=mailto:[EMAIL PROTECTED];Christoph G. Jung/a
- * @version $Revision: 1.10 $
+ * @version $Revision: 1.11 $
*/
public class JBossTestServices
{
@@ -93,6 +93,9 @@
public void setUp() throws Exception
{
log.debug(JBossTestServices.setUp());
+ log.info(jbosstest.beancount: + System.getProperty(jbosstest.beancount));
+ log.info(jbosstest.iterationcount: +
System.getProperty(jbosstest.iterationcount));
+ log.info(jbosstest.threadcount: +
System.getProperty(jbosstest.threadcount));
}
/**
@@ -262,10 +265,8 @@
String deployName = getDeployURL(name);
invoke(getDeployerName(),
deploy,
- new Object[]
- {deployName},
- new String[]
- {java.lang.String});
+ new Object[] {deployName},
+ new String[] {java.lang.String});
setDeployed(deployName);
}
/**
@@ -292,28 +293,23 @@
void flushAuthCache() throws Exception
{
ObjectName jaasMgr = new
ObjectName(jboss.security:name=JaasSecurityManager);
- Object[] params =
- {other};
- String[] signature =
- {java.lang.String};
+ Object[] params = {other};
+ String[] signature = {java.lang.String};
invoke(jaasMgr, flushAuthenticationCache, params, signature);
}
int getThreadCount()
{
- log.info(jbosstest.threadcount: +
System.getProperty(jbosstest.threadcount));
return Integer.getInteger(jbosstest.threadcount,
DEFAULT_THREADCOUNT).intValue();
}
int getIterationCount()
{
- log.info(jbosstest.iterationcount: +
System.getProperty(jbosstest.iterationcount));
return Integer.getInteger(jbosstest.iterationcount,
DEFAULT_ITERATIONCOUNT).intValue();
}
-
+
int getBeanCount()
{
- log.info(jbosstest.beancount: + System.getProperty(jbosstest.beancount));
return Integer.getInteger(jbosstest.beancount,
DEFAULT_BEANCOUNT).intValue();
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Latest HEAD Re-Deployment Broken
I just refreshed my tree again this morning... Re-deploying an EAR that contains a WAR seems broken. The changes in the WAR are not seen until the server is shutdown and restarted... Any idea what broke this? It was working fine on Saturday. Can anyone else confirm this? Hunter ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/hello/ejb HelloBean.java
User: starksm
Date: 02/02/25 12:59:57
Modified:src/main/org/jboss/test/hello/ejb HelloBean.java
Log:
Simplified the test code to get rid of tests that were not used
and convered by other unit tests
Revision ChangesPath
1.4 +5 -105jbosstest/src/main/org/jboss/test/hello/ejb/HelloBean.java
Index: HelloBean.java
===
RCS file: /cvsroot/jboss/jbosstest/src/main/org/jboss/test/hello/ejb/HelloBean.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- HelloBean.java15 Feb 2002 06:15:52 - 1.3
+++ HelloBean.java25 Feb 2002 20:59:57 - 1.4
@@ -4,141 +4,37 @@
*/
package org.jboss.test.hello.ejb;
-import java.io.*;
-import java.util.*;
-import javax.ejb.*;
+import javax.ejb.EJBException;
import org.jboss.test.util.ejb.SessionSupport;
-import org.jboss.test.hello.util.HelloUtil;
import org.jboss.test.hello.interfaces.Hello;
import org.jboss.test.hello.interfaces.HelloData;
/**
*
- * @see related
- * @author $Author: user57 $
- * @version $Revision: 1.3 $
+ * @author [EMAIL PROTECTED]
+ * @version $Revision: 1.4 $
*/
public class HelloBean
extends SessionSupport
{
- // Constants -
-
- // Attributes
-
- // Static
-
- // Constructors --
-
- // Public
public String hello(String name)
{
return Hello +name+!;
}
-
+
public Hello helloHello(Hello hello)
{
return hello;
}
-
+
public String howdy(HelloData name)
{
return Howdy +name.getName()+!;
}
-
- public String sayHello()
- {
- return Hello +sessionCtx.getCallerPrincipal()+!;
- }
-
- public void testSpeed(String name, int iter)
- throws java.rmi.RemoteException
- {
- Hello hello = (Hello)sessionCtx.getEJBObject();
- for (int i = 0; i iter; i++)
- hello.hello(name);
- }
-
- public void doNastyStuff()
- {
- // Try doing not allowed things
- try
- {
- System.getProperty(java.home);
- System.setProperty(java.home,tjo);
-
- throw new EJBException(Property Failed);
- } catch (EJBException e)
- {
- throw e;
- } catch (Exception e)
- {
- }
-
-/*
- try
- {
- new Thread(new Runnable()
-{
- public void run() { log.debug(Running); }
-}).start();
- throw new EJBException(Thread Failed);
- } catch (EJBException e)
- {
- throw e;
- } catch (Exception e)
- {
- }
-*/
- try
- {
- File f = new File(test.txt);
- new FileOutputStream(f).write(Tjosan.getBytes());
-
- throw new EJBException(File Failed);
- } catch (EJBException e)
- {
- throw e;
- } catch (Exception e)
- {
- }
-
- try
- {
- Properties cfg = new Properties();
- cfg.load(new HelloUtil().getResource(test.properties, this));
- log.debug(cfg);
- } catch (EJBException e)
- {
- throw e;
- } catch (Exception e)
- {
- throw new EJBException(e);
- }
- }
-
public void throwException()
{
throw new EJBException(Something went wrong);
}
}
-
-/*
- * $Id: HelloBean.java,v 1.3 2002/02/15 06:15:52 user57 Exp $
- * Currently locked by:$Locker: $
- * Revision:
- * $Log: HelloBean.java,v $
- * Revision 1.3 2002/02/15 06:15:52 user57
- *o replaced most System.out usage with Log4j. should really introduce
- * some base classes to make this mess more maintainable...
- *
- * Revision 1.2 2001/01/07 23:14:39 peter
- * Trying to get JAAS to work within test suite.
- *
- * Revision 1.1.1.1 2000/06/21 15:52:34 oberg
- * Initial import of jBoss test. This module contains CTS tests, some simple
examples, and small bean suites.
- *
- *
- *
- */
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/hello/util HelloUtil.java
User: starksm
Date: 02/02/25 12:59:58
Modified:src/main/org/jboss/test/hello/util HelloUtil.java
Log:
Simplified the test code to get rid of tests that were not used
and convered by other unit tests
Revision ChangesPath
1.3 +2 -14 jbosstest/src/main/org/jboss/test/hello/util/HelloUtil.java
Index: HelloUtil.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/hello/util/HelloUtil.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- HelloUtil.java7 Jan 2001 23:14:40 - 1.2
+++ HelloUtil.java25 Feb 2002 20:59:58 - 1.3
@@ -10,8 +10,8 @@
/**
*
* @see related
- * @author $Author: peter $
- * @version $Revision: 1.2 $
+ * @author $Author: starksm $
+ * @version $Revision: 1.3 $
*/
public class HelloUtil
{
@@ -35,18 +35,3 @@
});
}
}
-
-/*
- * $Id: HelloUtil.java,v 1.2 2001/01/07 23:14:40 peter Exp $
- * Currently locked by:$Locker: $
- * Revision:
- * $Log: HelloUtil.java,v $
- * Revision 1.2 2001/01/07 23:14:40 peter
- * Trying to get JAAS to work within test suite.
- *
- * Revision 1.1.1.1 2000/06/21 15:52:37 oberg
- * Initial import of jBoss test. This module contains CTS tests, some simple
examples, and small bean suites.
- *
- *
- *
- */
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/hello/interfaces Hello.java HelloData.java HelloHome.java
User: starksm
Date: 02/02/25 12:59:58
Modified:src/main/org/jboss/test/hello/interfaces Hello.java
HelloData.java HelloHome.java
Log:
Simplified the test code to get rid of tests that were not used
and convered by other unit tests
Revision ChangesPath
1.3 +8 -39 jbosstest/src/main/org/jboss/test/hello/interfaces/Hello.java
Index: Hello.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/hello/interfaces/Hello.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Hello.java7 Jan 2001 23:14:40 - 1.2
+++ Hello.java25 Feb 2002 20:59:58 - 1.3
@@ -4,60 +4,26 @@
*/
package org.jboss.test.hello.interfaces;
-import java.rmi.*;
-import javax.ejb.*;
+import java.rmi.RemoteException;
+import javax.ejb.EJBObject;
-/**
+/** A simple hello world stateless session bean home
*
- * @see related
- * @author $Author: peter $
- * @version $Revision: 1.2 $
+ * @author [EMAIL PROTECTED]
+ * @version $Revision: 1.3 $
*/
public interface Hello
extends EJBObject
{
- // Constants -
-
- // Attributes
-
- // Static
-
- // Constructors --
-
- // Public
public String hello(String name)
throws RemoteException;
-
+
public Hello helloHello(Hello object)
throws RemoteException;
-
- public String sayHello()
- throws RemoteException;
-
+
public String howdy(HelloData name)
throws RemoteException;
-
- public void testSpeed(String name, int iter)
- throws java.rmi.RemoteException;
-
- public void doNastyStuff()
- throws RemoteException;
-
+
public void throwException()
throws RemoteException;
}
-
-/*
- * $Id: Hello.java,v 1.2 2001/01/07 23:14:40 peter Exp $
- * Currently locked by:$Locker: $
- * Revision:
- * $Log: Hello.java,v $
- * Revision 1.2 2001/01/07 23:14:40 peter
- * Trying to get JAAS to work within test suite.
- *
- * Revision 1.1.1.1 2000/06/21 15:52:34 oberg
- * Initial import of jBoss test. This module contains CTS tests, some simple
examples, and small bean suites.
- *
- *
- *
- */
1.3 +12 -31
jbosstest/src/main/org/jboss/test/hello/interfaces/HelloData.java
Index: HelloData.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/hello/interfaces/HelloData.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- HelloData.java7 Jan 2001 23:14:40 - 1.2
+++ HelloData.java25 Feb 2002 20:59:58 - 1.3
@@ -4,43 +4,21 @@
*/
package org.jboss.test.hello.interfaces;
-import java.rmi.*;
-import javax.ejb.*;
-
-/**
- *
- * @see related
- * @author $Author: peter $
- * @version $Revision: 1.2 $
+/** A serializable data object for testing data passed to an EJB.
+ * @author [EMAIL PROTECTED]
+ * @version $Revision: 1.3 $
*/
public class HelloData
implements java.io.Serializable
{
- // Constants -
-
- // Attributes
- String name;
-
- // Static
+ private String name;
- // Constructors --
-
- // Public
- public String getName() { return name; }
- public void setName(String name) { this.name = name; }
+ public String getName()
+ {
+ return name;
+ }
+ public void setName(String name)
+ {
+ this.name = name;
+ }
}
-
-/*
- * $Id: HelloData.java,v 1.2 2001/01/07 23:14:40 peter Exp $
- * Currently locked by:$Locker: $
- * Revision:
- * $Log: HelloData.java,v $
- * Revision 1.2 2001/01/07 23:14:40 peter
- * Trying to get JAAS to work within test suite.
- *
- * Revision 1.1.1.1 2000/06/21 15:52:34 oberg
- * Initial import of jBoss test. This module contains CTS tests, some simple
examples, and small bean suites.
- *
- *
- *
- */
1.4 +6 -30
jbosstest/src/main/org/jboss/test/hello/interfaces/HelloHome.java
Index: HelloHome.java
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/hello/test HelloTimingStressTestCase.java
User: starksm
Date: 02/02/25 12:59:58
Modified:src/main/org/jboss/test/hello/test
HelloTimingStressTestCase.java
Log:
Simplified the test code to get rid of tests that were not used
and convered by other unit tests
Revision ChangesPath
1.7 +22 -57
jbosstest/src/main/org/jboss/test/hello/test/HelloTimingStressTestCase.java
Index: HelloTimingStressTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/hello/test/HelloTimingStressTestCase.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- HelloTimingStressTestCase.java29 Jan 2002 22:00:02 - 1.6
+++ HelloTimingStressTestCase.java25 Feb 2002 20:59:58 - 1.7
@@ -22,34 +22,33 @@
import org.jboss.test.JBossTestCase;
-/**
- *
- * @see related
- * @author Author: schaefera
- * @version $Revision: 1.6 $
+/** Simple tests of the Hello stateless session bean
+ *
+ * @author [EMAIL PROTECTED]
+ * @version $Revision: 1.7 $
*/
public class HelloTimingStressTestCase
extends JBossTestCase
{
// Constants -
-
+
// Attributes
// Static
static boolean deployed = false;
-
+
// Constructors --
public HelloTimingStressTestCase(String name)
{
- super(name);
+ super(name);
}
// Public
-
+
/**
* Lookup the bean, call it, remove it.
*
-* @exception Exception
+* @exception Exception
*/
public void testHello()
throws Exception
@@ -63,7 +62,7 @@
/**
* Test marshalling of custom data-holders.
*
-* @exception Exception
+* @exception Exception
*/
public void testData()
throws Exception
@@ -79,26 +78,17 @@
/**
* This tests the speed of invocations
*
-* @exception Exception
+* @exception Exception
*/
public void testSpeed()
throws Exception
{
long start = System.currentTimeMillis();
- long start2 = start;
HelloHome home = (HelloHome)getInitialContext().lookup(HelloHome.JNDI_NAME);
Hello hello = home.create();
for (int i = 0 ; i getIterationCount(); i++)
{
- hello.hello(Rickard);
-
- if (i % 100 == 0 i != 0)
- {
-long end = System.currentTimeMillis();
-getLog().debug(Time/call(ms):+((end-start2)/100));
-start2 = end;
- }
-
+ hello.hello(Rickard);
}
long end = System.currentTimeMillis();
getLog().debug(Avg. time/call(ms):+((end-start)/getIterationCount()));
@@ -107,57 +97,33 @@
/**
* This tests the speed of invocations
*
-* @exception Exception
+* @exception Exception
*/
public void testSpeed2()
throws Exception
{
long start = System.currentTimeMillis();
- long start2 = start;
+ long start2 = start;
HelloHome home = (HelloHome)getInitialContext().lookup(HelloHome.JNDI_NAME);
Hello hello = home.create();
for (int i = 0 ; i getIterationCount(); i++)
{
hello.helloHello(hello);
-
- if (i % 100 == 0 i != 0)
- {
-long end = System.currentTimeMillis();
-getLog().debug(Time/call(ms):+((end-start2)/100));
-start2 = end;
- }
}
long end = System.currentTimeMillis();
getLog().debug(Avg. time/call(ms):+((end-start)/getIterationCount()));
}
-
- /**
-* This tests the speed of server-internal invocations
-*
-* @exception Exception
-*/
-/* public void testInternalSpeed()
- throws Exception
- {
- HelloHome home = (HelloHome)getInitialContext().lookup(HelloHome.JNDI_NAME);
- Hello hello = home.create();
-
- long start = System.currentTimeMillis();
- hello.testSpeed(Rickard, getIterationCount());
- long end = System.currentTimeMillis();
- getLog().debug(Avg. time/call(ms):+((end-start)/getIterationCount()));
- }
-*/
+
/**
* This tests the speed of InitialContext lookups
* including getting the initial context.
-* @exception Exception
+* @exception Exception
*/
public void testContextSpeed()
throws Exception
{
long
[JBoss-dev] [ jboss-Bugs-522617 ] Redeploy broken with tmp/deploy changes
Bugs item #522617, was opened at 2002-02-25 12:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=522617group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 7 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Redeploy broken with tmp/deploy changes Initial Comment: With the change to use the original component jar name under the tmp/deploy directory we have regressed back to the ZipFile cache bug. Because the same file name is used for the initial deploy and subsequent deploys the jar contents are cached by the ZipFile under jdk1.3 and redeploy either fails with a java.lang.InternalError jzentry == 0, or the contents are not updated. I also see the same problem under jdk1.4 where I thought this issue was supposed to be fixed. Its simple to produce the problem. Run the org.jboss.test.hello.test.HelloTimingStressTestCase one, change the print statements in the org.jboss.test.hello.ejb.HelloBean class, rerun the HelloTimingStressTestCase and the reploy fails. Two solutions are: 1. Make the orig path name a directory under tmp/deploy and place uniqued jars under the directory. For example: origJar: /test/lib/hello.jar deployJar : jboss.home/tmp/deploy/test/lib/hello.jar/00.hello.jar redeployJar : jboss.home/tmp/deploy/test/lib/hello.jar/01.hello.jar The benefit of this approach is that one can still assign security permissions on a per component jar basis. 2. Only use the orig path upto the last directory. For example: origJar: /test/lib/hello.jar deployJar : jboss.home/tmp/deploy/test/lib/00.hello.jar redeployJar : jboss.home/tmp/deploy/test/lib/01.hello.jar This might be simpler but it limits the ability to set security permissions to the container directory. This is not that big a restriction as this is usually how one does permissions. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=522617group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Tshirts at JavaOne FREE TRAINING
http://www.v-2.org/articles/ayb.html for an explanation, or: http://www.allyourbrand.org/ For a page that thinks(maybe rightfully so) that this phrase has been mimicked WAY too many times. Dain Sundstrom [EMAIL PROTECTED] 2/25/02 2:38:50 PM JBoss: All your J2EE are belong to us Maybe I'm an idiot, but what the hell does this mean? -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Concrete example of needing the server loader
I have been using Ant in my production setup to generate the exact config (copy, touch, link, whatever) needed to run the given JBoss node. You might want to think about copying building an isolated jboss home for the tests (pulled from the build jboss home). For example: jboss-all/build/output/jboss-*/... jboss-all/build/output/test0/... Where there is some ant fluff which copies the proper bits from jboss-* to test0 omitting certain config, adding special test config whatever. This approache has worked really well for me. I have setup 6 classes of jboss node config and use that to start up the 30+ machines we run here, each with a seperate directory space with config pulled from the class type of that node, using filtering to add in node specific config. --jason Scott M Stark wrote: Here is what I want to do as part of the security unit tests: - Start jboss within Ant with a specified configuration, security manager and policy. The Ant task and security mgr+policy are simple and I have a prototype. The bigger issues is being able to completely specify a config that does not conflict with the default settings. Alternatively, the default config could be started for the standard unit tests, stopped, and then the server config for the security manager tests started. - Stop jboss after the tests. Also a simple custom Ant task I have a prototype of. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] We need more configurations in the distribution
Agreed. Did we ever decide on how to reorg things? I think that short term that if we go with Hirams idea of server(s) directory and leave lib, client and bin out on top then we can implement this soon. I like the idea of having a per server config lib dir to keep core libs seperated from examples/plugins and such, but i think it will take a little longer to figure out how to best mod the ServiceLibraries to handle such. --jason Scott M Stark wrote: Rather than making less use of the configuration file sets, we need to make more. We should be shipping with at least 3 configs: 1. A minimal config that is just the JMX spine, logging, and JNDI. No ejbs, JAAS security mgr, servlets, etc. 2. A basic J2EE config maybe a little leaner than our current default. 3. A J2EE + web services config. The whole webOS config. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Just bought JMX book
I picked up a copy early last week too, though I have not had too much time to dig into it yet. So far it looks really good. JMX users of the world thank you... as I might be able to understand ModelMBeans, Notifications and relationships more. Kudos! --jason Bill Burke wrote: Great job Juha! I talked to the lady at the bookstore and she said that they had 6 copies of the JBoss book on order. It's cool seeing JBoss and you guys in print. This is going to be a great year for jboss. Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/deployment DeploymentInfo.java
Not that I have a preference here, but I wanted to add that just because Sun comes up with a standard... doesn't mean that it is the best API available for the job. True it will probably get included into the bloat of other code in the jdk and so it may make sence to use it just because it will be there... but that doesn't really mean it is any good. --jason Dain Sundstrom wrote: JSX looks like the small fish in the sea anyway. I think we should use JaxB, as it will eventually dominate this field. Assuming you can get it to work. -dain David Jencks wrote: On 2002.02.24 22:05:19 -0500 Adam Heath wrote: On Sun, 24 Feb 2002, David Jencks wrote: [snip] JSX seems to work well for us here at work. Might want to check it out. Looks interesting, however I can't see how we could possibly use it: gpl or $$ licensing. david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] We need more configurations in the distribution
That is fine with me. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, February 25, 2002 2:47 PM Subject: Re: [JBoss-dev] We need more configurations in the distribution Agreed. Did we ever decide on how to reorg things? I think that short term that if we go with Hirams idea of server(s) directory and leave lib, client and bin out on top then we can implement this soon. I like the idea of having a per server config lib dir to keep core libs seperated from examples/plugins and such, but i think it will take a little longer to figure out how to best mod the ServiceLibraries to handle such. --jason Scott M Stark wrote: Rather than making less use of the configuration file sets, we need to make more. We should be shipping with at least 3 configs: 1. A minimal config that is just the JMX spine, logging, and JNDI. No ejbs, JAAS security mgr, servlets, etc. 2. A basic J2EE config maybe a little leaner than our current default. 3. A J2EE + web services config. The whole webOS config. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] We need more configurations in the distribution
I thought Marc nixed this idea -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Monday, February 25, 2002 6:29 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] We need more configurations in the distribution That is fine with me. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, February 25, 2002 2:47 PM Subject: Re: [JBoss-dev] We need more configurations in the distribution Agreed. Did we ever decide on how to reorg things? I think that short term that if we go with Hirams idea of server(s) directory and leave lib, client and bin out on top then we can implement this soon. I like the idea of having a per server config lib dir to keep core libs seperated from examples/plugins and such, but i think it will take a little longer to figure out how to best mod the ServiceLibraries to handle such. --jason Scott M Stark wrote: Rather than making less use of the configuration file sets, we need to make more. We should be shipping with at least 3 configs: 1. A minimal config that is just the JMX spine, logging, and JNDI. No ejbs, JAAS security mgr, servlets, etc. 2. A basic J2EE config maybe a little leaner than our current default. 3. A J2EE + web services config. The whole webOS config. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ 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
[JBoss-dev] RE: [JBoss-user] Constructor for JBossMQ ConnectionFactories
Lucas; Just for the record, WebLogic to JBossMQ is not a specific scenario I am trying to support, but rather it is an example of a generic scenario I am trying to support in my framework. I see your points, but it is common and supported practice to serialize ConnectionFactory objects into JNDI. The factory is static and should be configured to produce connections that are valid (conectable) assuming that the JMS server they are configured to connect to is up and running. The location of the JNDI where the ConnectionFactory should be irrelevant. To further this point, see the Java Doc for the parent class fo QueueConnectionFactory (javax.jms.ConnectionFactory) at http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/ConnectionFactory.html Quotes: 1.A ConnectionFactory object encapsulates a set of connection configuration parameters that has been defined by an administrator. A client uses it to create a connection with a JMS provider. 2. A ConnectionFactory object is a JMS administered object. 3. Although the interfaces for administered objects do not explicitly depend on the Java Naming and Directory Interface (JNDI) API, the JMS API establishes the convention that JMS clients find administered objects by looking them up in a JNDI namespace. In summary, for a compliant JMS server, I believe that you shoudl be able to acquire a QueueConnectionFactory (either by construction one, as in my SonicExample, or by looking it up in the JMS server's own JNDI) and serialize into another JNDI (say an LDAP server). Subsequent retrievals of the newly serialized QueueConnectionFactory will deliver an object that should yield up valid connections to the orogonal JMS server that the QueueConnectionFactory was configured to attach to. At least, it works that way with: MQSeries WebLogic SonicMQ Fiorano iBus (Working on more.) //Nicholas --- Lucas McGregor [EMAIL PROTECTED] wrote: So you want to access a Jboss QueueConnectionFactory from weblogic. Just to make sure that I am being clear on the subject (warning, I might sound resundant :-), you cannot serialize a QueueConnectionFactory. What is serialized and registered in the JNDI tree is a handle to the connection factory. This is analogous to a JDBC connection pools, you get access to them via a handle object, a DataSource. You can take the reference to the handle object from the Jboss JNDI registry and register it to the JNDI tree that weblogic is accessing. Now you have two JNDI tree's, each with a reference to a QueueConnectionFactory that is living in the Jboss JVM. Thus, if you shut down the Jboss JVM, you will have stale references in your weblogic JNDI tree. So, by serializing the ConnectionFactory, you are just copying the reference to the QueueConnectionFactory, not the actual factory. Jboss' QueueConnectionFactory is a MBean that Jboss loads in response to lines in your jboss.jcml file. The QueueConnectionFactory API defines no constructors, http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/QueueConnectionFacto ry.html It is up to the vendor to create QueueConnectionFactory as they see fit. They just have to implement the two createQueueConnection() methods. How app servers deal with JMS is very similar to how they deal with JDBC. The actual connections and connection pools are up to the app server and the driver vendor. How your EJB's (MDB's) interact with JMS is defined by the EJB 2.0 standard, but how each vendor implements the creation and management of the resource is not--just like how entity beans are bound to javax.sql.DataSource resources is defined by the EJB spec, but how your app server configures, manages, and runs the JDBC connections that the javax.sql.DataSource represent is not defined. The Sun J2EE Pattern Catalog (requires registration, but it's free) has a Data Accessor Object pattern(http://developer.java.sun.com/developer/restricted/patterns/DataAcce ssObject.html). It is used to isolate the differences between DataSource implementations. maybe you could adapt it to isolate differences in JMS implementations. They might have other patterns in the JDBC arena that might be helpful. http://www.theserverside.com/ has had a lot about JMS and MDB's in the last couple of months, maybe that have something that will help your with your abstraction layer. Good Luck! Lucas McGregor, NovaLogic -Original Message- From: Nicholas [mailto:[EMAIL PROTECTED]] Sent: Monday, February 25, 2002 2:23 PM To: Lucas McGregor Subject: RE: [JBoss-user] Constructor for JBossMQ ConnectionFactories Hmmm..., what I am trying to do, is write a paper that describes how to load JMS connection factories (and JMS Destinations)into AppServer's JNDI. This is so they can be used for deploying and running MDBs. I am also attempting to write a framework which will allow developers to easily incoorporate JMS objects from any
Re: [JBoss-dev] We need more configurations in the distribution
No, he thought David's idea of moving everything to deploy was a bad idea. The suggestion from Hiram was: jboss/ jboss/bin/ jboss/lib/ jboss/client/ jboss/servers/default jboss/servers/default/conf jboss/servers/default/tmp jboss/servers/default/db jboss/servers/default/deploy jboss/servers/minimal jboss/servers/minimal/conf jboss/servers/minimal/tmp jboss/servers/minimal/db jboss/servers/minimal/deploy etc. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, February 25, 2002 3:28 PM Subject: RE: [JBoss-dev] We need more configurations in the distribution I thought Marc nixed this idea -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Monday, February 25, 2002 6:29 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] We need more configurations in the distribution That is fine with me. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-522617 ] Redeploy broken with tmp/deploy changes
Bugs item #522617, was opened at 2002-02-25 12:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=522617group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 7 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Redeploy broken with tmp/deploy changes Initial Comment: With the change to use the original component jar name under the tmp/deploy directory we have regressed back to the ZipFile cache bug. Because the same file name is used for the initial deploy and subsequent deploys the jar contents are cached by the ZipFile under jdk1.3 and redeploy either fails with a java.lang.InternalError jzentry == 0, or the contents are not updated. I also see the same problem under jdk1.4 where I thought this issue was supposed to be fixed. Its simple to produce the problem. Run the org.jboss.test.hello.test.HelloTimingStressTestCase one, change the print statements in the org.jboss.test.hello.ejb.HelloBean class, rerun the HelloTimingStressTestCase and the reploy fails. Two solutions are: 1. Make the orig path name a directory under tmp/deploy and place uniqued jars under the directory. For example: origJar: /test/lib/hello.jar deployJar : jboss.home/tmp/deploy/test/lib/hello.jar/00.hello.jar redeployJar : jboss.home/tmp/deploy/test/lib/hello.jar/01.hello.jar The benefit of this approach is that one can still assign security permissions on a per component jar basis. 2. Only use the orig path upto the last directory. For example: origJar: /test/lib/hello.jar deployJar : jboss.home/tmp/deploy/test/lib/00.hello.jar redeployJar : jboss.home/tmp/deploy/test/lib/01.hello.jar This might be simpler but it limits the ability to set security permissions to the container directory. This is not that big a restriction as this is usually how one does permissions. -- Comment By: David Jencks (d_jencks) Date: 2002-02-25 14:37 Message: Logged In: YES user_id=60525 I'm confused. I find that if I redeploy hello.jar and rerun the tests, I get java.rmi.ServerException: argument type mismatch; nested exception is: java.lang.IllegalArgumentException: argument type mismatch java.lang.IllegalArgumentException: argument type mismatch at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessi... This is with or without implementing solution (1), and with or without changing/recompiling hello.jar. Is this a windows only problem? I think the argument mismatch may be caused by a classloader issue like with calling an ejb from an mbean, but I haven't investigated. Want me to commit suggestion(1) anyway? david jencks -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=522617group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] cvs problems?
Does anyone else see cvs errors like this: Received disconnect from 216.136.171.202: Command terminated on signal 1. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] We need more configurations in the distribution
Anyh objection to use 'server' instead of 'servers'. The singular form lines up better with the other directory names. --jason Scott M Stark wrote: No, he thought David's idea of moving everything to deploy was a bad idea. The suggestion from Hiram was: jboss/ jboss/bin/ jboss/lib/ jboss/client/ jboss/servers/default jboss/servers/default/conf jboss/servers/default/tmp jboss/servers/default/db jboss/servers/default/deploy jboss/servers/minimal jboss/servers/minimal/conf jboss/servers/minimal/tmp jboss/servers/minimal/db jboss/servers/minimal/deploy etc. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, February 25, 2002 3:28 PM Subject: RE: [JBoss-dev] We need more configurations in the distribution I thought Marc nixed this idea -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Monday, February 25, 2002 6:29 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] We need more configurations in the distribution That is fine with me. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/deployment DeploymentInfo.java MainDeployer.java
User: d_jencks
Date: 02/02/25 16:22:55
Modified:src/main/org/jboss/deployment DeploymentInfo.java
MainDeployer.java
Log:
changed to copy into unique jars. IMPORTANT NOTE: delete everything in
JBOSS_HOME/tmp/deploy or you will have conflicts with the previous copying scheme
Revision ChangesPath
1.2 +10 -7 jboss-system/src/main/org/jboss/deployment/DeploymentInfo.java
Index: DeploymentInfo.java
===
RCS file:
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/DeploymentInfo.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- DeploymentInfo.java 24 Feb 2002 10:24:33 - 1.1
+++ DeploymentInfo.java 26 Feb 2002 00:22:55 - 1.2
@@ -53,7 +53,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Daniel Schulze/a
* @author a href=mailto:[EMAIL PROTECTED];Christoph G. Jung/a
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
- * @version $Revision: 1.1 $ p
+ * @version $Revision: 1.2 $ p
*
* b20011211 marc fleury:/b
* ul
@@ -168,12 +168,7 @@
if (parent != null) parent.subDeployments.add(this);
// The short name for the deployment http://myserver/mybean.ear should
yield mybean.ear
- shortName = url.getFile();
-
- if (shortName.endsWith(/)) shortName = shortName.substring(0,
shortName.length() - 1);
-
- shortName = shortName.substring(shortName.lastIndexOf(/) + 1);
-
+ shortName = getShortName(url.getFile());
// Do we have an XML descriptor only deployment?
isXML = shortName.toLowerCase().endsWith(xml);
@@ -280,5 +275,13 @@
public String toString()
{
return super.toString() + { url= + url + };
+ }
+
+ public static String getShortName(String name)
+ {
+ if (name.endsWith(/)) name = name.substring(0, name.length() - 1);
+
+ name = name.substring(name.lastIndexOf(/) + 1);
+ return name;
}
}
1.7 +23 -1 jboss-system/src/main/org/jboss/deployment/MainDeployer.java
Index: MainDeployer.java
===
RCS file:
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/MainDeployer.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- MainDeployer.java 25 Feb 2002 13:52:31 - 1.6
+++ MainDeployer.java 26 Feb 2002 00:22:55 - 1.7
@@ -47,7 +47,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
- * @version $Revision: 1.6 $
+ * @version $Revision: 1.7 $
*/
public class MainDeployer
extends ServiceMBeanSupport
@@ -252,6 +252,24 @@
// Stop auto deploy thread
running = false;
}
+
+ protected void destroyService()
+ {
+ //undeploy everything in sight
+
+ for (Iterator i = listDeployed().iterator(); i.hasNext(); )
+ {
+ try
+ {
+removeDeployment((DeploymentInfo)i.next()).cleanup(log);
+ }
+ catch (Exception e)
+ {
+log.info(exception trying to undeploy during shutdown: , e);
+ } // end of try-catch
+
+ } // end of for ()
+ }
public boolean getScan()
{
@@ -1067,6 +1085,8 @@
path.deleteCharAt(i);
} // end of if ()
} // end of for ()
+String shortName = DeploymentInfo.getShortName(path.toString());
+ path.append(/).append(getNextID()).append(.).append(shortName);
sdi.localUrl = new File(tempDir, path.toString()).toURL();
copy(sdi.url, sdi.localUrl);
}
@@ -1074,6 +1094,8 @@
catch (Exception e)
{
log.error(Could not make local copy for +sdi.url.toString(), e);
+ log.error(if you have just upgraded jboss versions, please delete);
+ log.error( everything in the $JBOSS_HOME/tmp/deploy and try again);
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [JBoss-user] Constructor for JBossMQ ConnectionFactories
I am sorry, I guess I was not being clear. I thought you were asking my question is, if I need to construct a JBossMQ QueueConnectionFactory and load it into WebLogic's JNDI so I can drive a WebLogic MDB off a JBossMQ queue, how do I create it ? I gave you the answer. You can create a JBossMQ QueueConnectionFactory by putting the proper lines in your jboss.jcml. Jboss creates the QueueConnectionFactory and registers it with it's registry. Hmmm..., what I am trying to do, is write a paper that describes how to load JMS connection factories (and JMS Destinations)into AppServer's JNDI. This is so they can be used for deploying and running MDBs. I am also attempting to write a framework which will allow developers to easily incoorporate JMS objects from any vendor. From your follow up, I thought you were asking is there any generic way to create JMS ConnectionFactories, or at least to make them available from one app server to another (presumably for loose coupling of objects across app servers). All that I am saying is that the JMS ConnectionFactories are vendor specific. There is no defined constructor. So there is no generic way to create a ConnectionFactory object. This is a common issue for code that uses JDBC connections and JDBC connection pools. So in cases where you need a common interface for managing, accessing, or creating JDBC pools, people can use the Data Accessor pattern. If you want a common object that can handle the vendor specific instantiation of ConnectionFactories, then you might find this pattern a helpful starting point. As for the serialization of the ConnectionFactory, I guess I was being ambiguous by stating that you cannot serialize the ConnectionFactory. You can serialize the ConnectionFactory administrative object. But the actual factory that makes the connections may or may not be serialized--it too is implementation specific. The ConnectionFactory administrative object that you retrieve out of the JNDI tree is analogous to the javax.sql.Datasource object. It contains the data to fetch a connection for you. It may create a new connection, it may access a connection pool, it may contact a remote connection factory. In any case, The point is that if you take a ConnectionFactory object from one App Servers registry and register it with another, you are only guaranteed to have two copies of the ConnectionFactory. This may or may not give you the behavior you are looking for. For instance, in the Case of the Joram JMS server with the Jonas EJB server, Joram can live in the same JVM as Jonas. It creates a ConnectionFactory object and registers it with the local Registry. The ConnectionFactory object contains data to utilize the Joram connection factory which lives in the Joram JVM and creates and pools connections. If you serialize the ConnectionFactory object and put it another registry, you now have two copies of an object that will utilize the same connection factory object maintained in the Joram JVM. For example, if you start up another Jonas EJB server and copy over the ConnectionFactory object to it, both of the ConnectionFactories will utilize the connection factory in the original JVM that is running Joram. So if you shutdown the first JVM, your second will now have a ConnectionFactory that will no longer be able to fetch new connections. So, in this case, you cannot serialize the connection factory that the ConnectionFactories depend upon. It is compliant with the JMS specifications. It is just something that you have to be aware of. I hope that you find what information I am able to provide helpful, and I hope that I have clarified any ambiguities, Lucas McGregor, NovaLogic. -Original Message- From: Nicholas [mailto:[EMAIL PROTECTED]] Sent: Monday, February 25, 2002 3:35 PM To: Lucas McGregor Cc: [EMAIL PROTECTED] Subject: RE: [JBoss-user] Constructor for JBossMQ ConnectionFactories Lucas; Just for the record, WebLogic to JBossMQ is not a specific scenario I am trying to support, but rather it is an example of a generic scenario I am trying to support in my framework. I see your points, but it is common and supported practice to serialize ConnectionFactory objects into JNDI. The factory is static and should be configured to produce connections that are valid (conectable) assuming that the JMS server they are configured to connect to is up and running. The location of the JNDI where the ConnectionFactory should be irrelevant. To further this point, see the Java Doc for the parent class fo QueueConnectionFactory (javax.jms.ConnectionFactory) at http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/ConnectionFactory.ht ml Quotes: 1.A ConnectionFactory object encapsulates a set of connection configuration parameters that has been defined by an administrator. A client uses it to create a connection with a JMS provider. 2. A ConnectionFactory object is a JMS administered object. 3. Although the interfaces for administered
[JBoss-dev] Security problem in authentication model.
There is a problem with the use of ThreadLocals to record Authentication when the client (in this case Jetty) is using ThreadPools. I have previously mentioned this, but now I have confirmation that it is a problem for a Client. He created a small thread pool for the listener (4 threads), then used 4 browsers to hit authenticated pages and authenticated with a different user for each browser. The effect of this was for the JBoss authentication mechanism to create ThreadLocal authentications for each of these threads. He then got new browsers and started hitting unauthenticated pages that reported the request and EJB auth details. These new requests receive random EJB authentication depending on which thread from the thread pool they are allocated: 23:33:25,434 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=comercial 23:33:25,464 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=comercial 23:33:38,333 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:33:38,373 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:34:46,341 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:34:46,371 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:34:57,186 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=admin 23:34:57,236 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=admin We need a mechanism to unauthenticate Threads, so the Jetty can call this after each request. Note that it is not an option to get rid of the ThreadPool as that would be a HUGE performance hit. regards -- Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-522617 ] Redeploy broken with tmp/deploy changes
Bugs item #522617, was opened at 2002-02-25 12:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=522617group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 7 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Redeploy broken with tmp/deploy changes Initial Comment: With the change to use the original component jar name under the tmp/deploy directory we have regressed back to the ZipFile cache bug. Because the same file name is used for the initial deploy and subsequent deploys the jar contents are cached by the ZipFile under jdk1.3 and redeploy either fails with a java.lang.InternalError jzentry == 0, or the contents are not updated. I also see the same problem under jdk1.4 where I thought this issue was supposed to be fixed. Its simple to produce the problem. Run the org.jboss.test.hello.test.HelloTimingStressTestCase one, change the print statements in the org.jboss.test.hello.ejb.HelloBean class, rerun the HelloTimingStressTestCase and the reploy fails. Two solutions are: 1. Make the orig path name a directory under tmp/deploy and place uniqued jars under the directory. For example: origJar: /test/lib/hello.jar deployJar : jboss.home/tmp/deploy/test/lib/hello.jar/00.hello.jar redeployJar : jboss.home/tmp/deploy/test/lib/hello.jar/01.hello.jar The benefit of this approach is that one can still assign security permissions on a per component jar basis. 2. Only use the orig path upto the last directory. For example: origJar: /test/lib/hello.jar deployJar : jboss.home/tmp/deploy/test/lib/00.hello.jar redeployJar : jboss.home/tmp/deploy/test/lib/01.hello.jar This might be simpler but it limits the ability to set security permissions to the container directory. This is not that big a restriction as this is usually how one does permissions. -- Comment By: Scott M Stark (starksm) Date: 2002-02-25 15:01 Message: Logged In: YES user_id=175228 I see the same thing on win2k if I rerun without modifying the hello.jar so I think that issue is a seperate class loader problem. Comitting the name change will fix the jar caching problem and then we can move on to why the straight redeploy fails. -- Comment By: David Jencks (d_jencks) Date: 2002-02-25 14:37 Message: Logged In: YES user_id=60525 I'm confused. I find that if I redeploy hello.jar and rerun the tests, I get java.rmi.ServerException: argument type mismatch; nested exception is: java.lang.IllegalArgumentException: argument type mismatch java.lang.IllegalArgumentException: argument type mismatch at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessi... This is with or without implementing solution (1), and with or without changing/recompiling hello.jar. Is this a windows only problem? I think the argument mismatch may be caused by a classloader issue like with calling an ejb from an mbean, but I haven't investigated. Want me to commit suggestion(1) anyway? david jencks -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=522617group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] MainDeployer verbosity...
Why did main deployer all of a sudden become super verbose? The infromation that we need to get across to users/admins is this is deploying and/or this was deployed... the rest is just debug noise and makes difficult to can the logs and see what was deployed. Can we please revert back to a terse MD. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Tshirts at JavaOne FREE TRAINING
OK we have a winner, well actually we have two. JBoss: All your J2EE are belong to us JBoss: May the source be with you Thanks for all the great proposals. We chose based on we won and went with classic stuff. So we put an order for 1000 of them, which is going to cost us AN ARM AND A LEG and take a bulky 21 boxes space that we need a truck to move. You guys better show up and buy them. WE WILL TIE IN A RAFFLE: BUY A T-SHIRT, AND GET A FREE SPOT AT A JBOSS GROUP TRAINING. Buy a t-shirt, give us your b-card, and we will pick a winner on wednesday night, you get a free training with the gurus ($3500 cost). For those that can't come to JBoss One, if you give us a bulk order of 10 + shipping ($230) then we will put you in the raffle but the order needs to reach us before the end of the JB1 conference when we will pick a winner, so you basically have a month to put the order. We will put the information online but basically write to a href=mailto:[EMAIL PROTECTED]?subject=10 tshirts pleasesales/a and when we get your paypal payment we will send it. You will join the raffle. We will put this online. BTW for the raffle it is ONE card PER tshirt. So if you buy 10 t-shirts you multiply your chances by 10. Is this as good as it gets? take care see you there, marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Tshirts at JavaOne FREE TRAINING
[Hunter Hillegas] For those unable to attend, but that don't care about the raffle (or don't want to order 10), will the shirts be available any other way? better yet, can the images be published or put on cafepress? It'd just be zero hassle for the jboss group - if there's some money loss involved (like the group would make $4 off each sale) then just jack up the cafepress price appropriately. I'm all drooling over the first slogan :) -- James Manning [EMAIL PROTECTED] GPG Key fingerprint = B913 2FBD 14A9 CE18 B2B7 9C8E A0BF B026 EEBB F6E4 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Tshirts at JavaOne FREE TRAINING
JBoss: All your J2EE are belong to us Maybe I'm an idiot, but what the hell does this mean? -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [JBoss-user] Tshirts at JavaOne FREE TRAINING
On 02-02-26 0:17, marc fleury [EMAIL PROTECTED] wrote: OK we have a winner, well actually we have two. JBoss: All your J2EE are belong to us JBoss: May the source be with you Thanks for all the great proposals. We chose based on we won and went with classic stuff. So we put an order for 1000 of them, which is going to cost us AN ARM AND A LEG and take a bulky 21 boxes space that we need a truck to move. You guys better show up and buy them. WE WILL TIE IN A RAFFLE: BUY A T-SHIRT, AND GET A FREE SPOT AT A JBOSS GROUP TRAINING. Buy a t-shirt, give us your b-card, and we will pick a winner on wednesday night, you get a free training with the gurus ($3500 cost). For those that can't come to JBoss One, if you give us a bulk order of 10 + shipping ($230) then we will put you in the raffle but the order needs to reach us before the end of the JB1 conference when we will pick a winner, so you basically have a month to put the order. We will put the information online but basically write to a href=mailto:[EMAIL PROTECTED]?subject=10 tshirts pleasesales/a and when we get your paypal payment we will send it. You will join the raffle. We will put this online. BTW for the raffle it is ONE card PER tshirt. So if you buy 10 t-shirts you multiply your chances by 10. Is this as good as it gets? take care see you there, marcf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user What... Do you mean that I've to buy 10 t-shirts... Holy shit - you are a business man ;) I would like one or two... 10 t-shirts... She will think I'm totally out of my mind if I buy 10 equal t-shirts... /Lennart Sent using the Entourage X Test Drive. ___ 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
It's a reference to a videogame port with really bad translation of the words into English... The original quote is something like All Your Base Are Belong To Us. http://www.allyourbase.net/ Hunter From: Dain Sundstrom [EMAIL PROTECTED] Date: Mon, 25 Feb 2002 15:38:50 -0600 To: marc fleury [EMAIL PROTECTED] Cc: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED], Jboss-User@Lists. Sourceforge. Net [EMAIL PROTECTED] Subject: [JBoss-user] Re: [JBoss-dev] Tshirts at JavaOne FREE TRAINING JBoss: All your J2EE are belong to us Maybe I'm an idiot, but what the hell does this mean? -dain ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Tshirts at JavaOne FREE TRAINING
It's kinda late... but what about stickers? I would put one on my car and motorcycle... I would guess that others would too... --jason marc fleury wrote: OK we have a winner, well actually we have two. JBoss: All your J2EE are belong to us JBoss: May the source be with you Thanks for all the great proposals. We chose based on we won and went with classic stuff. So we put an order for 1000 of them, which is going to cost us AN ARM AND A LEG and take a bulky 21 boxes space that we need a truck to move. You guys better show up and buy them. WE WILL TIE IN A RAFFLE: BUY A T-SHIRT, AND GET A FREE SPOT AT A JBOSS GROUP TRAINING. Buy a t-shirt, give us your b-card, and we will pick a winner on wednesday night, you get a free training with the gurus ($3500 cost). For those that can't come to JBoss One, if you give us a bulk order of 10 + shipping ($230) then we will put you in the raffle but the order needs to reach us before the end of the JB1 conference when we will pick a winner, so you basically have a month to put the order. We will put the information online but basically write to a href=mailto:[EMAIL PROTECTED]?subject=10 tshirts pleasesales/a and when we get your paypal payment we will send it. You will join the raffle. We will put this online. BTW for the raffle it is ONE card PER tshirt. So if you buy 10 t-shirts you multiply your chances by 10. Is this as good as it gets? take care see you there, marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Security problem in authentication model.
Yeah that is a serious problem, we need Session based authentication. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Greg |Wilkins |Sent: Monday, February 25, 2002 4:31 PM |To: [EMAIL PROTECTED]; jules |Subject: [JBoss-dev] Security problem in authentication model. | | | |There is a problem with the use of ThreadLocals to record Authentication |when the client (in this case Jetty) is using ThreadPools. | |I have previously mentioned this, but now I have confirmation that it is |a problem for a Client. | |He created a small thread pool for the listener (4 threads), then |used 4 browsers to hit authenticated pages and authenticated |with a different user for each browser. | |The effect of this was for the JBoss authentication mechanism to |create ThreadLocal authentications for each of these threads. | |He then got new browsers and started hitting unauthenticated |pages that reported the request and EJB auth details. These |new requests receive random EJB authentication depending on |which thread from the thread pool they are allocated: | | 23:33:25,434 INFO [Default] request.getUserPrincipal=null; | ctx.getCallerPrincipal().getName()=comercial | 23:33:25,464 INFO [Default] request.getUserPrincipal=null; | ctx.getCallerPrincipal().getName()=comercial | 23:33:38,333 INFO [Default] request.getUserPrincipal=null; | ctx.getCallerPrincipal().getName()=cliente | 23:33:38,373 INFO [Default] request.getUserPrincipal=null; | ctx.getCallerPrincipal().getName()=cliente | 23:34:46,341 INFO [Default] request.getUserPrincipal=null; | ctx.getCallerPrincipal().getName()=cliente | 23:34:46,371 INFO [Default] request.getUserPrincipal=null; | ctx.getCallerPrincipal().getName()=cliente | 23:34:57,186 INFO [Default] request.getUserPrincipal=null; | ctx.getCallerPrincipal().getName()=admin | 23:34:57,236 INFO [Default] request.getUserPrincipal=null; | ctx.getCallerPrincipal().getName()=admin | | |We need a mechanism to unauthenticate Threads, so the Jetty can |call this after each request. | |Note that it is not an option to get rid of the ThreadPool as that |would be a HUGE performance hit. | | |regards | | |-- |Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 |Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 |http://www.mortbay.com AU Phone: +61-(0)2 98107029 | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-common/src/main/org/jboss/net/protocol/njar Handler.java NestedJarURLHandlerFactory.java
User: user57 Date: 02/02/25 17:28:37 Modified:src/main/org/jboss/net/protocol/njar Handler.java Removed: src/main/org/jboss/net/protocol/njar NestedJarURLHandlerFactory.java Log: o Adding factory that will load handlers from org.jboss.net.protocol as it appears that the URL version won't work with our custom class loading Revision ChangesPath 1.2 +3 -4 jboss-common/src/main/org/jboss/net/protocol/njar/Handler.java Index: Handler.java === RCS file: /cvsroot/jboss/jboss-common/src/main/org/jboss/net/protocol/njar/Handler.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Handler.java 25 Feb 2002 02:29:42 - 1.1 +++ Handler.java 26 Feb 2002 01:28:37 - 1.2 @@ -26,7 +26,7 @@ import java.util.Map; /** - * A protocol handler for the 'njar' protocol. + * A protocol handler for the n(ested)jar protocol. * * p * This is class allows you to use the njar: URL protocol. It is very @@ -37,9 +37,8 @@ * An example of how to use this class is: * pre * - *NestedJarURLHandlerFactory.start(); - *URL u = new URL(njar:njar:file:c:/test1.zip^/test2.zip^/hello.txt); - *u.openStream(); + *URL url = new URL(njar:njar:file:c:/test1.zip^/test2.zip^/hello.txt); + *url.openStream(); * * /pre * @@ -51,7 +50,7 @@ * p * TODO: Add accessors so that the cache can be flushed. * - * @version tt$Revision: 1.1 $/tt + * @version tt$Revision: 1.2 $/tt * @author a href=mailto:[EMAIL PROTECTED];Hiram Chirino/a */ public class Handler ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-common/src/main/org/jboss/net/protocol URLStreamHandlerFactory.java package.html
User: user57
Date: 02/02/25 17:28:37
Added: src/main/org/jboss/net/protocol URLStreamHandlerFactory.java
package.html
Log:
o Adding factory that will load handlers from org.jboss.net.protocol
as it appears that the URL version won't work with our custom class loading
Revision ChangesPath
1.1
jboss-common/src/main/org/jboss/net/protocol/URLStreamHandlerFactory.java
Index: URLStreamHandlerFactory.java
===
/***
* *
* JBoss: The OpenSource J2EE WebOS *
* *
* Distributable under LGPL license. *
* See terms of license at gnu.org. *
* *
***/
package org.jboss.net.protocol;
import java.net.URLStreamHandler;
/**
* A factory for loading JBoss specific protocols. This is based
* on Sun's URL mechanism, in that ttHandler/tt classes will be
* looked for in the ttorg.jboss.net.protocol/tt.
*
* pThis factory is installed by the default server implementaion
*as it appears that our custom class loading disallows the
*default URL logic to function when setting the
*ttjava.protocol.handler.pkgs/tt system property.
*
* @version tt$Revision: 1.1 $/tt
* @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
*/
public class URLStreamHandlerFactory
implements java.net.URLStreamHandlerFactory
{
/** The package prefix where JBoss protocol handlers live. */
public static final String PACKAGE_PREFIX = org.jboss.net.protocol;
/**
* Returns the Stream Handler.
*
* @param protocolThe protocol to use
* @returnThe protocol handler or null if not found
*/
public URLStreamHandler createURLStreamHandler(final String protocol)
{
URLStreamHandler handler = null;
try {
String classname = PACKAGE_PREFIX + . + protocol + .Handler;
Class type = null;
try {
type = Class.forName(classname);
}
catch (ClassNotFoundException e) {
ClassLoader cl = ClassLoader.getSystemClassLoader();
if (cl != null) {
type = cl.loadClass(classname);
}
}
if (type != null) {
handler = (URLStreamHandler)type.newInstance();
}
}
catch (Exception ignore) {}
return handler;
}
}
1.1 jboss-common/src/main/org/jboss/net/protocol/package.html
Index: package.html
===
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
html
head
!-- $Id: package.html,v 1.1 2002/02/26 01:28:37 user57 Exp $ --
!--
JBoss: The OpenSource J2EE WebOS
Distributable under LGPL license.
See terms of license at gnu.org.
--
/head
body bgcolor=white
pURL protocol stream helpers.
h2Package Specification/h2
ul
lia href=javascript: alert('not available')Not Available/a
/ul
h2Related Documentation/h2
ul
lia href=javascript: alert('not available')Not Available/a
/ul
h2Package Status/h2
ul
lifont color=greenbSTABLE/b/font
/ul
h2Todo/h2
ul
li???
/ul
!-- Put @see and @since tags down here. --
/body
/html
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-common/src/main/org/jboss/net/protocol/nestedjar NestedJarURLHandlerFactory.java
User: user57
Date: 02/02/25 17:28:37
Modified:src/main/org/jboss/net/protocol/nestedjar
NestedJarURLHandlerFactory.java
Log:
o Adding factory that will load handlers from org.jboss.net.protocol
as it appears that the URL version won't work with our custom class loading
Revision ChangesPath
1.4 +2 -0
jboss-common/src/main/org/jboss/net/protocol/nestedjar/NestedJarURLHandlerFactory.java
Index: NestedJarURLHandlerFactory.java
===
RCS file:
/cvsroot/jboss/jboss-common/src/main/org/jboss/net/protocol/nestedjar/NestedJarURLHandlerFactory.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- NestedJarURLHandlerFactory.java 25 Feb 2002 05:27:26 - 1.3
+++ NestedJarURLHandlerFactory.java 26 Feb 2002 01:28:37 - 1.4
@@ -66,6 +66,8 @@
*/
protected URLConnection openConnection(URL u) throws IOException
{
+ System.out.println(Using old factory style n(ested)jar protocol...);
+
String file = u.getFile();
String embeddedURL = file;
String jarPath = ;
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/system/server ServerImpl.java ServerInfo.java ServerInfoMBean.java
User: user57
Date: 02/02/25 17:36:24
Modified:src/main/org/jboss/system/server ServerImpl.java
ServerInfo.java ServerInfoMBean.java
Log:
o Added getProperty() to ServerInfo (easy acess to a sys prop w/o
having to search through showProp* output)
o ServerImpl uses org.jboss.net.protocol.URLStreamHandlerFactory
instead of setting system prop
Revision ChangesPath
1.3 +2 -7 jboss-system/src/main/org/jboss/system/server/ServerImpl.java
Index: ServerImpl.java
===
RCS file:
/cvsroot/jboss/jboss-system/src/main/org/jboss/system/server/ServerImpl.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ServerImpl.java 24 Feb 2002 10:24:34 - 1.2
+++ ServerImpl.java 26 Feb 2002 01:36:24 - 1.3
@@ -44,7 +44,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
public class ServerImpl
implements ServerImplMBean
@@ -110,12 +110,7 @@
log.info(JBoss Release: + jbossPackage.getImplementationTitle());
// Setup JBoss URL handlers
- String handlerPkgs = System.getProperty(java.protocol.handler.pkgs, null);
- if (handlerPkgs == null)
- handlerPkgs = org.jboss.net.protocol;
- else
- handlerPkgs += :org.jboss.net.protocol;
- System.setProperty(java.protocol.handler.pkgs, handlerPkgs );
+ URL.setURLStreamHandlerFactory(new
org.jboss.net.protocol.URLStreamHandlerFactory());
// create a new config object from the give properties
this.config = new ServerConfigImpl(props);
1.2 +12 -3 jboss-system/src/main/org/jboss/system/server/ServerInfo.java
Index: ServerInfo.java
===
RCS file:
/cvsroot/jboss/jboss-system/src/main/org/jboss/system/server/ServerInfo.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ServerInfo.java 24 Feb 2002 10:24:34 - 1.1
+++ ServerInfo.java 26 Feb 2002 01:36:24 - 1.2
@@ -31,7 +31,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Hiram Chirino/a
* @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public class ServerInfo
implements ServerInfoMBean, MBeanRegistration
@@ -255,8 +255,17 @@
info.append(/pre\n);
}
- /** Return a Map of System.getProperties() with a toString implementation
-*that provides an html table of the key/value pairs
+ /**
+* Get a single system property.
+*/
+ public String getProperty(String name)
+ {
+ return System.getProperty(name);
+ }
+
+ /**
+* Return a Map of System.getProperties() with a toString implementation
+* that provides an html table of the key/value pairs
*/
public Map showProperties()
{
1.2 +7 -2
jboss-system/src/main/org/jboss/system/server/ServerInfoMBean.java
Index: ServerInfoMBean.java
===
RCS file:
/cvsroot/jboss/jboss-system/src/main/org/jboss/system/server/ServerInfoMBean.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ServerInfoMBean.java 24 Feb 2002 10:24:34 - 1.1
+++ ServerInfoMBean.java 26 Feb 2002 01:36:24 - 1.2
@@ -23,7 +23,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public interface ServerInfoMBean
{
@@ -50,7 +50,7 @@
* Return a listing of the active threads and thread groups.
*/
String listThreadDump();
-
+
/**
* Display the java.lang.Package info for the pkgName
*/
@@ -63,6 +63,11 @@
* @return a simple html report of this information
*/
String displayInfoForClass(String className);
+
+ /**
+* Get a single system property.
+*/
+ String getProperty(String name);
/**
* Return a Map of System.getProperties() with a toString implementation
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-common/src/main/org/jboss/net/protocol/nestedjar NestedJarURLHandlerFactory.java
User: user57 Date: 02/02/25 17:37:21 Removed: src/main/org/jboss/net/protocol/nestedjar NestedJarURLHandlerFactory.java Log: o remove nestedjar stuff again, should work by default now o added warn log around njar usage to show any protocol exceptions that are thrown ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/deployment MainDeployer.java
User: user57
Date: 02/02/25 17:37:21
Modified:src/main/org/jboss/deployment MainDeployer.java
Log:
o remove nestedjar stuff again, should work by default now
o added warn log around njar usage to show any protocol exceptions
that are thrown
Revision ChangesPath
1.8 +3 -5 jboss-system/src/main/org/jboss/deployment/MainDeployer.java
Index: MainDeployer.java
===
RCS file:
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/MainDeployer.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- MainDeployer.java 26 Feb 2002 00:22:55 - 1.7
+++ MainDeployer.java 26 Feb 2002 01:37:21 - 1.8
@@ -47,16 +47,12 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
- * @version $Revision: 1.7 $
+ * @version $Revision: 1.8 $
*/
public class MainDeployer
extends ServiceMBeanSupport
implements MainDeployerMBean, Runnable
{
-
- //So it's a hack, at least it works
- { org.jboss.net.protocol.nestedjar.NestedJarURLHandlerFactory.start(); }
-
/** Deployers **/
private final Set deployers = new HashSet();
@@ -872,6 +868,8 @@
}
catch (Exception e)
{
+ log.warn(operation failed; ignoring, e);
+
//maybe this is not a jar nor a directory...
log.info(deploying non-jar/xml file: + di.url);
return;
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] njar (and other jboss specific protocol handlers) usage fixed
Looks like the default URL system doesn't work too well with our custom class loading stuff... so I implemented a factory that does the same thing that would happened if our classes were on the system cl and we set the pkgs prop. ServerImpl installs this factory now instead of setting the sys prop. Sorry I didn't catch this before, but I assumed it was working because I did not see any MalformedURLExcpetions (which were masked by MainDeployer). SHould work now, let me know if there are any other strange problems. BTW, this *should* work for other handlers which are not in the jboss-common.jar as long as they are in the org.jboss.net.protocol package and have a public Handler class with a default or public no-args constructor. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Security problem in authentication model.
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 Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Greg Wilkins [EMAIL PROTECTED] To: [EMAIL PROTECTED]; jules [EMAIL PROTECTED] Sent: Monday, February 25, 2002 4:30 PM Subject: [JBoss-dev] Security problem in authentication model. There is a problem with the use of ThreadLocals to record Authentication when the client (in this case Jetty) is using ThreadPools. I have previously mentioned this, but now I have confirmation that it is a problem for a Client. He created a small thread pool for the listener (4 threads), then used 4 browsers to hit authenticated pages and authenticated with a different user for each browser. The effect of this was for the JBoss authentication mechanism to create ThreadLocal authentications for each of these threads. He then got new browsers and started hitting unauthenticated pages that reported the request and EJB auth details. These new requests receive random EJB authentication depending on which thread from the thread pool they are allocated: 23:33:25,434 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=comercial 23:33:25,464 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=comercial 23:33:38,333 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:33:38,373 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:34:46,341 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:34:46,371 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:34:57,186 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=admin 23:34:57,236 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=admin We need a mechanism to unauthenticate Threads, so the Jetty can call this after each request. Note that it is not an option to get rid of the ThreadPool as that would be a HUGE performance hit. regards -- Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/javax/management ObjectName.java
User: squirest
Date: 02/02/25 17:56:55
Modified:src/main/javax/management ObjectName.java
Log:
small improvement to equals method
Revision ChangesPath
1.8 +12 -6 jmx/src/main/javax/management/ObjectName.java
Index: ObjectName.java
===
RCS file: /cvsroot/jboss/jmx/src/main/javax/management/ObjectName.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ObjectName.java 22 Feb 2002 20:41:41 - 1.7
+++ ObjectName.java 26 Feb 2002 01:56:54 - 1.8
@@ -19,7 +19,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Juha Lindfors/a.
* @author a href=mailto:[EMAIL PROTECTED];Trevor Squires/a.
- * @version $Revision: 1.7 $
+ * @version $Revision: 1.8 $
*
*/
public class ObjectName implements java.io.Serializable
@@ -89,13 +89,19 @@
// Public --
public boolean equals(Object object)
{
- if (!(object instanceof ObjectName))
- return false;
+ if (object == this)
+ {
+ return true;
+ }
- ObjectName oname = (ObjectName) object;
+ if (object instanceof ObjectName)
+ {
+ ObjectName oname = (ObjectName) object;
+ return (oname.hash == hash domain.equals(oname.domain)
+ckProps.equals(oname.ckProps));
+ }
- return (oname.hash == this.hash oname.domain.equals(this.domain)
- oname.ckProps.equals(this.ckProps));
+ return false;
}
public int hashCode()
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jboss-common/src/main/org/jboss/net/protocol URLStreamHandlerFactory.java package.html
So where we had a simple System.setProperty(bla bla) we now have a
factory, a stream handler that doesn't work reliably, a couple of
Class.forName() in the code (that OF COURSE don't work with the custom
classloading) a lot of crazyness **we don't need**?
man, it makes me nervous I tell you, I will try to look at this tomorrow, it
better be good, simple and NECESSARY jason, I pray it is good.
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Jason
|Dillon
|Sent: Monday, February 25, 2002 5:29 PM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-dev] CVS update:
|jboss-common/src/main/org/jboss/net/protocol
|URLStreamHandlerFactory.java package.html
|
|
| User: user57
| Date: 02/02/25 17:28:37
|
| Added: src/main/org/jboss/net/protocol URLStreamHandlerFactory.java
|package.html
| Log:
| o Adding factory that will load handlers from org.jboss.net.protocol
| as it appears that the URL version won't work with our custom
|class loading
|
| Revision ChangesPath
| 1.1
|jboss-common/src/main/org/jboss/net/protocol/URLStreamHandlerFactory.java
|
| Index: URLStreamHandlerFactory.java
| ===
| /***
| * *
| * JBoss: The OpenSource J2EE WebOS *
| * *
| * Distributable under LGPL license. *
| * See terms of license at gnu.org. *
| * *
| ***/
|
| package org.jboss.net.protocol;
|
| import java.net.URLStreamHandler;
|
| /**
| * A factory for loading JBoss specific protocols. This is based
| * on Sun's URL mechanism, in that ttHandler/tt classes will be
| * looked for in the ttorg.jboss.net.protocol/tt.
| *
| * pThis factory is installed by the default server implementaion
| *as it appears that our custom class loading disallows the
| *default URL logic to function when setting the
| *ttjava.protocol.handler.pkgs/tt system property.
| *
| * @version tt$Revision: 1.1 $/tt
| * @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
| */
| public class URLStreamHandlerFactory
| implements java.net.URLStreamHandlerFactory
| {
| /** The package prefix where JBoss protocol handlers live. */
| public static final String PACKAGE_PREFIX = org.jboss.net.protocol;
|
| /**
| * Returns the Stream Handler.
| *
| * @param protocolThe protocol to use
| * @returnThe protocol handler or null if not found
| */
| public URLStreamHandler createURLStreamHandler(final String protocol)
| {
|URLStreamHandler handler = null;
|
|try {
| String classname = PACKAGE_PREFIX + . + protocol + .Handler;
| Class type = null;
|
| try {
| type = Class.forName(classname);
| }
| catch (ClassNotFoundException e) {
| ClassLoader cl = ClassLoader.getSystemClassLoader();
| if (cl != null) {
| type = cl.loadClass(classname);
| }
| }
|
| if (type != null) {
| handler = (URLStreamHandler)type.newInstance();
| }
|}
|catch (Exception ignore) {}
|
|return handler;
| }
| }
|
|
|
| 1.1
|jboss-common/src/main/org/jboss/net/protocol/package.html
|
| Index: package.html
| ===
| !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
| html
|head
| !-- $Id: package.html,v 1.1 2002/02/26 01:28:37 user57 Exp $ --
| !--
|
| JBoss: The OpenSource J2EE WebOS
|
| Distributable under LGPL license.
| See terms of license at gnu.org.
|
| --
|/head
|
|body bgcolor=white
| pURL protocol stream helpers.
|
| h2Package Specification/h2
| ul
|lia href=javascript: alert('not available')Not Available/a
| /ul
|
| h2Related Documentation/h2
| ul
|lia href=javascript: alert('not available')Not Available/a
| /ul
|
| h2Package Status/h2
| ul
|lifont color=greenbSTABLE/b/font
| /ul
|
| h2Todo/h2
| ul
|li???
| /ul
|
| !-- Put @see and @since tags down here. --
|
|/body
| /html
|
|
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/capability AbstractInvocationDispatcher.java DispatcherFactory.java DynamicMBeanDispatcher.java MBeanDelegate.java ReflectedMBeanDispatcher.java ResourceDelegate.java ResourceInvoker.java AttributeProvider.java MBeanAdapter.java MBeanCapability.java OperationProvider.java StandardMBeanAdapter.java
User: squirest
Date: 02/02/25 18:02:59
Added: src/main/org/jboss/mx/capability
AbstractInvocationDispatcher.java
DispatcherFactory.java DynamicMBeanDispatcher.java
MBeanDelegate.java ReflectedMBeanDispatcher.java
ResourceDelegate.java ResourceInvoker.java
Removed: src/main/org/jboss/mx/capability AttributeProvider.java
MBeanAdapter.java MBeanCapability.java
OperationProvider.java StandardMBeanAdapter.java
Log:
moved and removed stuff. new items will go into capability until a better home can
be found
Revision ChangesPath
1.1
jmx/src/main/org/jboss/mx/capability/AbstractInvocationDispatcher.java
Index: AbstractInvocationDispatcher.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.mx.capability;
import org.jboss.mx.interceptor.InvocationException;
import org.jboss.mx.interceptor.MBeanInvocation;
import javax.management.Attribute;
import javax.management.AttributeList;
import javax.management.Notification;
import javax.management.NotificationFilter;
import javax.management.NotificationListener;
import javax.management.RuntimeOperationsException;
/**
* Convenient base class for MBeanDelegates that receive MBeanInvocations
*
* @author a href=mailto:[EMAIL PROTECTED];Trevor Squires/a.
*/
public abstract class AbstractInvocationDispatcher implements MBeanDelegate
{
public Object invoke(MBeanInvocation invocation) throws InvocationException
{
try
{
Object[] args = invocation.getArgs();
switch (invocation.getOpcode())
{
case MBeanInvocation.OPCODE_INVOKE:
return this.invoke((String) args[0], (Object[]) args[1], (String[])
args[2]);
case MBeanInvocation.OPCODE_GETATTRIBUTE:
return this.getAttribute((String) args[0]);
case MBeanInvocation.OPCODE_GETATTRIBUTES:
return this.getAttributes((String[]) args[0]);
case MBeanInvocation.OPCODE_SETATTRIBUTE:
this.setAttribute((Attribute) args[0]);
return null;
case MBeanInvocation.OPCODE_SETATTRIBUTES:
return this.setAttributes((AttributeList) args[0]);
case MBeanInvocation.OPCODE_GETMBEANINFO:
return this.getMBeanInfo();
case MBeanInvocation.OPCODE_ADDNOTIFICATIONLISTENER:
this.addNotificationListener((NotificationListener) args[0],
(NotificationFilter) args[1], args[2]);
return null;
case MBeanInvocation.OPCODE_REMOVENOTIFICATIONLISTENER:
this.removeNotificationListener((NotificationListener) args[0]);
return null;
case MBeanInvocation.OPCODE_GETNOTIFICATIONINFO:
return this.getNotificationInfo();
case MBeanInvocation.OPCODE_HANDLENOTIFICATION:
this.handleNotification((Notification) args[0], args[1]);
return null;
default:
String message = Invalid Opcode: + invocation.getOpcode();
throw new InvocationException(new RuntimeOperationsException(new
IllegalArgumentException(message)), message);
}
}
catch (InvocationException e)
{
// just rethrow it
throw e;
}
catch (ClassCastException e)
{
// FIXME - spec doesn't explicitly mention CCE as wrappable by RuntimeOpEx
- is this ok tho?
String message = Exception while unpacking arguments for Opcode: +
MBeanInvocation.REVERSE_OPCODES[invocation.getOpcode()];
throw new InvocationException(new RuntimeOperationsException(e, message),
message);
}
catch (ArrayIndexOutOfBoundsException e)
{
String message = Exception while unpacking arguments for Opcode: +
MBeanInvocation.REVERSE_OPCODES[invocation.getOpcode()];
throw new InvocationException(new RuntimeOperationsException(e, message),
message);
}
catch (Exception e)
{
throw new InvocationException(e, Exception caught in
MBeanTarget.invoke());
}
catch (Error e)
{
throw new InvocationException(e, Error caught in MBeanTarget.invoke());
}
}
}
1.1 jmx/src/main/org/jboss/mx/capability/DispatcherFactory.java
Index: DispatcherFactory.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of
[JBoss-dev] CVS update: jmx/src/main/javax/management/relation RoleInfo.java
User: squirest
Date: 02/02/25 18:02:58
Modified:src/main/javax/management/relation RoleInfo.java
Log:
moved and removed stuff. new items will go into capability until a better home can
be found
Revision ChangesPath
1.5 +13 -13jmx/src/main/javax/management/relation/RoleInfo.java
Index: RoleInfo.java
===
RCS file: /cvsroot/jboss/jmx/src/main/javax/management/relation/RoleInfo.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- RoleInfo.java 16 Feb 2002 10:29:55 - 1.4
+++ RoleInfo.java 26 Feb 2002 02:02:58 - 1.5
@@ -12,7 +12,7 @@
import javax.management.DynamicMBean;
import javax.management.NotCompliantMBeanException;
-import org.jboss.mx.capability.MBeanCapability;
+import org.jboss.mx.metadata.MBeanCapability;
/**
* This class contains information about a role. For example the
@@ -20,7 +20,7 @@
* are part of the role, whether the role is read/write, etc.p
*
* @author a href=mailto:[EMAIL PROTECTED];Adrian Brock/a.
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*
*/
public class RoleInfo
@@ -147,10 +147,10 @@
}
/**
-* Construct a role info with the given name, class name,
+* Construct a role info with the given name, class name,
* read/write attributes, minimum/maximum degree and description.
* The description can be null.p
-*
+*
* Pass iROLE_CARDINALITY_INFINITY/i for an unlimited degree.
* The minimum must be less than or equal to the maximum.
*
@@ -180,7 +180,7 @@
throw new IllegalArgumentException(Null class name);
if (maxDegree minDegree maxDegree != ROLE_CARDINALITY_INFINITY)
throw new InvalidRoleInfoException(maximum less than minimum);
- if (minDegree == ROLE_CARDINALITY_INFINITY
+ if (minDegree == ROLE_CARDINALITY_INFINITY
maxDegree != ROLE_CARDINALITY_INFINITY)
throw new InvalidRoleInfoException(maximum less than minimum);
this.name = name;
@@ -196,7 +196,7 @@
// Public --
/**
-* Check to see whether a given value is greater than or equal to the
+* Check to see whether a given value is greater than or equal to the
* minimum degree.
*
* @param value the value to check.
@@ -209,7 +209,7 @@
}
/**
-* Check to see whether a given value is less than or equal to the
+* Check to see whether a given value is less than or equal to the
* maximum degree.
*
* @param value the value to check.
@@ -300,17 +300,17 @@
{
StringBuffer buffer = new StringBuffer(RoleInfo for name: ();
buffer.append(name);
- buffer.append() class name: ();
+ buffer.append() class name: ();
buffer.append(className);
- buffer.append() description: ();
+ buffer.append() description: ();
buffer.append(description);
- buffer.append() readable: ();
+ buffer.append() readable: ();
buffer.append(readable);
- buffer.append() writable: ();
+ buffer.append() writable: ();
buffer.append(writable);
- buffer.append() minimum degree: ();
+ buffer.append() minimum degree: ();
buffer.append(minDegree);
- buffer.append() maximum degree: ();
+ buffer.append() maximum degree: ();
buffer.append(maxDegree);
buffer.append());
return buffer.toString();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/server MBeanServerImpl.java
User: squirest
Date: 02/02/25 18:03:01
Modified:src/main/org/jboss/mx/server MBeanServerImpl.java
Log:
moved and removed stuff. new items will go into capability until a better home can
be found
Revision ChangesPath
1.18 +94 -87jmx/src/main/org/jboss/mx/server/MBeanServerImpl.java
Index: MBeanServerImpl.java
===
RCS file: /cvsroot/jboss/jmx/src/main/org/jboss/mx/server/MBeanServerImpl.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- MBeanServerImpl.java 23 Feb 2002 16:10:02 - 1.17
+++ MBeanServerImpl.java 26 Feb 2002 02:03:00 - 1.18
@@ -6,19 +6,13 @@
*/
package org.jboss.mx.server;
-import java.lang.reflect.Constructor;
-import java.lang.reflect.Method;
-import java.lang.reflect.Modifier;
-import java.lang.reflect.InvocationTargetException;
-
-import java.io.ByteArrayInputStream;
-import java.io.IOException;
-import java.io.ObjectInputStream;
-
-import java.util.HashSet;
-import java.util.Iterator;
-import java.util.List;
-import java.util.Set;
+import org.jboss.mx.loading.LoaderRepository;
+import org.jboss.mx.logging.Logger;
+import org.jboss.mx.metadata.MBeanCapability;
+import org.jboss.mx.capability.DispatcherFactory;
+import org.jboss.mx.server.registry.BasicMBeanRegistry;
+import org.jboss.mx.server.registry.MBeanEntry;
+import org.jboss.mx.server.registry.MBeanRegistry;
import javax.management.Attribute;
import javax.management.AttributeList;
@@ -29,7 +23,6 @@
import javax.management.IntrospectionException;
import javax.management.InvalidAttributeValueException;
import javax.management.ListenerNotFoundException;
-import javax.management.MalformedObjectNameException;
import javax.management.MBeanException;
import javax.management.MBeanInfo;
import javax.management.MBeanRegistration;
@@ -37,12 +30,13 @@
import javax.management.MBeanServer;
import javax.management.MBeanServerDelegate;
import javax.management.MBeanServerNotification;
+import javax.management.MalformedObjectNameException;
import javax.management.NotCompliantMBeanException;
import javax.management.NotificationBroadcaster;
-import javax.management.NotificationListener;
import javax.management.NotificationFilter;
-import javax.management.ObjectName;
+import javax.management.NotificationListener;
import javax.management.ObjectInstance;
+import javax.management.ObjectName;
import javax.management.OperationsException;
import javax.management.QueryExp;
import javax.management.ReflectionException;
@@ -50,15 +44,15 @@
import javax.management.RuntimeMBeanException;
import javax.management.RuntimeOperationsException;
import javax.management.loading.DefaultLoaderRepository;
-
-import org.jboss.mx.capability.MBeanCapability;
-import org.jboss.mx.interceptor.MBeanInvoker;
-import org.jboss.mx.interceptor.MBeanTarget;
-import org.jboss.mx.loading.LoaderRepository;
-import org.jboss.mx.logging.Logger;
-import org.jboss.mx.server.registry.BasicMBeanRegistry;
-import org.jboss.mx.server.registry.MBeanEntry;
-import org.jboss.mx.server.registry.MBeanRegistry;
+import java.io.ByteArrayInputStream;
+import java.io.IOException;
+import java.io.ObjectInputStream;
+import java.lang.reflect.Constructor;
+import java.lang.reflect.InvocationTargetException;
+import java.util.HashSet;
+import java.util.Iterator;
+import java.util.List;
+import java.util.Set;
/**
@@ -90,7 +84,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Juha Lindfors/a.
* @author a href=mailto:[EMAIL PROTECTED];Adrian Brock/a.
- * @version $Revision: 1.17 $
+ * @version $Revision: 1.18 $
*/
public class MBeanServerImpl
implements MBeanServer, ServerConstants
@@ -108,32 +102,32 @@
private static final String[] NOSIG = new String[0];
// Attributes
-
+
/**
-* Sequence number for the MBean server registration notifications.
+* Sequence number for the MBean server registration notifications.
*/
protected long registrationNotificationSequence= 1;
-
+
/**
* Sequence number for the MBean server unregistration notifications.
*/
protected long unregistrationNotificationSequence = 1;
-
+
/**
* Default domain name ({@link ServerConstants#DEFAULT_DOMAIN DEFAULT_DOMAIN})
used by this server implementation.
*/
protected String defaultDomain = DEFAULT_DOMAIN;
-
+
/**
* Registry used by this server to map MBean object names to resource references.
*/
protected MBeanRegistry registry = null;
-
+
/**
* Direct reference to the mandatory MBean server
[JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/interceptor MBeanInterceptor.java MBeanInvocation.java
User: squirest
Date: 02/02/25 18:02:59
Modified:src/main/org/jboss/mx/interceptor MBeanInterceptor.java
MBeanInvocation.java
Log:
moved and removed stuff. new items will go into capability until a better home can
be found
Revision ChangesPath
1.2 +3 -1 jmx/src/main/org/jboss/mx/interceptor/MBeanInterceptor.java
Index: MBeanInterceptor.java
===
RCS file:
/cvsroot/jboss/jmx/src/main/org/jboss/mx/interceptor/MBeanInterceptor.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MBeanInterceptor.java 29 Jan 2002 03:33:22 - 1.1
+++ MBeanInterceptor.java 26 Feb 2002 02:02:59 - 1.2
@@ -6,16 +6,18 @@
*/
package org.jboss.mx.interceptor;
+import org.jboss.mx.capability.ResourceInvoker;
+
/**
* Base class for MBean interceptors
*
* @author a href=mailto:[EMAIL PROTECTED];Juha Lindfors/a.
* @author a href=mailto:[EMAIL PROTECTED];Trevor Squires/a.
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*
*/
-public class MBeanInterceptor
+public class MBeanInterceptor implements ResourceInvoker
{
// Attributes
1.2 +28 -13jmx/src/main/org/jboss/mx/interceptor/MBeanInvocation.java
Index: MBeanInvocation.java
===
RCS file: /cvsroot/jboss/jmx/src/main/org/jboss/mx/interceptor/MBeanInvocation.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MBeanInvocation.java 29 Jan 2002 03:33:22 - 1.1
+++ MBeanInvocation.java 26 Feb 2002 02:02:59 - 1.2
@@ -4,33 +4,36 @@
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
+
package org.jboss.mx.interceptor;
+import javax.management.ObjectName;
+
/**
- * Abstraction of the invocation that travels through the interceptor
- * stack.
+ * Object representing an MBean invocation
*
- * QUERY THS - I can see this needing a Context object but also,
- * should this be mutable with a placeholder for the return value?
- * IMHO that seems more like an invocation as used by interceptors...
+ * Note to self: try to sneak in stateless interceptors so that nobody
+ * notices.
*
- * @see org.jboss.mx.interceptor.Interceptor
- *
- * @author a href=mailto:[EMAIL PROTECTED];Juha Lindfors/a.
* @author a href=mailto:[EMAIL PROTECTED];Trevor Squires/a.
- * @version $Revision: 1.1 $
- *
*/
public class MBeanInvocation
{
// Constants -
+ // DYNAMIC MBEAN
public final static int OPCODE_INVOKE = 1;
public final static int OPCODE_GETATTRIBUTE = 2;
public final static int OPCODE_GETATTRIBUTES = 3;
public final static int OPCODE_SETATTRIBUTE = 4;
public final static int OPCODE_SETATTRIBUTES = 5;
public final static int OPCODE_GETMBEANINFO = 6;
+ // NOTIFICATION BROADCASTER
+ public final static int OPCODE_ADDNOTIFICATIONLISTENER = 7;
+ public final static int OPCODE_REMOVENOTIFICATIONLISTENER = 8;
+ public final static int OPCODE_GETNOTIFICATIONINFO = 9;
+ // NOTIFICATION LISTENER
+ public final static int OPCODE_HANDLENOTIFICATION = 10;
public final static String[] REVERSE_OPCODES = {
OPCODE_UNKNOWN,
@@ -39,13 +42,27 @@
OPCODE_GETATTRIBUTES,
OPCODE_SETATTRIBUTE,
OPCODE_SETATTRIBUTES,
- OPCODE_GETMBEANINFO
+ OPCODE_GETMBEANINFO,
+ OPCODE_ADDNOTIFICATIONLISTENER,
+ OPCODE_REMOVENOTIFICATIONLISTENER,
+ OPCODE_GETNOTIFICATIONINFO,
+ OPCODE_HANDLENOTIFICATION,
};
// Attributes
private int opcode;
private Object[] args;
+ // FIXME - there's extra stuff that I think should go in here
+ // perhaps as some sort of MBeanEnvironment object.
+ // I believe that it's separate from any sort of context we allow because
+ // IMHO the context should be independant of the Agent impl
+ //
+ // First, I think we should supply the ObjectName for the interceptors
+ private ObjectName objectName;
+ // Next, I think we should supply the MBean's classloader.
+ private ClassLoader mbeanLoader;
+
// Constructors --
public MBeanInvocation(int opcode, Object[] args)
{
@@ -63,6 +80,4 @@
{
return opcode;
}
-
}
-
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/metadata AOResolver.java MBeanCapability.java MBeanInfoConversion.java MethodMapper.java MetaDataBuilder.java StandardMetaData.java XMLMetaData.java
User: squirest
Date: 02/02/25 18:02:59
Modified:src/main/org/jboss/mx/metadata MetaDataBuilder.java
StandardMetaData.java XMLMetaData.java
Added: src/main/org/jboss/mx/metadata AOResolver.java
MBeanCapability.java MBeanInfoConversion.java
MethodMapper.java
Log:
moved and removed stuff. new items will go into capability until a better home can
be found
Revision ChangesPath
1.2 +3 -2 jmx/src/main/org/jboss/mx/metadata/MetaDataBuilder.java
Index: MetaDataBuilder.java
===
RCS file: /cvsroot/jboss/jmx/src/main/org/jboss/mx/metadata/MetaDataBuilder.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MetaDataBuilder.java 5 Dec 2001 14:22:30 - 1.1
+++ MetaDataBuilder.java 26 Feb 2002 02:02:59 - 1.2
@@ -6,9 +6,10 @@
import javax.management.MBeanInfo;
import javax.management.NotCompliantMBeanException;
-public interface MetaDataBuilder {
+public interface MetaDataBuilder
+{
public MBeanInfo build() throws NotCompliantMBeanException;
-
+
}
1.6 +106 -123 jmx/src/main/org/jboss/mx/metadata/StandardMetaData.java
Index: StandardMetaData.java
===
RCS file: /cvsroot/jboss/jmx/src/main/org/jboss/mx/metadata/StandardMetaData.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- StandardMetaData.java 18 Jan 2002 16:45:32 - 1.5
+++ StandardMetaData.java 26 Feb 2002 02:02:59 - 1.6
@@ -4,33 +4,22 @@
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
-package org.jboss.mx.metadata;
-
-import java.util.Map;
-import java.util.HashMap;
-import java.util.Iterator;
-import java.util.List;
-import java.util.ArrayList;
-import java.lang.reflect.Method;
-import java.lang.reflect.Constructor;
-
-import javax.management.NotCompliantMBeanException;
-import javax.management.IntrospectionException;
-import javax.management.MBeanInfo;
-import javax.management.MBeanAttributeInfo;
-import javax.management.MBeanOperationInfo;
-import javax.management.MBeanConstructorInfo;
-import javax.management.MBeanNotificationInfo;
-import javax.management.NotificationBroadcaster;
-
-import javax.management.modelmbean.ModelMBeanAttributeInfo;
-import javax.management.modelmbean.ModelMBeanOperationInfo;
-import javax.management.modelmbean.ModelMBeanNotificationInfo;
-import javax.management.modelmbean.ModelMBeanConstructorInfo;
-import javax.management.modelmbean.ModelMBeanInfoSupport;
-import javax.management.modelmbean.ModelMBeanInfo;
+package org.jboss.mx.metadata;
-import org.jboss.mx.server.StandardMBeanInvoker;
+import javax.management.IntrospectionException;
+import javax.management.MBeanAttributeInfo;
+import javax.management.MBeanConstructorInfo;
+import javax.management.MBeanInfo;
+import javax.management.MBeanNotificationInfo;
+import javax.management.MBeanOperationInfo;
+import javax.management.NotCompliantMBeanException;
+import javax.management.NotificationBroadcaster;
+import java.lang.reflect.Constructor;
+import java.lang.reflect.Method;
+import java.util.ArrayList;
+import java.util.HashMap;
+import java.util.Iterator;
+import java.util.List;
/**
* @author a href=mailto:[EMAIL PROTECTED];Juha Lindfors/a.
@@ -40,35 +29,46 @@
{
// Attributes
- private Object resource = null;
- private boolean isModelMetaData = false;
+ private Object mbeanInstance = null;
+ private Class mbeanClass = null;
+ private Class mbeanInterface = null;
// Constructors --
- public StandardMetaData(Object resource)
+ public StandardMetaData(Object resourceInstance)
{
- this.resource = resource;
+ this(resourceInstance.getClass());
+ this.mbeanInstance = resourceInstance;
}
- public StandardMetaData(Object resource, boolean isModelMetaData)
+ public StandardMetaData(Class resourceClass)
{
- this(resource);
- this.isModelMetaData = isModelMetaData;
+ this.mbeanClass = resourceClass;
+ this.mbeanInterface = StandardMetaData.findStandardInterface(resourceClass);
}
// MetaDataBuilder implementation
public MBeanInfo build() throws NotCompliantMBeanException
{
- Class stdInterface = StandardMBeanInvoker.getMBeanInterface(resource);
-
- Method[] methods = stdInterface.getMethods();
- HashMap getters = new HashMap();
- HashMap setters = new HashMap();
- List operInfo = new
[JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/modelmbean XMBean.java
User: squirest
Date: 02/02/25 18:03:00
Modified:src/main/org/jboss/mx/modelmbean XMBean.java
Log:
moved and removed stuff. new items will go into capability until a better home can
be found
Revision ChangesPath
1.5 +30 -24jmx/src/main/org/jboss/mx/modelmbean/XMBean.java
Index: XMBean.java
===
RCS file: /cvsroot/jboss/jmx/src/main/org/jboss/mx/modelmbean/XMBean.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- XMBean.java 26 Jan 2002 21:13:29 - 1.4
+++ XMBean.java 26 Feb 2002 02:03:00 - 1.5
@@ -27,10 +27,11 @@
import org.jboss.mx.metadata.XMLMetaData;
import org.jboss.mx.metadata.StandardMetaData;
+import org.jboss.mx.metadata.MBeanInfoConversion;
import org.jboss.mx.interceptor.ModelMBeanInterceptor;
public class XMBean
- extends ModelBase
+ extends ModelBase
implements MBeanRegistration, XMBeanConstants
{
@@ -50,18 +51,23 @@
{
try
{
- //if (resourceType.startsWith(CLASS_NAME))
+ //if (resourceType.startsWith(CLASS_NAME))
//{
- // String
- setManagedResource(resource, resourceType);
-
-
+ // String
+ setManagedResource(resource, resourceType);
+
+
if (resourceType.equals(STANDARD_INTERFACE))
-info = new ModelMBeanInfoSupport((ModelMBeanInfo)new
StandardMetaData(resource, true).build());
+ {
+MBeanInfo standardInfo = new StandardMetaData(resource).build();
+info = MBeanInfoConversion.toModelMBeanInfo(standardInfo);
+ }
if (resourceType.endsWith(.xml))
-info = new ModelMBeanInfoSupport((ModelMBeanInfo)new
XMLMetaData(resource.getClass().getName(), resourceType).build());
+ {
+info = new ModelMBeanInfoSupport((ModelMBeanInfo)new
XMLMetaData(resource.getClass().getName(), resourceType).build());
+ }
}
- catch (InstanceNotFoundException e)
+ catch (InstanceNotFoundException e)
{
throw new MBeanException(e);
}
@@ -69,66 +75,66 @@
{
if (resourceType.endsWith(.xml))
throw new MBeanException(e, Malformed URL: + resourceType);
-
+
throw new MBeanException(e, Unsupported resource type: + resourceType);
}
catch (MalformedURLException e)
{
throw new MBeanException(e, Malformed URL: + resourceType);
- }
+ }
}
- public XMBean(String resourceClass, String resourceType, Object resourceInfo)
+ public XMBean(String resourceClass, String resourceType, Object resourceInfo)
throws MBeanException, NotCompliantMBeanException
{
-
-
+
+
}
-
+
// Public
public boolean isSupportedResourceType(String resourceType)
{
return true;
-
+
/*
if (resourceType == null)
return false;
-
+
StringTokenizer strTokenizer = new StringTokenizer(resourceType, /);
String referenceType = strTokenizer.nextToken();
String interfaceType = / + strTokenizer.nextToken();
String resourceInfo = strTokenizer.nextToken();
-
+
if (referenceType.equals(OBJET_REF))
return true;
if (resourceType.equals(OBJECT_REF))
return true;
if (resourceType.equals(STANDARD_INTERFACE))
return true;
-
+
if (resourceType.endsWith(.xml))
try
{
new URL(resourceType);
return true;
}
- catch (MalformedURLException e)
+ catch (MalformedURLException e)
{
return false;
}
-
+
return false;
*/
}
-
+
// DynamicMBean implementation ---
public MBeanInfo getMBeanInfo()
{
return info;
}
-
-
+
+
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jboss-common/src/main/org/jboss/net/protocol URLStreamHandlerFactory.java package.html
what the *fuck* is a protocol handler,
please
marcf
|-Original Message-
|From: Jason Dillon [mailto:[EMAIL PROTECTED]]
|Sent: Monday, February 25, 2002 6:04 PM
|To: marc fleury
|Cc: Jason Dillon; [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] CVS update:
|jboss-common/src/main/org/jboss/net/protocol
|URLStreamHandlerFactory.java package.html
|
|
|Both setting the system property and installing a factory are both
|standard methods for introducing custom protocol handlers.
|
|I am not sure exactly why Class.forName() did not pick up the loaded
|classes. If you can see why, please let me know, cause I don't get it.
|
|As for the handler, it looks like it works well... there was just a
|problem getting it to be used with out having to have MainDeployer
|explicity install a factory.
|
|The changes to ServerImpl will allow more custom protocols to be used
|without having to explictly install the factory (which could mess up
|other protocol usage... perhaps).
|
|I am concerned why Class.forName() didn't pull this up, so please have a
|look and drop some knowledge =)
|
|--jason
|
|
|marc fleury wrote:
|
|So where we had a simple System.setProperty(bla bla) we now have a
|factory, a stream handler that doesn't work reliably, a couple of
|Class.forName() in the code (that OF COURSE don't work with the custom
|classloading) a lot of crazyness **we don't need**?
|
|man, it makes me nervous I tell you, I will try to look at this
|tomorrow, it
|better be good, simple and NECESSARY jason, I pray it is good.
|
|marcf
|
||-Original Message-
||From: [EMAIL PROTECTED]
||[mailto:[EMAIL PROTECTED]]On Behalf Of Jason
||Dillon
||Sent: Monday, February 25, 2002 5:29 PM
||To: [EMAIL PROTECTED]
||Subject: [JBoss-dev] CVS update:
||jboss-common/src/main/org/jboss/net/protocol
||URLStreamHandlerFactory.java package.html
||
||
|| User: user57
|| Date: 02/02/25 17:28:37
||
|| Added: src/main/org/jboss/net/protocol
|URLStreamHandlerFactory.java
||package.html
|| Log:
|| o Adding factory that will load handlers from org.jboss.net.protocol
|| as it appears that the URL version won't work with our custom
||class loading
||
|| Revision ChangesPath
|| 1.1
||jboss-common/src/main/org/jboss/net/protocol/URLStreamHandlerFactory.java
||
|| Index: URLStreamHandlerFactory.java
|| ===
|| /***
|| * *
|| * JBoss: The OpenSource J2EE WebOS *
|| * *
|| * Distributable under LGPL license. *
|| * See terms of license at gnu.org. *
|| * *
|| ***/
||
|| package org.jboss.net.protocol;
||
|| import java.net.URLStreamHandler;
||
|| /**
|| * A factory for loading JBoss specific protocols. This is based
|| * on Sun's URL mechanism, in that ttHandler/tt classes will be
|| * looked for in the ttorg.jboss.net.protocol/tt.
|| *
|| * pThis factory is installed by the default server implementaion
|| *as it appears that our custom class loading disallows the
|| *default URL logic to function when setting the
|| *ttjava.protocol.handler.pkgs/tt system property.
|| *
|| * @version tt$Revision: 1.1 $/tt
|| * @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
|| */
|| public class URLStreamHandlerFactory
|| implements java.net.URLStreamHandlerFactory
|| {
|| /** The package prefix where JBoss protocol handlers live. */
|| public static final String PACKAGE_PREFIX =
|org.jboss.net.protocol;
||
|| /**
|| * Returns the Stream Handler.
|| *
|| * @param protocolThe protocol to use
|| * @returnThe protocol handler or null if not found
|| */
|| public URLStreamHandler createURLStreamHandler(final String
|protocol)
|| {
||URLStreamHandler handler = null;
||
||try {
|| String classname = PACKAGE_PREFIX + . + protocol +
|.Handler;
|| Class type = null;
||
|| try {
|| type = Class.forName(classname);
|| }
|| catch (ClassNotFoundException e) {
|| ClassLoader cl = ClassLoader.getSystemClassLoader();
|| if (cl != null) {
|| type = cl.loadClass(classname);
|| }
|| }
||
|| if (type != null) {
|| handler = (URLStreamHandler)type.newInstance();
|| }
||}
||catch (Exception ignore) {}
||
||return handler;
|| }
|| }
||
||
||
|| 1.1
||jboss-common/src/main/org/jboss/net/protocol/package.html
||
|| Index: package.html
|| ===
|| !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
|| html
||head
|| !-- $Id: package.html,v 1.1 2002/02/26 01:28:37 user57 Exp $ --
||
Re: [JBoss-dev] Security problem in authentication model.
OK, I see what they are doing and will add a call to SecurityAssociation.setPrincipal(null) after each request. 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 Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Greg Wilkins [EMAIL PROTECTED] To: [EMAIL PROTECTED]; jules [EMAIL PROTECTED] Sent: Monday, February 25, 2002 4:30 PM Subject: [JBoss-dev] Security problem in authentication model. There is a problem with the use of ThreadLocals to record Authentication when the client (in this case Jetty) is using ThreadPools. I have previously mentioned this, but now I have confirmation that it is a problem for a Client. He created a small thread pool for the listener (4 threads), then used 4 browsers to hit authenticated pages and authenticated with a different user for each browser. The effect of this was for the JBoss authentication mechanism to create ThreadLocal authentications for each of these threads. He then got new browsers and started hitting unauthenticated pages that reported the request and EJB auth details. These new requests receive random EJB authentication depending on which thread from the thread pool they are allocated: 23:33:25,434 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=comercial 23:33:25,464 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=comercial 23:33:38,333 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:33:38,373 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:34:46,341 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:34:46,371 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=cliente 23:34:57,186 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=admin 23:34:57,236 INFO [Default] request.getUserPrincipal=null; ctx.getCallerPrincipal().getName()=admin We need a mechanism to unauthenticate Threads, so the Jetty can call this after each request. Note that it is not an option to get rid of the ThreadPool as that would be a HUGE performance hit. regards -- Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss-common/src/main/org/jboss/net/protocol URLStreamHandlerFactory.java package.html
Both setting the system property and installing a factory are both
standard methods for introducing custom protocol handlers.
I am not sure exactly why Class.forName() did not pick up the loaded
classes. If you can see why, please let me know, cause I don't get it.
As for the handler, it looks like it works well... there was just a
problem getting it to be used with out having to have MainDeployer
explicity install a factory.
The changes to ServerImpl will allow more custom protocols to be used
without having to explictly install the factory (which could mess up
other protocol usage... perhaps).
I am concerned why Class.forName() didn't pull this up, so please have a
look and drop some knowledge =)
--jason
marc fleury wrote:
So where we had a simple System.setProperty(bla bla) we now have a
factory, a stream handler that doesn't work reliably, a couple of
Class.forName() in the code (that OF COURSE don't work with the custom
classloading) a lot of crazyness **we don't need**?
man, it makes me nervous I tell you, I will try to look at this tomorrow, it
better be good, simple and NECESSARY jason, I pray it is good.
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Jason
|Dillon
|Sent: Monday, February 25, 2002 5:29 PM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-dev] CVS update:
|jboss-common/src/main/org/jboss/net/protocol
|URLStreamHandlerFactory.java package.html
|
|
| User: user57
| Date: 02/02/25 17:28:37
|
| Added: src/main/org/jboss/net/protocol URLStreamHandlerFactory.java
|package.html
| Log:
| o Adding factory that will load handlers from org.jboss.net.protocol
| as it appears that the URL version won't work with our custom
|class loading
|
| Revision ChangesPath
| 1.1
|jboss-common/src/main/org/jboss/net/protocol/URLStreamHandlerFactory.java
|
| Index: URLStreamHandlerFactory.java
| ===
| /***
| * *
| * JBoss: The OpenSource J2EE WebOS *
| * *
| * Distributable under LGPL license. *
| * See terms of license at gnu.org. *
| * *
| ***/
|
| package org.jboss.net.protocol;
|
| import java.net.URLStreamHandler;
|
| /**
| * A factory for loading JBoss specific protocols. This is based
| * on Sun's URL mechanism, in that ttHandler/tt classes will be
| * looked for in the ttorg.jboss.net.protocol/tt.
| *
| * pThis factory is installed by the default server implementaion
| *as it appears that our custom class loading disallows the
| *default URL logic to function when setting the
| *ttjava.protocol.handler.pkgs/tt system property.
| *
| * @version tt$Revision: 1.1 $/tt
| * @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
| */
| public class URLStreamHandlerFactory
| implements java.net.URLStreamHandlerFactory
| {
| /** The package prefix where JBoss protocol handlers live. */
| public static final String PACKAGE_PREFIX = org.jboss.net.protocol;
|
| /**
| * Returns the Stream Handler.
| *
| * @param protocolThe protocol to use
| * @returnThe protocol handler or null if not found
| */
| public URLStreamHandler createURLStreamHandler(final String protocol)
| {
|URLStreamHandler handler = null;
|
|try {
| String classname = PACKAGE_PREFIX + . + protocol + .Handler;
| Class type = null;
|
| try {
| type = Class.forName(classname);
| }
| catch (ClassNotFoundException e) {
| ClassLoader cl = ClassLoader.getSystemClassLoader();
| if (cl != null) {
| type = cl.loadClass(classname);
| }
| }
|
| if (type != null) {
| handler = (URLStreamHandler)type.newInstance();
| }
|}
|catch (Exception ignore) {}
|
|return handler;
| }
| }
|
|
|
| 1.1
|jboss-common/src/main/org/jboss/net/protocol/package.html
|
| Index: package.html
| ===
| !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
| html
|head
| !-- $Id: package.html,v 1.1 2002/02/26 01:28:37 user57 Exp $ --
| !--
|
| JBoss: The OpenSource J2EE WebOS
|
| Distributable under LGPL license.
| See terms of license at gnu.org.
|
| --
|/head
|
|body bgcolor=white
| pURL protocol stream helpers.
|
| h2Package Specification/h2
| ul
|lia href=javascript: alert('not available')Not Available/a
| /ul
|
| h2Related Documentation/h2
| ul
|lia href=javascript: alert('not available')Not Available/a
| /ul
|
| h2Package
RE: [JBoss-dev] CVS update: jboss-common/src/main/org/jboss/net/protocol URLStreamHandlerFactory.java package.html
ok here is an excercise for you
What are you trying to achieve in the embedding (LESS THAN 57 words)
I am serious about the 57 words limit, I don't want a mental diarreah email,
I want this is what I am trying to do. It is an excercise the french go
through when they are young (and I was never really good at it).
Bonus if you can fit in these 57 words the and this is how I do it
go!
marcf
|-Original Message-
|From: Jason Dillon [mailto:[EMAIL PROTECTED]]
|Sent: Monday, February 25, 2002 6:04 PM
|To: marc fleury
|Cc: Jason Dillon; [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] CVS update:
|jboss-common/src/main/org/jboss/net/protocol
|URLStreamHandlerFactory.java package.html
|
|
|Both setting the system property and installing a factory are both
|standard methods for introducing custom protocol handlers.
|
|I am not sure exactly why Class.forName() did not pick up the loaded
|classes. If you can see why, please let me know, cause I don't get it.
|
|As for the handler, it looks like it works well... there was just a
|problem getting it to be used with out having to have MainDeployer
|explicity install a factory.
|
|The changes to ServerImpl will allow more custom protocols to be used
|without having to explictly install the factory (which could mess up
|other protocol usage... perhaps).
|
|I am concerned why Class.forName() didn't pull this up, so please have a
|look and drop some knowledge =)
|
|--jason
|
|
|marc fleury wrote:
|
|So where we had a simple System.setProperty(bla bla) we now have a
|factory, a stream handler that doesn't work reliably, a couple of
|Class.forName() in the code (that OF COURSE don't work with the custom
|classloading) a lot of crazyness **we don't need**?
|
|man, it makes me nervous I tell you, I will try to look at this
|tomorrow, it
|better be good, simple and NECESSARY jason, I pray it is good.
|
|marcf
|
||-Original Message-
||From: [EMAIL PROTECTED]
||[mailto:[EMAIL PROTECTED]]On Behalf Of Jason
||Dillon
||Sent: Monday, February 25, 2002 5:29 PM
||To: [EMAIL PROTECTED]
||Subject: [JBoss-dev] CVS update:
||jboss-common/src/main/org/jboss/net/protocol
||URLStreamHandlerFactory.java package.html
||
||
|| User: user57
|| Date: 02/02/25 17:28:37
||
|| Added: src/main/org/jboss/net/protocol
|URLStreamHandlerFactory.java
||package.html
|| Log:
|| o Adding factory that will load handlers from org.jboss.net.protocol
|| as it appears that the URL version won't work with our custom
||class loading
||
|| Revision ChangesPath
|| 1.1
||jboss-common/src/main/org/jboss/net/protocol/URLStreamHandlerFactory.java
||
|| Index: URLStreamHandlerFactory.java
|| ===
|| /***
|| * *
|| * JBoss: The OpenSource J2EE WebOS *
|| * *
|| * Distributable under LGPL license. *
|| * See terms of license at gnu.org. *
|| * *
|| ***/
||
|| package org.jboss.net.protocol;
||
|| import java.net.URLStreamHandler;
||
|| /**
|| * A factory for loading JBoss specific protocols. This is based
|| * on Sun's URL mechanism, in that ttHandler/tt classes will be
|| * looked for in the ttorg.jboss.net.protocol/tt.
|| *
|| * pThis factory is installed by the default server implementaion
|| *as it appears that our custom class loading disallows the
|| *default URL logic to function when setting the
|| *ttjava.protocol.handler.pkgs/tt system property.
|| *
|| * @version tt$Revision: 1.1 $/tt
|| * @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
|| */
|| public class URLStreamHandlerFactory
|| implements java.net.URLStreamHandlerFactory
|| {
|| /** The package prefix where JBoss protocol handlers live. */
|| public static final String PACKAGE_PREFIX =
|org.jboss.net.protocol;
||
|| /**
|| * Returns the Stream Handler.
|| *
|| * @param protocolThe protocol to use
|| * @returnThe protocol handler or null if not found
|| */
|| public URLStreamHandler createURLStreamHandler(final String
|protocol)
|| {
||URLStreamHandler handler = null;
||
||try {
|| String classname = PACKAGE_PREFIX + . + protocol +
|.Handler;
|| Class type = null;
||
|| try {
|| type = Class.forName(classname);
|| }
|| catch (ClassNotFoundException e) {
|| ClassLoader cl = ClassLoader.getSystemClassLoader();
|| if (cl != null) {
|| type = cl.loadClass(classname);
|| }
|| }
||
|| if (type != null) {
|| handler = (URLStreamHandler)type.newInstance();
|| }
||}
||catch (Exception ignore) {}
||
||return handler;
|| }
||
Re: [JBoss-dev] CVS update: jboss-common/src/main/org/jboss/net/protocol URLStreamHandlerFactory.java package.html
Read this:
http://java.sun.com/j2se/1.4/docs/api/java/net/URL.html#URL(java.lang.String,
java.lang.String, int, java.lang.String)
--jason
marc fleury wrote:
what the *fuck* is a protocol handler,
please
marcf
|-Original Message-
|From: Jason Dillon [mailto:[EMAIL PROTECTED]]
|Sent: Monday, February 25, 2002 6:04 PM
|To: marc fleury
|Cc: Jason Dillon; [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] CVS update:
|jboss-common/src/main/org/jboss/net/protocol
|URLStreamHandlerFactory.java package.html
|
|
|Both setting the system property and installing a factory are both
|standard methods for introducing custom protocol handlers.
|
|I am not sure exactly why Class.forName() did not pick up the loaded
|classes. If you can see why, please let me know, cause I don't get it.
|
|As for the handler, it looks like it works well... there was just a
|problem getting it to be used with out having to have MainDeployer
|explicity install a factory.
|
|The changes to ServerImpl will allow more custom protocols to be used
|without having to explictly install the factory (which could mess up
|other protocol usage... perhaps).
|
|I am concerned why Class.forName() didn't pull this up, so please have a
|look and drop some knowledge =)
|
|--jason
|
|
|marc fleury wrote:
|
|So where we had a simple System.setProperty(bla bla) we now have a
|factory, a stream handler that doesn't work reliably, a couple of
|Class.forName() in the code (that OF COURSE don't work with the custom
|classloading) a lot of crazyness **we don't need**?
|
|man, it makes me nervous I tell you, I will try to look at this
|tomorrow, it
|better be good, simple and NECESSARY jason, I pray it is good.
|
|marcf
|
||-Original Message-
||From: [EMAIL PROTECTED]
||[mailto:[EMAIL PROTECTED]]On Behalf Of Jason
||Dillon
||Sent: Monday, February 25, 2002 5:29 PM
||To: [EMAIL PROTECTED]
||Subject: [JBoss-dev] CVS update:
||jboss-common/src/main/org/jboss/net/protocol
||URLStreamHandlerFactory.java package.html
||
||
|| User: user57
|| Date: 02/02/25 17:28:37
||
|| Added: src/main/org/jboss/net/protocol
|URLStreamHandlerFactory.java
||package.html
|| Log:
|| o Adding factory that will load handlers from org.jboss.net.protocol
|| as it appears that the URL version won't work with our custom
||class loading
||
|| Revision ChangesPath
|| 1.1
||jboss-common/src/main/org/jboss/net/protocol/URLStreamHandlerFactory.java
||
|| Index: URLStreamHandlerFactory.java
|| ===
|| /***
|| * *
|| * JBoss: The OpenSource J2EE WebOS *
|| * *
|| * Distributable under LGPL license. *
|| * See terms of license at gnu.org. *
|| * *
|| ***/
||
|| package org.jboss.net.protocol;
||
|| import java.net.URLStreamHandler;
||
|| /**
|| * A factory for loading JBoss specific protocols. This is based
|| * on Sun's URL mechanism, in that ttHandler/tt classes will be
|| * looked for in the ttorg.jboss.net.protocol/tt.
|| *
|| * pThis factory is installed by the default server implementaion
|| *as it appears that our custom class loading disallows the
|| *default URL logic to function when setting the
|| *ttjava.protocol.handler.pkgs/tt system property.
|| *
|| * @version tt$Revision: 1.1 $/tt
|| * @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
|| */
|| public class URLStreamHandlerFactory
|| implements java.net.URLStreamHandlerFactory
|| {
|| /** The package prefix where JBoss protocol handlers live. */
|| public static final String PACKAGE_PREFIX =
|org.jboss.net.protocol;
||
|| /**
|| * Returns the Stream Handler.
|| *
|| * @param protocolThe protocol to use
|| * @returnThe protocol handler or null if not found
|| */
|| public URLStreamHandler createURLStreamHandler(final String
|protocol)
|| {
||URLStreamHandler handler = null;
||
||try {
|| String classname = PACKAGE_PREFIX + . + protocol +
|.Handler;
|| Class type = null;
||
|| try {
|| type = Class.forName(classname);
|| }
|| catch (ClassNotFoundException e) {
|| ClassLoader cl = ClassLoader.getSystemClassLoader();
|| if (cl != null) {
|| type = cl.loadClass(classname);
|| }
|| }
||
|| if (type != null) {
|| handler = (URLStreamHandler)type.newInstance();
|| }
||}
||catch (Exception ignore) {}
||
||return handler;
|| }
|| }
||
||
||
|| 1.1
||jboss-common/src/main/org/jboss/net/protocol/package.html
||
|| Index: package.html
|| ===
||
Re: [JBoss-dev] njar (and other jboss specific protocol handlers)usage fixed
On Mon, 25 Feb 2002, Jason Dillon wrote: Looks like the default URL system doesn't work too well with our custom class loading stuff... so I implemented a factory that does the same thing that would happened if our classes were on the system cl and we set the pkgs prop. ServerImpl installs this factory now instead of setting the sys prop. You might still want to look in a list of locations, so it all doesn't have to be in one 'package'. BTW, this *should* work for other handlers which are not in the jboss-common.jar as long as they are in the org.jboss.net.protocol package and have a public Handler class with a default or public no-args constructor. Yeah, like when I write URL support for .ar, .cpio, .tar, and .deb. :) .ar - single format .cpio - binary and compat formats .tar - posix, gnu, sysv filename formats .deb is a .ar wrapper around 2 tars. (I already have all of the above in an abstract api, pure java, both reading/writing, and direct indexing). I've played around with reading of rpms, but they are quite a bit more complex. Also, I've looked at other DOS based formats, but they all like to include their own compression code, and finding docs on that is complex at best. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] njar (and other jboss specific protocol handlers) usage fixed
The default searching is still done by URL. When we need to search JBoss packages then we can add that to the factory then. --jason Adam Heath wrote: On Mon, 25 Feb 2002, Jason Dillon wrote: Looks like the default URL system doesn't work too well with our custom class loading stuff... so I implemented a factory that does the same thing that would happened if our classes were on the system cl and we set the pkgs prop. ServerImpl installs this factory now instead of setting the sys prop. You might still want to look in a list of locations, so it all doesn't have to be in one 'package'. BTW, this *should* work for other handlers which are not in the jboss-common.jar as long as they are in the org.jboss.net.protocol package and have a public Handler class with a default or public no-args constructor. Yeah, like when I write URL support for .ar, .cpio, .tar, and .deb. :) .ar - single format .cpio - binary and compat formats .tar - posix, gnu, sysv filename formats .deb is a .ar wrapper around 2 tars. (I already have all of the above in an abstract api, pure java, both reading/writing, and direct indexing). I've played around with reading of rpms, but they are quite a bit more complex. Also, I've looked at other DOS based formats, but they all like to include their own compression code, and finding docs on that is complex at best. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-522762 ] Server config from system properties
Change Notes item #522762, was opened at 2002-02-25 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=522762group_id=22866 Category: None Group: v3.0 (Rabbit Hole) Status: Open Priority: 5 Submitted By: Jason Dillon (user57) Assigned to: Nobody/Anonymous (nobody) Summary: Server config from system properties Initial Comment: The Server componet is now configurable from system properties in addition to the command line arguments gotten from Main (aka. run.[bat|sh]). This allow greater control to users who have specific environment requirements. See system/src/main/org/jboss/system/server/ServerConfig.j ava for more details. Eventually should be included in an howto embed jboss guide. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=522762group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosspool build.xml
User: user57
Date: 02/02/25 18:19:03
Modified:.build.xml
Log:
o build file clean up
Revision ChangesPath
1.19 +1 -17 jbosspool/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbosspool/build.xml,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- build.xml 24 Feb 2002 10:24:30 - 1.18
+++ build.xml 26 Feb 2002 02:19:03 - 1.19
@@ -12,7 +12,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.18 2002/02/24 10:24:30 user57 Exp $ --
+!-- $Id: build.xml,v 1.19 2002/02/26 02:19:03 user57 Exp $ --
project default=main name=JBoss/Pool
@@ -119,13 +119,6 @@
!-- Modules --
!-- === --
-!-- J2EE --
-property name=jboss.j2ee.root value=${project.root}/j2ee/output/
-property name=jboss.j2ee.lib value=${jboss.j2ee.root}/lib/
-path id=jboss.j2ee.classpath
- pathelement path=${jboss.j2ee.lib}/jboss-j2ee.jar/
-/path
-
!-- Common --
property name=jboss.common.root value=${project.root}/common/output/
property name=jboss.common.lib value=${jboss.common.root}/lib/
@@ -133,18 +126,9 @@
pathelement path=${jboss.common.lib}/jboss-common.jar/
/path
-!-- Server --
-property name=jboss.server.root value=${project.root}/server/output/
-property name=jboss.server.lib value=${jboss.server.root}/lib/
-path id=jboss.server.classpath
- pathelement path=${jboss.server.lib}/jboss.jar/
-/path
-
!-- The combined depedant module classpath --
path id=dependentmodule.classpath
- path refid=jboss.j2ee.classpath/
path refid=jboss.common.classpath/
- path refid=jboss.server.classpath/
/path
!-- = --
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/jboss build.xml
User: user57
Date: 02/02/25 18:19:02
Modified:jbossbuild.xml
Log:
o build file clean up
Revision ChangesPath
1.93 +70 -98build/jboss/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/build/jboss/build.xml,v
retrieving revision 1.92
retrieving revision 1.93
diff -u -r1.92 -r1.93
--- build.xml 25 Feb 2002 01:23:23 - 1.92
+++ build.xml 26 Feb 2002 02:19:01 - 1.93
@@ -12,7 +12,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.92 2002/02/25 01:23:23 user57 Exp $ --
+!-- $Id: build.xml,v 1.93 2002/02/26 02:19:01 user57 Exp $ --
project default=main name=JBoss/Build
@@ -196,9 +196,11 @@
!-- Module groups --
group name=core
+include modules=common, system/
+ /group
+
+ group name=basic
include modules=j2ee,
- common,
- system,
naming,
server/
/group
@@ -227,15 +229,15 @@
!-- Module group sets --
group name=default
-include groups=core, standard/
+include groups=core, basic, standard/
/group
group name=most
-include groups=core, standard, optional/
+include groups=core, basic, standard, optional/
/group
group name=all
-include groups=core, standard, optional, optional-requires-config/
+include groups=core, basic, standard, optional,
optional-requires-config/
/group
/moduleconfig
@@ -282,10 +284,6 @@
property name=install.db value=${install.root}/db/
property name=install.deploy value=${install.root}/deploy/
property name=install.lib value=${install.root}/lib/
-
-!-- FIXME: remove the usage of this bad boy --
-property name=install.lib.ext value=${install.lib}/
-
property name=install.log value=${install.root}/log/
property name=install.tmp value=${install.root}/tmp/
@@ -354,15 +352,15 @@
property name=_module.output override=true
value=${project.root}/${_module.name}/output/
-!-- Copy the generated libraries (lib/ext) --
-mkdir dir=${install.lib.ext}/
-copy todir=${install.lib.ext} filtering=no
+!-- Copy the generated libraries --
+mkdir dir=${install.lib}/
+copy todir=${install.lib} filtering=no
fileset dir=${_module.output}/lib
include name=jboss-j2ee.jar/
/fileset
/copy
-!-- Copy the generated libraries (client) --
+!-- Copy the generated client libraries --
mkdir dir=${install.client}/
copy todir=${install.client} filtering=no
fileset dir=${_module.output}/lib
@@ -390,15 +388,15 @@
property name=_module.output override=true
value=${project.root}/${_module.name}/output/
-!-- Copy the generated libraries (lib/ext) --
-mkdir dir=${install.lib.ext}/
-copy todir=${install.lib.ext} filtering=no
+!-- Copy the generated libraries --
+mkdir dir=${install.lib}/
+copy todir=${install.lib} filtering=no
fileset dir=${_module.output}/lib
include name=jboss-common.jar/
/fileset
/copy
-!-- Copy the generated libraries (client) --
+!-- Copy the generated client libraries --
mkdir dir=${install.client}/
copy todir=${install.client} filtering=no
fileset dir=${_module.output}/lib
@@ -426,7 +424,7 @@
property name=_module.output override=true
value=${project.root}/${_module.name}/output/
-!-- Copy the generated libraries (lib) --
+!-- Copy the generated libraries --
mkdir dir=${install.lib}/
copy todir=${install.lib} filtering=no
fileset dir=${_module.output}/lib
@@ -435,7 +433,7 @@
/fileset
/copy
-!-- Copy the generated libraries (client) --
+!-- Copy the generated client --
mkdir dir=${install.client}/
copy todir=${install.client} filtering=no
fileset dir=${_module.output}/lib
@@ -443,7 +441,7 @@
/fileset
/copy
-!-- Copy the generated scripts runnable jars (bin) --
+!-- Copy the generated scripts runnable jars --
mkdir dir=${install.bin}/
copy todir=${install.bin} filtering=no
fileset dir=${_module.output}/bin
@@ -480,15 +478,15 @@
property name=_module.output override=true
value=${project.root}/${_module.name}/output/
-!-- Copy the generated libraries (lib/ext) --
-mkdir dir=${install.lib.ext}/
-copy todir=${install.lib.ext} filtering=no
+!--
RE: [JBoss-dev] CVS update: jboss-common/src/main/org/jboss/net/protocol URLStreamHandlerFactory.java package.html
And you explain in those 57 words why you need one in the embedding world
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Jason
|Dillon
|Sent: Monday, February 25, 2002 6:10 PM
|To: marc fleury
|Cc: Jason Dillon; [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] CVS update:
|jboss-common/src/main/org/jboss/net/protocol
|URLStreamHandlerFactory.java package.html
|
|
|Read this:
|
|http://java.sun.com/j2se/1.4/docs/api/java/net/URL.html#URL(java.la
|ng.String,
|java.lang.String, int, java.lang.String)
|
|--jason
|
|
|marc fleury wrote:
|
|what the *fuck* is a protocol handler,
|
|please
|
|marcf
|
||-Original Message-
||From: Jason Dillon [mailto:[EMAIL PROTECTED]]
||Sent: Monday, February 25, 2002 6:04 PM
||To: marc fleury
||Cc: Jason Dillon; [EMAIL PROTECTED]
||Subject: Re: [JBoss-dev] CVS update:
||jboss-common/src/main/org/jboss/net/protocol
||URLStreamHandlerFactory.java package.html
||
||
||Both setting the system property and installing a factory are both
||standard methods for introducing custom protocol handlers.
||
||I am not sure exactly why Class.forName() did not pick up the loaded
||classes. If you can see why, please let me know, cause I don't get it.
||
||As for the handler, it looks like it works well... there was just a
||problem getting it to be used with out having to have MainDeployer
||explicity install a factory.
||
||The changes to ServerImpl will allow more custom protocols to be used
||without having to explictly install the factory (which could mess up
||other protocol usage... perhaps).
||
||I am concerned why Class.forName() didn't pull this up, so please have a
||look and drop some knowledge =)
||
||--jason
||
||
||marc fleury wrote:
||
||So where we had a simple System.setProperty(bla bla) we now have a
||factory, a stream handler that doesn't work reliably, a couple of
||Class.forName() in the code (that OF COURSE don't work with the custom
||classloading) a lot of crazyness **we don't need**?
||
||man, it makes me nervous I tell you, I will try to look at this
||tomorrow, it
||better be good, simple and NECESSARY jason, I pray it is good.
||
||marcf
||
|||-Original Message-
|||From: [EMAIL PROTECTED]
|||[mailto:[EMAIL PROTECTED]]On
|Behalf Of Jason
|||Dillon
|||Sent: Monday, February 25, 2002 5:29 PM
|||To: [EMAIL PROTECTED]
|||Subject: [JBoss-dev] CVS update:
|||jboss-common/src/main/org/jboss/net/protocol
|||URLStreamHandlerFactory.java package.html
|||
|||
||| User: user57
||| Date: 02/02/25 17:28:37
|||
||| Added: src/main/org/jboss/net/protocol
||URLStreamHandlerFactory.java
|||package.html
||| Log:
||| o Adding factory that will load handlers from org.jboss.net.protocol
||| as it appears that the URL version won't work with our custom
|||class loading
|||
||| Revision ChangesPath
||| 1.1
|||jboss-common/src/main/org/jboss/net/protocol/URLStreamHandlerFa
|ctory.java
|||
||| Index: URLStreamHandlerFactory.java
||| ===
||| /***
||| * *
||| * JBoss: The OpenSource J2EE WebOS *
||| * *
||| * Distributable under LGPL license. *
||| * See terms of license at gnu.org. *
||| * *
||| ***/
|||
||| package org.jboss.net.protocol;
|||
||| import java.net.URLStreamHandler;
|||
||| /**
||| * A factory for loading JBoss specific protocols. This is based
||| * on Sun's URL mechanism, in that ttHandler/tt classes will be
||| * looked for in the ttorg.jboss.net.protocol/tt.
||| *
||| * pThis factory is installed by the default server implementaion
||| *as it appears that our custom class loading disallows the
||| *default URL logic to function when setting the
||| *ttjava.protocol.handler.pkgs/tt system property.
||| *
||| * @version tt$Revision: 1.1 $/tt
||| * @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
||| */
||| public class URLStreamHandlerFactory
||| implements java.net.URLStreamHandlerFactory
||| {
||| /** The package prefix where JBoss protocol handlers live. */
||| public static final String PACKAGE_PREFIX =
||org.jboss.net.protocol;
|||
||| /**
||| * Returns the Stream Handler.
||| *
||| * @param protocolThe protocol to use
||| * @returnThe protocol handler or null if not found
||| */
||| public URLStreamHandler createURLStreamHandler(final String
||protocol)
||| {
|||URLStreamHandler handler = null;
|||
|||try {
||| String classname = PACKAGE_PREFIX + . + protocol +
||.Handler;
||| Class type = null;
|||
||| try {
||| type = Class.forName(classname);
||| }
||| catch (ClassNotFoundException e) {
|||
Re: [JBoss-dev] CVS update: jboss-common/src/main/org/jboss/net/protocol URLStreamHandlerFactory.java package.html
This has nothing todo with embedding. It simplifies usage of such
handlers which may be used inside the system. Since ServerImpl is where
the base gets initialized it seems logical that such init should be done
here.
Why the objection? I don't understand your motives here. 57 words
coming along...
--jason
marc fleury wrote:
And you explain in those 57 words why you need one in the embedding world
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Jason
|Dillon
|Sent: Monday, February 25, 2002 6:10 PM
|To: marc fleury
|Cc: Jason Dillon; [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] CVS update:
|jboss-common/src/main/org/jboss/net/protocol
|URLStreamHandlerFactory.java package.html
|
|
|Read this:
|
|http://java.sun.com/j2se/1.4/docs/api/java/net/URL.html#URL(java.la
|ng.String,
|java.lang.String, int, java.lang.String)
|
|--jason
|
|
|marc fleury wrote:
|
|what the *fuck* is a protocol handler,
|
|please
|
|marcf
|
||-Original Message-
||From: Jason Dillon [mailto:[EMAIL PROTECTED]]
||Sent: Monday, February 25, 2002 6:04 PM
||To: marc fleury
||Cc: Jason Dillon; [EMAIL PROTECTED]
||Subject: Re: [JBoss-dev] CVS update:
||jboss-common/src/main/org/jboss/net/protocol
||URLStreamHandlerFactory.java package.html
||
||
||Both setting the system property and installing a factory are both
||standard methods for introducing custom protocol handlers.
||
||I am not sure exactly why Class.forName() did not pick up the loaded
||classes. If you can see why, please let me know, cause I don't get it.
||
||As for the handler, it looks like it works well... there was just a
||problem getting it to be used with out having to have MainDeployer
||explicity install a factory.
||
||The changes to ServerImpl will allow more custom protocols to be used
||without having to explictly install the factory (which could mess up
||other protocol usage... perhaps).
||
||I am concerned why Class.forName() didn't pull this up, so please have a
||look and drop some knowledge =)
||
||--jason
||
||
||marc fleury wrote:
||
||So where we had a simple System.setProperty(bla bla) we now have a
||factory, a stream handler that doesn't work reliably, a couple of
||Class.forName() in the code (that OF COURSE don't work with the custom
||classloading) a lot of crazyness **we don't need**?
||
||man, it makes me nervous I tell you, I will try to look at this
||tomorrow, it
||better be good, simple and NECESSARY jason, I pray it is good.
||
||marcf
||
|||-Original Message-
|||From: [EMAIL PROTECTED]
|||[mailto:[EMAIL PROTECTED]]On
|Behalf Of Jason
|||Dillon
|||Sent: Monday, February 25, 2002 5:29 PM
|||To: [EMAIL PROTECTED]
|||Subject: [JBoss-dev] CVS update:
|||jboss-common/src/main/org/jboss/net/protocol
|||URLStreamHandlerFactory.java package.html
|||
|||
||| User: user57
||| Date: 02/02/25 17:28:37
|||
||| Added: src/main/org/jboss/net/protocol
||URLStreamHandlerFactory.java
|||package.html
||| Log:
||| o Adding factory that will load handlers from org.jboss.net.protocol
||| as it appears that the URL version won't work with our custom
|||class loading
|||
||| Revision ChangesPath
||| 1.1
|||jboss-common/src/main/org/jboss/net/protocol/URLStreamHandlerFa
|ctory.java
|||
||| Index: URLStreamHandlerFactory.java
||| ===
||| /***
||| * *
||| * JBoss: The OpenSource J2EE WebOS *
||| * *
||| * Distributable under LGPL license. *
||| * See terms of license at gnu.org. *
||| * *
||| ***/
|||
||| package org.jboss.net.protocol;
|||
||| import java.net.URLStreamHandler;
|||
||| /**
||| * A factory for loading JBoss specific protocols. This is based
||| * on Sun's URL mechanism, in that ttHandler/tt classes will be
||| * looked for in the ttorg.jboss.net.protocol/tt.
||| *
||| * pThis factory is installed by the default server implementaion
||| *as it appears that our custom class loading disallows the
||| *default URL logic to function when setting the
||| *ttjava.protocol.handler.pkgs/tt system property.
||| *
||| * @version tt$Revision: 1.1 $/tt
||| * @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
||| */
||| public class URLStreamHandlerFactory
||| implements java.net.URLStreamHandlerFactory
||| {
||| /** The package prefix where JBoss protocol handlers live. */
||| public static final String PACKAGE_PREFIX =
||org.jboss.net.protocol;
|||
||| /**
||| * Returns the Stream Handler.
||| *
||| * @param protocolThe protocol to use
||| * @returnThe protocol handler or null if not found
||| */
||| public URLStreamHandler createURLStreamHandler(final String
||protocol)
[JBoss-dev] 57 words... and a signature
The embedding changes provides integrators with a simple API to configure, start and stop JBoss. It will allow 99% of resources to be loaded off network, leaving the boot footprint small for limited devices. This is achieved by seperating server interfaces from implemenation and utilizing core java.* classes to setup access to required boot resources. That's it. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] And 57+sig more...
Changes to come will further absrtact and detach File usage, abstract logging or provide logging adapters, and provide an api for core system configuraton (descriptors and such). MBeans will also be modified to return structured data instead of html preformatted strings, which could be rendered as plain or html as needed. More to come as requirements settle. --jason ___ 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
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 501 Successful tests: 491 Errors:4 Failures: 6 [time of test: 26 February 2002 2:54 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-21] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] 57 words... and a signature
Ok 57 congratulations, although you are a bit skimpy on the how |The embedding changes provides integrators with a simple API to |configure, start and stop JBoss. |It will allow 99% of resources to be loaded off network, leaving the |boot footprint small for |limited devices. this is a valid requirement, I understand it and I see the need, it is a new feature. go right ahead. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] How should shutdown work?? (jboss 3)
Right now, shutdown happens by stopping, destroying, and unregistering all mbeans the ServiceController knows about. Since MainDeployer is not one of them, and since deployments are not usually mbeans themselves, this means the deployers don't get to do any cleanup and that in particular the local copies of deployed packages are never deleted. This sucks, and several people have complained about it. We could: 1. Change shutdown so that MainDeployer is a registered mbean with ServiceController, and it's destroy method simply kills all the local copies. This would presumably be about as fast as what we are doing now. 2. Change shutdown so that first all deployed packages are undeployed ( in reverse order), then any remaining mbeans are stopped, destroyed, and removed. This is apt to take longer than what we do now, but does allow deployers to do arbitrary cleanup. 3. Make all deployments into mbeans themselves, so when they are stop/destroyed they clean themselves up. Anyone have an opinion? I favor (2 or 3) since we don't really know what cleanup a particular deployer might like to do. (2) is simpler for now, (3) might be for the future. david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 57 words... and a signature
I ran out of words for the how. Such words (probably not limited to 57) and more should go into a howto embed JBoss guide... --jason marc fleury wrote: Ok 57 congratulations, although you are a bit skimpy on the how |The embedding changes provides integrators with a simple API to |configure, start and stop JBoss. |It will allow 99% of resources to be loaded off network, leaving the |boot footprint small for |limited devices. this is a valid requirement, I understand it and I see the need, it is a new feature. go right ahead. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] How should shutdown work?? (jboss 3)
|Right now, shutdown happens by stopping, destroying, and unregistering all |mbeans the ServiceController knows about. Since MainDeployer is not one of |them, and since deployments are not usually mbeans themselves, this means |the deployers don't get to do any cleanup and that in particular the local |copies of deployed packages are never deleted. This sucks, and several |people have complained about it. yes it does suck, clearly. I remember that there was a remove EJBs in the old factory. We should clearly call MainDeployer (register it when we can then) as I remember coding support for a full shutdown. |We could: | |1. Change shutdown so that MainDeployer is a registered mbean with |ServiceController, and it's destroy method simply kills all the local |copies. This would presumably be about as fast as what we are doing now. Yes, and I remember coding the stop that calls all the deployments? (is that right?) however this should be done through the respective deployers (they know what to do) and I remember coding it that way (is that right?). |2. Change shutdown so that first all deployed packages are undeployed ( in |reverse order), then any remaining mbeans are stopped, destroyed, and |removed. This is apt to take longer than what we do now, but does allow |deployers to do arbitrary cleanup. this is achieved by putting the deployer as the last service and first undeployed... I don't think we care. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 501 Successful tests: 492 Errors:4 Failures: 5 [time of test: 26 February 2002 3:23 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-21] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] And 57+sig more...
marc fleury wrote: |Changes to come will further absrtact and detach File usage, abstract |logging or provide |logging adapters, and provide an api for core system configuraton |(descriptors and such). This I cannot make sense of. I mean the point is weak. Yes, yes the second 57 words are things that we may need todo and I don't currently have any plans todo anything about them except perhaps abstracted File usage, but I don't have a clear picture for how that should be done yet, so I am gonna let that one cook. Don't complicate the codebase with nth degree bullshit FOR NO GAIN SO DONT DO ANYTHING THERE, see how people use the embedding, let them ask for the feature. I don't believe that anything I have done has complicated things, perhaps made it a bit more sophisticated. Again, I am gonna let things cook for a bit. Perhaps we can get someone to actually embed and give us feed back too. |MBeans will also be modified to return structured data instead of html |preformatted strings, |which could be rendered as plain or html as needed. Wow, while that fits in 57 words, it has nothing to do with the stuff above. I was trying to fill up 57 words... I think we got a good case of your first idea is good, your second one stinks. And there is good reason todo this, as we can not really expect that an embbeded user will have html capabilities, but will have the capacity to iterator over a set and such. I think it is more like it takes a bit for folks to get what I am talking about. Sure sometimes I come up with crap, don't we all... Ok, so you are done, stop working. Let the requirement bite your ass before you take your keyboard again. Do you hear me? I don't want to see a single commit. This is just plain silly. As issue some up I will need to resolve them... thus commiting. I am working on the layout changes for a 3.0 final now... which will eventually need to be commited. Don't code with your sense of style or your sense of perfection, they both suck, everyone's sense of style and perfection suck, they just do, that's just taste and it all sucks. Lets not talk about who's style sucks. There isn't really a point to that a? It just gets me fired up and I would rather avoid that. Being an artist I assert that style is important. Being a virgo I can not help but strive for perfection. Being an engineer I can not avoid either of these from affecting my work. Code with your sense of necessity (a la hiram) meaning I really need this feature, I really do, and here is the SIMPLEST way to do it. The rest MUST go to /dev/null. Agreed... for the most part. Most of what I do is structured, in that layers must be put in place to allow for later layers to be placed. Take for example the build system changes that I originally did. I did that so that I could better help fix tx, mdb and jms problems. It was a needed step to avoid wasting time down the line, compiling and sorting out the mess to get jars from a to b with out missing a step and invalidating tests. I could have just skipped right to fixing the code, as that would have been simple, yet it was not the most effective solution. OK? le mieux est l'ennemi du bien (better is the enemy of good) but I remember making this point to you 6 month ago on buildmagic. Go simplify buildmagic first, please! Yes you did make this point. I think something is lost in the translation though... unless your perspective is that better is pointless since good is good enough. I think that might be true if better adds a degree of complication and does not provide substantial gain. If something is better then it isn't it already good? I will work on the build system soon. I am still hoping you will provide some concreate examples of the complexity you see anyone else for that matter. What is simple to me may be complex to you (as well as the opposite yo). --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] AAAHOOO JBoss in London!
Ok, yes, it sounds like a corny song from the late 70's but really London is coming up and is going to be one hell of a show. The last of its kind worldwide as we are changing the formula for the next ones (next ones will be San Fran/Montreal/Palma de Mallorca/(possibly) Hong Kong). THERE IS ***ONE*** SEAT LEFT And you got 2 weeks to register. So hurry, the class will be kick ass, we really put on a show and it is the best way for serious developers to become contributor or be able to completely use JBoss internally. Also we will do an open house that I will announce separately (already on the website). These are extremelly popular, come meet Marc Fleury and Sacha Labourey. I saw a werewolf drinking a pina colada at Trader Vic's His hair was perfect -- Werewolves of London again ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Security problem in authentication model.
Probably the easiest way would be to subclass the SingleSignOn Valve and use the session based cache to obtain the authentication information. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Luke Taylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 25, 2002 6:48 PM Subject: 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
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 501 Successful tests: 492 Errors:4 Failures: 5 [time of test: 26 February 2002 4:20 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-21] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Auto-resolving dependencies/deployment
ok, still jet lagged... (australia!) So let's imagine that we multi-thread the MainDeployer, each deployment gets a thread. Each time a thread wants a class the ServiceLibraries tries and if it is a CNFE waits. when a class is registered in the SL it notifiesAll threads waiting. voila! auto-resolving dependencies at deployment time, Am I delirious or is it this simple. marcf PS: will it completely screw up the log? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
