Re: [JBoss-dev] Adopting log4j over org.jboss.logging.Log
In my opinion, the log4j service implementation that JBoss is using is not "correct". Instead of using Categories for the user data, it is "pushing" the user data onto the NDC stack. Unfortunately, this means that if you *DO* use the log4j interface for logging in your code, you have difficulty formatting your logging messages in a consistent way with the JBoss logging messages. I'm actually using a modified version of Log4jService.java for our purposes that uses Categories for the User data instead of the NDC stack. Then, in our code, we use Log4j categories pretty readily. ++Jeff Scott M Stark wrote: > The main branch has been updated to use the org.apache.log4j framework > as the default logging implementation. One question is why not adopt the > log4j framework as the JBoss logging interface as well? I don't see any downside > to this and there are many benefits. Are there any objections to permitting > the use of the log4j framework in JBoss/JBossXX code? > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Remote Proxies do not know the server they came from
Just to let you know, I am almost done adding this. I will probably be able
to finish the impl sometime tomorrow, but it might take a little longer than
that to get it checked in. I want to be sure that the test suite is updated
to actually test that all of my changes work correctly (and I am not really
sure how to do that just yet).
Any ways, you can expect this to be available in CVS sometime mid next week
(if not earlier).
--jason
On Thu, 26 Apr 2001, Alf Werder wrote:
> Jason Dillon wrote:
>
> > I spent some time (long ago...) fixing this very problem, but I have not
> > really had time to integrate it into the latest codeline. I can put some
> > more effort into fixing this soon.
>
> I really would appreciate that.
>
> > Does anyone happen to know what the EJB spec says about handles and if they
> > should return bean refs to the *exact* server which they came from? I can
> > not recall any real detail about handles except that they are used to allow
> > clients to restore a reference to a given bean.
>
> I don't think so. In a clustering environment, that cannot be guaranteed anyway. The
>spec (1.1) talks about handles in section 8.7 and 8.8.
>
>
> > Any ways, I do not think that this will take that long to fix. I can
> > probably make this optional too (via a property that will enable the new
> > behavior). The only problem that I remember running into was when the proxy
> > is generated there isn't an easy way to find out what the provider url is for
> > the current machine (in a non-jboss specific fashion). Perhaps that has
> > changed.
> >
> > What I might do is force users who are interested in this, to provide some
> > extra properties (or another jndi properties file) that specifies the exact
> > environment properties required to restore a bean from a handle.
>
> I think, that is the best way, because you cannot determine the host name of a
>server.
>
> -alf
>
> > --jason
> >
> >
> > On Thu, 26 Apr 2001, Alf Werder wrote:
> >
> >
> >> Hi,
> >>
> >> The last two months I made my first experiences with jboss as a bean
> >> developer. I am really surprised and impressed by the work, that is
> >> done. But now, the first serious problem arised.
> >>
> >> In an EJB client a tried to obtain the home interface of a bean from its
> >> remote interface. But a call to EJBObject.getEJBHome() throws an
> >> exception. That was the first sign. Later, I tried to use a HomeHandle
> >> to reobtain a home interface after a server restart.
> >> HomeHandel.getEJBHome() throws an exception.
> >>
> >> I had a deeper look and found the problem: My code was
> >>
> >>Hashtable env = new Hashtable();
> >>env.put("java.naming.factory.initial",
> >> "org.jnp.interfaces.NamingContextFactory");
> >>env.put("java.naming.provider.url", "localhost:1099");
> >>env.put("java.naming.factory.url.pkgs", "org.jboss.naming");
> >>
> >>MyHome home = (MyHome) new InitialContext(env).lookup("MyHome");
> >>MyHome h = (MyHome) home.getHomeHandle().getEJBHome();
> >>
> >> The last line throws the exception. It works, when I change the code to:
> >>
> >>Hashtable env = new Hashtable();
> >>System.setProperty("java.naming.factory.initial",
> >> "org.jnp.interfaces.NamingContextFactory");
> >>System.setProperty("java.naming.provider.url", "localhost:1099");
> >>System.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming");
> >>
> >> MyHome home = (MyHome) new InitialContext().lookup("MyHome");
> >> MyHome h = (MyHome) home.getHomeHandle().getEJBHome();
> >>
> >> So had a look into the jboss source code. The HomeHandle implementation
> >> simply does not know the server, is came from. It just creates a new
> >> inital context without any Arguments. So it gets the local root context,
> >> which is not the context its home interface is bound to.
> >>
> >> -alf
> >>
> >>
> >
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Change Notes-419301 ] JMS Connector resource adapter
Hi, This is great! It is not clear to me from the change note if this supports XA transactions. As I understand the situation this would be necessary to really get ejb/database changes made and a message sent inside the same transaction. Is this correct and could you clarify exactly what is supported? Thanks david jencks On 2001.04.26 17:32:12 -0400 [EMAIL PROTECTED] wrote: > Change Notes item #419301, was updated on 2001-04-26 14:32 > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=381174&aid=419301&group_id=22866 > > Category: None > Group: None > Status: Open > Priority: 5 > Submitted By: Peter Antman (pra) > Assigned to: Nobody/Anonymous (nobody) > Summary: JMS Connector resource adapter > > Initial Comment: > A JMS Connector resource adapter has been added to the > JBoss > main trunk, under the package org.jboss.jms.ra. > > A new JMSProviderAdapter has also been added to support > JMS ra with local transactions: JBossLocalTXProvider. > > The adapter is installed into dist/deploy/lib and an > entry for a TX version have been added to jboss.jcml. I > have left configuration for a LocalTransaction out of > the default configuration, which will insted be > documented in the JBoss docu. > > It is (probably) possible to get the ra to work also in > JBoss 2.2.1, but it will not be added to that trunc in > the CVS. > > The connector makes it possible to use JMS in beans as > is specifyed in J2EE 1.3, namely as a truly transacted > resource. > > It also makes it possible to deploy the Publisher > example for the SUN JMS tutorial, with a jboss.xml file > like this: > > > > > false > > > topicfactoryref > java:/JmsXA > > > topicref > > topic/testTopic > > > > > >Publisher >publisher >Standard Stateless > SessionBean > > > jms/MyTopicConnectionFactory > > topicfactoryref > > >jms/TopicName >topicref > > > > > > -- > > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=381174&aid=419301&group_id=22866 > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss daily test results
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JBoss daily test results SUMMARY Number of tests run: 57 Successful tests: 49 Errors:3 Failures: 5 DETAILS OF ERRORS Suite: org.jboss.test.cts.test.AllJUnitTests Test:testRemoveSessionObject Type:failure Exception: junit.framework.AssertionFailedError Message: [EJB 1.1, p42] Expected 'RemoveException', detail:java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory); nested exception is: java.rmi.NoSuchObjectException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory) Stack Trace: junit.framework.AssertionFailedError: [EJB 1.1, p42] Expected 'RemoveException', detail:java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory); nested exception is: java.rmi.NoSuchObjectException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory) at junit.framework.Assert.fail(Assert.java:143) at org.jboss.test.cts.test.StatefulSessionTest.testRemoveSessionObject(StatefulSessionTest.java:187) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:155) at junit.framework.TestCase.runBare(TestCase.java:129) at junit.framework.TestResult$1.protect(TestResult.java:100) at junit.framework.TestResult.runProtected(TestResult.java:117) at junit.framework.TestResult.run(TestResult.java:103) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.run(TestSuite.java:144) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:202) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:326) - Suite: org.jboss.test.cts.test.AllJUnitTests Test:testProbeBeanContext Type:failure Exception: junit.framework.AssertionFailedError Message: Caught an unknown exception in testProbeBeanContex Stack Trace: junit.framework.AssertionFailedError: Caught an unknown exception in testProbeBeanContex at junit.framework.Assert.fail(Assert.java:143) at org.jboss.test.cts.test.StatefulSessionTest.testProbeBeanContext(StatefulSessionTest.java:466) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:155) at junit.framework.TestCase.runBare(TestCase.java:129) at junit.framework.TestResult$1.protect(TestResult.java:100) at junit.framework.TestResult.runProtected(TestResult.java:117) at junit.framework.TestResult.run(TestResult.java:103) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.run(TestSuite.java:144) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:202) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:326) - Suite: org.jboss.test.cts.test.AllJUnitTests Test:testUserTrx Type:failure Exception: junit.framework.AssertionFailedError Message: Naming excepiton failure Stack Trace: junit.framework.AssertionFailedError: Naming excepiton failure at junit.framework.Assert.fail(Assert.java:143) at org.jboss.test.cts.test.StatefulSessionTest.testUserTrx(StatefulSessionTest.java:566) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:155) at junit.framework.TestCase.runBare(TestCase.java:129) at junit.framework.TestResult$1.protect(TestResult.java:100) at junit.framework.TestResult.runProtected(TestResult.java:117) at junit.framework.TestResult.run(TestResult.java:103) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.run(TestSuite.java:144) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:202) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:326) -
Re: [JBoss-dev] Unable to start JBOSS 2.2 on NT
Post this to jboss-user. You will not get an answer on this list. Toby. On Thu, Apr 26, 2001 at 07:43:19PM -0400, Amit Banerji wrote: > I am getting the sealing violation error. I have tried clearing the classpath by >setting it to nothing. And still, JBOSS won't start. Any help will be appreciated. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Unable to start JBOSS 2.2 on NT
I am getting the sealing violation error. I have tried clearing the classpath by setting it to nothing. And still, JBOSS won't start. Any help will be appreciated. Thanks, -Amit Banerji [Info] Java version: 1.3.0,Sun Microsystems Inc.[Info] Java VM: Java HotSpot(TM) Client VM 1.3.0-C,Sun Microsystems Inc.[Info] System: Windows NT 4.0,x86[Shutdown] Shutdown hook added[Service Control] Registered with server[Default] java.lang.SecurityException: sealing violation[Default] at java.net.URLClassLoader.defineClass(URLClassLoader.java:234)[Default] at java.net.URLClassLoader.access$100(URLClassLoader.java:56)[Default] at java.net.URLClassLoader$1.run(URLClassLoader.java:195)[Default] at java.security.AccessController.doPrivileged(Native Method)[Default] at java.net.URLClassLoader.findClass(URLClassLoader.java:188)[Default] at java.lang.ClassLoader.loadClass(ClassLoader.java:297)[Default] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)[Default] at java.lang.ClassLoader.loadClass(ClassLoader.java:253)[Default] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)[Default] at java.lang.ClassLoader.defineClass0(Native Method)[Default] at java.lang.ClassLoader.defineClass(ClassLoader.java:486)[Default] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)[Default] at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)[Default] at java.net.URLClassLoader.access$100(URLClassLoader.java:56)[Default] at java.net.URLClassLoader$1.run(URLClassLoader.java:195)[Default] at java.security.AccessController.doPrivileged(Native Method)[Default] at java.net.URLClassLoader.findClass(URLClassLoader.java:188)[Default] at java.lang.ClassLoader.loadClass(ClassLoader.java:297)[Default] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)[Default] at java.lang.ClassLoader.loadClass(ClassLoader.java:253)[Default] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)[Default] at org.apache.crimson.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(DocumentBuilderFactoryImpl.java:82)[Default] at org.jboss.configuration.ConfigurationService.loadConfiguration(ConfigurationService.java:258)[Default] at java.lang.reflect.Method.invoke(Native Method)[Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)[Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)[Default] at org.jboss.Main.(Main.java:195)[Default] at org.jboss.Main$1.run(Main.java:107)[Default] at java.security.AccessController.doPrivileged(Native Method)[Default] at org.jboss.Main.main(Main.java:103)[Default] JBoss 2.2.1 Started in 0m:1s[Default] Shutting down[Service Control] Stopping 0 MBeans[Service Control] Stopped 0 services[Service Control] Destroying 0 MBeans[Service Control] Destroyed 0 services[Default] Shutdown completePress any key to continue . . .
[JBoss-dev] [ jboss-Change Notes-419301 ] JMS Connector resource adapter
Change Notes item #419301, was updated on 2001-04-26 14:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=419301&group_id=22866 Category: None Group: None Status: Open Priority: 5 Submitted By: Peter Antman (pra) Assigned to: Nobody/Anonymous (nobody) Summary: JMS Connector resource adapter Initial Comment: A JMS Connector resource adapter has been added to the JBoss main trunk, under the package org.jboss.jms.ra. A new JMSProviderAdapter has also been added to support JMS ra with local transactions: JBossLocalTXProvider. The adapter is installed into dist/deploy/lib and an entry for a TX version have been added to jboss.jcml. I have left configuration for a LocalTransaction out of the default configuration, which will insted be documented in the JBoss docu. It is (probably) possible to get the ra to work also in JBoss 2.2.1, but it will not be added to that trunc in the CVS. The connector makes it possible to use JMS in beans as is specifyed in J2EE 1.3, namely as a truly transacted resource. It also makes it possible to deploy the Publisher example for the SUN JMS tutorial, with a jboss.xml file like this: false topicfactoryref java:/JmsXA topicref topic/testTopic Publisher publisher Standard Stateless SessionBean jms/MyTopicConnectionFactory topicfactoryref jms/TopicName topicref -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=419301&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/build build.xml
User: pra Date: 01/04/26 14:18:52 Modified:src/build build.xml Log: Added small testsuite for JMS Connector ra, will only work against the current cvs JBoss Revision ChangesPath 1.24 +16 -0 jbosstest/src/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosstest/src/build/build.xml,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- build.xml 2001/04/26 07:57:37 1.23 +++ build.xml 2001/04/26 21:18:52 1.24 @@ -385,6 +385,22 @@ includes="org/jboss/test/security/proxy/*" /> --> + + + + + + + + + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jmsra/bean Publisher.java PublisherBean.java PublisherCMP.java PublisherCMPBean.java PublisherCMPHome.java PublisherHome.java TopicAdapter.java TopicPublisherBean.java
User: pra
Date: 01/04/26 14:18:52
Added: src/main/org/jboss/test/jmsra/bean Publisher.java
PublisherBean.java PublisherCMP.java
PublisherCMPBean.java PublisherCMPHome.java
PublisherHome.java TopicAdapter.java
TopicPublisherBean.java
Log:
Added small testsuite for JMS Connector ra, will only work against the current cvs
JBoss
Revision ChangesPath
1.1 jbosstest/src/main/org/jboss/test/jmsra/bean/Publisher.java
Index: Publisher.java
===
package org.jboss.test.jmsra.bean;
import javax.ejb.EJBObject;
import java.rmi.RemoteException;
public interface Publisher extends EJBObject {
public static final String JMS_MESSAGE_NR = "MESSAGE_NR";
public void simple(int messageNr) throws RemoteException;
public void simpleFail(int messageNr) throws RemoteException;
public void beanOk(int messageNr) throws RemoteException;
public void beanError(int messageNr) throws RemoteException;
}
1.1 jbosstest/src/main/org/jboss/test/jmsra/bean/PublisherBean.java
Index: PublisherBean.java
===
package org.jboss.test.jmsra.bean;
import java.rmi.RemoteException;
import java.util.*;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
import javax.ejb.EJBException;
import javax.naming.*;
import javax.jms.*;
public class PublisherBean implements SessionBean {
private static final String CONNECTION_JNDI =
"java:comp/env/jms/MyQueueConnection";
private static final String QUEUE_JNDI = "java:comp/env/jms/QueueName";
private static final String BEAN_JNDI = "java:comp/env/ejb/PublisherCMP";
private SessionContext ctx = null;
private Queue queue = null;
private QueueConnection queueConnection = null;
public PublisherBean() {
}
public void setSessionContext(SessionContext ctx) {
this.ctx = ctx;
}
public void ejbCreate() throws EJBException {
try {
Context context = new InitialContext();
queue = (Queue)context.lookup(QUEUE_JNDI);
QueueConnectionFactory factory =
(QueueConnectionFactory)context.lookup(CONNECTION_JNDI);
queueConnection = factory.createQueueConnection();
} catch (Exception ex) {
// JMSException or NamingException could be thrown
ex.printStackTrace();
throw new EJBException(ex.toString());
}
}
/**
* Send a message with a message nr in property MESSAGE_NR
*/
public void simple(int messageNr) throws EJBException {
sendMessage(messageNr);
}
/**
* Try send a message with a message nr in property MESSAGE_NR,
* but set rollback only
*/
public void simpleFail(int messageNr) throws EJBException {
sendMessage(messageNr);
// Roll it back, no message should be sent if transactins work
System.err.println("DEBUG: Setting rollbackOnly");
ctx.setRollbackOnly();
System.err.println("DEBUG rollback set: " + ctx.getRollbackOnly());
}
public void beanOk(int messageNr) throws EJBException{
// DO JMS - First transaction
sendMessage(messageNr);
PublisherCMPHome h = null;
try {
// DO entity bean - Second transaction
h = (PublisherCMPHome) new InitialContext().lookup(BEAN_JNDI);
PublisherCMP b = h.create(new Integer(messageNr));
b.ok(messageNr);
}catch(Exception ex) {
throw new EJBException("OPS exception in ok: " + ex);
} finally {
try {
h.remove(new Integer(messageNr));
}catch(Exception e) {
e.printStackTrace();
}
}
}
public void beanError(int messageNr) throws EJBException{
// DO JMS - First transaction
sendMessage(messageNr);
PublisherCMPHome h = null;
try {
// DO entity bean - Second transaction
h = (PublisherCMPHome) new InitialContext().lookup(BEAN_JNDI);
PublisherCMP b = h.create(new Integer(messageNr));
b.error(messageNr);
} catch(Exception ex) {
throw new EJBException("Exception in erro: " + ex);
}finally {
try {
h.remove(new Integer(messageNr));
}catch(Exception ex) {
ex.printStackTrace();
}
}
}
public void ejbRemove() throws RemoteException {
if(queueConnection != null) {
try {
queueConnection.close();
}
[JBoss-dev] CVS update: jbosstest/src/resources/jmsra client.policy jndi.properties
User: pra
Date: 01/04/26 14:18:53
Added: src/resources/jmsra client.policy jndi.properties
Log:
Added small testsuite for JMS Connector ra, will only work against the current cvs
JBoss
Revision ChangesPath
1.1 jbosstest/src/resources/jmsra/client.policy
Index: client.policy
===
grant {
// Allow everything for now
permission java.security.AllPermission;
};
1.1 jbosstest/src/resources/jmsra/jndi.properties
Index: jndi.properties
===
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jnp.interfaces
java.naming.provider.url=localhost
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/bin jmsratest.sh
User: pra Date: 01/04/26 14:18:52 Added: src/bin jmsratest.sh Log: Added small testsuite for JMS Connector ra, will only work against the current cvs JBoss Revision ChangesPath 1.1 jbosstest/src/bin/jmsratest.sh Index: jmsratest.sh === #!/bin/sh CP=../lib/jmsratest.jar CP=../lib/junit.jar:$CP CP=../lib/jndi.jar:$CP CP=../lib/jnp-client.jar:$CP CP=../lib/ejb.jar:$CP CP=../lib/jboss-client.jar:$CP CP=../lib/jbossmq-client.jar:$CP CP=../lib/jaas.jar:$CP CP=../lib/jms.jar:$CP java -Djava.security.auth.login.config==file:../lib/auth.conf -Djava.security.policy=jar:file:../lib/jmsratest.jar!/client.policy -Djava.security.manager -classpath $CP junit.swingui.TestRunner org.jboss.test.jmsra.test.AllJUnitTest ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/jmsra/META-INF ejb-jar.xml jboss.xml
User: pra Date: 01/04/26 14:18:53 Added: src/resources/jmsra/META-INF ejb-jar.xml jboss.xml Log: Added small testsuite for JMS Connector ra, will only work against the current cvs JBoss Revision ChangesPath 1.1 jbosstest/src/resources/jmsra/META-INF/ejb-jar.xml Index: ejb-jar.xml === Queue Publisher PublisherBean Publisher QueuePublisher org.jboss.test.jmsra.bean.PublisherHome org.jboss.test.jmsra.bean.Publisher org.jboss.test.jmsra.bean.PublisherBean Stateless Container A Queue ConnectionFactory jms/MyQueueConnection javax.jms.QueueConnectionFactory Container A Queue jms/QueueName javax.jms.Queue Container ejb/PublisherCMP Entity org.jboss.test.jmsra.bean.PublisherCMPHome org.jboss.test.jmsra.bean.PublisherCMP PublisherCMP TopicPublisher TopicPublisher org.jboss.test.jmsra.bean.PublisherHome org.jboss.test.jmsra.bean.Publisher org.jboss.test.jmsra.bean.TopicPublisherBean Stateless Container A Topic ConnectionFactory jms/MyTopicConnection javax.jms.TopicConnectionFactory Container A Topic jms/TopicName javax.jms.Topic Container ejb/PublisherCMP Entity org.jboss.test.jmsra.bean.PublisherCMPHome org.jboss.test.jmsra.bean.PublisherCMP PublisherCMP Publisher Entity PublisherCMP org.jboss.test.jmsra.bean.PublisherCMPHome org.jboss.test.jmsra.bean.PublisherCMP org.jboss.test.jmsra.bean.PublisherCMPBean Container java.lang.Integer True Nr nr nr TopicAdapter org.jboss.test.jmsra.bean.TopicAdapter Container javax.jms.Topic NonDurable A Queue ConnectionFactory jms/MyQueueConnection javax.jms.QueueConnectionFactory Container A Queue jms/QueueName javax.jms.Queue Container TopicAdapter * Required 1.1 jbosstest/src/resources/jmsra/META-INF/jboss.xml Index: jboss.xml === false queuefactoryref java:/JmsXA queueref queue/testQueue topicfactoryref java:/JmsXA topicref topic/testTopic QueuePublisher TxPublisher Standard Stateless SessionBean jms/MyQueueConnection queuefactoryref jms/QueueName queueref ejb/PublisherCMP TopicPublisher TxTopicPublisher Standard Stateless SessionBean jms/MyTopicConnection topicfactoryref jms/TopicName topicref ejb/PublisherCMP PublisherCMP PublisherCMP TopicAdapter Standard Message Driven Bean topic/testTopic jms/MyQueueConnection queuefactoryref jms/QueueName queueref ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jmsra/test AllJUnitTest.java TestRa.java
User: pra
Date: 01/04/26 14:18:53
Added: src/main/org/jboss/test/jmsra/test AllJUnitTest.java
TestRa.java
Log:
Added small testsuite for JMS Connector ra, will only work against the current cvs
JBoss
Revision ChangesPath
1.1 jbosstest/src/main/org/jboss/test/jmsra/test/AllJUnitTest.java
Index: AllJUnitTest.java
===
/*
* Copyright (c) 2001 Peter Antman Tim <[EMAIL PROTECTED]>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
package org.jboss.test.jmsra.test;
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
/**
* TestSuite.java
*
*
* Created: Mon Apr 23 22:08:13 2001
*
* @author
* @version
*/
public class AllJUnitTest extends TestCase{
public AllJUnitTest(String name) {
super(name);
}
public static Test suite ()
{
TestSuite suite = new TestSuite();
try{
System.out.println("Deploying");
new org.jboss.jmx.client.Deployer().deploy("../deploy/jmsra.jar");
System.out.println("Testing Queue publishing");
suite.addTest(new TestRa("testSimple", "TxPublisher"));
suite.addTest(new TestRa("testSimpleFail", "TxPublisher"));
suite.addTest(new TestRa("testBeanOk", "TxPublisher"));
suite.addTest(new TestRa("testBeanError", "TxPublisher"));
System.out.println("Testing topic publishing");
suite.addTest(new TestRa("testSimple", "TxTopicPublisher"));
suite.addTest(new TestRa("testSimpleFail", "TxTopicPublisher"));
suite.addTest(new TestRa("testBeanOk", "TxTopicPublisher"));
suite.addTest(new TestRa("testBeanError", "TxTopicPublisher"));
} catch (Exception ex) {
ex.printStackTrace();
System.exit(0);
}
return suite;
}
public static void main(String[] args) {
}
} // TestSuite
1.1 jbosstest/src/main/org/jboss/test/jmsra/test/TestRa.java
Index: TestRa.java
===
/*
* Copyright (c) 2001 Peter Antman Tim <[EMAIL PROTECTED]>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
package org.jboss.test.jmsra.test;
import org.jboss.test.jmsra.bean.*;
import javax.jms.*;
import javax.naming.InitialContext;
import javax.naming.Context;
/**
* TestRa.java
*
*
* Created: Mon Apr 23 21:35:25 2001
*
* @author
* @version
*/
public class TestRa extends junit.framework.TestCase
implements MessageListener{
private String QUEUE_FACTORY = "QueueConnectionFactory";
private String QUEUE = "queue/testQueue";
private String beanJNDI;
private QueueConnection queueConnection;
private QueueSession queueSession;
private QueueReceiver queueReceiver;
private Queue queue;
private Publisher publisher;
private String n;
public TestRa(String name, String beanJNDI) throws Exception {
super(name);
n = name;
this.beanJNDI = beanJNDI;
setUp();
}
protected void printHeader() {
System.out.println("\n Testing method " + n +
[JBoss-dev] CVS update: jbosstest/src/resources/jmsra/META-INF - New directory
User: pra Date: 01/04/26 14:12:40 jbosstest/src/resources/jmsra/META-INF - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/jmsra - New directory
User: pra Date: 01/04/26 14:11:59 jbosstest/src/resources/jmsra - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jmsra/bean - New directory
User: pra Date: 01/04/26 14:09:54 jbosstest/src/main/org/jboss/test/jmsra/bean - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jmsra - New directory
User: pra Date: 01/04/26 14:09:32 jbosstest/src/main/org/jboss/test/jmsra - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jmsra/test - New directory
User: pra Date: 01/04/26 14:09:54 jbosstest/src/main/org/jboss/test/jmsra/test - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default jboss.jcml
User: pra Date: 01/04/26 14:06:54 Modified:src/etc/conf/default jboss.jcml Log: Added entry for JMS connector ra with TX support Revision ChangesPath 1.27 +34 -0 jboss/src/etc/conf/default/jboss.jcml Index: jboss.jcml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/jboss.jcml,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- jboss.jcml2001/04/20 08:40:59 1.26 +++ jboss.jcml2001/04/26 21:06:54 1.27 @@ -310,6 +310,40 @@ --> + + +JmsXA +JCA:service=RARDeployer +JMS Adapter +MinervaXACMFactory + + + # Pool type - uncomment to force, otherwise it is the default + #PoolConfiguration=per-factory + + # Connection pooling properties - see + # org.opentools.minerva.pool.PoolParameters + MinSize=0 + MaxSize=10 + Blocking=true + GCEnabled=false + IdleTimeoutEnabled=false + InvalidateOnError=false + TrackLastUsed=false + GCIntervalMillis=12 + GCMinIdleMillis=120 + IdleTimeoutMillis=180 + MaxIdleTimeoutPercent=1.0 + + + +org.jboss.resource.security.ManyToOnePrincipalMapping + + + + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/jms/ra/META-INF ra.xml
User: pra Date: 01/04/26 14:04:07 Added: src/resources/org/jboss/jms/ra/META-INF ra.xml Log: Added resources for JMS connector ra Revision ChangesPath 1.1 jboss/src/resources/org/jboss/jms/ra/META-INF/ra.xml Index: ra.xml === http://java.sun.com/j2ee/dtds/connector_1_0.dtd'> JMS Adapter JBoss org 1.0 1.0 JMS org.jboss.jms.ra.JmsManagedConnectionFactory org.jboss.jms.ra.client.JmsConnectionFactory org.jboss.jms.ra.JmsConnectionFactoryImp javax.jms.Session org.jboss.jms.ra.JmsSession xa_transaction JmsProviderAdapterJNDI java.lang.String java:DefaultJMSProvider basic-password javax.resource.security.PasswordCredential false ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/build build.xml
User: pra
Date: 01/04/26 14:05:57
Modified:src/build build.xml
Log:
Added build stuff for JMS resource adapter; installs jms-ra.rar in deploy/lib for
default deploy
Revision ChangesPath
1.68 +16 -1 jboss/src/build/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jboss/src/build/build.xml,v
retrieving revision 1.67
retrieving revision 1.68
diff -u -r1.67 -r1.68
--- build.xml 2001/04/22 18:24:52 1.67
+++ build.xml 2001/04/26 21:05:57 1.68
@@ -190,7 +190,7 @@
basedir="${build.classes.dir}"
manifest="${etc.dir}/jboss.mf"
includes="org/jboss/**"
-
excludes="org/jboss/Main*,org/jboss/ejb/deployment/**,org/jboss/security/SecurityAssociation.class,org/jboss/security/SimplePrincipal.class,org/jboss/security/SimpleGroup.class,org/jboss/ejb/plugins/jaws/deployment/**,org/jboss/dependencies/**,org/jboss/security/**/*LoginModule.class,org/jboss/tm/GlobalId.class"
+
excludes="org/jboss/Main*,org/jboss/ejb/deployment/**,org/jboss/security/SecurityAssociation.class,org/jboss/security/SimplePrincipal.class,org/jboss/security/SimpleGroup.class,org/jboss/ejb/plugins/jaws/deployment/**,org/jboss/dependencies/**,org/jboss/security/**/*LoginModule.class,org/jboss/tm/GlobalId.class,org/jboss/jms/ra/META-INF*"
/>
@@ -230,6 +230,18 @@
manifest="${etc.dir}/connector.mf"
includes="org/jboss/jmx/interfaces/JMXConnector.class,org/jboss/jmx/interfaces/JMXConnectorMBean.class,org/jboss/jmx/interfaces/RMIConnector.class,org/jboss/jmx/interfaces/RMINotificationListener.class,org/jboss/jmx/client/RMIClientConnectorImpl*.class,org/jboss/jmx/server/RMIConnectorImpl_Stub.class,org/jboss/jmx/server/ObjectHandler.class,org/jboss/jmx/client/ConnectorFactory*.class,org/jboss/util/Service.class,org/jboss/util/ServiceMBean*.class,org/jboss/logging/Log.class,org/jboss/logging/Log$$*.class,test/jboss/jmx/TestClient*.class"
/>
+
+
+
+
+
+
@@ -326,6 +338,9 @@
+
+
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/jms/ra/META-INF - New directory
User: pra Date: 01/04/26 14:03:08 jboss/src/resources/org/jboss/jms/ra/META-INF - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jms/ra/client - New directory
User: pra Date: 01/04/26 13:58:35 jboss/src/main/org/jboss/jms/ra/client - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jms/ra JmsConnectionFactoryImpl.java JmsConnectionManager.java JmsConnectionRequestInfo.java JmsCred.java JmsLocalTransaction.java JmsLogger.java JmsManagedConnection.java JmsManagedConnectionFactory.java JmsMetaData.java JmsSession.java JmsSessionFactoryImpl.java Level.java TestClient.java
User: pra
Date: 01/04/26 14:02:13
Added: src/main/org/jboss/jms/ra JmsConnectionFactoryImpl.java
JmsConnectionManager.java
JmsConnectionRequestInfo.java JmsCred.java
JmsLocalTransaction.java JmsLogger.java
JmsManagedConnection.java
JmsManagedConnectionFactory.java JmsMetaData.java
JmsSession.java JmsSessionFactoryImpl.java
Level.java TestClient.java
Log:
Added classes for a JMS connector resource adapter
Revision ChangesPath
1.1 jboss/src/main/org/jboss/jms/ra/JmsConnectionFactoryImpl.java
Index: JmsConnectionFactoryImpl.java
===
/*
* Copyright (c) 2001 Peter Antman Tim <[EMAIL PROTECTED]>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
package org.jboss.jms.ra;
import java.io.Serializable;
import javax.naming.Reference;
import javax.resource.Referenceable;
import javax.resource.ResourceException;
import javax.resource.spi.ManagedConnectionFactory;
import javax.resource.spi.ConnectionManager;
import javax.jms.JMSException;
import javax.jms.QueueConnection;
import javax.jms.TopicConnection;
import org.jboss.jms.ra.client.JmsConnectionFactory;
/**
* JmsConnectionFactoryImpl.java
*
*
* Created: Thu Apr 26 17:02:50 2001
*
* @author Peter Antman ([EMAIL PROTECTED])
* @version $Revision: 1.1 $
*/
public class JmsConnectionFactoryImpl
implements JmsConnectionFactory,Serializable, Referenceable {
private Reference reference;
/**
* JmsRa own factory
*/
private ManagedConnectionFactory mcf;
/**
* Hook to the appserver
*/
private ConnectionManager cm;
public JmsConnectionFactoryImpl(ManagedConnectionFactory mcf,
ConnectionManager cm)
{
this.mcf = mcf;
this.cm = cm;
if (cm == null) {
// This is standalone usage, no appserver
this.cm = new JmsConnectionManager();
} else {
this.cm = cm;
}
}
public void setReference(Reference reference)
{
this.reference = reference;
}
public Reference getReference()
{
return reference;
}
// --- QueueConnectionFactory
public QueueConnection createQueueConnection()
throws JMSException
{
JmsSessionFactoryImpl s = new JmsSessionFactoryImpl(mcf,cm);
s.isTopic(Boolean.FALSE);
return s;
}
public QueueConnection createQueueConnection(String userName,
String password)
throws JMSException
{
JmsSessionFactoryImpl s = new JmsSessionFactoryImpl(mcf,cm);
s.isTopic(Boolean.FALSE);
s.setUserName(userName);
s.setPassword(password);
return s;
}
// --- TopicConnectionFactory
public TopicConnection createTopicConnection()
throws JMSException
{
JmsSessionFactoryImpl s = new JmsSessionFactoryImpl(mcf,cm);
s.isTopic(Boolean.TRUE);
return s;
}
public TopicConnection createTopicConnection(String userName,
String password)
throws JMSException
{
JmsSessionFactoryImpl s = new JmsSessionFactoryImpl(mcf,cm);
s.isTopic(Boolean.TRUE);
s.setUserName(userName);
s.setPassword(password);
return s;
}
} // JmsConnectionFactoryImpl
1.1 jboss/src/main/org/jboss/jms/ra/JmsConnectionManager.java
Index: JmsConnectionManager.java
===
/*
* Copyright (c) 2001 Peter Antman Tim <[EMAIL PROTECTED]>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at yo
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/jms - New directory
User: pra Date: 01/04/26 14:02:43 jboss/src/resources/org/jboss/jms - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jms/ra/client JmsConnectionFactory.java JmsSessionFactory.java
User: pra
Date: 01/04/26 14:02:14
Added: src/main/org/jboss/jms/ra/client JmsConnectionFactory.java
JmsSessionFactory.java
Log:
Added classes for a JMS connector resource adapter
Revision ChangesPath
1.1 jboss/src/main/org/jboss/jms/ra/client/JmsConnectionFactory.java
Index: JmsConnectionFactory.java
===
/*
* Copyright (c) 2001 Peter Antman Tim <[EMAIL PROTECTED]>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
package org.jboss.jms.ra.client;
import javax.jms.TopicConnectionFactory;
import javax.jms.QueueConnectionFactory;
/**
* JmsConnectionFactory.java
*
*
* Created: Thu Apr 26 17:01:35 2001
*
* @author Peter Antman ([EMAIL PROTECTED])
* @version $Revision: 1.1 $
*/
public interface JmsConnectionFactory
extends TopicConnectionFactory, QueueConnectionFactory
{
} // JmsConnectionFactory
1.1 jboss/src/main/org/jboss/jms/ra/client/JmsSessionFactory.java
Index: JmsSessionFactory.java
===
/*
* Copyright (c) 2001 Peter Antman Tim <[EMAIL PROTECTED]>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
package org.jboss.jms.ra.client;
import javax.jms.TopicConnection;
import javax.jms.QueueConnection;
/**
* A marker interface to join topics and queues into one
factory.
*
*
* Created: Thu Mar 29 15:37:21 2001
*
* @author Peter Antman ([EMAIL PROTECTED])
* @version $Revision: 1.1 $
*/
public interface JmsSessionFactory extends TopicConnection,QueueConnection {
} // JmsSessionFactory
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/jms/ra - New directory
User: pra Date: 01/04/26 14:02:56 jboss/src/resources/org/jboss/jms/ra - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jms/jndi JBossLocalTXProvider.java
User: pra
Date: 01/04/26 14:02:13
Added: src/main/org/jboss/jms/jndi JBossLocalTXProvider.java
Log:
Added classes for a JMS connector resource adapter
Revision ChangesPath
1.1 jboss/src/main/org/jboss/jms/jndi/JBossLocalTXProvider.java
Index: JBossLocalTXProvider.java
===
/*
* Copyright (c) 2000 Peter Antman DN <[EMAIL PROTECTED]>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
package org.jboss.jms.jndi;
import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
/**
* A JMS provider adapter for JBossMQ with non transacted factories.
*
* May be used to get LocalTransaction in JMS ra.
*
* Created: Fri Dec 22 09:34:04 2000
*
* @author Peter Antman ([EMAIL PROTECTED])
* @version $Revision: 1.1 $
*/
public class JBossLocalTXProvider
extends JBossMQProvider
{
public static final String TOPIC_CONNECTION_FACTORY = "TopicConnectionFactory";
public static final String QUEUE_CONNECTION_FACTORY = "QueueConnectionFactory";
public JBossLocalTXProvider() {
super();
// Hackish
queueFactoryName =QUEUE_CONNECTION_FACTORY;
topicFactoryName = TOPIC_CONNECTION_FACTORY;
}
} // JBossMQProvider
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jms/ra - New directory
User: pra Date: 01/04/26 13:57:42 jboss/src/main/org/jboss/jms/ra - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Remote Proxies do not know the server they came from
Jason Dillon wrote:
> I spent some time (long ago...) fixing this very problem, but I have not
> really had time to integrate it into the latest codeline. I can put some
> more effort into fixing this soon.
I really would appreciate that.
> Does anyone happen to know what the EJB spec says about handles and if they
> should return bean refs to the *exact* server which they came from? I can
> not recall any real detail about handles except that they are used to allow
> clients to restore a reference to a given bean.
I don't think so. In a clustering environment, that cannot be guaranteed anyway. The
spec (1.1) talks about handles in section 8.7 and 8.8.
> Any ways, I do not think that this will take that long to fix. I can
> probably make this optional too (via a property that will enable the new
> behavior). The only problem that I remember running into was when the proxy
> is generated there isn't an easy way to find out what the provider url is for
> the current machine (in a non-jboss specific fashion). Perhaps that has
> changed.
>
> What I might do is force users who are interested in this, to provide some
> extra properties (or another jndi properties file) that specifies the exact
> environment properties required to restore a bean from a handle.
I think, that is the best way, because you cannot determine the host name of a server.
-alf
> --jason
>
>
> On Thu, 26 Apr 2001, Alf Werder wrote:
>
>
>> Hi,
>>
>> The last two months I made my first experiences with jboss as a bean
>> developer. I am really surprised and impressed by the work, that is
>> done. But now, the first serious problem arised.
>>
>> In an EJB client a tried to obtain the home interface of a bean from its
>> remote interface. But a call to EJBObject.getEJBHome() throws an
>> exception. That was the first sign. Later, I tried to use a HomeHandle
>> to reobtain a home interface after a server restart.
>> HomeHandel.getEJBHome() throws an exception.
>>
>> I had a deeper look and found the problem: My code was
>>
>>Hashtable env = new Hashtable();
>>env.put("java.naming.factory.initial",
>> "org.jnp.interfaces.NamingContextFactory");
>>env.put("java.naming.provider.url", "localhost:1099");
>>env.put("java.naming.factory.url.pkgs", "org.jboss.naming");
>>
>>MyHome home = (MyHome) new InitialContext(env).lookup("MyHome");
>>MyHome h = (MyHome) home.getHomeHandle().getEJBHome();
>>
>> The last line throws the exception. It works, when I change the code to:
>>
>>Hashtable env = new Hashtable();
>>System.setProperty("java.naming.factory.initial",
>> "org.jnp.interfaces.NamingContextFactory");
>>System.setProperty("java.naming.provider.url", "localhost:1099");
>>System.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming");
>>
>> MyHome home = (MyHome) new InitialContext().lookup("MyHome");
>> MyHome h = (MyHome) home.getHomeHandle().getEJBHome();
>>
>> So had a look into the jboss source code. The HomeHandle implementation
>> simply does not know the server, is came from. It just creates a new
>> inital context without any Arguments. So it gets the local root context,
>> which is not the context its home interface is bound to.
>>
>> -alf
>>
>>
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
--
Alf Werder | System Engineering | TOMORROW Technologies GmbH
Oberstraße 14b | D-20144 Hamburg
Mail: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JavaOne
How do we sign up for it? marc fleury wrote: > We are giving a BOF, mandatory presence for all those on this list, free > tshirts > > marc > > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of Jason > |Dillon > |Sent: Wednesday, April 25, 2001 12:40 AM > |To: [EMAIL PROTECTED] > |Subject: [JBoss-dev] JavaOne > | > | > |Just curious if anyone is going to be going to JavaOne this year? > | > |--jason > | > | > |___ > |Jboss-development mailing list > |[EMAIL PROTECTED] > |http://lists.sourceforge.net/lists/listinfo/jboss-development > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Remote Proxies do not know the server they came from
- Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, April 26, 2001 12:10 PM Subject: Re: [JBoss-dev] Remote Proxies do not know the server they came from > I spent some time (long ago...) fixing this very problem, but I have not > really had time to integrate it into the latest codeline. I can put some > more effort into fixing this soon. > > Does anyone happen to know what the EJB spec says about handles and if they > should return bean refs to the *exact* server which they came from? I can > not recall any real detail about handles except that they are used to allow > clients to restore a reference to a given bean. > No it does not require this and it would not make sense to be exact as the handle should be valid across server restarts. The exact location of the server may well change during the lifetime of the handle. > Any ways, I do not think that this will take that long to fix. I can > probably make this optional too (via a property that will enable the new > behavior). The only problem that I remember running into was when the proxy > is generated there isn't an easy way to find out what the provider url is for > the current machine (in a non-jboss specific fashion). Perhaps that has > changed. > > What I might do is force users who are interested in this, to provide some > extra properties (or another jndi properties file) that specifies the exact > environment properties required to restore a bean from a handle. > You want the ability to specify the the jndi properties that are associated with a handle in general because you can't determine what the correct hostname/ip of the server machine is. It could be some internal name/ip that can't be used externally. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Bug in jnp (handling references to remote JNDI servers)
marc fleury wrote: > call for that?), and frankly I just don't know how that is done. Does this > work on BEA Yes, it does. Even more, the Proxies generated by BEA are that robust, that tey are still useable, even if the server as been down in the meanwhile. -alf -- Alf Werder | System Engineering | TOMORROW Technologies GmbH Oberstraße 14b | D-20144 Hamburg Mail: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Remote Proxies do not know the server they came from
It is part of the ejb 1.1 spec (see section 8.7 and 8.8). Maybe even 1.0. It's ment to be a robust reference to the entities remote or home interface, that can be serialized, to put it into a DB or pass it to another machine. -alf marc fleury wrote: > is the handle part of the new EJB spec? it is a strange construct... > > marc > > |So had a look into the jboss source code. The HomeHandle implementation > |simply does not know the server, is came from. It just creates a new > |inital context without any Arguments. So it gets the local root context, > |which is not the context its home interface is bound to. > | > |-alf > | > |-- > |Alf Werder | System Engineering | TOMORROW Technologies GmbH > |Oberstraße 14b | D-20144 Hamburg > |Mail: [EMAIL PROTECTED] > | > | > |___ > |Jboss-development mailing list > |[EMAIL PROTECTED] > |http://lists.sourceforge.net/lists/listinfo/jboss-development > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development -- Alf Werder | System Engineering | TOMORROW Technologies GmbH Oberstraße 14b | D-20144 Hamburg Mail: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Remote Proxies do not know the server they came from
I spent some time (long ago...) fixing this very problem, but I have not
really had time to integrate it into the latest codeline. I can put some
more effort into fixing this soon.
Does anyone happen to know what the EJB spec says about handles and if they
should return bean refs to the *exact* server which they came from? I can
not recall any real detail about handles except that they are used to allow
clients to restore a reference to a given bean.
Any ways, I do not think that this will take that long to fix. I can
probably make this optional too (via a property that will enable the new
behavior). The only problem that I remember running into was when the proxy
is generated there isn't an easy way to find out what the provider url is for
the current machine (in a non-jboss specific fashion). Perhaps that has
changed.
What I might do is force users who are interested in this, to provide some
extra properties (or another jndi properties file) that specifies the exact
environment properties required to restore a bean from a handle.
--jason
On Thu, 26 Apr 2001, Alf Werder wrote:
> Hi,
>
> The last two months I made my first experiences with jboss as a bean
> developer. I am really surprised and impressed by the work, that is
> done. But now, the first serious problem arised.
>
> In an EJB client a tried to obtain the home interface of a bean from its
> remote interface. But a call to EJBObject.getEJBHome() throws an
> exception. That was the first sign. Later, I tried to use a HomeHandle
> to reobtain a home interface after a server restart.
> HomeHandel.getEJBHome() throws an exception.
>
> I had a deeper look and found the problem: My code was
>
>Hashtable env = new Hashtable();
>env.put("java.naming.factory.initial",
> "org.jnp.interfaces.NamingContextFactory");
>env.put("java.naming.provider.url", "localhost:1099");
>env.put("java.naming.factory.url.pkgs", "org.jboss.naming");
>
>MyHome home = (MyHome) new InitialContext(env).lookup("MyHome");
>MyHome h = (MyHome) home.getHomeHandle().getEJBHome();
>
> The last line throws the exception. It works, when I change the code to:
>
>Hashtable env = new Hashtable();
>System.setProperty("java.naming.factory.initial",
> "org.jnp.interfaces.NamingContextFactory");
>System.setProperty("java.naming.provider.url", "localhost:1099");
>System.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming");
>
> MyHome home = (MyHome) new InitialContext().lookup("MyHome");
> MyHome h = (MyHome) home.getHomeHandle().getEJBHome();
>
> So had a look into the jboss source code. The HomeHandle implementation
> simply does not know the server, is came from. It just creates a new
> inital context without any Arguments. So it gets the local root context,
> which is not the context its home interface is bound to.
>
> -alf
>
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Bug in jnp (handling references to remote JNDI servers)
|> To fix this, all proxy objects need to know the host, they are
|> originating from.
If you really want to do that (because you really need to use the code you
just showed us) then go ahead and work on the JNP stub classes also the home
must be able to extract that information from the IC (is there a standard
call for that?), and frankly I just don't know how that is done. Does this
work on BEA
Like I said a strange construct but if you do it you will have proven
something, what I don't know exactly ...
One way I can see it working is by encoding the server in the stub,
independently of the JNP provider... h... no that won't work either
since you actually need the JNP provider...
pfff you do it!
marc
|>
|> Hashtable env = new Hashtable();
|> env.put("java.naming.factory.initial",
|> "org.jnp.interfaces.NamingContextFactory");
|> env.put("java.naming.provider.url", host);
|>
|> new InitialContext(env).lookup(name);
|>
|>
|> -alf
|>
|
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Bug in jnp (handling references to remote JNDI servers)
Right, the name should be the full jnp url not just the local jndi name.
- Original Message -
From: "Alf Werder" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 26, 2001 8:50 AM
Subject: Re: [JBoss-dev] Bug in jnp (handling references to remote JNDI servers)
> The problem is a lack of information, the handle and the proxy object
> has. If you look into
> org/jboss/ejb/plugins/jrmp/interfaces/EntityHandleImp.java, you can see
> it. The implementation of 'getEJBObject()' simply calls 'new
> InitialContext()' and gets the root context of JBoss2 on host2. To
> reobtain the entity one needs the root context of JBoss1 on host1, where
> the home interface of the baen is bound to 'name'.
>
> The handle does not have the information, where to find its own home
> interface. As far as I can see, not even the proxy object itself has
> this information.
>
> To fix this, all proxy objects need to know the host, they are
> originating from. So the can say something like
>
> Hashtable env = new Hashtable();
> env.put("java.naming.factory.initial",
> "org.jnp.interfaces.NamingContextFactory");
> env.put("java.naming.provider.url", host);
>
> new InitialContext(env).lookup(name);
>
>
> -alf
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Any objections to cut over to jboss-j2ee jars in main branch
On Thu, Apr 26, 2001 at 06:47:36AM -0400, Jay Walters wrote: > It looks like the jboss-j2ee stuff works defined as jboss compiles and runs > my beans. I will run the jbosstest suite again and if all works I'd like to > start going through all the sub-projects and replacing the sun jars with > ours. > > Any objections? Nope, as long as you don't call any of the jars "j2ee.jar". I can just imagine all of the "I replaced your j2ee.jar with a newer one from Sun..." questions. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Remote Proxies do not know the server they came from
You would need to adapt the home to remember the environment properties its InitialContext was created with. How do you do that? We would need to keep that information somewhere... somehow... is the handle part of the new EJB spec? it is a strange construct... marc |So had a look into the jboss source code. The HomeHandle implementation |simply does not know the server, is came from. It just creates a new |inital context without any Arguments. So it gets the local root context, |which is not the context its home interface is bound to. | |-alf | |-- |Alf Werder | System Engineering | TOMORROW Technologies GmbH |Oberstraße 14b | D-20144 Hamburg |Mail: [EMAIL PROTECTED] | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Any objections to cut over to jboss-j2ee jars in main branch
if it just works :) of course there is no objection. Make sure that the test are ok and put it in, marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jay |Walters |Sent: Thursday, April 26, 2001 6:48 AM |To: '[EMAIL PROTECTED]' |Subject: [JBoss-dev] Any objections to cut over to jboss-j2ee jars in |main branch | | |It looks like the jboss-j2ee stuff works defined as jboss compiles and runs |my beans. I will run the jbosstest suite again and if all works |I'd like to |start going through all the sub-projects and replacing the sun jars with |ours. | |Any objections? | |Cheers |Jay | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-419192 ] TM.setTransactionTimeout() bug
Bugs item #419192, was updated on 2001-04-26 10:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=419192&group_id=22866 Category: JBossTX Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ole Husgaard (sparre) Assigned to: Ole Husgaard (sparre) Summary: TM.setTransactionTimeout() bug Initial Comment: With the Fast in-VM TM, setTransactionTimeout() sets a global timeout value. But the Javadoc for TransactionManager says: "Modify the value of the timeout value that is associated with the transactions started by the current thread with the begin method." So a per-thread timeout value variable is needed. Only the DEFAULT timeout value should be global. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=419192&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Server Load Information
I want to find out programmatically ( through a JNDI exposed object maybe ) information about the server's load. Basic stuff, like how many beans are running, what types etc. Also memory, processor ( if JBoss can tell me such things... ). The more, the better. Any help would be appreciated. Thanks ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Bulk update of entity beans from a session bean
Hi, I've an application where I need to implement item by item and bulk updating of entity beans ie in some cases only a few entity beans are getting modified and in other cases a very large no of entity beans are getting modifed. I intend to use commit-option A and since JBoss has pessimistic concurrency control (one-instance-per-pk and Serialized call I learnt) , I am thinking of implementing bulk update of entity beans as follow for performance reasons. 1. use a BMT session bean and start transaction 2. update all records in the database 3. findByPKs() all entity beans 4. call a business method say, populate() on each entity bean and inside this method update the state of entity bean. Although this method sets the state of the bean it doesn't mark that bean as modified and hence IsModified() method return false (hence it will not be stored again) 5. commit the transaction. Please comment from a developmental prospective if it will work? What are the flaws ? Is there any other preferred way to do it ? Regards, SRP ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Remote Proxies do not know the server they came from
Hi,
The last two months I made my first experiences with jboss as a bean
developer. I am really surprised and impressed by the work, that is
done. But now, the first serious problem arised.
In an EJB client a tried to obtain the home interface of a bean from its
remote interface. But a call to EJBObject.getEJBHome() throws an
exception. That was the first sign. Later, I tried to use a HomeHandle
to reobtain a home interface after a server restart.
HomeHandel.getEJBHome() throws an exception.
I had a deeper look and found the problem: My code was
Hashtable env = new Hashtable();
env.put("java.naming.factory.initial",
"org.jnp.interfaces.NamingContextFactory");
env.put("java.naming.provider.url", "localhost:1099");
env.put("java.naming.factory.url.pkgs", "org.jboss.naming");
MyHome home = (MyHome) new InitialContext(env).lookup("MyHome");
MyHome h = (MyHome) home.getHomeHandle().getEJBHome();
The last line throws the exception. It works, when I change the code to:
Hashtable env = new Hashtable();
System.setProperty("java.naming.factory.initial",
"org.jnp.interfaces.NamingContextFactory");
System.setProperty("java.naming.provider.url", "localhost:1099");
System.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming");
MyHome home = (MyHome) new InitialContext().lookup("MyHome");
MyHome h = (MyHome) home.getHomeHandle().getEJBHome();
So had a look into the jboss source code. The HomeHandle implementation
simply does not know the server, is came from. It just creates a new
inital context without any Arguments. So it gets the local root context,
which is not the context its home interface is bound to.
-alf
--
Alf Werder | System Engineering | TOMORROW Technologies GmbH
Oberstraße 14b | D-20144 Hamburg
Mail: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Bug in jnp (handling references to remote JNDI servers)
The problem is a lack of information, the handle and the proxy object
has. If you look into
org/jboss/ejb/plugins/jrmp/interfaces/EntityHandleImp.java, you can see
it. The implementation of 'getEJBObject()' simply calls 'new
InitialContext()' and gets the root context of JBoss2 on host2. To
reobtain the entity one needs the root context of JBoss1 on host1, where
the home interface of the baen is bound to 'name'.
The handle does not have the information, where to find its own home
interface. As far as I can see, not even the proxy object itself has
this information.
To fix this, all proxy objects need to know the host, they are
originating from. So the can say something like
Hashtable env = new Hashtable();
env.put("java.naming.factory.initial",
"org.jnp.interfaces.NamingContextFactory");
env.put("java.naming.provider.url", host);
new InitialContext(env).lookup(name);
-alf
Scott M Stark wrote:
> I have not tried this case so I'm not sure that its the same problem. The
> problem seen by Anatoly has been fixed in the main branch so you could
> try your test case against the latest cvs code if you want.
>
> - Original Message -
> From: "Francisco Reverbel" <[EMAIL PROTECTED]>
> To: "JBoss-Dev" <[EMAIL PROTECTED]>
> Sent: Thursday, April 26, 2001 3:39 AM
> Subject: Re: [JBoss-dev] Bug in jnp (handling references to remote JNDI servers)
>
>
>
>> I run into a similar problem with EJB handles:
>>
>> BeanA is on host1, JBoss1
>> BeanB is on host2, JBoss2
>>
>> BeanA creates an EJB handle to one of its entity beans and saves it in a
>> file or database. BeanB somehow gets the serialized handle, deserializes
>> it, and attempts to use it. This does not work: JBoss2 does not attempt
>> to contact the remote server on host1.
>>
>> Francisco
>> --
>> Francisco Reverbel, Assistant Professor
>> Department of Computer Science [EMAIL PROTECTED]
>> University of Sao Paulo, Brazilhttp://www.ime.usp.br/~reverbel/
>>
>
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
--
Alf Werder | System Engineering | TOMORROW Technologies GmbH
Oberstraße 14b | D-20144 Hamburg
Mail: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/docs production.xml
User: starksm Date: 01/04/26 09:28:04 Modified:src/docs production.xml Log: The JNDI/RMI port is now configurable. Indicate this for JBoss 2.3+ Revision ChangesPath 1.2 +178 -178 manual/src/docs/production.xml Index: production.xml === RCS file: /cvsroot/jboss/manual/src/docs/production.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- production.xml2001/04/25 12:40:26 1.1 +++ production.xml2001/04/26 16:28:04 1.2 @@ -1,178 +1,178 @@ - - - JBoss in production - Author: - - Sebastien - Alborini - - [EMAIL PROTECTED] - - - - Introduction - - JBoss is now considered to be production ready. This section will give a few guidelines for putting JBoss in production use. I will first review the Hardware / OS / JVM compatibility question, and then give a few tips for tweaking your JBoss configuration for production use. - - JBoss is a completely modular application server, and thus it can be thoroughly configured. For ease of use reasons however, the default configuration is more intended for developpers than for administrators. This document will outline some of the options that you might reasonably want to change before putting JBoss in production. This includes settings for increased performance, enhanced security, and ease of administration. - - If you have other production tips and tricks, please share them with the JBoss community by posting them on the jboss-user mailing list. - - - - - Hardware / OS / JVM - JBoss is 100% pure Java, so it should run on any Java platform. The recommended JVM version is jdk1.3. JBoss used to run with jdk1.2.2 with a little tuning, but this is not supported anymore. - - For example, JBoss has been reported to run well on a variety of PCs with Windows NT / 2000 / Linux, on Sun/Solaris boxe, on MacOs X... - - Be aware however that JBoss performance is very dependant on the underlying configuration. For example, informal tests show that on the same PC box, it can run twice as fast under Windows 2000 / Sun JVM than under Linux 2.2 / Sun JVM. - - Linux users probably already know that linux does not support real threads. Under heavy load, JBoss will for example crash with 200 concurrent users under linux, whereas it can handle 1000 of them on the same box with Windows 2000. Of course, if you use Apache or Jetty in front of JBoss to handle the thread pooling, this will not be a problem. - - - - Security - Security is a nagging concern for the admin in charge of a production site. Some of JBoss default settings are not secure at all, so please read carefully. - - - Use EJB security - The EJB specification provides the possibility to restrict access to your beans on a per-method basis, using authentication and authorization. By default, JBoss does not enforce such restrictions, and any call is allowed through the container. To enforce a security policy in JBoss, you have to setup a security domain, define roles... For a description of EJB security in JBoss, see , or see . - - - - Open Ports - JBoss starts a number of services by default, which listen on a number of ports. For security reasons, you might want to firewall these ports and/or to close the corresponding services. The ports used by JBoss are shown in - - - Open Ports - - - - Port Number - JBoss service - Configured in - Description - Should be open to - - - - - 1099 - JNDI - jnp.properties - Used by clients to connect to JBoss to get the initial naming context. - EJB clients -
Re: [JBoss-dev] jboss daily test results
The timing increase seems to be do to the latest version of Hypersonic. I see a long pause(20-30) secs on the console after these msgs: [Hypersonic] Starting Server 1.4 is running Press [Ctrl]+[C] to abort ... JBoss 2.3 BETA Started in 0m:37s This used to start in under 10 secs on my box so something has really slowed down. > > I have found out why I am getting problems with this - I allow 20seconds for > the jboss server to startup - this used to be plenty - it now takes around > 40seconds on the same machine... > > So, I now allow 120seconds and we are back to the same errors again. > > I wonder if you can query the server/jmx to find out its startup time - > perhaps we could add a test to check this is less than a set time - although > I guess it varies from machine to machine... > > As I get time, I plan to look at the errors we are getting...see if we can > reduce them. > > Chris > _ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Bug in jnp (handling references to remote JNDI servers)
I have not tried this case so I'm not sure that its the same problem. The problem seen by Anatoly has been fixed in the main branch so you could try your test case against the latest cvs code if you want. - Original Message - From: "Francisco Reverbel" <[EMAIL PROTECTED]> To: "JBoss-Dev" <[EMAIL PROTECTED]> Sent: Thursday, April 26, 2001 3:39 AM Subject: Re: [JBoss-dev] Bug in jnp (handling references to remote JNDI servers) > I run into a similar problem with EJB handles: > > BeanA is on host1, JBoss1 > BeanB is on host2, JBoss2 > > BeanA creates an EJB handle to one of its entity beans and saves it in a > file or database. BeanB somehow gets the serialized handle, deserializes > it, and attempts to use it. This does not work: JBoss2 does not attempt > to contact the remote server on host1. > > Francisco > -- > Francisco Reverbel, Assistant Professor > Department of Computer Science [EMAIL PROTECTED] > University of Sao Paulo, Brazilhttp://www.ime.usp.br/~reverbel/ > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Any objections to cut over to jboss-j2ee jars in main branch
It looks like the jboss-j2ee stuff works defined as jboss compiles and runs my beans. I will run the jbosstest suite again and if all works I'd like to start going through all the sub-projects and replacing the sun jars with ours. Any objections? Cheers Jay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-j2ee/src/build build.xml
User: jwalters Date: 01/04/26 03:39:53 Modified:src/build build.xml Log: Split j2ee.jar up into two separate jars, jdbc-ext.jar and j2ee.jar. Fixed a few miscellaneous problems up so jboss and other projects will compile properly with these jars. Revision ChangesPath 1.6 +16 -3 jboss-j2ee/src/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss-j2ee/src/build/build.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- build.xml 2001/04/18 15:05:03 1.5 +++ build.xml 2001/04/26 10:39:53 1.6 @@ -36,8 +36,15 @@ - + + + + + @@ -70,11 +77,17 @@ + + + - + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-j2ee/src/main/javax/transaction/xa XAException.java
User: jwalters
Date: 01/04/26 03:39:53
Modified:src/main/javax/transaction/xa XAException.java
Log:
Split j2ee.jar up into two separate jars, jdbc-ext.jar and j2ee.jar. Fixed
a few miscellaneous problems up so jboss and other projects will compile
properly with these jars.
Revision ChangesPath
1.3 +31 -22jboss-j2ee/src/main/javax/transaction/xa/XAException.java
Index: XAException.java
===
RCS file: /cvsroot/jboss/jboss-j2ee/src/main/javax/transaction/xa/XAException.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- XAException.java 2001/04/01 13:52:44 1.2
+++ XAException.java 2001/04/26 10:39:53 1.3
@@ -9,54 +9,63 @@
/** The XAException is thown by the Resource Manager (RM) to inform the
Transaction Manager of error encountered for the transaction involved.
-@version $Revision: 1.2 $
+@version $Revision: 1.3 $
*/
public class XAException extends java.lang.Exception {
+public int errorCode = 0;
+
/** Creates new XAException without detail message.
*/
-public XAException()
-{
+public XAException() {
}
/** Constructs an XAException with the specified detail message.
@param msg the detail message.
*/
-public XAException(String msg)
-{
+public XAException(String msg) {
super(msg);
}
/** Constructs an XAException for the specified error code.
@param msg the detail message.
*/
-public XAException(int errorCode)
-{
+public XAException(int errorCode) {
super();
-
-_errorCode = errorCode;
-}
-
-// PUBLIC METHODS --
-
-public int getErrorCode()
-{
-return _errorCode;
+this.errorCode = errorCode;
}
// STATIC VARIABLES -
/** added by kimptoc - needed for jbossmq to compile... */
public static final int XAER_NOTA = 1001;
-/** added by kimptoc - needed for jbossmq to compile... */
public static final int XAER_RMERR = 1002;
-/** added by kimptoc - needed for jbossmq to compile... */
public static final int XAER_OUTSIDE = 1003;
-/** added by kimptoc - needed for jbossmq to compile... */
public static final int XAER_DUPID = 1004;
-
-// PRIVATE VARIABLE --
-private int _errorCode = -1;
+/** added by jwalters for completeness */
+public static final int XAER_ASYNC = 1005;
+public static final int XAER_INVAL = 1006;
+public static final int XAER_PROTO = 1007;
+public static final int XAER_RMFAIL= 1008;
+
+/** added by jwalters - needed for jboss */
+public static final int XA_HEURCOM = 1;
+public static final int XA_HEURHAZ = 2;
+public static final int XA_HEURMIX = 3;
+public static final int XA_HEURRB = 4;
+public static final int XA_NOMIGRATE = 5;
+public static final int XA_RDONLY = 6;
+public static final int XA_RETRY = 7;
+public static final int XA_RBBASE = 8;
+public static final int XA_RBCOMMFAIL = 8;
+public static final int XA_RBDEADLOCK = 9;
+public static final int XA_RBINTEGRITY = 10;
+public static final int XA_RBOTHER = 11;
+public static final int XA_RBPROTO = 12;
+public static final int XA_RBROLLBACK = 13;
+public static final int XA_RBTIMEOUT = 14;
+public static final int XA_RBTRANSIENT = 15;
+public static final int XA_RBEND = 15;
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Bug in jnp (handling references to remote JNDIservers)
I run into a similar problem with EJB handles: BeanA is on host1, JBoss1 BeanB is on host2, JBoss2 BeanA creates an EJB handle to one of its entity beans and saves it in a file or database. BeanB somehow gets the serialized handle, deserializes it, and attempts to use it. This does not work: JBoss2 does not attempt to contact the remote server on host1. Francisco -- Francisco Reverbel, Assistant Professor Department of Computer Science [EMAIL PROTECTED] University of Sao Paulo, Brazilhttp://www.ime.usp.br/~reverbel/ On Wed, 25 Apr 2001, Anatoly Akkerman wrote: > > It seems to me that there is a bug in JNP NamingContext.checkRef() method > > Here is when I encounter > > BeanA is on host1, JBoss1 > BeanB is on host2, JBoss2 > > BeanA is supposed to call BeanB, so it has an entry in jboss.xml that maps > ejb/BeanB > > to jnp://host2:port/testapp/BeanB > > After obtaining the LinkRef and resolving it, JNP does not contact the > remote server on the remote machine (checkRef() only obtains a new Naming > for the server if the current one is null, which is wrong in this case of > a remote reference, since we are leaving the current Naming of the local > machine and have to contact the remote now). One way to fix it is to > remove this if (naming == null) > > around checkRef() body but it would obviously hurt performace. Any better > ideas? > > - > Anatoly Akkerman > Computer Science Dept. > Courant Institute of Mathematical Sciences, NYU > 719 Broadway, #715 Tel: 212 998-3525 > New York, NY 10003 Fax: 212 995-4123 > - > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-j2ee/src/main/javax/ejb DuplicateKeyException.java
User: jwalters
Date: 01/04/26 03:39:53
Modified:src/main/javax/ejb DuplicateKeyException.java
Log:
Split j2ee.jar up into two separate jars, jdbc-ext.jar and j2ee.jar. Fixed
a few miscellaneous problems up so jboss and other projects will compile
properly with these jars.
Revision ChangesPath
1.2 +1 -1 jboss-j2ee/src/main/javax/ejb/DuplicateKeyException.java
Index: DuplicateKeyException.java
===
RCS file: /cvsroot/jboss/jboss-j2ee/src/main/javax/ejb/DuplicateKeyException.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- DuplicateKeyException.java2001/03/30 11:37:51 1.1
+++ DuplicateKeyException.java2001/04/26 10:39:53 1.2
@@ -13,7 +13,7 @@
* exists. This exception is thrown by the create methods defined in an
* enterprise Bean's home interface.
*/
-public class DuplicateKeyException extends Exception {
+public class DuplicateKeyException extends CreateException {
/**
* Constructs an DuplicateKeyException with no detail message.
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jdbc2_0-stdext.jar in /lib
Security, makes it so hard to get stuff done... Ok, I will break the former j2ee.jar into two pieces then, so we can put what needs to be in lib in lib, and the rest in lib/ext. Cheers -Original Message- From: Scott M Stark To: [EMAIL PROTECTED] Sent: 4/25/01 5:39 PM Subject: Re: [JBoss-dev] jdbc2_0-stdext.jar in /lib Yes, because of how JAAS does classloading it must be in the system classpath. - Original Message - From: "Jay Walters" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 25, 2001 9:49 AM Subject: RE: [JBoss-dev] jdbc2_0-stdext.jar in /lib > And it needs to load from lib not from lib/ext? The reason I am asking is > that it is the only bit of the j2ee replacement jar which we've built which > can't go in lib/ext right now. > > Cheers > > -Original Message- > From: Scott M Stark [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 25, 2001 12:40 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] jdbc2_0-stdext.jar in /lib > > > Its only used when someone configures it for their security domain. By > default it is not configured for use. > > - Original Message - > From: "Jay Walters" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, April 25, 2001 9:17 AM > Subject: RE: [JBoss-dev] jdbc2_0-stdext.jar in /lib > > > > Thanks for the reply. When does that module get used/what does it do? It > > seems that I can remove the jar file from lib and my jboss starts up and > > works... > > > > Cheers > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss daily test results
Hi, >From: "Scott M Stark" <[EMAIL PROTECTED]> > >The log4j classes have been in the lib/ext directory for quite a while now >(at least a month) as the Log4jService requires this. > I don't know what caused my problem with this - as it now starts fine. >I just pulled down a clean cvs co and built it and the server came up >without any problems. This is at Wed Apr 25 21:47:24 GMT. The >jbosstest suite is running normally against the build. > I have found out why I am getting problems with this - I allow 20seconds for the jboss server to startup - this used to be plenty - it now takes around 40seconds on the same machine... So, I now allow 120seconds and we are back to the same errors again. I wonder if you can query the server/jmx to find out its startup time - perhaps we could add a test to check this is less than a set time - although I guess it varies from machine to machine... As I get time, I plan to look at the errors we are getting...see if we can reduce them. Chris _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JavaOne
> > We are the talk of the town this year, everyone is aware of us, every > vendor lets go a soft fart when our name is mentioned and the > "cognoscenti" can recite our code by heart... > If you expect a lot of vendors, maybe little bottles of Bean-O with the JBoss logo on them would be in order... Cheers Jay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/naming/ejb TestENCBean.java
User: starksm
Date: 01/04/26 00:56:59
Modified:src/main/org/jboss/test/naming/ejb TestENCBean.java
Log:
Add sample remote ejb-ref test
Revision ChangesPath
1.2 +4 -1 jbosstest/src/main/org/jboss/test/naming/ejb/TestENCBean.java
Index: TestENCBean.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/naming/ejb/TestENCBean.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TestENCBean.java 2001/04/18 19:48:28 1.1
+++ TestENCBean.java 2001/04/26 07:56:59 1.2
@@ -13,7 +13,7 @@
to test ENC usage.
@author [EMAIL PROTECTED]
-@version $Revision: 1.1 $
+@version $Revision: 1.2 $
*/
public class TestENCBean implements SessionBean
{
@@ -81,6 +81,9 @@
System.out.println("ejb/bean0 = "+ejb);
ejb = initCtx.lookup("java:comp/env/ejb/bean1");
System.out.println("ejb/bean1 = "+ejb);
+//ejb = initCtx.lookup("java:comp/env/ejb/remote-bean");
+ejb = null;
+System.out.println("ejb/remote-bean = "+ejb);
}
private void testJdbcDataSource(Context initCtx, Context myEnv) throws
NamingException
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/build build.xml
User: starksm Date: 01/04/26 00:57:37 Modified:src/build build.xml Log: Added steps to create remote-naming.jar Revision ChangesPath 1.23 +16 -3 jbosstest/src/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosstest/src/build/build.xml,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- build.xml 2001/04/21 20:17:58 1.22 +++ build.xml 2001/04/26 07:57:37 1.23 @@ -317,10 +317,23 @@ - - - + + + + + + + + + + + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/client jnp-client.jar
User: starksm Date: 01/04/26 00:53:05 Modified:src/client jnp-client.jar Log: Remove debugging statements Revision ChangesPath 1.11 +9 -8 jboss/src/client/jnp-client.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/naming/META-INF remote-ejb-jar.xml remote-jboss.xml ejb-jar.xml jboss.xml
User: starksm Date: 01/04/26 00:56:21 Modified:src/resources/naming/META-INF ejb-jar.xml jboss.xml Added: src/resources/naming/META-INF remote-ejb-jar.xml remote-jboss.xml Log: Added remote ejb-ref tests Revision ChangesPath 1.2 +6 -0 jbosstest/src/resources/naming/META-INF/ejb-jar.xml Index: ejb-jar.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/naming/META-INF/ejb-jar.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ejb-jar.xml 2001/04/19 15:54:12 1.1 +++ ejb-jar.xml 2001/04/26 07:56:21 1.2 @@ -67,6 +67,12 @@ org.jboss.test.naming.interfaces.TestENCHome org.jboss.test.naming.interfaces.TestENC + +ejb/remote-bean +Session +org.jboss.test.naming.interfaces.TestENCHome +org.jboss.test.naming.interfaces.TestENC + 1.2 +12 -0 jbosstest/src/resources/naming/META-INF/jboss.xml Index: jboss.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/naming/META-INF/jboss.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jboss.xml 2001/04/19 15:54:12 1.1 +++ jboss.xml 2001/04/26 07:56:21 1.2 @@ -6,6 +6,14 @@ ENCBean + +ejb/bean1 +jnp://localhost:1099/ENCTests/ejbs/ENCBean1 + + +ejb/remote-bean + jnp://banshee:1099/ENCTests/ejbs/RemoteENCBean + DefaultDS jdbc/DefaultDS @@ -18,6 +26,10 @@ QueFactory jms/QueFactory + + +ENCBean1 +ENCTests/ejbs/ENCBean1 1.1 jbosstest/src/resources/naming/META-INF/remote-ejb-jar.xml Index: remote-ejb-jar.xml === http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd";> ENC Remote Tests A remote session bean used by the ENC testsuite RemoteENCBean org.jboss.test.naming.ejb.TestENCBean org.jboss.test.naming.interfaces.TestENCHome org.jboss.test.naming.interfaces.TestENC Stateless Container 1.1 jbosstest/src/resources/naming/META-INF/remote-jboss.xml Index: remote-jboss.xml === RemoteENCBean ENCTests/ejbs/RemoteENCBean ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib jnpserver.jar
User: starksm Date: 01/04/26 00:53:05 Modified:src/lib jnpserver.jar Log: Remove debugging statements Revision ChangesPath 1.12 +11 -10jboss/src/lib/jnpserver.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jnp/src/main/org/jnp/interfaces/jnp jnpURLContextFactory.java
User: starksm
Date: 01/04/26 00:50:52
Modified:src/main/org/jnp/interfaces/jnp jnpURLContextFactory.java
Log:
Fix bug 419015 and rmiPort externalization.
Revision ChangesPath
1.4 +8 -5 jnp/src/main/org/jnp/interfaces/jnp/jnpURLContextFactory.java
Index: jnpURLContextFactory.java
===
RCS file:
/cvsroot/jboss/jnp/src/main/org/jnp/interfaces/jnp/jnpURLContextFactory.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- jnpURLContextFactory.java 2001/04/23 06:08:06 1.3
+++ jnpURLContextFactory.java 2001/04/26 07:50:51 1.4
@@ -13,12 +13,12 @@
import org.jnp.interfaces.NamingContext;
-/**
- *
+/** The URL context factory for jnp: style URLs.
*
* @see
- * @author $Author: starksm $
- * @version $Revision: 1.3 $
+ * @author oberg
+ * @author [EMAIL PROTECTED]
+ * @version $Revision: 1.4 $
*/
public class jnpURLContextFactory
implements ObjectFactory
@@ -41,7 +41,10 @@
throws Exception
{
if (obj == null)
- return new NamingContext(environment, name, null);
+ {
+ Context urlContext = new NamingContext(environment, name, null);
+ return urlContext;
+ }
else if (obj instanceof String)
{
String url = (String)obj;
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jnp/src/etc/conf jnp.properties
User: starksm Date: 01/04/26 00:50:51 Modified:src/etc/conf jnp.properties Log: Fix bug 419015 and rmiPort externalization. Revision ChangesPath 1.2 +5 -2 jnp/src/etc/conf/jnp.properties Index: jnp.properties === RCS file: /cvsroot/jboss/jnp/src/etc/conf/jnp.properties,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jnp.properties2000/10/10 12:42:36 1.1 +++ jnp.properties2001/04/26 07:50:51 1.2 @@ -1,3 +1,6 @@ -# JNP server configuration +### JNP server configuration +# The port the JNDI naming service listens on jnp.port=1099 -jnp.log=true +# The port the RMI NamingServer is exported on, 0 = bind any available port +jnp.rmiPort=0 + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jnp/src/main/org/jnp/server Main.java NamingServer.java
User: starksm
Date: 01/04/26 00:50:52
Modified:src/main/org/jnp/server Main.java NamingServer.java
Log:
Fix bug 419015 and rmiPort externalization.
Revision ChangesPath
1.5 +21 -24jnp/src/main/org/jnp/server/Main.java
Index: Main.java
===
RCS file: /cvsroot/jboss/jnp/src/main/org/jnp/server/Main.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Main.java 2001/04/23 07:13:10 1.4
+++ Main.java 2001/04/26 07:50:52 1.5
@@ -31,9 +31,9 @@
/** A main() entry point for running the jnp naming service implementation as
a standalone process.
-@author $Author: starksm $
+@author oberg
@author [EMAIL PROTECTED]
-@version $Revision: 1.4 $
+@version $Revision: 1.5 $
*/
public class Main
implements Runnable, MainMBean
@@ -53,6 +53,13 @@
public static void main(String[] args)
throws Exception
{
+// Make sure the config file can be found
+ClassLoader loader = Thread.currentThread().getContextClassLoader();
+URL url = loader.getResource("log4j.properties");
+if( url == null )
+System.err.println("Failed to find log4j.properties");
+else
+PropertyConfigurator.configure(url);
new Main().start();
}
@@ -68,9 +75,10 @@
// Ignore
}
-// Set configuration
+// Set configuration from the system properties
setPort(Integer.getInteger("jnp.port",getPort()).intValue());
-// log = Category.getInstance("org.jnp.Naming");
+setRmiPort(Integer.getInteger("jnp.rmiPort",getRmiPort()).intValue());
+log = Category.getInstance("Naming");
}
// Public
@@ -83,14 +91,7 @@
public void start()
throws Exception
{
-/* Make sure the config file can be found
-ClassLoader loader = Thread.currentThread().getContextClassLoader();
-URL url = loader.getResource("log4j.properties");
-if( url == null )
-throw new FileNotFoundException("Failed to find log4j.properties");
-PropertyConfigurator.configure(url);
log.info("Starting jnp server");
-*/
// Create remote object
theServer = new NamingServer();
@@ -105,12 +106,11 @@
{
serverSocket = null;
serverSocket = new ServerSocket(getPort());
-// log.info("Started on port " + getPort());
+log.info("Started jnpPort=" + getPort()+", rmiPort="+getRmiPort());
listen();
} catch (IOException e)
{
-// log.error("Could not start on port " + getPort(), e);
-e.printStackTrace();
+log.error("Could not start on port " + getPort(), e);
}
}
@@ -118,7 +118,7 @@
{
try
{
-// log.info("Stopping");
+log.info("Stopping");
// Unexport server
UnicastRemoteObject.unexportObject(theServer, false);
@@ -127,11 +127,10 @@
ServerSocket s = serverSocket;
serverSocket = null;
s.close();
-// log.info("Stopped");
+log.info("Stopped");
} catch (Exception e)
{
-// log.error("Exception during shutdown", e);
-e.printStackTrace();
+log.error("Exception during shutdown", e);
}
}
@@ -147,15 +146,14 @@
} catch (IOException e)
{
if (serverSocket == null) return; // Stopped by normal means
-// log.error("Naming stopped", e);
-// log.info("Restarting naming");
+log.error("Naming stopped", e);
+log.info("Restarting naming");
try
{
start();
} catch (Exception ex)
{
-// log.error("Restart failed", ex);
-ex.printStackTrace();
+log.error("Restart failed", ex);
return;
}
}
@@ -171,8 +169,7 @@
}
catch (IOException ex)
{
-// log.error("Error writing response", ex);
-ex.printStackTrace();
+log.error("Error writing response", ex);
}
finally
{
1.6 +4 -5 jnp/src/main/org/jnp/server/NamingServer.java
Index: NamingServer.java
===
RCS file: /cvsroot/jboss/jnp/src/main/org/jnp/server/NamingServer.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- NamingSe
[JBoss-dev] CVS update: jnp/src/main/org/jnp/client Main.java
User: starksm
Date: 01/04/26 00:50:51
Modified:src/main/org/jnp/client Main.java
Log:
Fix bug 419015 and rmiPort externalization.
Revision ChangesPath
1.5 +39 -21jnp/src/main/org/jnp/client/Main.java
Index: Main.java
===
RCS file: /cvsroot/jboss/jnp/src/main/org/jnp/client/Main.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Main.java 2001/04/23 06:42:32 1.4
+++ Main.java 2001/04/26 07:50:51 1.5
@@ -29,20 +29,16 @@
* in various ways to test the functionality.
*
* The JNDI configuration is provided in the jndi.properties file.
- *
+ *
* @see NamingContext
- * @author $Author: starksm $
+ * @author oberg
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*/
public class Main
implements Runnable
{
- // Constants -
-
- // Attributes
-
- // Static
+org.jnp.server.Main remoteServer;
/**
* Start the test
@@ -50,12 +46,16 @@
* @param args
* @exception Exception
*/
- public static void main(String[] args)
+public static void main(String[] args)
throws Exception
- {
- new Main().run();
- }
-
+{
+ System.setProperty("java.naming.factory.initial",
"org.jnp.interfaces.NamingContextFactory");
+ System.setProperty("java.naming.factory.url.pkgs", "org.jnp.interfaces");
+ System.setProperty("java.naming.provider.url", "localhost");
+ System.setErr(System.out);
+ new Main().run();
+}
+
// Constructors --
// Public
@@ -208,7 +208,6 @@
}
showTree(ctx);
- iniCtx.close();
// Create an initial context that is rooted at /test
Properties env = new Properties();
@@ -232,20 +231,39 @@
server = ctx.lookup("test/server");
System.out.println("+ PROVIDER_URL=jnp://localhost:1099/
lookup(test/server):"+server);
+ // Test accessing a remote by accessing a non-default local server
+ runRemoteServer();
+ System.out.println("+++ Started second jnp server on port 10099");
+ test = (Context) iniCtx.lookup("test");
+ showTree(test);
+
+ env = new Properties();
+ env.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"org.jnp.interfaces.NamingContextFactory");
+ env.setProperty(Context.URL_PKG_PREFIXES, "org.jnp.interfaces");
+ ctx = (Context) new InitialContext(env).lookup("jnp://localhost:10099/");
+ System.out.println(ctx.getEnvironment());
+ // Create subcontext
+ test = ctx.createSubcontext("test2");
+ System.out.println("10099 test2 created:"+test);
+ System.out.println("10099 test2.env:"+test.getEnvironment());
+ test.bind("external", new LinkRef("jnp://localhost:1099/test"));
+ Context external = (Context) new
InitialContext(env).lookup("jnp://localhost:10099/test2/external");
+ System.out.println("jnp://localhost:10099/test2 = "+external);
+ System.out.println("jnp://localhost:10099/test2.env =
"+external.getEnvironment());
+ remoteServer.stop();
}
catch (Exception e)
{
e.printStackTrace(System.err);
}
}
-
- // Y overrides ---
- // Package protected -
-
- // Protected -
-
- // Private ---
+ private void runRemoteServer() throws Exception
+ {
+ remoteServer = new org.jnp.server.Main();
+ remoteServer.setPort(10099);
+ remoteServer.start();
+ }
/**
* Print the contents of a JNDI context recursively
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jnp/src/main/org/jnp/interfaces NamingContext.java
User: starksm Date: 01/04/26 00:50:51 Modified:src/main/org/jnp/interfaces NamingContext.java Log: Fix bug 419015 and rmiPort externalization. Revision ChangesPath 1.9 +9 -8 jnp/src/main/org/jnp/interfaces/NamingContext.java Index: NamingContext.java === RCS file: /cvsroot/jboss/jnp/src/main/org/jnp/interfaces/NamingContext.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- NamingContext.java2001/04/23 06:43:17 1.8 +++ NamingContext.java2001/04/26 07:50:51 1.9 @@ -27,13 +27,17 @@ import javax.naming.spi.NamingManager; import javax.naming.spi.ResolveResult; -/** - * - * - * @see +/** This class provides the jnp provider Context implementation. It is a +Context interface wrapper for a RMI Naming instance that is obtained from +either the local server instance or by locating the server given by the +Context.PROVIDER_URL value. + +This class also serves as the jnp url resolution context. jnp style urls +passed to the + * @author oberg * @author [EMAIL PROTECTED] - * @version $Revision: 1.8 $ + * @version $Revision: 1.9 $ */ public class NamingContext implements Context, java.io.Serializable @@ -225,9 +229,6 @@ this.env = new Hashtable(); this.naming = server; - - // Check if server is available - checkRef(env); } // Public ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default jnp.properties
User: starksm Date: 01/04/26 00:38:04 Modified:src/etc/conf/default jnp.properties Log: Updated defaults to show the rmiPort option Revision ChangesPath 1.2 +4 -2 jboss/src/etc/conf/default/jnp.properties Index: jnp.properties === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/jnp.properties,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jnp.properties2000/10/27 09:52:48 1.1 +++ jnp.properties2001/04/26 07:38:03 1.2 @@ -1,3 +1,5 @@ -# JNP server configuration +### JNP server configuration +# The port the JNDI naming service listens on jnp.port=1099 -jnp.log=false +# The port the RMI NamingServer is exported on, 0 = bind any available port +jnp.rmiPort=0 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/naming NamingService.java
User: starksm
Date: 01/04/26 00:40:49
Modified:src/main/org/jboss/naming NamingService.java
Log:
Remove the getLog/setLog methods
Revision ChangesPath
1.10 +2 -11 jboss/src/main/org/jboss/naming/NamingService.java
Index: NamingService.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/naming/NamingService.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- NamingService.java2001/04/23 06:31:11 1.9
+++ NamingService.java2001/04/26 07:40:49 1.10
@@ -20,7 +20,7 @@
* @see
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.9 $
+ * @version $Revision: 1.10 $
*/
public class NamingService
extends ServiceMBeanSupport
@@ -59,16 +59,7 @@
{
return naming.getRmiPort();
}
-
- public void setLogging(boolean l)
- {
- }
-
- public boolean getLogging()
- {
- return false;
- }
-
+
public ObjectName getObjectName(MBeanServer server, ObjectName name)
throws javax.management.MalformedObjectNameException
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/client jnp-client.jar
User: starksm Date: 01/04/26 00:40:11 Modified:src/client jnp-client.jar Log: Fix problem with jnp urls to external servers(Bug #416817). Revision ChangesPath 1.10 +44 -47jboss/src/client/jnp-client.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib jnpserver.jar
User: starksm Date: 01/04/26 00:40:11 Modified:src/lib jnpserver.jar Log: Fix problem with jnp urls to external servers(Bug #416817). Revision ChangesPath 1.11 +55 -64jboss/src/lib/jnpserver.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
