jboss-dev-forums — The jboss development forum posts

[Jboss-dev-forums] [TODO -- DEVELOPMENT] - Re: Want to contribute?

[<tom...@jb...>]

Sebastian, sending you an e-mail now.

-Tom

Tom Elrod
Remoting Lead

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881155#3881155

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881155

[Jboss-dev-forums] [Design of the JBoss EJB Container] - Running JBoss 4.02 in Elcipse 3.1M5 with JDK1.5003

[songhe <nu...@jb...>]

Is there an existing set up in Eclipse 3.1M5 that can build and run JBoss 4.02 from source or any documentation to that effect? I think, at least for me, this is one of the most effective way to get a definite answer to some of the questions on the behaviors of 4.02.

Thanks!

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881154#3881154

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881154

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messaging Core Specification - Revision 1

[<ad...@jb...>]

"ovi...@jb..." wrote : I agree about the "identity of each delivery operation". 
  | 

You've got part of the enlightment.

The other part is the stateless design. By passing around a "Delivery" object
you remove the need to perform HashMap lookups in the optimized in memory case.

You are doing call-by-reference all the way through, rather the call-by-value
that is done in JBossMQ with the BasicQueue acknowledgement maps.

This is essentially the same optimization I did to JCA in 3.2.2 to remove map lookups
as points of contentions (beside the fact that it is needless work :-).

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881152#3881152

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881152

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messaging Core Specification - Revision 1

[<ovi...@jb...>]

anonymous wrote : I do want to see the persistence stuff, especially when it is peer-peer.

You will. But let's first make sure this guy knows how to deal with mundane things such as JMS 1.1 compliance :)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881151#3881151

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881151

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messaging Core Specification - Revision 1

[<ovi...@jb...>]

I agree about the "identity of each delivery operation". 

The queue (the asynchronous channel) can guarantee recovery so it ACKs to its sender. The way can guarantee that it is by maintaing what you call delivery identity, for each message. In my case, the delivery identity is part of the message state ("DELIVERED"), as maintained by the channel. Since a channel can deliver to many receivers, the message state maintains multiple NACKs (or ACKs).

Thanks for the code, I am currently analyzing it and I will update the design documents as soon as the elightnment happens :)



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881150#3881150

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881150

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messaging Core Specification - Revision 1

[<ad...@jb...>]

I do want to see the persistence stuff, especially when it is peer-peer. 
This is the killer feature. ;-)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881149#3881149

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881149

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messaging Core Specification - Revision 1

[<ad...@jb...>]

I've created a separate thread to get your opinion on the acknowledgement/delivery/message state handling, especially WRT to your
identified race conditions.

I think the key part is that you need to setup a unique identity of each delivery
operation before you perform it. Then it is a QOS thing on handling spurious
acks.
i.e. If I know what I'm doing and can guarantee ack recovery and correct semantics, 
I can avoid storing acks in previous parts of the pipe. 
However, if I don't trust things further down the pipe (like JMS clients) 
then I need to take extra steps.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881148#3881148

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881148

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: The missing prototype...

[<ad...@jb...>]

Obviously, you don't have to use this idea, but I think it does resolve
a lot of your race condition problems.
For distributed work (or delivery with ack/nack across reboots), 
the "Delivery" will certainly need an global id to correctly identify it.
For in memory work, it can obviously just use the Object indentity.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881147#3881147

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881147

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: The missing prototype...

[<ad...@jb...>]

