[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
=
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS=
=
JAVA VERSION DETAILS
java version "1.3.1_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01)
Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode)
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
output:
[mkdir] Created dir: /home/jboss/jbossci/jboss-head/aop/output/lib
[jar] Building jar: /home/jboss/jbossci/jboss-head/aop/output/lib/jboss-aop.jar
==
==
== Finished 'most' in module 'aop'.
==
==
_module-aop-most:
[copy] Copying 1 file to /home/jboss/jbossci/jboss-head/build/output/testbuild/lib
[copy] Copying 1 file to /home/jboss/jbossci/jboss-head/build/output/testbuild/lib
==
==
== Executing 'most' in module 'cache'...
==
==
configure-modules:
Overriding previous definition of reference to jboss.naming.classpath
compile-mbean-sources:
[mkdir] Created dir: /home/jboss/jbossci/jboss-head/cache/output/gen/classes
Running
INFO:Some classes refer to other classes that were not found among the sources or
on the classpath.
(Perhaps the referred class doesn't exist? Hasn't been generated yet?)
The referring classes do not import any fully qualified classes matching
these classes.
However, since no packages are imported, xjavadoc has assumed that the
referred classes
belong to the same package as the referring class. The classes are:
org.jboss.cache.CacheImplMBean --> ServiceMBean qualified to ServiceMBean
org.jboss.cache.EvictionPolicy --> Service qualified to Service
_default:compile-classes:
[mkdir] Created dir: /home/jboss/jbossci/jboss-head/cache/output/classes
[depend] Deleted 0 out of date files in 0 seconds
[javac] Compiling 14 source files to
/home/jboss/jbossci/jboss-head/cache/output/classes
/home/jboss/jbossci/jboss-head/cache/src/main/org/jboss/cache/CacheImpl.java:682:
cannot resolve symbol
symbol : class CacheEntry
location: class org.jboss.cache.CacheImpl
CacheEntry getInternal(Object key) {
^
1 error
BUILD FAILED
file:/home/jboss/jbossci/jboss-head/cache/../tools/etc/buildfragments/targets.ent:45:
Compile failed; see the compiler error output for details.
Total time: 48 seconds
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-661682 ] 3.1 dtd missing from XmlFileLoader
Bugs item #661682, was opened at 2003-01-03 07:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=661682&group_id=22866 Category: JBossServer Group: v3.2 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Oskari Kettunen (aok) >Assigned to: Scott M Stark (starksm) Summary: 3.1 dtd missing from XmlFileLoader Initial Comment: Hello gents, Somewhere along the way of fitting together xdoclet1.2 and jboss3.2 I ran into a stalemate of descriptors ad dtds fixed easiest by adding the 3.1 dtd to XmlFileLoader. I suspect you might have some reason for keeping it out of 3.2, but in case this is just an oversight, attached is a one-line diff. Oskari Kettunen, Krocus Communications OY Finland -- >Comment By: Scott M Stark (starksm) Date: 2003-01-12 18:39 Message: Logged In: YES user_id=175228 This has been fixed. This dtd should be jboss_3_2.dtd and have a public name of "-//JBoss//DTD JBOSS 3.2//EN" however. -- Comment By: Oskari Kettunen (aok) Date: 2003-01-03 07:39 Message: Logged In: YES user_id=558871 this file upload thingy is taking a piss at me... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=661682&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MDB container causes resource exhaustion
This is due to Bugs item #665360, which has been fixed.
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=665360&group_id=22866
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: "Stefan Arentz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, January 12, 2003 5:06 PM
Subject: [JBoss-dev] MDB container causes resource exhaustion
> I think I have found a serious bug in the code where beans are not
> correctly recycled. However, I do not know/understand all the details
> of how this is implemented in JBoss, so I would like to ask this to the
> person responsible for the MDB container to take a look at this.
>
> My test case is very simple, on JBoss 3.2.0b3 I have this code:
>
> public class OutgoingQueueHandlerBean implements MessageDrivenBean,
> MessageListener
> {
> private Logger mLogger;
>
> private static int count = 0;
>
> public void setMessageDrivenContext(MessageDrivenContext context)
> {
>mLogger = Logger.getLogger(this.getClass().getName());
> }
>
> public void ejbCreate()
> {
>mLogger.info("ejbCreate; count = " + ++count);
> }
>
> public void ejbRemove()
> {
>mLogger.info("ejbRemove; count = " + --count);
> }
>
> public void onMessage(Message message)
> {
>...
> }
> }
>
> When I feed this MDB say 5000 messages, the counter goes up to 243.
> This is odd since this is a standard JBoss install, which has a MDB
> pool size of 100. Also, ejbRemove is *never* called. This leads to
> resource exhaustion since all my MDBs also connect to other beans or
> queues.
>
> Can someone verify this behaviour?
>
> Stefan
>
>
>
> ---
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665394 ] MDB pool size is not bounded -- Is the max size being read?
Bugs item #665394, was opened at 2003-01-09 15:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665394&group_id=22866 Category: JBossMQ Group: v3.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Elias Ross (genman) Assigned to: Nobody/Anonymous (nobody) Summary: MDB pool size is not bounded -- Is the max size being read? Initial Comment: I don't really want to create 100 MDB for my application, so I changed the standardjboss.xml configuration (like I did in 3.2): --- standardjboss.xml Fri Dec 20 18:47:58 2002 +++ /home/eross/src/javapackages/jboss/server/default/conf/standardjboss.xml Thu Jan 9 14:22:38 2003 @@ -774,7 +774,7 @@ org.jboss.tm.TxManager -100 + 5 This doesn't seem to work and I end up with hundreds of threads (and eventually run out of sockets...) Actually setting this number to -1 or something else doesn't create any error... I end up with this in the logs: 2003-01-09 22:32:54,997 ERROR [JMSContainerInvoker] Exception in JMSCI message listener javax.ejb.TransactionRolledbackLocalException: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused); CausedByException is: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:228) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:237) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:101) at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:100) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154) at org.jboss.ejb.MessageDrivenContainer.invoke(MessageDrivenContainer.java:311) at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:697) at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:985) at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:241) at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:601) at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:415) at org.jboss.mq.SpySession.run(SpySession.java:293) at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:177) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:655) at java.lang.Thread.run(Thread.java:536) javax.ejb.EJBException: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused) -- Comment By: Elias Ross (genman) Date: 2003-01-09 18:38 Message: Logged In: YES user_id=556458 In my application, I create a JMS connection in my ejbCreate() method. Apparently, this is where things start to get out of control... It appears to be a configuration error (*grin*) with how the JMS connection pool is larger than the MDB pool. (I was configuring things like I did in JBoss 3.0 to reduce the pool size.) If the MDB pool is too small, then new instances are always thrown away. This is a user area, but hard to diagnose. In such situations, I notice that ejbRemove() is never called for my MDB, even though there are literally hundreds of new instances apparently thrown out. I guess I'd like someone to verify that ejbRemove is eventually called for a MDB that's thrown out of the AbstractPool... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665394&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665360 ] MDB pool size is not bounded -- Is the max size being read?
Bugs item #665360, was opened at 2003-01-09 14:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665360&group_id=22866 >Category: JBossServer Group: v3.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Elias Ross (genman) >Assigned to: Scott M Stark (starksm) Summary: MDB pool size is not bounded -- Is the max size being read? Initial Comment: I don't really want to create 100 MDB for my application, so I changed the standardjboss.xml configuration (like I did in 3.2): --- standardjboss.xml Fri Dec 20 18:47:58 2002 +++ /home/eross/src/javapackages/jboss/server/default/conf/standardjboss.xml Thu Jan 9 14:22:38 2003 @@ -774,7 +774,7 @@ org.jboss.tm.TxManager -100 + 5 This doesn't seem to work and I end up with hundreds of threads (and eventually run out of sockets...) Actually setting this number to -1 or something else doesn't create any error... I end up with this in the logs: 2003-01-09 22:32:54,997 ERROR [JMSContainerInvoker] Exception in JMSCI message listener javax.ejb.TransactionRolledbackLocalException: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused); CausedByException is: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:228) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:237) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:101) at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:100) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154) at org.jboss.ejb.MessageDrivenContainer.invoke(MessageDrivenContainer.java:311) at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:697) at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:985) at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:241) at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:601) at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:415) at org.jboss.mq.SpySession.run(SpySession.java:293) at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:177) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:655) at java.lang.Thread.run(Thread.java:536) javax.ejb.EJBException: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused) -- >Comment By: Scott M Stark (starksm) Date: 2003-01-12 18:31 Message: Logged In: YES user_id=175228 We have a rather bizare notion of MaximumSize in that it is a soft limit that will be exceeded if demand warrents it. I have restored the strictMaximumSize notion of 2.4 to 3.0.5 and 3.2.0RC1 so that a configuration like: 5 true means only 5 instances will be created. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665360&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] MDB container causes resource exhaustion
I think I have found a serious bug in the code where beans are not
correctly recycled. However, I do not know/understand all the details
of how this is implemented in JBoss, so I would like to ask this to the
person responsible for the MDB container to take a look at this.
My test case is very simple, on JBoss 3.2.0b3 I have this code:
public class OutgoingQueueHandlerBean implements MessageDrivenBean,
MessageListener
{
private Logger mLogger;
private static int count = 0;
public void setMessageDrivenContext(MessageDrivenContext context)
{
mLogger = Logger.getLogger(this.getClass().getName());
}
public void ejbCreate()
{
mLogger.info("ejbCreate; count = " + ++count);
}
public void ejbRemove()
{
mLogger.info("ejbRemove; count = " + --count);
}
public void onMessage(Message message)
{
...
}
}
When I feed this MDB say 5000 messages, the counter goes up to 243.
This is odd since this is a standard JBoss install, which has a MDB
pool size of 100. Also, ejbRemove is *never* called. This leads to
resource exhaustion since all my MDBs also connect to other beans or
queues.
Can someone verify this behaviour?
Stefan
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossMQ, multiplexor test
Thanks for the explanation of the receive loop Hiram.
I am trying to run the Multiplexor test included in
org.jboss.mq.il.uil.multiplexor. For some indiscernible reason, the test
is freezing after starting the first stream.
I am trying to run the test under jdk1.4.1_01 -- are there any known
compatibility problems? Or can someone verify that the test runs ?
Thanks,
fawce
-
John Fawcett
CTO, Tamale Software, LLC
26 Fox Road
Waltham, MA 02451
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of
Hiram Chirino
Sent: Friday, January 10, 2003 6:50 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JBossMQ
Your kinda right. the loop is there for the case where the destination
is
queue based (p2p and durable subs). The polling happens when the queue
is
full. Now when the queue is not full (or in the pub sub case, there is
no
queue), then the thread goes into asynch mode and it waits for the
message
to get delivered async via the ClientIL.receive method. I'll comment
the
code a little:
// gets the next message in queue or registers us for asynch
delivery
if none available.
mes = session.connection.receive( subscription, 0 );
if ( mes == null ) // should always be null for pub-sub case.
{
// start waiting for the message to get delivered asynch
waitingForMessage = true;
while ( ( messages.isEmpty() && !closed ) || (
!session.running ) )
{
try
{
// messages gets signaled once ClientIL.receive finishes
processing the message.
messages.wait();
} catch ( InterruptedException e )
{
}
}
if ( closed )
{
waitingForMessage = false;
break outer;
}
// the message sent via ClientIL.receive should now be sitting
in
messages
mes = ( SpyMessage )messages.removeFirst();
waitingForMessage = false;
}
I hope that helped! I think the XIL is great idea! We might even be
able
to develop a c base API to access mq services (important in the
integration
space).
Regards,
Hiram
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
John
> Fawcett
> Sent: Thursday, January 09, 2003 8:09 PM
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] JBossMQ
>
>
> Hi,
>
> I am working on a new invocation layer (IL) for JbossMQ that encodes
all
> communication in Xml (XIL). I've got the IL pretty near completion,
and
> I am working on a C# jbossmq client. I am trying to develop the
> TopicSubsciber, which is an extension of MessageConsumer. In reviewing
> the code in the jbossmq java sources, it looks to me like the client
to
> a topic actually runs a loop sending receive requests to the server
> regularly.
>
> Is this really necessary? Once the connection has been established,
why
> can't the server just invoke the ClientIL.receive method (which
actually
> sends the message to the client) when a message arrives at the
> destination?
> It looks to me like the current implementation is not truly
> asynchronous...
> What am I missing?
>
> Thanks,
> fawce
>
>
> -
> John Fawcett
> CTO, Tamale Software, LLC
> 26 Fox Road
> Waltham, MA 02451
>
>
>
> ---
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 12-January-2003
JBoss daily test results SUMMARY Number of tests run: 1010 Successful tests: 1007 Errors:2 Failures: 1 [time of test: 2003-01-12.15-13 GMT] [java.version: 1.4.1_01] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.1_01-b01] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows 2000] [os.arch: x86] [os.version: 5.0] See http://users.jboss.org/~starksm/Branch_3_0/2003-01-12.15-13 for details of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - Suite: LocalWrapperCleanupUnitTestCase Test: testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Row committed, autocommit still on! - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666802 ] ConcurrentModificationException on startup
Bugs item #666802, was opened at 2003-01-12 22:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666802&group_id=22866 Category: JBossServer Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Frank Langelage (lafr) Assigned to: Nobody/Anonymous (nobody) Summary: ConcurrentModificationException on startup Initial Comment: on startup of jboss-head on linux with sun`s jdk 1.4.1 I get a java.util.ConcurrentModificationException. An extract from the server.log with the stack trace is attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666802&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665037 ] HomeHandle causing NoInitialContextException in JBOSS3.0.4
Bugs item #665037, was opened at 2003-01-09 06:32
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665037&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Shone Sadler (ssadler)
>Assigned to: Scott M Stark (starksm)
Summary: HomeHandle causing NoInitialContextException in JBOSS3.0.4
Initial Comment:
When running our remote clients we get a
NoInitialContextException. The exception is caused by
a call to HomeHandle.getEJBHome(). After Looking
through the source code for JBOSS, it seems that
JBOSS 3.0.4's
com.jboss.proxy.ejb.handle.HomeHandleImpl does not
serialize the JNDI context information like is should (and
used to in JBOSS2.4. Instead it always creates a new
InitialContext in the getEJBHome method. The following
example illustrates the problem.
import
com.qlinktech.pof3.omapi.POFObjectManagerRemoteHo
me;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import javax.ejb.HomeHandle;
import java.util.Properties;
public class Example {
public static void main(String[] args) throws Exception
{
Properties _prop = new Properties();
_prop.setProperty
("java.naming.factory.initial","org.jnp.interfaces.NamingC
ontextFactory");
_prop.setProperty
("java.naming.factory.url.pkgs","org.jboss.naming:org.jnp.
interfaces");
_prop.setProperty
("java.naming.provider.url","localhost");
_prop.setProperty
("java.naming.provider.port","1099");
InitialContext _ic = new InitialContext(_prop);
POFObjectManagerRemoteHome _om_home =
(POFObjectManagerRemoteHome)
PortableRemoteObject.narrow(_ic.lookup
("qlink/POFObjectManager"),POFObjectManagerRemote
Home.class);
HomeHandle _hhandle = _om_home.getHomeHandle
();
//Here is where the NoInitialContextException is
thrown
_om_home = (POFObjectManagerRemoteHome)
javax.rmi.PortableRemoteObject.narrow
(_hhandle.getEJBHome
(),POFObjectManagerRemoteHome.class);
}
}
Thanks,
Shone Sadler
Senior Software Developer
Q-Link Technologies
OS: Win2000
JDK:1.3.1_06
Server Trace:
C:\development>java Example
Exception in thread "main" java.rmi.ServerException:
Could not get EJBHome; nes
ed exception is:
javax.naming.NoInitialContextException: Need to
specify class name in e
vironment or system property, or as an applet
parameter, or in an application r
source file: java.naming.factory.initial
javax.naming.NoInitialContextException: Need to specify
class name in environme
t or system property, or as an applet parameter, or in an
application resource
ile: java.naming.factory.initial
at
javax.naming.spi.NamingManager.getInitialContext
(NamingManager.java:
38)
at javax.naming.InitialContext.getDefaultInitCtx
(InitialContext.java:24
)
at
javax.naming.InitialContext.getURLOrDefaultInitCtx
(InitialContext.ja
a:278)
at javax.naming.InitialContext.lookup
(InitialContext.java:345)
at
org.jboss.proxy.ejb.handle.HomeHandleImpl.getEJBHom
e(HomeHandleImpl.
ava:72)
at Example.main(Example.java:29)
--
>Comment By: Scott M Stark (starksm)
Date: 2003-01-12 13:42
Message:
Logged In: YES
user_id=175228
Yes, that is a silly regression in 3.x. You have to restore the
handle in a context with a jndi.properties file that matches
that in which the handle was looked up. It will be addressed
in the 3.0.6 and 3.2 releases.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665037&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666662 ] Still problems redeploying with JDK 1.4 and jboss-3.0.5RC1
Bugs item #62, was opened at 2003-01-12 15:08
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=62&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Loz (lozzer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Still problems redeploying with JDK 1.4 and jboss-3.0.5RC1
Initial Comment:
I know this has been reported before, but the blurb for
3.0.5 was interested in checking whether these types of
errors had been fixed.
First time round everything works fine. On a redeploy I
get a class cast exception, during a narrow call:
14:38:25,625 ERROR [system] [Exception passed to
ExceptionHelper]
14:38:25,639 ERROR [system] Stack trace...
java.lang.ClassCastException
at
com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:293)
at
javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134)
at
uk.co.ecsoft.justine.component.gui.service.GUIFacadeImpl.(GUIFacadeImpl.java:52)
at
uk.co.ecsoft.justine.component.gui.service.GUIFacadeFactory.getInstance(GUIFacadeFactory.java:30)
The Java leading up to this is a standard JNDI lookup
sequence:
public GUIFacadeImpl(Hashtable env) throws
FacadeException {
if (_ejbHome == null) {
try {
InitialContext context = (env == null) ? new
InitialContext() : new InitialContext(env);
Object obj = context.lookup(DEFAULT_JNDI_NAME);
this._ejbHome = (GUIServiceHome)
PortableRemoteObject.narrow(obj, GUIServiceHome.class);
} catch (Exception e) {
ExceptionHelper.logException(e);
throw new FacadeException(e);
}
}
}
Start of server.log
JBoss Bootstrap Environment
JBOSS_HOME: /usr/local/jboss
JAVA: /usr/java/bin/java
JAVA_OPTS:
-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
-Dprogram.name=run.sh
CLASSPATH:
/usr/local/jboss/bin/run.jar:/usr/java/lib/tools.jar
15:00:14,001 INFO [Server] JBoss Release:
JBoss-3.0.5RC1 CVSTag=JBoss_3_0_5_RC1
15:00:14,035 INFO [Server] Home Dir:
/usr/local/jboss-3.0.5RC1
15:00:14,048 INFO [Server] Home URL:
file:/usr/local/jboss-3.0.5RC1/
15:00:14,061 INFO [Server] Library URL:
file:/usr/local/jboss-3.0.5RC1/lib/
15:00:14,075 INFO [Server] Patch URL: null
15:00:14,087 INFO [Server] Server Name: default
15:00:14,100 INFO [Server] Server Home Dir:
/usr/local/jboss-3.0.5RC1/server/default
15:00:14,112 INFO [Server] Server Home URL:
file:/usr/local/jboss-3.0.5RC1/server/default/
15:00:14,125 INFO [Server] Server Data Dir:
/usr/local/jboss-3.0.5RC1/server/default/db
15:00:14,138 INFO [Server] Server Temp Dir:
/usr/local/jboss-3.0.5RC1/server/default/tmp
15:00:14,150 INFO [Server] Server Config URL:
file:/usr/local/jboss-3.0.5RC1/server/default/conf/
15:00:14,163 INFO [Server] Server Library URL:
file:/usr/local/jboss-3.0.5RC1/server/default/lib/
15:00:14,176 INFO [Server] Root Deployemnt Filename:
jboss-service.xml
15:00:14,192 INFO [Server] Starting General Purpose
Architecture (GPA)...
15:00:14,575 INFO [ServerInfo] Java version:
1.4.1_01,Sun Microsystems Inc.
15:00:14,590 INFO [ServerInfo] Java VM: Java
HotSpot(TM) Client VM 1.4.1_01-b01,Sun Microsystems Inc.
15:00:14,603 INFO [ServerInfo] OS-System: Linux
2.4.20,i386
--
>Comment By: Loz (lozzer)
Date: 2003-01-12 21:39
Message:
Logged In: YES
user_id=686442
Thanks for the tip. I downloaded the source to the class
indicated, compiled and added it to run.jar, and now things
seem to be fine.
As is happens, I did try and compile the whole thing from
the source, but I got a lot of compile errors. Were there
some bits missing from jboss-3.0.5RC1-src.tgz? The first
error was:
compile-classes:
[javac] Compiling 419 source files to
/home/loz/src/jboss-3.0.5RC1-src/jmx/output/classes
[execmodules]
/home/loz/src/jboss-3.0.5RC1-src/jmx/src/main/org/jboss/mx/modelmbean/ModelBase.java:43:
package org.jboss.mx.persistence does not exist
[execmodules] import org.jboss.mx.persistence.NullPersistence;
There is no NullPersistence source in the tarball that I
downloaded.
Finally (if you don't mind giving out free coding tips!),
You mentioned not using the rmi layer if I was in the same
VM. Would you suggest attempting a standard cast, before
doing a narrow call, or an environment setting to
distinguish between the two. Or maybe you have something
cleverer in mind?
thanks again,
Loz
Re: [JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 12-January-2003
This is a run on a w2k box with the server built with JDK 1.4.1 and the client tests running with 1.3.1. There are no new issues showing up here. I will do two builds for the 3.0.5 release, one with JDK 1.4.1 and one with JDK 1.3.1 and then transition to only building with 1.4+ after that. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, January 12, 2003 1:21 PM Subject: [JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 12-January-2003 > > > JBoss daily test results > > SUMMARY > > Number of tests run: 1012 > > > > Successful tests: 1006 > > Errors:5 > > Failures: 1 > > > > > > [time of test: 2003-01-12.11-48 GMT] > [java.version: 1.3.1_05] > [java.vendor: Sun Microsystems Inc.] > [java.vm.version: 1.3.1_05-b02] > [java.vm.name: Java HotSpot(TM) Client VM] > [java.vm.info: mixed mode] > [os.name: Windows 2000] > [os.arch: x86] > [os.version: 5.0] > > See http://users.jboss.org/~starksm/Branch_3_0/2003-01-12.11-48 > for details of this test. > > NOTE: If there are any errors shown above - this mail is only highlighting > them - it is NOT indicating that they are being looked at by anyone. > > It is assumed that whoever makes change(s) to jboss that > break the test will be fixing the test or jboss, as appropriate! > > > > > > DETAILS OF ERRORS > > > > Suite: BeanStressTestCase > Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) > Type:failure > Exception: junit.framework.AssertionFailedError > Message: expected a client deadlock for AB BA > - > > > > Suite: LocalWrapperCleanupUnitTestCase > Test: >testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase) > Type:error > Exception: java.rmi.ServerException > Message: RemoteException occurred in server thread; nested exception is: >java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Row committed, autocommit still on! > - > > > > Suite: MissingClassUnitTestCase > Test: >testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) > Type:error > Exception: org.jboss.deployment.DeploymentException > Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) > - > > > > Suite: SimpleUnitTestCase > Test:testSecureHttpInvoker(org.jboss.test.naming.test.SimpleUnitTestCase) > Type:error > Exception: javax.security.auth.login.LoginException > Message: Missing users.properties file. > - > > > > Suite: SimpleUnitTestCase > Test:testLoginInitialContext(org.jboss.test.naming.test.SimpleUnitTestCase) > Type:error > Exception: javax.naming.AuthenticationException > Message: Failed to login using protocol=testLoginInitialContext > - > > > > Suite: HttpsUnitTestCase > Test:testHttpsURL(org.jboss.test.security.test.HttpsUnitTestCase) > Type:error > Exception: java.io.IOException > Message: Failed to get SSLContext for TLS algorithm > - > > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 12-January-2003
JBoss daily test results SUMMARY Number of tests run: 1012 Successful tests: 1006 Errors:5 Failures: 1 [time of test: 2003-01-12.12-20 GMT] [java.version: 1.3.1] [java.vendor: Apple Computer, Inc.] [java.vm.version: 1.3.1_03-69] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Mac OS X] [os.arch: ppc] [os.version: 10.2.3] See http://users.jboss.org/~starksm/Branch_3_0/2003-01-12.12-20 for details of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: LocalWrapperCleanupUnitTestCase Test: testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Row committed, autocommit still on! - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: SimpleUnitTestCase Test:testSecureHttpInvoker(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.security.auth.login.LoginException Message: Missing users.properties file. - Suite: SimpleUnitTestCase Test:testLoginInitialContext(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.naming.AuthenticationException Message: Failed to login using protocol=testLoginInitialContext - Suite: HttpsUnitTestCase Test:testHttpsURL(org.jboss.test.security.test.HttpsUnitTestCase) Type:error Exception: java.io.IOException Message: Failed to get SSLContext for TLS algorithm - Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 12-January-2003
JBoss daily test results SUMMARY Number of tests run: 1012 Successful tests: 1006 Errors:5 Failures: 1 [time of test: 2003-01-12.11-48 GMT] [java.version: 1.3.1_05] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_05-b02] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows 2000] [os.arch: x86] [os.version: 5.0] See http://users.jboss.org/~starksm/Branch_3_0/2003-01-12.11-48 for details of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - Suite: LocalWrapperCleanupUnitTestCase Test: testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Row committed, autocommit still on! - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: SimpleUnitTestCase Test:testSecureHttpInvoker(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.security.auth.login.LoginException Message: Missing users.properties file. - Suite: SimpleUnitTestCase Test:testLoginInitialContext(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.naming.AuthenticationException Message: Failed to login using protocol=testLoginInitialContext - Suite: HttpsUnitTestCase Test:testHttpsURL(org.jboss.test.security.test.HttpsUnitTestCase) Type:error Exception: java.io.IOException Message: Failed to get SSLContext for TLS algorithm - --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666704 ] Deploying SARs via application.xml barfs
Bugs item #666704, was opened at 2003-01-12 09:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666704&group_id=22866 >Category: JBossServer >Group: v3.2 >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Stefan Arentz (sateh) >Assigned to: Scott M Stark (starksm) Summary: Deploying SARs via application.xml barfs Initial Comment: In a recent message on the mailinglist I found that you have to add a .sar to your application.xml like this: mccp.sar However, this throws an exception while deploying: org.jboss.deployment.DeploymentException: exception in init of file:/soze/home/stefan/Java/jboss- 3.2.0B3/server/default/deploy/mccp.ear; - nested throwable: (org.jboss.deployment.DeploymentException: Service archives must be in jboss-app.xml) It refers to jboss-app.xml, which does not exist in JBoss 3.2. Stefan Arentz -- >Comment By: Scott M Stark (starksm) Date: 2003-01-12 12:02 Message: Logged In: YES user_id=175228 The dtd has been added. -- Comment By: Stefan Arentz (sateh) Date: 2003-01-12 10:33 Message: Logged In: YES user_id=66079 The DTD for jboss-app.xml is missing. -- Comment By: Adrian Brock (ejort) Date: 2003-01-12 09:47 Message: Logged In: YES user_id=9459 jboss-app.xml is something you create alongside the application.xml in the META-INF of the ear. mccp.sar Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666704&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] 最新网络报价
¡¶È«¹úÍøÂçϵͳ¼¯³É·½°¸¼¯¡· + ×îÐÂPHP£¬ASP£¬JAVA¡¢VB¡¢PB¡¢DELPHI¡¢VC Ô´ÂëϵÁйâÅÌ ±¾¼¯ÊÕ¼ÁËÈ«¹ú¸÷µØ´óÁ¿ÍøÂçϵͳºÍϵͳ¼¯³É·½ÃæµÄ×ÊÁÏ¡¢·½°¸¡¢¹æ»®¡¢¼¼Êõ¡¢½â¾ö·½°¸µÈµÈÕä¹ó²ÄÁÏ£¡ÄÚÈÝÉæ¼°°üÀ¨Õþ¸®¡¢Ð£Ô°¡¢¹ãµç¡¢½ðÈÚ¡¢µç×ÓÉÌÎñ¡¢Ë°Îñ¡¢Éç±£¡¢¿í´øÍø¡¢ÖÇÄÜСÇøµÈÊ®¶à¸öÐÐÒµ£¡³¬¹ý1.8GµÄÎĵµÈ«²¿Ñ¹ËõÖÁCDÄÚ£¡£¡¾ø¶ÔÊǸöÈËÍøÂç¼¼Êõ°®ºÃÕß¡¢ÏµÍ³¼¯³ÉÐÐÒµµÈ²»¿É¶àµÃµÄ±¦¹ó²Î¿¼×ÊÁÏ£¡£¡£¡ÊÇITÒµ½ç×ÊÉîר¼ÒѪº¹Ö®×÷£¬Ö±»÷µ±½ñIT¼¯³É×î¸ßˮƽ£¬´øÄú×ß½øÎÞÓǵÄITÊÀ½ç£¬ÈÃÄúÒ»Ò¹³ÉΪϵͳ¼¯³Éר¼Ò¡£¼¸°Ù¸ö³É¹¦µÄϵͳ¼¯³ÉÉè¼Æ¡¢Ê©¹¤·½°¸£¬¼«ÓмÛÖµµÄÄÚ²¿È«Õæ×ÊÁÏ£¨°üÀ¨£º½â¾ö·½°¸¡¢Éè¼Æ·½°¸¡¢±êÊé¡¢ÍøÂ簲ȫ×ÊÁÏ¡¢ÉÌÒµ¼Æ»®Ê飩£¬¶ÔÓÚ´ÓÊÂÏà¹ØÁìÓòµÄ¹«Ë¾»ò¸öÈ˾ßÓкܸߵĽè¼ø¼ÛÖµ¡£ÎÒÃdzÐŵ£º¿îµ½ºóÁ¢¼´×¨µÝËÍÅÌÉÏÃÅ£»Ò»ÄêÄÚÐÂÔö·½°¸ Ãâ·ÑÔùËÍÉý¼¶¡££¡ ×ÊÁÏÑùÆ·Çëµã»÷ÕâÀïÏÂÔØ ÏµÍ³¼¯³É¹âÅÌĿ¼ ÊÛ¼Û300Ô²(EMS¿ìµÝ¹âÅÌ£º300Ôª/ÕÅ £¨°ü¿ìµÝ·Ñ£© ÌṩÏÂÔصØÖ·£º250Ôª/ÕÅ) 1¡¢¿í´øÍø³ÇÓòÍø---11ƪ 2¡¢µç×ÓÉÌÎñÍøÕ¾---26ƪ 3¡¢ÍøÂ簲ȫ6ƪ 4¡¢ÍøÂç¹ÜÀí---13ƪ 5¡¢ÍøÂç·½°¸4ƪ 6¡¢ºô½ÐÖÐÐÄ5ƪ 7¡¢TCP/IPÅàѵ--3ƪ 8¡¢ÊÓƵ»áÒé¡¢VOD--13ƪ 9¡¢VOIP5ƪ 10¡¢IPµç»°-9ƪ 11¡¢½¨Éè¹æ·¶Êé13ƪ 12¡¢·ÃÎÊ·þÎñÆ÷21ƪ 13¡¢½ðÈÚ--26ƪ 14¡¢¹ãµç---5ƪ 15¡¢Õþ¸®--24ƪ 16¡¢Ð£Ô°--19ƪ 17¡¢ÓÊÕþ---3ƪ 18¡¢Éç±£---6ƪ 19¡¢¹«¼ì·¨-3ƪ 20¡¢¼Æ·Ñ--xxƪ 21¡¢Ë°Îñ---3ƪ 23¡¢°ì¹«×Ô¶¯»¯15ƪ 24¡¢ÈÝ´í¡¢±¸·Ý11ƪ 25¡¢¼¼Êõ½â¾ö·½°¸--58ƪ 26¡¢ÎÞÏß´«Êä---5ƪ 27¡¢Í¶±êÊé-7ƪ 28¡¢ÖÇÄÜÂ¥Óî--10ƪ 29¡¢×ۺϲ¼Ïß--12ƪ 30¡¢»ÃµÆƬ18ƪ 31¡¢¹¤³Ìͼֽ--88ƪ 32¡¢Cisco×ÊÁÏxxxƪ 33¡¢¹ÜÀíÔ±ÊÖ²á20ƪ 34¡¢ÏúÊÛ·½°¸---7ƪ 35¡¢ÆäËü--24ƪ ÐÂÏʳöÁý£º 36¡¢×îÐÂÖбê½â¾ö·½°¸¾«Ñ¡2001-2002111ƪ ÍøÂçÌáÉý·þÎñ£Ë¼¿Æ½â¾ö·½°¸ÔÚÉ̼ìϵͳµÄÓ¦ÓÃ.zip ¹«°²¼ÆËã»úÓ¦ÓÃÈí¼þ¼¼Êõ°×ƤÊé.zip **¹«Ë¾»ú³¡Éú²úÔËÓª¹ÜÀíϵͳ..zip ³ÇÓòÍø½â¾ö·½°¸.zip Ô˳﷽´çÖ®¼ä£¬¾ö²ßǧÀïÖ®Íâ--**ÊгÇÊй滮¾Ö¹ãÓòÍøÂçϵͳ¹¤³Ì.zip ÈõØÏÂÒøÁú²åÉÏÐÅÏ¢»¯µÄ³á°ò--**µØÌú×ܹ«Ë¾¼ÆËã»úÍøÂçϵͳ½¨Éè·½°¸. **Ê¡Õþ¸®ÐÅÏ¢ÍøÒ»ÆÚ¹¤³Ì.zip ¿ª±ÙÎÞÏßÍøÂçпռä£Ë¼¿Æ¼ÑÓ¯ÐÁ¦ÍƽøÐÐÒµÓ¦ÓÃ.zip Áª´´ÏµÍ³°²È«½â¾ö·½°¸.zip ϵͳ¼¯³É-È«¹ú¾ÅÆß×ÝÏòÁªÍø..zip **Á¶Óͳ§ÆóÒµÍø½¨Éè·½°¸.zip ·ÆÍúʯÓÍʯ»¯ÆóҵȫÃæµç×Ó»¯¹ÜÀí½â¾ö·½°¸.zip **ÓÍÌï¹ãÓòÍø.zip *ÓÍÌﺣÑ󴬲°¹«Ë¾ÊÓƵ»áÒé½â¾ö·½°¸.zip ³¤´ï¿Æ¼¼ÐéÄâ˽ÈËÍøÂç.zip ¿ìÍþµç×Óѧϰ½â¾ö·½°¸.zip ÖÐÁªÊý×Ö»¯Í¼Êé¹ÝÍøÂç½â¾ö·½°¸.zip DavnetÒýÁìUOBPlaza&ShawHouse½øÈëÎÞÏß½ÓÈëÊÀ½ç.zip ¶ÔÓÚ¸ñÁÖ˹²©ÂÞÊÐÀ´Ëµ£¬²ÉÓÃÎÞÏßÍøÂ罫ÏñÔö¼ÓÁ˲»Óø¶¹¤×ʵŤ×÷ÈËÔ±Ò»Ñù.zip ¾º±ê³É¹¦µÄ±³ºó--´óÁ¬ÓÐÏßµçÊÓ¿í´ø¶àýÌå¹Ç¸ÉÍø´´ÔìÁ½ÏîµÚÒ».zip ¿í´ø½ÓÈë½â¾ö·½°¸.zip ¿í´øСÇø¼Æ·Ñ½â¾ö·½°¸.zip ÍøÂç¹ÜÀíϵͳ·½°¸½¨ÒéÊé.zip AironetÎÞÏßÍøÂç²úƷϵÁнâ¾ö·½°¸.zip CiscoÖÐСÆóÒµÍøÂç½â¾ö·½°¸.zip IBMIPµç»°.zip IBMIPÓïÒô£¨VoIP£©.zip IBMÍøÂ簲ȫ·þÎñ.zip IBMÍøÂç¹ÜÀí·þÎñ.zip IBMÍøÂçÄ£Ðͽ¨Á¢.zip IBMÍøÂçÆÀ¹À·þÎñ.zip IBMÍøÂç×Éѯ·þÎñ.zip IBMÎÞÏß¾ÖÓòÍø.zip IBMÏȽø²¼Ïßϵͳ.zip ProcurementÍøÉϲɹºÏµÍ³.z
[JBoss-dev] [ jboss-Bugs-666752 ] EOFException on server-startup
Bugs item #666752, was opened at 2003-01-12 20:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666752&group_id=22866 Category: JBossServer Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Frank Langelage (lafr) Assigned to: Nobody/Anonymous (nobody) Summary: EOFException on server-startup Initial Comment: on startup of jboss head on linux with sun jdk 1.4.1 I get an EOFException. Reason for this is that in line 273 of XSLSubDeployer.java the wrong StreamSource ss instead of dss. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666752&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666662 ] Still problems redeploying with JDK 1.4 and jboss-3.0.5RC1
Bugs item #62, was opened at 2003-01-12 07:08
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=62&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Loz (lozzer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Still problems redeploying with JDK 1.4 and jboss-3.0.5RC1
Initial Comment:
I know this has been reported before, but the blurb for
3.0.5 was interested in checking whether these types of
errors had been fixed.
First time round everything works fine. On a redeploy I
get a class cast exception, during a narrow call:
14:38:25,625 ERROR [system] [Exception passed to
ExceptionHelper]
14:38:25,639 ERROR [system] Stack trace...
java.lang.ClassCastException
at
com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:293)
at
javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134)
at
uk.co.ecsoft.justine.component.gui.service.GUIFacadeImpl.(GUIFacadeImpl.java:52)
at
uk.co.ecsoft.justine.component.gui.service.GUIFacadeFactory.getInstance(GUIFacadeFactory.java:30)
The Java leading up to this is a standard JNDI lookup
sequence:
public GUIFacadeImpl(Hashtable env) throws
FacadeException {
if (_ejbHome == null) {
try {
InitialContext context = (env == null) ? new
InitialContext() : new InitialContext(env);
Object obj = context.lookup(DEFAULT_JNDI_NAME);
this._ejbHome = (GUIServiceHome)
PortableRemoteObject.narrow(obj, GUIServiceHome.class);
} catch (Exception e) {
ExceptionHelper.logException(e);
throw new FacadeException(e);
}
}
}
Start of server.log
JBoss Bootstrap Environment
JBOSS_HOME: /usr/local/jboss
JAVA: /usr/java/bin/java
JAVA_OPTS:
-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
-Dprogram.name=run.sh
CLASSPATH:
/usr/local/jboss/bin/run.jar:/usr/java/lib/tools.jar
15:00:14,001 INFO [Server] JBoss Release:
JBoss-3.0.5RC1 CVSTag=JBoss_3_0_5_RC1
15:00:14,035 INFO [Server] Home Dir:
/usr/local/jboss-3.0.5RC1
15:00:14,048 INFO [Server] Home URL:
file:/usr/local/jboss-3.0.5RC1/
15:00:14,061 INFO [Server] Library URL:
file:/usr/local/jboss-3.0.5RC1/lib/
15:00:14,075 INFO [Server] Patch URL: null
15:00:14,087 INFO [Server] Server Name: default
15:00:14,100 INFO [Server] Server Home Dir:
/usr/local/jboss-3.0.5RC1/server/default
15:00:14,112 INFO [Server] Server Home URL:
file:/usr/local/jboss-3.0.5RC1/server/default/
15:00:14,125 INFO [Server] Server Data Dir:
/usr/local/jboss-3.0.5RC1/server/default/db
15:00:14,138 INFO [Server] Server Temp Dir:
/usr/local/jboss-3.0.5RC1/server/default/tmp
15:00:14,150 INFO [Server] Server Config URL:
file:/usr/local/jboss-3.0.5RC1/server/default/conf/
15:00:14,163 INFO [Server] Server Library URL:
file:/usr/local/jboss-3.0.5RC1/server/default/lib/
15:00:14,176 INFO [Server] Root Deployemnt Filename:
jboss-service.xml
15:00:14,192 INFO [Server] Starting General Purpose
Architecture (GPA)...
15:00:14,575 INFO [ServerInfo] Java version:
1.4.1_01,Sun Microsystems Inc.
15:00:14,590 INFO [ServerInfo] Java VM: Java
HotSpot(TM) Client VM 1.4.1_01-b01,Sun Microsystems Inc.
15:00:14,603 INFO [ServerInfo] OS-System: Linux
2.4.20,i386
--
>Comment By: Scott M Stark (starksm)
Date: 2003-01-12 10:42
Message:
Logged In: YES
user_id=175228
This can be avoided by not including a PROVIDER_URL in
the env, or equivalently using the default InitialContext().
--
Comment By: Adrian Brock (ejort)
Date: 2003-01-12 09:36
Message:
Logged In: YES
user_id=9459
The 3.0.5RC1 binary release was built with 1.3 so
it does not include the 1.4 RMIClassLoader workaround.
It won't compile on 1.3 :-(
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/jboss-
system/src/main/org/jboss/system/JBossRMIClassLoader.jav
a?annotate=1.1.2.1
If you build the source release on 1.4 it will be included
in run.jar
Alternatively, download the above class, compile it
and add it to the classpath.
Ideally, you should not be using the RMI layer
when you are in the same VM.
Regards,
Adrian
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=62&group_id=22866
---
This SF.NET emai
[JBoss-dev] [ jboss-Bugs-666704 ] Deploying SARs via application.xml barfs
Bugs item #666704, was opened at 2003-01-12 18:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666704&group_id=22866 Category: None Group: None Status: Open Resolution: Invalid Priority: 5 Submitted By: Stefan Arentz (sateh) Assigned to: Nobody/Anonymous (nobody) Summary: Deploying SARs via application.xml barfs Initial Comment: In a recent message on the mailinglist I found that you have to add a .sar to your application.xml like this: mccp.sar However, this throws an exception while deploying: org.jboss.deployment.DeploymentException: exception in init of file:/soze/home/stefan/Java/jboss- 3.2.0B3/server/default/deploy/mccp.ear; - nested throwable: (org.jboss.deployment.DeploymentException: Service archives must be in jboss-app.xml) It refers to jboss-app.xml, which does not exist in JBoss 3.2. Stefan Arentz -- >Comment By: Stefan Arentz (sateh) Date: 2003-01-12 19:33 Message: Logged In: YES user_id=66079 The DTD for jboss-app.xml is missing. -- Comment By: Adrian Brock (ejort) Date: 2003-01-12 18:47 Message: Logged In: YES user_id=9459 jboss-app.xml is something you create alongside the application.xml in the META-INF of the ear. mccp.sar Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666704&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666704 ] Deploying SARs via application.xml barfs
Bugs item #666704, was opened at 2003-01-12 18:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666704&group_id=22866 Category: None Group: None >Status: Open Resolution: Invalid Priority: 5 Submitted By: Stefan Arentz (sateh) Assigned to: Nobody/Anonymous (nobody) Summary: Deploying SARs via application.xml barfs Initial Comment: In a recent message on the mailinglist I found that you have to add a .sar to your application.xml like this: mccp.sar However, this throws an exception while deploying: org.jboss.deployment.DeploymentException: exception in init of file:/soze/home/stefan/Java/jboss- 3.2.0B3/server/default/deploy/mccp.ear; - nested throwable: (org.jboss.deployment.DeploymentException: Service archives must be in jboss-app.xml) It refers to jboss-app.xml, which does not exist in JBoss 3.2. Stefan Arentz -- Comment By: Adrian Brock (ejort) Date: 2003-01-12 18:47 Message: Logged In: YES user_id=9459 jboss-app.xml is something you create alongside the application.xml in the META-INF of the ear. mccp.sar Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666704&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666702 ] Debug messages in INFO priority
Bugs item #666702, was opened at 2003-01-12 16:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666702&group_id=22866 Category: JBossCMP Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Stefan Arentz (sateh) >Assigned to: Adrian Brock (ejort) Summary: Debug messages in INFO priority Initial Comment: 2003-01-12 17:48:04,259 INFO [org.jboss.ejb.plugins.cmp.jdbc.JDBCRemoveEntityCom mand.User] Checking if already deleted: 35400 2003-01-12 17:48:04,259 INFO [org.jboss.ejb.plugins.cmp.jdbc.JDBCRemoveEntityCom mand.User] Deleteing: 35400 These should not show up under INFO, the log quickly fills with thousands of these when deleting many objects. Stefan Arentz -- >Comment By: Adrian Brock (ejort) Date: 2003-01-12 18:24 Message: Logged In: YES user_id=9459 Fixed in 3.0 and 3.2 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666702&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666704 ] Deploying SARs via application.xml barfs
Bugs item #666704, was opened at 2003-01-12 17:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666704&group_id=22866 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Stefan Arentz (sateh) Assigned to: Nobody/Anonymous (nobody) Summary: Deploying SARs via application.xml barfs Initial Comment: In a recent message on the mailinglist I found that you have to add a .sar to your application.xml like this: mccp.sar However, this throws an exception while deploying: org.jboss.deployment.DeploymentException: exception in init of file:/soze/home/stefan/Java/jboss- 3.2.0B3/server/default/deploy/mccp.ear; - nested throwable: (org.jboss.deployment.DeploymentException: Service archives must be in jboss-app.xml) It refers to jboss-app.xml, which does not exist in JBoss 3.2. Stefan Arentz -- >Comment By: Adrian Brock (ejort) Date: 2003-01-12 17:47 Message: Logged In: YES user_id=9459 jboss-app.xml is something you create alongside the application.xml in the META-INF of the ear. mccp.sar Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666704&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666662 ] Still problems redeploying with JDK 1.4 and jboss-3.0.5RC1
Bugs item #62, was opened at 2003-01-12 15:08
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=62&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Loz (lozzer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Still problems redeploying with JDK 1.4 and jboss-3.0.5RC1
Initial Comment:
I know this has been reported before, but the blurb for
3.0.5 was interested in checking whether these types of
errors had been fixed.
First time round everything works fine. On a redeploy I
get a class cast exception, during a narrow call:
14:38:25,625 ERROR [system] [Exception passed to
ExceptionHelper]
14:38:25,639 ERROR [system] Stack trace...
java.lang.ClassCastException
at
com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:293)
at
javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134)
at
uk.co.ecsoft.justine.component.gui.service.GUIFacadeImpl.(GUIFacadeImpl.java:52)
at
uk.co.ecsoft.justine.component.gui.service.GUIFacadeFactory.getInstance(GUIFacadeFactory.java:30)
The Java leading up to this is a standard JNDI lookup
sequence:
public GUIFacadeImpl(Hashtable env) throws
FacadeException {
if (_ejbHome == null) {
try {
InitialContext context = (env == null) ? new
InitialContext() : new InitialContext(env);
Object obj = context.lookup(DEFAULT_JNDI_NAME);
this._ejbHome = (GUIServiceHome)
PortableRemoteObject.narrow(obj, GUIServiceHome.class);
} catch (Exception e) {
ExceptionHelper.logException(e);
throw new FacadeException(e);
}
}
}
Start of server.log
JBoss Bootstrap Environment
JBOSS_HOME: /usr/local/jboss
JAVA: /usr/java/bin/java
JAVA_OPTS:
-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
-Dprogram.name=run.sh
CLASSPATH:
/usr/local/jboss/bin/run.jar:/usr/java/lib/tools.jar
15:00:14,001 INFO [Server] JBoss Release:
JBoss-3.0.5RC1 CVSTag=JBoss_3_0_5_RC1
15:00:14,035 INFO [Server] Home Dir:
/usr/local/jboss-3.0.5RC1
15:00:14,048 INFO [Server] Home URL:
file:/usr/local/jboss-3.0.5RC1/
15:00:14,061 INFO [Server] Library URL:
file:/usr/local/jboss-3.0.5RC1/lib/
15:00:14,075 INFO [Server] Patch URL: null
15:00:14,087 INFO [Server] Server Name: default
15:00:14,100 INFO [Server] Server Home Dir:
/usr/local/jboss-3.0.5RC1/server/default
15:00:14,112 INFO [Server] Server Home URL:
file:/usr/local/jboss-3.0.5RC1/server/default/
15:00:14,125 INFO [Server] Server Data Dir:
/usr/local/jboss-3.0.5RC1/server/default/db
15:00:14,138 INFO [Server] Server Temp Dir:
/usr/local/jboss-3.0.5RC1/server/default/tmp
15:00:14,150 INFO [Server] Server Config URL:
file:/usr/local/jboss-3.0.5RC1/server/default/conf/
15:00:14,163 INFO [Server] Server Library URL:
file:/usr/local/jboss-3.0.5RC1/server/default/lib/
15:00:14,176 INFO [Server] Root Deployemnt Filename:
jboss-service.xml
15:00:14,192 INFO [Server] Starting General Purpose
Architecture (GPA)...
15:00:14,575 INFO [ServerInfo] Java version:
1.4.1_01,Sun Microsystems Inc.
15:00:14,590 INFO [ServerInfo] Java VM: Java
HotSpot(TM) Client VM 1.4.1_01-b01,Sun Microsystems Inc.
15:00:14,603 INFO [ServerInfo] OS-System: Linux
2.4.20,i386
--
>Comment By: Adrian Brock (ejort)
Date: 2003-01-12 17:36
Message:
Logged In: YES
user_id=9459
The 3.0.5RC1 binary release was built with 1.3 so
it does not include the 1.4 RMIClassLoader workaround.
It won't compile on 1.3 :-(
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/jboss-
system/src/main/org/jboss/system/JBossRMIClassLoader.jav
a?annotate=1.1.2.1
If you build the source release on 1.4 it will be included
in run.jar
Alternatively, download the above class, compile it
and add it to the classpath.
Ideally, you should not be using the RMI layer
when you are in the same VM.
Regards,
Adrian
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=62&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666704 ] Deploying SARs via application.xml barfs
Bugs item #666704, was opened at 2003-01-12 18:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666704&group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Arentz (sateh) Assigned to: Nobody/Anonymous (nobody) Summary: Deploying SARs via application.xml barfs Initial Comment: In a recent message on the mailinglist I found that you have to add a .sar to your application.xml like this: mccp.sar However, this throws an exception while deploying: org.jboss.deployment.DeploymentException: exception in init of file:/soze/home/stefan/Java/jboss- 3.2.0B3/server/default/deploy/mccp.ear; - nested throwable: (org.jboss.deployment.DeploymentException: Service archives must be in jboss-app.xml) It refers to jboss-app.xml, which does not exist in JBoss 3.2. Stefan Arentz -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666704&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666702 ] Debug messages in INFO priority
Bugs item #666702, was opened at 2003-01-12 17:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666702&group_id=22866 Category: JBossCMP Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Arentz (sateh) Assigned to: Nobody/Anonymous (nobody) Summary: Debug messages in INFO priority Initial Comment: 2003-01-12 17:48:04,259 INFO [org.jboss.ejb.plugins.cmp.jdbc.JDBCRemoveEntityCom mand.User] Checking if already deleted: 35400 2003-01-12 17:48:04,259 INFO [org.jboss.ejb.plugins.cmp.jdbc.JDBCRemoveEntityCom mand.User] Deleteing: 35400 These should not show up under INFO, the log quickly fills with thousands of these when deleting many objects. Stefan Arentz -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666702&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666701 ] Incompatibility in run.sh (: not found)
Bugs item #666701, was opened at 2003-01-12 17:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666701&group_id=22866 Category: None Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Arentz (sateh) Assigned to: Nobody/Anonymous (nobody) Summary: Incompatibility in run.sh (: not found) Initial Comment: When starting Jboss on: FreeBSD 4.6-STABLE Sun JDK 1.3.1 It starts with: : not found : not found : not found : not found : not found : not found : not found = === JBoss Bootstrap Environment JBOSS_HOME: /soze/home/stefan/Java/jboss-3.2.0B3 JAVA: /usr/local/jdk1.3.1/bin/java JAVA_OPTS: -Dprogram.name=run.sh CLASSPATH: /soze/home/stefan/Java/jboss- 3.2.0B3/bin/run.jar:/usr/local/jdk1.3.1/lib/tools.jar = === Other than that the server boots fine. Stefan Arentz -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666701&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666662 ] Still problems redeploying with JDK 1.4 and jboss-3.0.5RC1
Bugs item #62, was opened at 2003-01-12 15:08
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=62&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Loz (lozzer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Still problems redeploying with JDK 1.4 and jboss-3.0.5RC1
Initial Comment:
I know this has been reported before, but the blurb for
3.0.5 was interested in checking whether these types of
errors had been fixed.
First time round everything works fine. On a redeploy I
get a class cast exception, during a narrow call:
14:38:25,625 ERROR [system] [Exception passed to
ExceptionHelper]
14:38:25,639 ERROR [system] Stack trace...
java.lang.ClassCastException
at
com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:293)
at
javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134)
at
uk.co.ecsoft.justine.component.gui.service.GUIFacadeImpl.(GUIFacadeImpl.java:52)
at
uk.co.ecsoft.justine.component.gui.service.GUIFacadeFactory.getInstance(GUIFacadeFactory.java:30)
The Java leading up to this is a standard JNDI lookup
sequence:
public GUIFacadeImpl(Hashtable env) throws
FacadeException {
if (_ejbHome == null) {
try {
InitialContext context = (env == null) ? new
InitialContext() : new InitialContext(env);
Object obj = context.lookup(DEFAULT_JNDI_NAME);
this._ejbHome = (GUIServiceHome)
PortableRemoteObject.narrow(obj, GUIServiceHome.class);
} catch (Exception e) {
ExceptionHelper.logException(e);
throw new FacadeException(e);
}
}
}
Start of server.log
JBoss Bootstrap Environment
JBOSS_HOME: /usr/local/jboss
JAVA: /usr/java/bin/java
JAVA_OPTS:
-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
-Dprogram.name=run.sh
CLASSPATH:
/usr/local/jboss/bin/run.jar:/usr/java/lib/tools.jar
15:00:14,001 INFO [Server] JBoss Release:
JBoss-3.0.5RC1 CVSTag=JBoss_3_0_5_RC1
15:00:14,035 INFO [Server] Home Dir:
/usr/local/jboss-3.0.5RC1
15:00:14,048 INFO [Server] Home URL:
file:/usr/local/jboss-3.0.5RC1/
15:00:14,061 INFO [Server] Library URL:
file:/usr/local/jboss-3.0.5RC1/lib/
15:00:14,075 INFO [Server] Patch URL: null
15:00:14,087 INFO [Server] Server Name: default
15:00:14,100 INFO [Server] Server Home Dir:
/usr/local/jboss-3.0.5RC1/server/default
15:00:14,112 INFO [Server] Server Home URL:
file:/usr/local/jboss-3.0.5RC1/server/default/
15:00:14,125 INFO [Server] Server Data Dir:
/usr/local/jboss-3.0.5RC1/server/default/db
15:00:14,138 INFO [Server] Server Temp Dir:
/usr/local/jboss-3.0.5RC1/server/default/tmp
15:00:14,150 INFO [Server] Server Config URL:
file:/usr/local/jboss-3.0.5RC1/server/default/conf/
15:00:14,163 INFO [Server] Server Library URL:
file:/usr/local/jboss-3.0.5RC1/server/default/lib/
15:00:14,176 INFO [Server] Root Deployemnt Filename:
jboss-service.xml
15:00:14,192 INFO [Server] Starting General Purpose
Architecture (GPA)...
15:00:14,575 INFO [ServerInfo] Java version:
1.4.1_01,Sun Microsystems Inc.
15:00:14,590 INFO [ServerInfo] Java VM: Java
HotSpot(TM) Client VM 1.4.1_01-b01,Sun Microsystems Inc.
15:00:14,603 INFO [ServerInfo] OS-System: Linux
2.4.20,i386
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=62&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-663114 ] MarshallException when accessing remote bean
Bugs item #663114, was opened at 2003-01-06 05:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=663114&group_id=22866 >Category: JBossTX Group: v3.0 Rabbit Hole Status: Open >Resolution: Postponed Priority: 5 Submitted By: Maxim (kimerinn) Assigned to: Nobody/Anonymous (nobody) Summary: MarshallException when accessing remote bean Initial Comment: Hi! Scenario: 1) I have two session beans A and B, each of them have remote interfaces. A obtains home & remote interface of bean B and invokes method B.hello(). 2) When both beans are locating on the same machine, all works Ok. 3) When bean A is hosting on one computer and bean B on second, bean A obtains home interface of bean B and obtain exception when creating remote interface of bean B. 4) When the bean B is accesed fom another computer through application client, all works Ok. Here is full stack trace: = 13:16:12,169 ERROR [STDERR] java.rmi.MarshalException: error marshalling arguments; nested exception is: java.io.NotSerializableException: org.jboss.tm.TransactionImpl 13:16:12,169 ERROR [STDERR] java.io.NotSerializableException: org.jboss.tm.TransactionImpl 13:16:12,169 ERROR [STDERR] at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1148) 13:16:12,169 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366) 13:16:12,179 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.writeExternal(MarshalledInvocation.java:377) 13:16:12,179 ERROR [STDERR] at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1172) 13:16:12,179 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366) 13:16:12,179 ERROR [STDERR] at sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:268) 13:16:12,179 ERROR [STDERR] at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:106) 13:16:12,179 ERROR [STDERR] at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source) 13:16:12,179 ERROR [STDERR] at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:138) 13:16:12,179 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:108) 13:16:12,179 ERROR [STDERR] at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:77) 13:16:12,179 ERROR [STDERR] at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:80) 13:16:12,220 ERROR [STDERR] at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:198) 13:16:12,220 ERROR [STDERR] at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76) 13:16:12,220 ERROR [STDERR] at $Proxy25.create(Unknown Source) 13:16:12,220 ERROR [STDERR] at aside.ABean.testB(ABean.java:46) 13:16:12,220 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 13:16:12,220 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:660) 13:16:12,220 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:107) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:178) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:60) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) 13:16:12,240 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313) 13:16:12,240 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java:712) 13:16:12,240 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) 13:16:12,240 ERROR [STDERR] at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:382) 13:16:12,240 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 13:16:12,240 ERROR [STDERR] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241) 13:16:12,240 ERROR [STDERR] at sun.rmi.transport.Transport$1.run(Transport.java:152) 13:16:12,240 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native Method) 13:16:12,240 ERROR [STDERR] at sun.rmi.transport.Transport.serviceCall(Transport.java:148) 13:16:12,240 ERROR [STDERR] at sun.rmi.transport.tcp.TCPTransport.handleMess
[JBoss-dev] Transaction propagation change
Regarding bug: [ 663114 ] MarshallException when accessing remote bean, this is due to a change made to store the transaction context of an Invocation in the as_is_payload rather than the transient_payload map about the time of the 3.0.0 release. Our tx info never has been serializable, and the marshalled form of the tpc is handled at the MarshalledInvocation layer anyway rather than relying on the correct form of the tx context being placed into the Invocation. In the case of this particular bug, an EJB A on host 1 calls an EJB B on host 2. Both EJBs uses REQUIRED transaction attributes for all methods, so according to the EJB spec this call should actually fail since the expectation a client can assume is that the existing transaction context of EJB A will be propagated. However, we fail all calls regardless of the transaction attributes. If EJB B was using RequiresNew the call should succeed. I'm inclined to move the transaction context into the transient_payload map to allow valid calls to succeed. This does raise the possibility that the application data can become corrupted if it does expected distributed transaction semantics on inter-server EJB calls. We need to cleanup the tx propagation so that its consistent with the spec. Both for the case of not supporting tx propagation and the case of supporting it. Is this being included in the 4.0 changes concerning the distributed transaction support? Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