Test output

  | // Just some wiring together (deployment :-)
  | test.ConsumerChannel@affc70 addConsumer test.Test$1@1e63e3d
  | test.ChannelImpl@1004901 addConsumer test.ConsumerChannel@affc70
  | test.ChannelImpl@1004901 receive test.ConsumerChannel@affc70  []
  | 
  | // Add Message1 goes down the pipe
  | test.ChannelImpl@1004901 addMessage Message1
  | test.ChannelImpl@1004901 internalAddMessage Message1
  | test.ChannelImpl@1004901 findConsumer test.ChannelImpl@1004901 Message1 [test.ConsumerChannel@affc70]
  | test.ConsumerChannel@affc70 accepts test.ChannelImpl@1004901 Message1
  | 
  | // No end consumer so we deliver it to the holding part of the pipe
  | test.ConsumerChannel@affc70 findConsumer test.ChannelImpl@1004901 Message1 []
  | test.ChannelImpl@1004901 doDelivery test.ConsumerChannel$ConsumerChannelDelivery@1a8c4e7
  | test.ConsumerChannel@affc70 addMessage Message1
  | test.ConsumerChannel@affc70 internalAddMessage Message1
  | test.ConsumerChannel@affc70 findConsumer test.ConsumerChannel@affc70 Message1 []
  | 
  | // And ack the message on the original channel
  | test.ConsumerChannel$ConsumerChannelDelivery@1a8c4e7 ack
  | test.ChannelImpl@1004901 ack test.ConsumerChannel$ConsumerChannelDelivery@1a8c4e7
  | 
  | // Now we do the receive
  | test.ConsumerChannel@affc70 receive test.Test$1@1e63e3d  [Message1]
  | test.Test$1@1e63e3d accepts test.ConsumerChannel@affc70 Message1
  | test.ConsumerChannel@affc70 doDelivery test.ConsumerImpl$1@cf2c80
  | Got message Message1
  | 
  | // Which acks to the holding part of the pipe
  | test.ConsumerImpl$1@cf2c80 ack
  | test.ConsumerChannel@affc70 ack test.ConsumerImpl$1@cf2c80
  | 
  | // Receive with not messages
  | test.ConsumerChannel@affc70 receive test.Test$1@1e63e3d  []
  | 
  | // Now we add a message
  | test.ChannelImpl@1004901 addMessage Message2
  | test.ChannelImpl@1004901 internalAddMessage Message2
  | test.ChannelImpl@1004901 findConsumer test.ChannelImpl@1004901 Message2 [test.ConsumerChannel@affc70]
  | test.ConsumerChannel@affc70 accepts test.ChannelImpl@1004901 Message2
  | test.ConsumerChannel@affc70 findConsumer test.ChannelImpl@1004901 Message2 [test.Test$1@1e63e3d]
  | test.Test$1@1e63e3d accepts test.ChannelImpl@1004901 Message2
  | 
  | // This can go straight through the pipe
  | test.ChannelImpl@1004901 doDelivery test.ConsumerImpl$1@1729854
  | Got message Message2
  | test.ConsumerImpl$1@1729854 ack
  | test.ChannelImpl@1004901 ack test.ConsumerImpl$1@1729854
  | 
  | // We are going to NACK this, see the test code
  | test.ChannelImpl@1004901 addMessage Message3
  | test.ChannelImpl@1004901 internalAddMessage Message3
  | test.ChannelImpl@1004901 findConsumer test.ChannelImpl@1004901 Message3 [test.ConsumerChannel@affc70]
  | test.ConsumerChannel@affc70 accepts test.ChannelImpl@1004901 Message3
  | test.ConsumerChannel@affc70 findConsumer test.ChannelImpl@1004901 Message3 []
  | test.ChannelImpl@1004901 doDelivery test.ConsumerChannel$ConsumerChannelDelivery@6eb38a
  | test.ConsumerChannel@affc70 addMessage Message3
  | test.ConsumerChannel@affc70 internalAddMessage Message3
  | test.ConsumerChannel@affc70 findConsumer test.ConsumerChannel@affc70 Message3 []
  | test.ConsumerChannel$ConsumerChannelDelivery@6eb38a ack
  | 
  | // In the holding part of the pipe
  | test.ChannelImpl@1004901 ack test.ConsumerChannel$ConsumerChannelDelivery@6eb38a
  | 
  | // Now we try to receive
  | test.ConsumerChannel@affc70 receive test.Test$1@1e63e3d  [Message3]
  | test.Test$1@1e63e3d accepts test.ConsumerChannel@affc70 Message3
  | test.ConsumerChannel@affc70 doDelivery test.ConsumerImpl$1@1cd2e5f
  | Got message Message3
  | 
  | // Got it but we nack
  | test.ConsumerImpl$1@1cd2e5f nack
  | test.ConsumerChannel@affc70 nack test.ConsumerImpl$1@1cd2e5f
  | 
  | // It goes back in the holding part of the pipe
  | test.ConsumerChannel@affc70 internalAddMessage Message3
  | test.ConsumerChannel@affc70 findConsumer test.ConsumerChannel@affc70 Message3 []
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881146#3881146

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881146

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: The missing prototype...

[<ad...@jb...>]

Test code

  | /*
  |  * JBoss, the OpenSource J2EE webOS
  |  * 
  |  * Distributable under LGPL license.
  |  * See terms of license at gnu.org.
  |  */
  | package test;
  | 
  | public class Test
  | {
  |    public static void main(String[] args) throws Throwable
  |    {
  |       System.setErr(System.out);
  |       
  |       ConsumerImpl consumer = new ConsumerImpl()
  |       {
  |          public void deliver(Object message) throws Throwable
  |          {
  |             super.deliver(message);
  |             if ("Message3".equals(message))
  |                throw new RuntimeException("nack");
  |          }
  |       };
  |       ConsumerChannel consumerChannel = new ConsumerChannel();
  |       consumerChannel.addConsumer(consumer);
  |       ChannelImpl channel = new ChannelImpl();
  |       channel.addConsumer(consumerChannel);
  |       channel.receiveConsumer(consumerChannel);
  |       
  |       channel.addMessage("Message1");
  |       consumerChannel.receiveConsumer(consumer);
  |       consumerChannel.receiveConsumer(consumer);
  |       channel.addMessage("Message2");
  |       channel.addMessage("Message3");
  |       consumerChannel.receiveConsumer(consumer);
  |    }
  | }
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881145#3881145

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881145

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: The missing prototype...

[<ad...@jb...>]

Channel

  | /*
  |  * JBoss, the OpenSource J2EE webOS
  |  * 
  |  * Distributable under LGPL license.
  |  * See terms of license at gnu.org.
  |  */
  | package test;
  | 
  | public interface Channel
  | {
  |    void addMessage(Object message) throws Throwable;
  |    
  |    void addConsumer(Consumer consumer) throws Throwable;
  |    
  |    void removeConsumer(Consumer consumer) throws Throwable;
  |    
  |    void receiveConsumer(Consumer consumer) throws Throwable;
  |    
  |    void ack(Delivery delivery) throws Throwable;
  |    
  |    void nack(Delivery delivery);
  | }
  | 

ChannelImpl

  | /*
  |  * JBoss, the OpenSource J2EE webOS
  |  * 
  |  * Distributable under LGPL license.
  |  * See terms of license at gnu.org.
  |  */
  | package test;
  | 
  | import java.util.ArrayList;
  | import java.util.HashSet;
  | import java.util.Iterator;
  | 
  | 
  | public class ChannelImpl implements Channel
  | {
  |    private ArrayList messages = new ArrayList();
  |    
  |    private HashSet<Consumer> consumers = new HashSet<Consumer>();
  |    
  |    private HashSet<Consumer> waitingConsumers = new HashSet<Consumer>();
  |    
  |    public void addMessage(Object message) throws Throwable
  |    {
  |       System.out.println(this + " addMessage " + message);
  |       internalAddMessage(message);
  |    }
  | 
  |    public void addConsumer(Consumer consumer)
  |    {
  |       System.out.println(this + " addConsumer " + consumer);
  |       consumers.add(consumer);
  |    }
  | 
  |    public void removeConsumer(Consumer consumer)
  |    {
  |       System.out.println(this + " removeConsumer " + consumer);
  |       consumers.remove(consumer);
  |    }
  | 
  |    public void receiveConsumer(Consumer consumer) throws Throwable
  |    {
  |       System.out.println(this + " receive " + consumer + "  " + messages);
  |       if (consumers.contains(consumer) == false)
  |          throw new Exception("Not a registered consumer " + consumers);
  |       Delivery delivery = null;
  |       for (Iterator i = messages.iterator(); i.hasNext();)
  |       {
  |          Object message = i.next();
  |          delivery = consumer.accepts(this, message);
  |          if (delivery != null)
  |          {
  |             i.remove();
  |             break;
  |          }
  |       }
  |       if (delivery != null)
  |          doDelivery(delivery);
  |       else
  |          waitingConsumers.add(consumer);
  |    }
  |    
  |    public void ack(Delivery delivery) throws Throwable
  |    {
  |       System.out.println(this + " ack " + delivery);
  |    }
  | 
  |    public void nack(Delivery delivery)
  |    {
  |       System.out.println(this + " nack " + delivery);
  |       internalAddMessage(delivery.getMessage());
  |    }
  | 
  |    protected void internalAddMessage(Object message)
  |    {
  |       System.out.println(this + " internalAddMessage " + message);
  |       Delivery delivery = findConsumer(this, message);
  |       if (delivery != null)
  |          doDelivery(delivery);
  |       else
  |          messages.add(message);
  |    }
  |    
  |    protected void doDelivery(Delivery delivery)
  |    {
  |       System.out.println(this + " doDelivery " + delivery);
  |       try
  |       {
  |          delivery.deliver();
  |       }
  |       catch (Throwable t)
  |       {
  |          delivery.nack();
  |       }
  |    }
  | 
  |    protected Delivery findConsumer(Channel channel, Object message)
  |    {
  |       System.out.println(this + " findConsumer " + channel + " " + message + " " + waitingConsumers);
  |       for (Iterator<Consumer> i = waitingConsumers.iterator(); i.hasNext(); )
  |       {
  |          Consumer consumer = i.next();
  |          Delivery delivery = consumer.accepts(channel, message);
  |          if (delivery != null)
  |          {
  |             if (consumer instanceof ConsumerChannel == false)
  |                waitingConsumers.remove(consumer);
  |             return delivery;
  |          }
  |       }
  |       return null;
  |    }
  | }
  | 

Consumer

  | /*
  |  * JBoss, the OpenSource J2EE webOS
  |  * 
  |  * Distributable under LGPL license.
  |  * See terms of license at gnu.org.
  |  */
  | package test;
  | 
  | public interface Consumer
  | {
  |    Delivery accepts(Channel channel, Object message);
  | }
  | 

ConsumerImpl

  | /*
  |  * JBoss, the OpenSource J2EE webOS
  |  * 
  |  * Distributable under LGPL license.
  |  * See terms of license at gnu.org.
  |  */
  | package test;
  | 
  | public class ConsumerImpl implements Consumer
  | {
  |    public Delivery accepts(Channel channel, Object message)
  |    {
  |       System.out.println(this + " accepts " + channel + " " + message);
  |       return new DeliveryImpl(channel, message)
  |       {
  |          public void deliver()
  |          {
  |             try
  |             {
  |                ConsumerImpl.this.deliver(message);
  |                ack();
  |             }
  |             catch (Throwable t)
  |             {
  |                nack();
  |             }
  |          }
  |       };
  |    }
  | 
  |    public void deliver(Object message) throws Throwable
  |    {
  |       System.out.println("Got message " + message);
  |    }
  | }
  | 

ConsumerChannel

  | /*
  |  * JBoss, the OpenSource J2EE webOS
  |  * 
  |  * Distributable under LGPL license.
  |  * See terms of license at gnu.org.
  |  */
  | package test;
  | 
  | public class ConsumerChannel extends ChannelImpl implements Consumer
  | {
  |    public Delivery accepts(Channel channel, Object message)
  |    {
  |       System.out.println(this + " accepts " + channel + " " + message);
  |       Delivery delivery = findConsumer(channel, message);
  |       if (delivery == null)
  |          delivery = new ConsumerChannelDelivery(channel, message);
  |       return delivery;
  |    }
  |    
  |    protected class ConsumerChannelDelivery extends DeliveryImpl
  |    {
  |       public ConsumerChannelDelivery(Channel channel, Object message)
  |       {
  |          super(channel, message);
  |       }
  |       
  |       public void deliver()
  |       {
  |          try
  |          {
  |             addMessage(message);
  |             ack();
  |          }
  |          catch (Throwable t)
  |          {
  |             nack();
  |          }
  |       }
  |    }
  | }
  | 

Delivery

  | /*
  |  * JBoss, the OpenSource J2EE webOS
  |  * 
  |  * Distributable under LGPL license.
  |  * See terms of license at gnu.org.
  |  */
  | package test;
  | 
  | public interface Delivery
  | {
  |    Object getMessage();
  |    
  |    void deliver();
  |    
  |    void ack() throws Throwable;
  |    
  |    void nack();
  | }
  | 

DeliveryImpl

  | /*
  |  * JBoss, the OpenSource J2EE webOS
  |  * 
  |  * Distributable under LGPL license.
  |  * See terms of license at gnu.org.
  |  */
  | package test;
  | 
  | public class DeliveryImpl implements Delivery
  | {
  |    protected Channel channel;
  |    protected Object message;
  |    
  |    public DeliveryImpl(Channel channel, Object message)
  |    {
  |       this.channel = channel;
  |       this.message = message;
  |    }
  | 
  |    public Object getMessage()
  |    {
  |       return message;
  |    }
  | 
  |    public void deliver()
  |    {
  |    }
  |    
  |    public void ack() throws Throwable
  |    {
  |       System.out.println(this + " ack");
  |       channel.ack(this);
  |    }
  | 
  |    public void nack()
  |    {
  |       System.out.println(this + " nack");
  |       channel.nack(this);
  |    }
  | }
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881144#3881144

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881144

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - The missing prototype...

[<ad...@jb...>]

Ovidiu, after reading your comments about race conditions in revision1
I went to my abandoned prototype and remembered that I didn't commit
the final prototype that did the all the receive processing.
I couldn't find it on my laptop either, so it is either on my other laptop
or I deleted it :-(

I've tried to quickly reproduce it. 
Obviously I can't reproduce it exactly in such a short time, so this does not
include things like full error checking, synchronization or close processing :-)

Some of the names have changed from the original, and in the original
I abstracted out policy into handlers.
Don't worry too much about the names or the implementation not matching
yours. This is not deliberate, I just want to demonstrate the notion of "Delivery"
which I think I originally called an "Acknowledgement"?

The idea is that when you deliver a message the accepts creates a "Delivery"
which the Channel can hold. The Delivery is the vehicle for acks/nacks.
If the channel detects that the Consumer/Receiver crashes, or it removes itself
without completing the processing, it can do the nacks for it 
(not shown in this quick bit of code).

The Delivery forms a sort of identity for the message processing that is
established *before* it is actually done. It lets you trap spurious or double
acks/nacks.

I'll show the example code implementing the point then some test code
with the output.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881143#3881143

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881143

[Jboss-dev-forums] [TODO -- DEVELOPMENT] - Re: Want to contribute?

[<s.r...@wa...>]

Hello 
I want to join to JBossRemoting what I should to do.



Regards
Sebastian 



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881138#3881138

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881138

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messaging Core Specification - Revision 1

[<ovi...@jb...>]

The new document presents mainly concepts that haven't been sufficiently qualified by the first version. If you think about it in terms of diff, the revision should be merged in the first version, the overlap is minimal. I will eventually do that and produce a consolidated version, but only after I have at least a working beta out.  Until them, here are some highlights:

The AcknowledgmentStore was renamed ChannelState (since it contains more than acknowledgments).

The first document doesn't specify too much about transactional and reliable handling. Revision 1 does. It's true that further work needs to be done on a more detailed specification for persistence. I will do that soon.

The first document doesn't specify anything about an individual message state. Revision 1 does.

The revision also highlights the changes that have been applied to the Channel interface.

New subjects are filters and message order. 






View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881134#3881134

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881134

[Jboss-dev-forums] [Design of JBoss Internal Benchmarking] - Re: Datasource on JRunit Web Report application

[<ad...@jb...>]

Ideally, it should be in a resource-ref.

In anycase, you can always define the real binding with a naming alias.

  |    <mbean code="org.jboss.naming.NamingAlias"
  |                 name="jboss.jrunit,type=DataSource,alias=JRunitDS">
  |       <attribute name="FromName">java:/JRunitDS</attribute>
  |       <attribute name="ToName">java:/MySQLDS</attribute>
  |       <depends>jboss:service=Naming</depends>
  |    </mbean>
  | 


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881133#3881133

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881133

[Jboss-dev-forums] [Design of JBoss Internal Benchmarking] - Datasource on JRunit Web Report application

[<cle...@jb...>]

I will need to use a datasource for accessing the database with benchmark executions.

I'm considering to use a pre-determined name (like JRunitDS) and document it. 

Is this okay, or someone thinks I should configure it in a XML/property file?


Clebert

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881132#3881132

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881132

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messaging Core Specification - Revision 1

[<ad...@jb...>]

Since you didn't update the original page....
Can you post a "diff" that summarises the changes?


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881130#3881130

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881130

[Jboss-dev-forums] [Design of Persistence on JBoss] - EJB3.0 Preview outside the J2EE container?

[levitator <nu...@jb...>]

Hi,

Apparently with the new EJB3.0 apis it is possible to use the persistence implementations from different vendors both within and outside a J2EE container. 

Is this possible with the EJB3.0 Preview 5 implementation of persistence from JBOSS? Can I use the jar to persistence of plain java objects outside the container environment? If so, is there any resource you could point me to that will help me do this quickly?

Thanks
levitator

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881117#3881117

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881117

[Jboss-dev-forums] [Design of JBoss Remoting, Unified Invokers] - Re: Streaming support - use cases?

[<tom...@jb...>]

"ma...@jb..." wrote : anonymous wrote : 1. Requirements for accessing the client over the network. Right now, the requirement would be that the server MUST be able to make calls directly to the client in order to reach that callback component for the client's stream. I don't see any other way to do this at the moment. Is this an acceptable requirement? 
  | 
  | Does this mean if I want to stream data, that means I have to have a socket open on my client side?  Not desireable.  Maybe I misunderstand what you are saying.

Yes.  Is the only way I can think of so that when the server handler calls the read() method on the server side, I can call back on the client to execute the read() method on the actual stream object on the client.  Let me know if you can think of another way to do this.  When the UIL2 type transport is done, that will call will back over the same socket the client called on, so won't be an issue (but that is a ways off, so don't want to wait for it at this point).

anonymous wrote : 
  | As for the API, can't you just overload invoke() with an invoke(InputStream) and let the compiler take care of it?

That works.  Only issue would be context of the call.  Just not sure if server side will know what to do with the stream.  If user codes so that does same thing with every stream that comes in, then is fine.  Just didn't know if would want to have any other data attached with the call (but guess that can be done via metadata passed if have to).

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881107#3881107

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881107

[Jboss-dev-forums] [Design of JBoss Remoting, Unified Invokers] - Re: Streaming support - use cases?

[<ma...@jb...>]

anonymous wrote : 1. Requirements for accessing the client over the network. Right now, the requirement would be that the server MUST be able to make calls directly to the client in order to reach that callback component for the client's stream. I don't see any other way to do this at the moment. Is this an acceptable requirement? 

Does this mean if I want to stream data, that means I have to have a socket open on my client side?  Not desireable.  Maybe I misunderstand what you are saying.

As for the API, can't you just overload invoke() with an invoke(InputStream) and let the compiler take care of it?

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881103#3881103

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881103

[Jboss-dev-forums] [Design of JBoss Remoting, Unified Invokers] - Streaming support - use cases?

[<tom...@jb...>]

I am working on adding support of adding the ability to send InputStreams via remoting.  I have the basics working, but am struggling with how to expose this via the API.  

The concept is that if a user wants to pass any InputStream type to the server, the remoting framework will keep a reference to that stream on the client side and create a server component wrapped around that InputStream.  Then will call on the server side to let it know it has an InputStream available and create a proxy on the server side to that InputStream on the client (which calls back on the server component created).  The user handler on the server side is just given that InputStream proxy, which is typed as an InputStream so can call on it as though it was a local InputStream.  I have all this working.

So now onto the questions.  

1. Requirements for accessing the client over the network.  Right now, the requirement would be that the server MUST be able to make calls directly to the client in order to reach that callback component for the client's stream.  I don't see any other way to do this at the moment.  Is this an acceptable requirement?

2. What should the client API for this call look like?  I would prefer to make this a seperate method within the Client class (i.e. stream(InputStream stream)).  This makes it much easier to process because I know I am dealing with a stream explicitly.  The only problem is just sending an InputStream to the server handler does not provide much context as to what to do with it.  Also requires the user code on the client to know it is sending an InputStream (which I feel comfortable with as a requirement).

The other way to do this would be to just call on the existing invoke(Object param) method and pass the InputStream as the param.  This is easier from the client coding side, but will require a check on the param to see if it is of type InputStream (so extra overhead which is probably not often needed).  Then under the covers, can process it as would the stream(InputStream stream) method.  

Once again, still have the problem of the server handler just getting the stream without any context as what to do with it.  So another, more difficult option, would be to inspect the entire object graph for any param passed in the invoker(Object param) method and try to see if it contains an InputStream at any level and handle it.  This option is almost impossible because even if can find that one of the object reference within one of the member variables of param object is of type InputStream, can not be sure that I will be able to remove it and replace with the wrapper.  The only way I can think to do this is to use AOP and would then not make it into the next release of remoting.

3. When to close the stream?  My idea was to wait till the server handler called close() on the stream proxy and then close it on the client side.  Only problem is in the case there is some sort of network error where the server can not reach the client and the client's real InputStream never gets closed.  Should there be some sort of timeout based around this?

Please provide any input you might have on this and will try to get this knocked out within the next week for the remoting release.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881100#3881100

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881100

[Jboss-dev-forums] [Design of JBoss Eclipse IDE (dev)] - Re: suport for eclipse 3.1M7+

[raghavendra.vaidya <nu...@jb...>]

one of the things that changed from 3.1 M6 to 3.1 M7 + is the changes that were made to the org.eclipse.jdt.internal.debug.ui.launcher.LauncherMessages...the eclipse team removed the getString(String arg0) method and created a series of public static String fields which were initialized...I think the JBOss IDE plugin needs to make changes to use the public static fields instead of calling getString method...

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881098#3881098

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881098

[Jboss-dev-forums] [Design of JBoss Remoting, Unified Invokers] - Re: remoting on Jboss 3.x

[<tom...@jb...>]

I don't know all the touch points in remoting to external JBossAS, but my guess would be that it would not be able to run within an older version dues to these.  

I will be building a jboss-remoting-client.jar as part of this next release, so will be easier to narrow what the dependancies will be.  

As a side note, remoting has existed in the 3.x releases since 3.2.4, but is one of the very early versions.  So the API is a little bit different (and really isn't supported any more).

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881094#3881094

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881094

[Jboss-dev-forums] [Design of JBoss Remoting, Unified Invokers] - remoting on Jboss 3.x

[<ma...@jb...>]

I'm curious to know about the possibility of running JBoss/Remoting inside JBoss 3.x.

As we know, JBoss/Remoting can run standalone - so it doesn't have any JBossAS dependencies.  However, due to some libraries that ship with JBoss/Remoting, there are classpath/classloading issues that occur if you run in JBossAS (i.e. JBossAS ships with the same libraries - which may or may not be the same versions as those libraries shipped with JBoss/Remoting).

But what if I just want to run the "client" portion of JBoss/Remoting in a JBossAS (3.2.3 to be exact)?

I assume there will still be problems (jboss-common.jar is probably used on both client and server).  But I figured I would ask.  Is it possible to separate out the client API and its components from the server and run it in JBossAS 3.x.  [as I type this, I'm coming to the realization that you can't do this, but since I'm here I'll post this just to get the confirmation]

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881092#3881092

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881092

[Jboss-dev-forums] [Design of JBoss Eclipse IDE (dev)] - Re: Cannot enter closing brackets with German keyboard

[vollmarm <nu...@jb...>]

I had the same problem.
See here for the solution:

http://www.jbossgroup.com/index.html?module=bb&op=viewtopic&t=61526



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881091#3881091

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881091