Re: [JBoss-dev] EJB Timer Service Update
(when) does it make sense to backport this to the 3.2 branch? how much effort is it? Holger On Tue, 2002-12-17 at 07:37, Andy wrote: > Hi Geeks > > I just checked in the latest update of the EJB Timer Service. I added a > simple > file-based persistence layer, finished the implementation of the Timer class > and > added a timer testcase to the JBoss testsuite. > > The next part is the implementation of the transaction support. Right know I > think > I will just make the AbstractTimerSource transactional and manage the > pending > timers in memory. The spec. request at least one resend of the timeout and I > will > drop the timeout afterwards. > > Have fun > > Andreas Schaefer > "Code or be coded" > > Check out www.madplanet.com > > > > > --- > This sf.net email is sponsored by: > With Great Power, Comes Great Responsibility > Learn to use your power at OSDN's High Performance Computing Channel > http://hpc.devchannel.org/ > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.NET email is sponsored by: Geek Gift Procrastinating? Get the perfect geek gift now! Before the Holidays pass you by. T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX on the client side?
On Mon, 2002-11-11 at 07:13, Dain Sundstrom wrote: > Hiram Chirino wrote: > >>Hiram, I think you missed the point. Of course we could do this with > >>out requiring JMX; anything is possible. The point is if we agree that > >>JMX is always on the client side then entire system is simplified. > > > > I guess the disconnect is happening right here. IMO JMX does not always > > make things easier. What do you think JMX provides that would simplify "the > > entire system"? Is it: > > (1) Runtime server administration > > (2) Service creation/configuration/lookup. > > > > Even though those are super important on the server side, I just don't see > > how important those would be on the client side. Am I missing something > > else? > > Yes. The microkernel, but more importantly only one system to > understand. The reuse is huge, and not just code reuse; we get reuse of > understanding and design. > > As for specifics on what I think is most important about JMS, I would > say detyped invocation, lifecycle management and lookup. The management > stuff is useful too ;) Without even understanding, what the specifics of detyped invocation, .. are, I _can_ say, that using the microkernel on the client side is the way to go. It's aspect oriented programming, what the EJB spec is all about (although most people seem to ignore it). Only the notation of aspects isn't as smooth as can get yet. We need services, we need containers, we need interceptors and we need aspects everywhere. BTW: jboss architecture must support calls between different jboss jvms with proper transaction handling anyway. So beside an application-client deployer, the requirements of a jboss client are a subset of the requirements of the server. just my 2 cents, Holger --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: FW: [JBoss-dev] configuration of interceptors
On Fri, 2002-09-13 at 07:43, Hiram Chirino wrote:
Sounds good. What I want to configure is the aspects, not the
interceptors. The interceptors have to arrange themselves, travel to the
client, reside on the server, complement one another, ..
However, I don't really know, what the xml should contain? Is there a
tool, where I select aspects and it will automatically write the
interceptor configuration to the xml. Or do I write the aspects in the
xml and the interceptors are installed automatically during deployment?
the former is more flexible, because I can change the output of the tool
manually. The latter definately feels more magic.
Holger
> >
> > interface AspectManager
> > {
> > void createChain(String name);
> > void registerInterceptorSingleton(String name, Interceptor interceptor);
> >
> > // These methods globally modify the chain of any Aspect in system with
> > the given name
> > void prependAspect(String chainname, String interceptorName,
> > Class clazz,
> > Element metadata);
> > void appendAspect(String chainname, String interceptorName, Class clazz,
> > Element metadata);
> >
> > void prependAspect(String chainname, String singletonName);
> > void appendAspect(String chainname, String singletonName);
> >
> > void removeAspect(String chainname, String interceptorName);
> >
> >
> > /**
> >* Given any old object, make it Aspect Oriented.
> >* metadata could hold InvocationContext-like information
> >*/
> > Aspect metamorphisis(String chainName, Class[] interfaces, Element
> > metadata, Object targetObject);
> >
> > /**
> >* No target object, useful for remote invocations.
> >* metadata could hold InvocationContext-like information like
> > MBean name
> > to invoke on
> >* and stuff like that.
> >*/
> > Aspect createAspect(String chainName, Class[] interfaces, Element
> > metadata);
> > }
> >
> > /**
> > * Every DynamicProxy would implement this interface
> > */
> > interface Aspect
> > {
> >String getAspectName();
> >
> >/**
> > * Allows you to detach this particular aspect
> > */
> >void setAspectName(String newName);
> >
> >Object[] getInterceptors();
> >Interceptor findInterceptor(String name);
> >
> >Object getTargetObject();
> >
> > }
> >
> >
> > So, XML would look something like this. An AspectChain MBean would create
> > chains within the AspectManager. Add a new keyword to XML .
> > This would give the deployer a reference to the name of the interceptor
> > chain to use. The Deployer would create a Proxy via the
> > AspectManager with
> > this chain name and register this Proxy with the MBeanServer.
> >
> > >name="MyMBean">
> >
> > jboss.AspectChains:name=SomeOldChain
> >
> >
> > >name="jboss.AspectChains:name=ClientProxyChain>
> >
> >
> > > name="Transaction"
> > type="instance"
> > class="org.jboss.proxy.TransactionInterceptor"
> > />
> >
> >
> >
> >
> >
>
> Looks cool. I'll send you the javadocs for what I commited to CVS today.
> My stuff is lacking on the JMX features. Anyways.. I'm glad we are all
> exited about this kinda stuff.
>
> Regards,
> Hiram
>
> >
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Hiram
> > > Chirino
> > > Sent: Thursday, September 12, 2002 2:25 PM
> > > To: [EMAIL PROTECTED]
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: FW: [JBoss-dev] configuration of interceptors
> > >
> > >
> > >
> > > Ok I imagine a client invocation chain will look like:
> > >
> > > clientproxy -> client-interceptor-stack ->
> > > serverproxy -> server-interceptor-stack -> targetMbean
> > >
> > > Would doing some think like this satisfy you client-server
> > requirments? :
> > >
> > > serverproxy = factory.createAspect("server-interceptor-stack",
> > > targetMbean);
> > > clientproxy = factory.createAspect("client-interceptor-stack",
> > > serverproxy
> > > );
> > >
> > > Please note: that "server-interceptor-stack" in essence will resolve to
> > > a set of { server-interfaces[], server-interceptors[],
> > > server-configurations[] }
> > >
> > > On another note, right now the factory that generates the proxys
> > > for say the
> > > "server-interceptor-stack", is configured through static xml
> > > files. If we
> > > provide a JMX interface to the factory so that you can view/update stack
> > > configurations, would that satisfy your requirement "to have
> > > these puppies
> > > manageable."
> > >
> > > Regards,
> > > Hiram
> > >
> > >
> > > >From: "marc fleury" <[EMAIL PROTECTED]>
> > > >To: <[EMAIL PROTECTED]>
> > > >Subject: FW: [JBoss-dev] configuration of interceptors
> > > >Date: Thu, 12 Sep 2002 13:44:03 -0400
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: [EMAIL PROTECTED]
> > > > > [mailto:[EMAIL PROTECTED]] On
> > > > > Behalf Of marc fleury
> > > > > Sent: Thursda
RE: [JBoss-dev] http transport
On Thu, 27 Jun 2002, Holger Engels wrote: > That is local jndi. I am looking up the "coded name" in my local > jndi-namespace. The coded name is defined as an ejb-ref in my > application-client.xml. what I get is something, that feels like a proxy > to the ejb's home. the ejb-ref must be configured with: > > o an url, that points to the invoker (protocol, server, "context") > o the jndi-name of the bean > o optional client interceptors > > if I invoke create(..) on this proxy, the invocation is stuffed with the > jndi-name and forwarded to the invoker (url). the invoker returns a > handle, that contains all configuration, that is required to setup the > invoker proxy and the client interceptors. > > So now tell me, for what do I need the server side jndi content on the > client? Maybe, I'm missing something .. > > connecting to a cluster might need some more configuration (there are more > than one servers/invokers). but it's not harder to connect to a clustered > invoker than to bootstrap clustered jndi access. > > restriction: all home methods (create, finders, entity) won't have the > interceptor configuration from the server. Ok, I can see it now. Fetching the complete invoker proxy from the server is the better idea. It works also with other component types (without home interfaces). Still want the mapping from coded names to jndi-names in my application-client.xml and still want to have the possibility to specify additional interceptors for *-refs. Holger --- This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
On Thu, 27 Jun 2002, Sacha Labourey wrote: > > Yes. But if we need to bootsrap the jndi communication, we can skip this > > jndi lookup and just send the create invocation to the invoker. How the > > invokers can be accessed must either be "wellknown" or somehow configured > > on the client. > > yes, the problem is that I am not sure (in fact I am pretty sure that it is > not possible with RMI/JRMP) that it is possible to have "well-known" ports > for a very simply reason: SocketFactory can be set for the RMI invoker on > the server side for example. If I remember well, this well-known thing is > possible with CORBA. > > > Please, please tell me, for what do we need server side jndi content on > > the client? > > ?!? MyHome home = ctx.lookup (MyHome.JNDI_NAME); ?!? > > Do I understand your question? > That is local jndi. I am looking up the "coded name" in my local jndi-namespace. The coded name is defined as an ejb-ref in my application-client.xml. what I get is something, that feels like a proxy to the ejb's home. the ejb-ref must be configured with: o an url, that points to the invoker (protocol, server, "context") o the jndi-name of the bean o optional client interceptors if I invoke create(..) on this proxy, the invocation is stuffed with the jndi-name and forwarded to the invoker (url). the invoker returns a handle, that contains all configuration, that is required to setup the invoker proxy and the client interceptors. So now tell me, for what do I need the server side jndi content on the client? Maybe, I'm missing something .. connecting to a cluster might need some more configuration (there are more than one servers/invokers). but it's not harder to connect to a clustered invoker than to bootstrap clustered jndi access. restriction: all home methods (create, finders, entity) won't have the interceptor configuration from the server. Holger --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
On Thu, 27 Jun 2002, Sacha Labourey wrote: > Just a small point: do we agree that independing on the protocol used to > communicate with JNDI, the proxy needs to be obtained in a specific way > (like now, through standard TCP) to bootstrap. Yes. But if we need to bootsrap the jndi communication, we can skip this jndi lookup and just send the create invocation to the invoker. How the invokers can be accessed must either be "wellknown" or somehow configured on the client. Please, please tell me, for what do we need server side jndi content on the client? Holger --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
On Thu, 27 Jun 2002, Bill Burke wrote:
> Holger, your ideas are very interesting and thought provoking. Although I
> disagree with a lot of them (read further), I believe that this is a good
> conversion and something very cool will come out of it.
Actually I've already learned from this discussion ;-)
>
> That's not what I meant. IMHO, coding the protocol into the jndi-name is a
> hack. i.e. ctx.lookup("http/foo")
>
> I think how you communicate to jndi should be described in the
> jndi.properties file. But how you get references to other objects should be
> different.
>
> I would rather have one of these possible solutions:
>
> 1. Depending the transport type, a different value for "foo" is returned.
> If you do a ctx.lookup("foo") and you're talking HTTP, you get a foo HTTP
> proxy back to communicate.
>
> 2. Let the application developer decide how things are mapped in JNDI. For
> instance, we can recommend that they bind a invoker-proxy binding into jndi
> as "http/foo" , iiop as "iiop/foo". Am I making sense?
You mean no url provider, but jndi.properties (=environment)? OK. But I
can't live with global jndi.properties. I need them on a per *-ref basis,
because the components I connect are spreaded across several different
application servers.
> > o the server hosts components and makes them accessible through
> > rmi, iiop,
> > http, .. (different invokers)
> > o serverside interceptors and container are configured per component on
> > the server. Invokers are configured as part of the server configuration.
>
> Right now, client and container and invoker configurations are all separate.
> This allows us to have multiple transports per EJB(later per MBean too).
>
> > o that's the server's part. nothing more!
>
> Not true at all. The server has to have knowledge of the client-side
> interceptors. Where you idea breaks down is when an method returns a
> different EJB or a collection of EJBs of different types. How will your
> ideas work then? How will the correct client-side interceptor chain and
> transport and endpoint be attached to the EJB refs contained in these
> arbitrary collection objects? When I was implementing the multi-invoker
> stuff, I played with the idea of having generic EJB refs, but the idea fell
> apart in this scenario.
Good point! Never thought of that. However, the result of an invocation
are handles or something similar, right?. Can we put the configuration,
that is comming from the server into these handles? Thus a proxy is
partially configured from the client (client chooses the transport and
might in very few cases add its own interceptors) and mostly from the
information, that comes with the handle?
> Also, many server-side interceptors require a mirror client-side interceptor
> to work. Security, Transactions and especially Clustering fall into this
> category.
>
> This just goes against location transparency and I can't see why anybody
> would want to hard-code the address of each component in their system, or to
> manage and know what protocols and what bindings and what client-side
> interceptors are required. Client side configuration just does not scale.
> Too many config files in separate places to manage. People want centralized
> config, especially ISVs.
I want to keep these addresses out of my code, thus only use *-refs (call
it nicknames). But these nicknames have to be mapped to something, that
fully identifies the target. For the server doesn't know the client, but
the client knows, what components are there on the server, this mapping
has to be done on the client? I cant send an email to a nickname. I have
to lookup the email address.
OK, you convinced me, that most of the interceptor chain has to be
configured from the server. My point is now, that I don't want the lookup
in the server's jndi-namespace, before invoking the create method.
1. an invoker proxy is choosen on the client
2. the client knows the address of the invoker (always the same)
3. the client knows what component it wants to connect to (jndi-name)
4. this is all, we need to know, in order to send the create invocation
5. the jndi-name is passed with the invocation of create. the result is
a handle carrying all information, that is required to setup the client
side interceptor chain.
What am I missing?
Holger
---
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
On Wed, 26 Jun 2002, Bill Burke wrote: > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > > fleury > > Sent: Wednesday, June 26, 2002 12:55 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] http transport > > > > > > |Seems like I don't need an HTTPInvoker. Only an HTTPInvokerProxy and a > > |InvokerServlet, that forwards invocations to the local invoker. If I > > > > use the JMX bus directly, > > > > |understand it, the proxy must provide a TransactionPropagationContext > > |instance to each Invocation. This has to be "imported" in the servlet > > |before the invocation is forwarded to the LocalInvoker. > > > > The transaction is not mandatory, but if it is there then yes it has to be > > "imported" (this is a weakness, necessary I am told (?) of the current > > transaction engine design). > > > > This weakness needs to be corrected. > > > |Also, there must be a HTTPProxyFactory, that binds an HTTPInvokerProxy > > |into jndi for every ejb. An then, there's the setup / integration. I need > > |some MBean, that sets up the proxy factory and deploys the servlet. > > > > I am thinking, bill, we should do a "factory bind" in JNDI that knows what > > I think we may have to use JNDI properties to implement this i.e. > > jndi.properties: > > java.naming.factory.initial=org.jnp.interfaces.HTTPNamingContextFactory > java.naming.provider.url=http://yomama.com/JrmpInvoker > > Also, this may be the best solution anyways. I really want to avoid any > proprietary configuration on the client side. Coding the protocol into the jndi-name is a good idea, but I'm still not confident with this approach. I see it this way: o the server hosts components and makes them accessible through rmi, iiop, http, .. (different invokers) o serverside interceptors and container are configured per component on the server. Invokers are configured as part of the server configuration. o that's the server's part. nothing more! o the client / caller does a lookup in its local jndi namespace with a coded name. The coded name is declared somewhere as an ejb-ref, res-ref, *-ref o the declaration of this *-ref is parameterized in a jboss specific descriptor (jboss.xml): + protocoll (InvokerProxy) + identifier of the target component (jndi-name) + both, the protocol and the address of the component can be coded into a single jndi-name, by using a special url context factory for every protocol or by using a subcontext + client side interceptors (there are interceptors, that can _never_ be configured on the server / per component / per invoker (think of a recording interceptor) > I also agree that this whole proxy mess needs to be non-EJB specific and > generic to MBeans. The first step though is creating an HTTPInvokerProxy > and HTTPInvoker. The HTTPInvoker is a servlet or httpd. There's no lookup of this invoker, only invocations, that are sent to the servlet. how many remote calls are involved in a simple acces to a bean method: 1. lookup 2. create 3. bean why not skip the first one? just give the client a proxy, wether the target component is accessible or not. the invocation of create can fail anyway. there's no way, how we could assure, that a create works, if the lookup has worked. thus imo there's no problem, if we skip the lookup. That's like communication happens in real life. If I send you a message, you won't give me the pencil, I have to use. I don't lookup your address at your door. I look it up in my private addressbook. If I send the message, I don't know, if the address is correct. However, I'll notice if it was incorrect. Holger --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
On Mon, 24 Jun 2002, Bill Burke wrote: > ProxyFactory is not an MBean. Just an object right now. Config code, > creates and attaches ProxyFactorys to each EJB. (Each EJB is an mbean > though). Still trying to understand .. Seems like I don't need an HTTPInvoker. Only an HTTPInvokerProxy and a InvokerServlet, that forwards invocations to the local invoker. If I understand it, the proxy must provide a TransactionPropagationContext instance to each Invocation. This has to be "imported" in the servlet before the invocation is forwarded to the LocalInvoker. Also, there must be a HTTPProxyFactory, that binds an HTTPInvokerProxy into jndi for every ejb. An then, there's the setup / integration. I need some MBean, that sets up the proxy factory and deploys the servlet. All that together should be packaged into one single deployment unit, e.g. a sar. Right? Holger --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
On Fri, 21 Jun 2002, Bill Burke wrote: > Holger, in JBoss 3.0 we have client interceptors, and pluggable transports. > The invocation has been totally decoupled from the EJB container. The EJB > Container is now just an MBean and all EJB invocations go across the JMX > bus. Great! > JBoss 3.1 takes things a bit further. In 3.1 you can now define multiple > invokers (transports) per EJB container. So an EJB container can be > configured to receive requests from RMI, IIOP, SOAP, HTTP, whatever all at > the same time. We'll want to hook your HTTP invoker into this architecture. Ok, I'm already trying to do that. > The files and java packages you'll want to look at are as follows, There's > also a detail email I sent out 2 months ago that is copied later on in this > email: > > In server module: > Packages org.jboss.invocation, org.jboss.proxy > > org.jboss.invocation.jrmp.server.JRMPInvoker.java is the main entry point on > the server side. It accepts invocation requests and routes them across the > JMX bus. I think your HTTP POST protocol can be very simple. Just marshall > an Invocation and send it across the wire. The JRMPInvoker is stateless and > can route any Invocation. So far, that's straight forward. I' am writing a HTTPInvoker, that deploys a servlet (same hack as jboss.net axis servlet) and forwards invocations to the HTTPInvoker. The invoker feeds them into jmx. > For the client side, you'll need to implement a new > org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy. This is really the > "Transport" on the client side. You'll also need to implement a > org.jboss.proxy.ejb.ProxyFactory. The JBoss clustering can be used as an > example since it has extended JRMPInvokerProxy, ProxyFactory and has its own > Invoker. see the cluster module. All classes under the above packages. If I understand it correctly, the ProxyFactory is an MBean, running on the server, facturing InvokerProxy instances that are moved to and used on the client (caller side)!? > What sucks is that even if you've implemented this stuff, its not very > helpful because JNDI does not have pluggable transports. Maybe I am still missing something, but what if the server configuration would simply end with the invoker layer. container is server side. invoker is the entry point for the container, thus also server side. remaining config is _client_side_. The client (another bean, application-client, web-application) is always referring an (ejb|ejb-local|..)-ref (coded name) in its private jndi namespace. It is never accessing the server's jndi namespace directly! The ejb-ref is the place for configuration bits that: o identify the target component o determine the transport protocol o locate the invoker o setup the client interceptors (terms server and client often used in the sense of callee/caller) This would have some big advantages: o decoupling of client and server o no jndi plugins for different protocols required o jndi is mostly (if not completely) local o server is responsible for containment and accessibility o client can connect wherever it wants (also to different appservers in different locations with different protocols) o client code uses coded names instead of deployment specific jndi-names o client interceptors are configured per client .. thus server makes no assumptions about the client Holger --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
On Fri, 21 Jun 2002, Bill Burke wrote: > Good enough for me. Thanks for the info. Holger, we should talk. I can > give you pointers on how to integrate the HTTP Invoker into the 3.1 > architecture. Ok, I need to know, where I can start. If you could answer the questions of my first mail, this would be great. I had a look at the iiop module. I think, the http invoker is less complex. I don't need a proxy compiler, no ior, no naming service, .. how do you call, what I call "transport", the last interceptor on the client side, that does the marshalling. that is the point, where the invocation has to be embedded in a http post request? What are the classnames of the IIOP / RMI / SOAP pendants? They serve as a reference for the http implementation. How can I configure jboss to use my implementation of this class? invoker-proxy-binding? unfortunately, I won't be in the office till monday and thus won't read / answer mail until then .. holger > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Dave > > Smith > > Sent: Friday, June 21, 2002 10:21 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] http transport > > > > > > The HTTP RMI tunning is the shits. Firstly there is no option to go with > > https without getting really ugly. Secondly, the whole cgi-script or > > servlet which then calls the local rmi listener generates two network > > calls for lookup. Since jetty is running in the container the servlet > > lookup should be a local JNDI lookup. > > > > If you read Holger's web site (http://smartcc.sourceforge.net) he is > > trying to cleanup EJB transport issues when firwalls are in the way. > > > > I hope somebody with more knowledge than me steps up to the plate. I for > > 1 will be using this stuff.. > > > > > > > > > > On Fri, 2002-06-21 at 08:36, Bill Burke wrote: > > > JDK already has built in RMI HTTP tunneling. Why would we need this > > > transport? > > > > > > Here's directions: > > > > > > > > > http://www.dmh2000.com/ApacheTomcatRMI.htm > > > > > > Bill > > > > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > > > Holger Engels > > > > Sent: Friday, June 21, 2002 5:00 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: [JBoss-dev] http transport > > > > > > > > > > > > > > > > I try to understand, how a http transport can be implemented > > within jboss > > > > .. so what do I need? > > > > > > > > > > > > on the server side: > > > > > > > > o a connector servlet / extra http deamon, that accepts invocations > > > > embedded in http posts. the result of a home invocation is a handle. > > > > subsequent invocations (remote interface) contain the > > handle to identify > > > > the target ejb. the servlet is completely stateless. > > > > o an mbean service, that manages the servlet / http deamon > > > > > > > > > > > > on the client: > > > > > > > > o some interceptor (the last one in the chain), that marshalls the > > > > invocation as an http post request and demarshalls results > > / throwables. > > > > I call it the 'Transport' > > > > o is a special handle implementation required? > > > > o usertransaction handling is transparent (part of Invocation)? > > > > > > > > > > > > configuration: > > > > > > > > o it's the server's job to provide the connector servlet. the servlet > > > > doesn't need to be configured. the invocations carry all > > the information > > > > that is required to perform home-/ remote-invocations. > > > > > > > > o the client will do a lookup first (coded name, declared in the > > > > application-client descriptor). it then gets a dynamic > > proxy passing on > > > > the java style invocation to the invocation handler. the invocation > > > > handler feeds the invocation into the interceptor chain. > > this chain has > > > > to be configured somehow (during deployment of the > > application-client > > > > jar). > > > > > > > > o afaik there's no application client deployment at the moment and
[JBoss-dev] http transport
I try to understand, how a http transport can be implemented within jboss .. so what do I need? on the server side: o a connector servlet / extra http deamon, that accepts invocations embedded in http posts. the result of a home invocation is a handle. subsequent invocations (remote interface) contain the handle to identify the target ejb. the servlet is completely stateless. o an mbean service, that manages the servlet / http deamon on the client: o some interceptor (the last one in the chain), that marshalls the invocation as an http post request and demarshalls results / throwables. I call it the 'Transport' o is a special handle implementation required? o usertransaction handling is transparent (part of Invocation)? configuration: o it's the server's job to provide the connector servlet. the servlet doesn't need to be configured. the invocations carry all the information that is required to perform home-/ remote-invocations. o the client will do a lookup first (coded name, declared in the application-client descriptor). it then gets a dynamic proxy passing on the java style invocation to the invocation handler. the invocation handler feeds the invocation into the interceptor chain. this chain has to be configured somehow (during deployment of the application-client jar). o afaik there's no application client deployment at the moment and the client side interceptors are configured from the server, right? so what makes up the whole interceptor chain? we distinguish: o client side interceptors o server side interceptors (synchronization, pooling / caching, security) o symmetric interceptors (encryption / decryption for instance) the overall configuration of the (ordered) interceptor chain is made of component aspects and reference aspects. transport is just another aspect of the reference. authentication: in the smartcc, using the http transport requires a http login module (basic/digest auth) to be configured. the authentication task is performed by the servlet container. the container cares about setting up the security association. dain asked for an http plugin for jndi. my question: why do I need the server side's jndi content on the client if I don't lookup homes? what does a java client need beside what's configured in the application client descriptor. what am i missing? holger --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [PATCH] jaws JDBCCommand
Please insert these two lines into the JDBCCommand. The patch has been
applied to the 2.4 branch some time ago, but unfortunately didn't make it
into 3.0.
Description:
when a cmp field of type byte[] is written, it is written as a plain byte
array (no serialization takes place). when it is read back, it is
deserialized .. and that - of course - fails!
=
--- src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java 12 Jan 2002 21:14:27
- 1.41
+++ src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java 14 Jun 2002 15:14:34
+-
@@ -454,6 +454,8 @@
if( bytes == null ) {
result = null;
+} else if (destination.getName().equals("[B")) {
+ return bytes;
} else {
// We should really reuse these guys
=
Thanks,
Holger
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss through firwall - RMI -HTTP tunneling
On 12 Jun 2002, Marius Kotsbak wrote: > On Wed, 2002-06-12 at 14:03, Holger Engels wrote: > > On 12 Jun 2002, Dave Smith wrote: > > > > > > > > Now I have my swing client running with a jboss backend I would like to > > > move this beast out on to the internet. Some of my clients have > > > firewalls that only allow them http and https access through a proxy, so > > > a direct connection is out. It would seem I could optimize this by > > > writting a custom EJB proxy for the connection and use HTTP tunneling > > > for the naming lookup. I think soap for my app is overkill and would be > > > quite slow. > > > > > > Experences, optionions , suggestions? > > > > > > > smartcc.sourcefore.net .. a generic j2ee conform client container, that > > addresses exactly this problem. Features: > > > > o client side interceptors > > o pluggable transport (RMI/HTTP) > > o Replay Tool for recording use cases and performing load tests > > o no proprietary API > > > > Holger > Interesting. Have you tried it? Well .. yes. I have coded it. > There is just some extra jars and a modified auth.conf on the client > side? Is it a server part of this also? Client side: o ClientContainer.jar, crimson.jar, ejb.jar, jaxp.jar o auth.conf: org.smartcc.login.HTTPLoginModule for HTTP org.jboss.security.ClientLoginModule for RMI o META-INF/application-client.xml with s o META-INF/smart-client.xml with additional configuration for ejb-refs (interceptor chain, transport) Server side: o nothing for RMI o generic HTTPConnector servlet for HTTP. The servlet's web.xml must be configured with ejb-refs. The pathinfo is used as the jndi name. https should work, too. Actually, I have not tested it. But the predecessor of the client container (in house project) does work with https transparently. Holger ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss through firwall - RMI -HTTP tunneling
On 12 Jun 2002, Dave Smith wrote: > > Now I have my swing client running with a jboss backend I would like to > move this beast out on to the internet. Some of my clients have > firewalls that only allow them http and https access through a proxy, so > a direct connection is out. It would seem I could optimize this by > writting a custom EJB proxy for the connection and use HTTP tunneling > for the naming lookup. I think soap for my app is overkill and would be > quite slow. > > Experences, optionions , suggestions? > smartcc.sourcefore.net .. a generic j2ee conform client container, that addresses exactly this problem. Features: o client side interceptors o pluggable transport (RMI/HTTP) o Replay Tool for recording use cases and performing load tests o no proprietary API Holger ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] instance pool too eager?
a stateless sessionbean with an instance counter writes the following lines to the console: first run: 17:50:25,231 INFO [STDOUT] [-1] new 17:50:25,252 INFO [STDOUT] [-1] setSessionContext org.jboss.ejb.StatelessSessionEnterpriseContext$SessionContextImpl@558939 17:50:25,254 INFO [STDOUT] [1] create 17:50:25,257 INFO [STDOUT] 1 message: remote test 17:50:25,259 INFO [STDOUT] [-1] new 17:50:25,261 INFO [STDOUT] [-1] setSessionContext org.jboss.ejb.StatelessSessionEnterpriseContext$SessionContextImpl@4a7df6 17:50:25,262 INFO [STDOUT] [2] create 17:50:25,263 INFO [STDOUT] [-1] new 17:50:25,264 INFO [STDOUT] [-1] setSessionContext org.jboss.ejb.StatelessSessionEnterpriseContext$SessionContextImpl@13df2c 17:50:25,266 INFO [STDOUT] [3] create [...] 17:50:29,887 INFO [STDOUT] [-1] new 17:50:29,888 INFO [STDOUT] [-1] setSessionContext org.jboss.ejb.StatelessSessionEnterpriseContext$SessionContextImpl@7918f0 17:50:29,888 INFO [STDOUT] [98] create 17:50:29,897 INFO [STDOUT] [-1] new 17:50:29,898 INFO [STDOUT] [-1] setSessionContext org.jboss.ejb.StatelessSessionEnterpriseContext$SessionContextImpl@546dbc 17:50:29,898 INFO [STDOUT] [99] create 17:50:29,900 INFO [STDOUT] [-1] new 17:50:29,901 INFO [STDOUT] [-1] setSessionContext org.jboss.ejb.StatelessSessionEnterpriseContext$SessionContextImpl@708ed8 17:50:29,901 INFO [STDOUT] [100] create 17:50:29,902 INFO [STDOUT] [-1] new 17:50:29,902 INFO [STDOUT] [-1] setSessionContext org.jboss.ejb.StatelessSessionEnterpriseContext$SessionContextImpl@322bce 17:50:29,903 INFO [STDOUT] [101] create -> 101 instances have been created! although default poolsize is 100 second run: 17:53:46,416 INFO [STDOUT] 101 message: remote test -> current poolsize seems to be 101 and the last instance from the pool seems to be used further runs: 17:53:51,902 INFO [STDOUT] 100 message: remote test 17:53:56,389 INFO [STDOUT] 100 message: remote test 17:53:59,775 INFO [STDOUT] 100 message: remote test -> the last instance from the pool seems to be used, but the pool size was shrinked to 100 instances. maybe the loop, that populates the pool, iterates once too often!? didn't look into the code, because I currently don't have the time, sorry! holger ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] AW: Workaround for CL stuff
On Tue, 23 Apr 2002, Jung , Dr. Christoph wrote: > As a quick work-around while I´m busy today with doing business (buaaeeeh:-( > > Patch the java.lang.ClassLoader class ... Either remove the synchronized > keyword from loadClassInternal (should be safe) > or make it protected and remove the synchronized keyword in an overriding > method of UnifiedClassLoader (makes the build > Depending on that patch, not that nice). Put the patched class in a > patch.jar and start jboss > With the option -Xbootclasspath/a:patch.jar did you mean -Xbootclasspath/p:patch.jar ? Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] How are ejb-link relative refs really supposed towork?
On Wed, 17 Apr 2002, David Jencks wrote: > IMO the j2ee spec does not clearly define the meaning of relative ejb-link > elements. It gives and example of > > ../products/product.jar#ProductEJB > > What does the .. mean? > > I think it refers to this situation: > > accounting/accounting.jar (the ejb-jar.xml snippet above comes from this) > products/products.jar (contains ProductEJB) > > Any other opinions? Experience with other app servers? That's also the way, websphere people iterprete it. Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JaasSecurityManager is not thread safe
The method
defaultLogin(Principal principal, Object credential)
in JaasSecurityManager instantiates a new LoginContext. The constructor of
LoginContext delegates to com.sun...ConfigFile. The method
getAppConfigurationEntry is not thread safe.
StackTrace:
[ERROR,UserInfo] CONTAINER EXCEPTION:
java.lang.SecurityException: Configuration Error:
Line 3: expected '{', found 'oi'
at
com.sun.security.auth.login.ConfigFile.getAppConfigurationEntry(ConfigFile.java:221)
at
javax.security.auth.login.LoginContext.init(LoginContext.java:172)
at
javax.security.auth.login.LoginContext.(LoginContext.java:266)
at
javax.security.auth.login.LoginContext.(LoginContext.java:380)
at
org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:393)
at
org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:361)
at
org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:217)
at
org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityInterceptor.java:163)
at
org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:91)
at
org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:103)
at
org.jboss.ejb.StatelessSessionContainer.invokeHome(StatelessSessionContainer.java:268)
at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invokeHome(JRMPContainerInvoker.java:387)
at java.lang.reflect.Method.invoke(Native
Method)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241)
at
sun.rmi.transport.Transport$1.run(Transport.java:152)
at
java.security.AccessController.doPrivileged(Native
Method)
at
sun.rmi.transport.Transport.serviceCall(Transport.java:148)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:465)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:706)
at java.lang.Thread.run(Thread.java:484)
Attachment: a java source, that reproduces the error.
Proposal: make defaultLogin(..) synchronized.
Applies: at least to 2.4.4 and 3.0.0
Sorry, I tried to post this on sourceforge several times with both
konqueror and mozilla, but it didn't work.
Holger Engels
package reflect;
import java.io.*;
import javax.security.auth.callback.*;
import javax.security.auth.login.*;
public class Test
{
public static void main(String args[])
throws Exception
{
String resource = "auth.conf";
java.net.URL loginConfig = Test.class.getClassLoader().getResource(resource);
if(loginConfig != null) {
System.setProperty("java.security.auth.login.config",
loginConfig.toExternalForm());
}
System.out.println("init");
int count = new Integer(args[0]).intValue();
Thread[] threads = new Thread[count];
for (int i=0; i < count; i++) {
threads[i] = new Thread(new TestThread());
}
System.out.println("start");
for (int i=0; i < count; i++) {
threads[i].start();
}
}
}
class TestThread
implements Runnable
{
public void run() {
try {
LoginContext lc = new LoginContext("juna", new CallbackHandler() {
public void handle(Callback[] callbacks)
throws IOException, UnsupportedCallbackException
{
}
});
}
catch (Exception e) {
System.err.println(e.getMessage());
e.printStackTrace(System.err);
}
}
}
Re: [JBoss-dev] ejb-local-ref broken?
On Wed, 20 Feb 2002, Scott M Stark wrote: > The DeploymentInfo object groups all of the elements together in > a heirarchy of components. This object is not passed into the > method that creates these ejb links. We need to unify the objects > created to model the deployment and get rid of legacy classes. > Through the complete DeploymentInfo it would be easy to handle > cross ejb-jar links. See the DeploymentInfo.findEjbLink code. The question is: do you want, that Container depends on DeploymentInfo? Rather not! IMHO we should keep all these *Deployment / DeploymentInfo classes out of the Application-(EJB|Web)Module-Container hierarchy. Thus: o rename Application to Module o implement the classes Module, EJBModule, WebModule (give them a method getApplication()) o implement a new class, called Application that models an enterprise application and contains a bunch of Modules o implement a sophisticated getContainer() method, that conforms to ejb-spec-2_0, chapter 20.3.2 o implement an EARDeployer, that is activated by the MainDeployer instead of the method deploySubPackages Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ejb-local-ref broken?
On Wed, 20 Feb 2002, David Jencks wrote: > I'm working on some other modifications to Container and I will apply this > patch (if no one objects). > > I think there is a big problem with the deployment order. Right now with > an ear that contains many ejb jars we deploy the jars individually in a > more or less random order. I believe we need to: > > 1. get all the classes in all of the .ear in classloaders > > 2. in a create() step, create each Container and bind it in jndi. Also make > the jsr-77 mbean. This step should do everything possible that doesn't > look at configuration outside the Container we are create()ing. > > 3. in a start() step, resolve the jndi local environments, links, etc, and > then make the container available to calls. This step hooks up all the > configuration that looks outside the current Container. > > Would this fix the ejb-link problem you refer to? Yes. The class Application is a little missnamed in my opinion because there's a level above required. something that bundles these "Applications" into an "EnterpriseApplication" (what I would call Application) .. Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ejb-local-ref broken?
Actually it does not work .. here's a patch, that fixes at least the local
ejb-links. Mappings, that are specified in jboss.xml are not supported as
of the current implementation. Somebody else posted the same bug, see
jboss-Bugs-520454.
There's another problem left with ejb-links, that span over different
ejb-jars in an ear, see my previous postings with subject "[JBoss-dev] bug
in ear deployment". I think we need something like an EARDeployer and / or
something, that bundles Applications into EnterpriseApplications ..
BTW: websphere 4 allows to choose between one classloader per ear or one
classloader per ejb-jar.
Holger
Index: server/src/main/org/jboss/ejb/Container.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/Container.java,v
retrieving revision 1.76
diff -u -r1.76 Container.java
--- server/src/main/org/jboss/ejb/Container.java17 Feb 2002 03:06:45 -
1.76
+++ server/src/main/org/jboss/ejb/Container.java20 Feb 2002 14:45:23 -
@@ -854,12 +854,11 @@
{
// Internal link
log.debug("Binding "+refName+" to bean source: "+ref.getLink());
- if (getApplication().getContainer(ref.getLink()) == null)
+
+ Container refContainer =
+getApplication().getContainer(ref.getLink());
+ if (refContainer == null)
throw new DeploymentException ("Bean "+ref.getLink()+" not found
within this application.");
- /* Create a link from the ENC to the localJndiName where the
- which is the location of the local home
- */
- Util.bind(envCtx, refName, new LinkRef(localJndiName));
+ Util.bind(envCtx, ref.getName(), new
+LinkRef(refContainer.getBeanMetaData().getLocalJndiName()));
}
else
{
Re: [JBoss-dev] bug in ear deployment
On Wed, 13 Feb 2002, Holger Engels wrote: > > If I got it right, the following happens during deployment of an ear: > > 1. the MainDeployer unpacks the ear and iterates over the modules > 2. the MainDeployer retrieves an apropriate deployer for each module >(e.g. EJBDeployer) and invokes the method "deploy" on it > 3. The EJBDeployer creates an Application for its ejb-jar and _starts_ it! > 4. The Application initializes, _creates_ and starts a Container for every >bean > 5. The create Method invokes setupEnvironment > 6. during setupEnvironment the ejb-links are resolved getApplication(). > > So there's one Application per ejb-jar, instead of one Application per > ear. That's a problem: > > If the ear contained two ejb-jars and an ejb from the first jar > "ejb-ref"-links an ejb from the second jar, the link cannot be resolved: > > getApplication().getContainer(ref.getLink()) > > .. will fail, because the two beans are in different applications. If I'm > right, the EJBDeployer should not instantiate a separate Application for > each ejb-jar, but share one Application instance per ear-File. > > If that's not possible, the Applications could be arranged hierarchically. > All ejb-jar Applications from one ear have one ear Application as parent. > Anyway, there must be a unit, that maps all ejb-names from all modules of > an ear to the appropriate Containers. > Ok, I found out, that the DeploymentInfos are arranged hierarchically and a DeploymentInfo has a public 'shortName'. So it's possible to find all ejb-jar DeploymentInfos, that belong to one ear DeploymentInfo. But that's of no help for the Container .. The shortName can be used as the first part of a "full quallified ejb-name", as described in ejb-spec-2_0, chapter 20.3.2: # The second part of the name is the name of the Container in the Application. To resolve an ejb-name in an ear, we need a containment unit at the level of the ear. The same way, a Container belongs to an Application, an Application might belong to an "ApplicationBundle". Alternatively, we could parent all Containers of all ejb-jars of one ear with one Application instance. I'd prefer the latter, because at runtime, there's no need to distinguish between the origins of the different ejbs. That's only a matter of assembly and ease of deployment. The keys of the map "containers" should be full qualified ejb-names then and if you lookup a plain ejb-name (only second part), you have to iterate through the keys. The EJBDeployer must not start the Application, this task remains to the deploySubPackages method in the MainDeployer. In the Container, the: setupEnvironment(); -call has to be moved to the beginning of the start method, instead of the end of the create method. Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] bug in ear deployment
If I got it right, the following happens during deployment of an ear: 1. the MainDeployer unpacks the ear and iterates over the modules 2. the MainDeployer retrieves an apropriate deployer for each module (e.g. EJBDeployer) and invokes the method "deploy" on it 3. The EJBDeployer creates an Application for its ejb-jar and _starts_ it! 4. The Application initializes, _creates_ and starts a Container for every bean 5. The create Method invokes setupEnvironment 6. during setupEnvironment the ejb-links are resolved getApplication(). So there's one Application per ejb-jar, instead of one Application per ear. That's a problem: If the ear contained two ejb-jars and an ejb from the first jar "ejb-ref"-links an ejb from the second jar, the link cannot be resolved: getApplication().getContainer(ref.getLink()) .. will fail, because the two beans are in different applications. If I'm right, the EJBDeployer should not instantiate a separate Application for each ejb-jar, but share one Application instance per ear-File. If that's not possible, the Applications could be arranged hierarchically. All ejb-jar Applications from one ear have one ear Application as parent. Anyway, there must be a unit, that maps all ejb-names from all modules of an ear to the appropriate Containers. The Application can be started, after all modules of the container are deployed. Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBOSS @ JAVAONE TSHIRT CONTEST
On Wed, 6 Feb 2002, marc fleury wrote: Make something out of "I robot. You boss." .. perhaps: Others robot. JBoss. native speakers: form up! Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] cgs - IGNORE
On Fri, 1 Feb 2002, Holger Engels wrote: sorry, wrong mailing list, wrong project, wrong audience ... ignore it holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] cgs
The scripting and stylesheet extensions in pre-1_0-cleanup require a lot
of changes to the CGs:
o the component's ids have to be written to make the components
addressable by scripts
o the styles, that are defined in the component's attribute set are
written to the dynamic stylesheet. They address the target component
using the "#"-selector (by id).
the button cg may render the following code, if the button has a text but
no icon:
href && enabled:
${text}
form && enabled:
disabled:
${text}
Some weeks ago, we decided to use different id attributes for scripting
and styling. Does somebody remember, why? We could save lots of spans, if
we wouldn't ..
We still have a problem with cell renderers. The ids of a cell renderer
component must not be written for every cell, because the ids have to be
unique. Either we need a way to switch off ids or some counter mechanism.
I tend to the latter. The counter has to be reset before every code
generation traversal and there has to be a counter for every component,
that uses cell renderers. Imagine a table:
id.0 | id.1 | id.2
-+--+-
id.3 | id.4 | id.5
How can we achieve this? Any ideas? We need something like a code
generation context, do we?
BTW: I'd rather make all these changes to the jsp plafs .. when can we
bargain for the compiler?
Holger
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TODO: client side interceptors
On Thu, 31 Jan 2002, Bill Burke wrote: > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Luke > > Taylor > > Sent: Thursday, January 31, 2002 9:32 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] TODO: client side interceptors > > > > > > olger Engels wrote: > > > > > > > > I'm glad to see, that jboss will support pluggable interceptors on the > > > client side, now. You can do cool things with that. Think of: > > > > > > ... > > > > > > > > > > o caching interceptor (for getters) > > > > > > How will that work in practice? Aren't the interceptors stateless, > > without being specific to a particular EJB/component instance? > > > > Well, on the server side, the interceptor chain is uniquely attached to each > container. On the client side, you could have a unique interceptor > chain(instances in memory) attached to each and every proxy. I really like > this idea for EntityBeans. Could be kinda cool. Of course, we'd have to > expand on the metadata to describe this type of thing. > > > > o invocation bundeling (send an array of method invocations and > > return an > > > array of results .. all that in one user transaction) > > > > > > I don't quite get that either - interceptors are meant to be transparent > > to the client code. So how could a client make multiple (sequential) > > invocations and have them bundled into a single request? > > > > You're right here. EJBs have no asynchronous interface like CORBA object do. > Plus, in EJB the request is not exposed like in CORBA as well. > Some interceptors are transparent, others are not .. Let the dynamic proxy implement the remote interface and all additional interfaces of all interceptors, that add non transparent behaviour to the component. We have already three additional apis: o SecurityAssociation o UserTransaction o ejb methods only the last one is directly implemented by the dynamic proxy. security and transactions are somewhat transcendent/magic. A drawback of multiple interfaces is that you have to cast the object to these particular interfaces in order to use them. Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TODO: client side interceptors
On Wed, 30 Jan 2002, marc fleury wrote: > Bill got my hear yesterday where he pitched the interceptor design on the 3.0 client >side. > Instant love. > > We are not that far from it in fact, it a bit of renaming and factory game on the >server. Essentially the client does > > Generic Proxy -> Handler -> EJB behavior -> Transport > > In the transport layer we extract the Tx and Security information. > > The pitch was simple it had to do with moving > > GP->Handler->interceptor 1 (EJB behavior for example) ->interceptor 2 (Tx >extraction) -> interceptor 3 (Security) -> Transport (invoker). I'm glad to see, that jboss will support pluggable interceptors on the client side, now. You can do cool things with that. Think of: o tracing interceptor o profiling interceptor o caching interceptor (for getters) o invocation bundeling (send an array of method invocations and return an array of results .. all that in one user transaction) o exception discrimination for retry / reconnect (if not implemented in the transport already) o loadbalancing / failover for stateless sessionbeans (if not implemented in the transport already) o invocation recording and replaying (for restoring initial state after reconnect to a stateful sessionbean) o mobility !!! if the caller is a sessionbean, serialize it, move it to a container on the target, do local calls, return to the originating container o compression (zip the serialized invocations .. results are mostly disappointing, because reducing latency is much more importent than reducing data) o encryption / signing some of these interceptors add additional methods to the components interface / dynamic proxy: o ejb behaviour o recording o mobility o invocation bundeling invocations to these methods will be handled by the corresponding interceptors. Only the method invocations of the component's remote interface will reach the transport at the end of the interceptor chain. The (named) interceptor configuration should be chooseable for every ejb-ref. the interceptor configuration requirements of home interfaces might differ from that of the remote interfaces. Love it, Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] javax.management.InstanceAlreadyExistsException...
On Tue, 27 Nov 2001, Julian Gosnell wrote: > On running the WebIntegration test on a freshly built > Server (cvs updated about 12 hours ago) I get a : > > javax.management.InstanceAlreadyExistsException: > SingleJBoss:name=jbosstest-web.ear, J2EEServer=Single, > J2EEApplication=jbosstest-web.ear, type=EJBModule, > J2EEManagement=Manager, > from JMX. > I get a similar message, when deploying an ear: 11:49:12,628 INFO [Default] File: file:/home/hengels/jdevel/jboss-all/build/output/jboss-3.0.0alpha/deploy/Default/egor.ear/ejb1006.jar, descriptor: META-INF/ejb-jar.xml 11:49:12,643 INFO [Default] J2EEManagedObject.getObjectName(), name: SingleJBoss:name=egor.ear,J2EEServer=Single,J2EEApplication=egor.ear,type=EJBModule,J2EEManagement=Manager 11:49:12,645 INFO [Default] J2EEManagedObject.postRegister(), parent: SingleJBoss:J2EEServer=Single,name=egor.ear,type=J2EEApplication,J2EEManagement=Manager 11:49:12,647 ERROR [Default] javax.management.InstanceAlreadyExistsException: SingleJBoss:name=egor.ear,J2EEServer=Single,J2EEApplication=egor.ear,type=EJBModule,J2EEManagement=Manager 11:49:12,649 ERROR [Default]at com.sun.management.jmx.RepositorySupport.addMBean(RepositorySupport.java:134) 11:49:12,650 ERROR [Default]at com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.java:2352) 11:49:12,651 ERROR [Default]at com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:641) 11:49:12,653 ERROR [Default]at org.jboss.management.j2ee.EjbModule.create(EjbModule.java:78) 11:49:12,654 ERROR [Default]at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:394) 11:49:12,655 ERROR [Default]at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:368) 11:49:12,657 ERROR [Default]at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:299) 11:49:12,658 ERROR [Default]at java.lang.reflect.Method.invoke(Native Method) 11:49:12,659 ERROR [Default]at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) 11:49:12,660 ERROR [Default]at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) 11:49:12,662 ERROR [Default]at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:516) 11:49:12,663 ERROR [Default]at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:490) 11:49:12,665 ERROR [Default]at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:222) 11:49:12,666 ERROR [Default]at java.lang.reflect.Method.invoke(Native Method) 11:49:12,667 ERROR [Default]at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) 11:49:12,669 ERROR [Default]at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) 11:49:12,670 ERROR [Default]at org.jboss.deployment.AutoDeployer.deploy(AutoDeployer.java:653) 11:49:12,671 ERROR [Default]at org.jboss.deployment.AutoDeployer.run(AutoDeployer.java:326) 11:49:12,672 ERROR [Default]at java.lang.Thread.run(Thread.java:484) 11:49:12,674 ERROR [ContainerFactory] Could not deploy file:/home/hengels/jdevel/jboss-all/build/output/jboss-3.0.0alpha/deploy/Default/egor.ear my checkout is less than an hour old, holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] (rh) Can we combine j2ee and jboss dds with xsl toget just one dd?
On Mon, 26 Nov 2001, David Jencks wrote: > It's just an idea... > > What if > > --when we are doing j2ee spec compliant deployment we use xsl (or something > like it) to combine the 2 (or 3 or ...) dds into one unified dd that can be > processed in one pass. > > --we can also deploy the unified version directly for those who like it. > what if we use xslt to transform the deploymentdescriptors to jdk1.4's longterm persistence format and let the task of parsing the xml and instantiating the metadata beans to the java.beans.XMLDecoder .. this would at least enhance maintainability. > > Good idea or am I nuts? > .. definately I am ;-) Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [PATCH] JDBCCommand.java
On Wed, 14 Nov 2001, Scott M Stark wrote:
>
> Yes, this change has been in since the start of 2.4, and people have
> complained about CacheKey showing up as a bottleneck since its
> release. It started showing up even more dramtically in the pending
> 2.4.4 codebase due to some other change that is banging on its
> ctor.
>
.. you're talking about a 2.4.4 ..
I sent in a patch some weeks ago, that fixed a bug in jaws regarding
cmpfields of type byte[]. The problem was, that jaws tried to deserialize
an object, because the jdbcType was considered to be a binary type.
if( bytes == null ) {
result = null;
} else {
// We should really reuse these guys
should be:
if( bytes == null ) {
result = null;
} else if (destination.getName().equals("[B")) {
return bytes;
} else {
// We should really reuse these guys
I just noticed, that it still has not been applied.
Thanks,
Holger
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [PATCH] ant task with (nested) fileset(s)
On Sat, 10 Nov 2001, Peter Donald wrote: please do not enter the following command in your shell, otherwise 3.0.alpha will definitely not be out on monday ;-) telnet towel.blinkenlights.nl Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] cmp: foreign-key-mapping
On Tue, 23 Oct 2001, Dain Sundstrom wrote:
>
> Glad to see it is working.
>
I didn't check, if foreign keys are actually written to the db, if I set
them in the ejbPostCreate method .. I think of, what Peter Levart posted
on this thread .. I'll get there soon.
>
> > But now, I have another question. Are EJBLocalObjects valid
> > parameters for
> > finders? I haven't found anything on that in the spec ..
> >
> > If we agree, that it should be supported, it's only 2 places,
> > that require
> > modification:
> >
> > o JDBCQueryMetaDataFactory.convertToJavaClass(..) seems to
> > use the wrong
> > classloader
> >
> > o JDBCDefinedFinderCommand.setParameters(..) should handle local
> > interfaces (obtain the pk) itself and delegate everything
> > else to the
> > JDBCTypeFactory
>
I declare the following finder in LocalAttributeHome:
java.util.Collection findByVersion(LocalVersion version);
and have the following section in the jbosscmp descriptor:
findByVersion
de.mercatis.egor.ejb.LocalVersion
egor.Version
version = {0}
number desc
JDBCQueryMetaDataFactory.convertToJavaClass tries to load the interface
class 'de.mercatis.egor.ejb.LocalVersion', but fails with the following
Exception:
org.jboss.ejb.DeploymentException: Parameter class not found:
de.mercatis.egor.ejb.LocalEntry
at
org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCQueryMetaDataFactory.convertToJavaClass(JDBCQueryMetaDataFactory.java:178)
at
org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCQueryMetaDataFactory.convertToJavaClasses(JDBCQueryMetaDataFactory.java:142)
at
org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCQueryMetaDataFactory.getQueryMethods(JDBCQueryMetaDataFactory.java:83)
at
org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCEntityMetaData.(JDBCEntityMetaData.java:402)
at
org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCApplicationMetaData.(JDBCApplicationMetaData.java:187)
at
org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCXmlFileLoader.load(JDBCXmlFileLoader.java:72)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadJDBCEntityMetaData(JDBCStoreManager.java:349)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.init(JDBCStoreManager.java:104)
at
org.jboss.ejb.plugins.CMPPersistenceManager.init(CMPPersistenceManager.java:136)
at org.jboss.ejb.EntityContainer.init(EntityContainer.java:313)
at org.jboss.ejb.Application.init(Application.java:198)
at
org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:377)
...
I tried to find a note in the spec, if local references to related
entities are valid parameters for a finder .. but found nothing.
After that, I tried to find out, if jbosscmp supports it and came across
the method setParameters in JDBCDefinedFinderCommand .. if understand the
code right, it doesn't !?
As a workaround I could easily do without passing entities ... just pass
the primary key instead. But I think, passing entities as parameters to a
finder in the local home interface should work in general.
Holger
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] cmp: foreign-key-mapping
On Mon, 22 Oct 2001, Dain Sundstrom wrote: > See my previous email. This shouldn't happen if the relationship is > specified the right way. > > Anyway, thanks for your good emails. You are one of the first users of the > new cmp 2.0 code, so anything you can tell us will help clean the system for > normal users. This escpecially applies to wierd, misleading or non-existant > message from the system. In the future try to keep the discussion on the > list, so users in the future will be able to look at the archive for help. > Cool! Seems to work now. Thanks for your help. But now, I have another question. Are EJBLocalObjects valid parameters for finders? I haven't found anything on that in the spec .. If we agree, that it should be supported, it's only 2 places, that require modification: o JDBCQueryMetaDataFactory.convertToJavaClass(..) seems to use the wrong classloader o JDBCDefinedFinderCommand.setParameters(..) should handle local interfaces (obtain the pk) itself and delegate everything else to the JDBCTypeFactory Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] cmp: foreign-key-mapping
The following issues apply to foreign-key-mapping .. 1) problems with unidirectional relations: deployment does not work, because the JDBCCMRFieldBridge.initRelatedData does not find the related cmrField -> throws DeploymentException 2) problems with "not null" constraints on foreign keys: the JDBCCreateEntityCommand builds an insert statement with the cmp fields but without the cmr fields .. as far as I know, createEntity is the only affected command 3) problems with in jbosscmp: the s are searched for in the related entity during JDBCRelationshipRoleMetaData.loadForeignKeyFields but it seems to be also used as the name of the cmr field's foreign key. I assume, the specified name should be that of the foreign key, rather than that of the related primary key .. It could also mean, that I should have specified the opposite relation ship role in the jbosscmp descriptor .. but this might have no , if the relationship is unidirectional! Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RemoteMethodInvocation.getMethod()
On Thu, 30 Aug 2001, Lennart Petersson wrote:
> I'm debugging through the code to see what is happening within JBoss and within our
>beans to see where i can tune to get better performance. Using JBoss 2.4.0 final.
>
> Can someone explain why we aren't returning m in this code snippet:
>
> In class org.jboss.ejb.plugins.jrmp.interfaces.RemoteMethodInvocation
>
> public Method getMethod()
>{
> Method m = (Method)methodMap.get(new Long(hash));
>
> if (m == null)
> throw new NullPointerException("METHOD IS NOT FOUND:"+hash+" "+methodMap);
>
> return (Method)methodMap.get(new Long(hash));
>}
Well, I actually didn't look into the code. Perhaps I can help you to find
it out yourself by providing some hints:
o Method is not serializable
o getClass().getMethod("name", types) !=
getClass().getInterfaces()[i].getMethod("name", types)
o the methodMap is built once (e.g. at deploy time) or lazy?
Holger
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DTDs
On Thu, 23 Aug 2001, Victor Langelo wrote: > The standard way of accessing a local dtd in SGML/XML is the following: > > > > if jboss.dtd is in the same directory as the xml file. Otherwise use relative or > absolute paths. I don't know if this works with the crimson parser though. It should work, if not, you can provide an EntityResolver. Have a look at the ant sources. > Aaron Mulder wrote: > > > My fault, I had the case wrong (JBoss <> JBOSS). BTW, it appears > > that you must provide a URL - if I use something like: > > > > > > > > The parser refuses to accept it. In any case, is there some way > > to avoid loaded the DTD at all when the validate flag is off? I don't remember the reason, but there's no way to prevent the parser from resolving entities. However, xerces used some proprietary method, to allow this. Holger ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RMI Callback Question
On Wed, 22 Aug 2001, Andreas Schaefer wrote: > Hi Geeks > > When a client of an EJB can use RMI to access an EJB is it > then also true that the EJB can use an RMI callback object > (sent by the client) to send information back to the client ? No, that does only work in certain situations .. if server and client share the same network, for instance. It depends, if the server can reach the client, it should be possible. If the client is behind a firewall / proxy and / or there's something like SOCKS or NAT in between, it's not possible at all. As a rule of thumb, you can say YES for an intranet / extranet and NO for connections through the internet. > Let's say the client want to register an Event Listener on the > EJB where then the events are sent back through the RMI call- > back to the client. Did you want to implement a cache, that is notified, when data on the server's chaning ;-) Holger ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] A new user interface for JBoss
On Fri, 10 Aug 2001, Wei-ju Wu wrote: > Hm, it is not the code that made me think of a complete > rewrite, it's (IMHO) its non-existence of usability and > user-friendliness which lies in its concept. > > Furthermore, the advanced options of EJB 2.0 and > JBoss >= 2.4 are not supported. > > I think user interfaces should be developed more from the > user perspective, not from the technical perspective, which > is very difficult as this means using the tool over and over > and rethinking the interface to optimize handling and workflow > and is a different kind of challenge. Maybe, you're right. But I think, you cannot hide complexity! People have to understand, what they do. What you provide in a deployment descriptor is a highly compact meta description. Every bit of information has impact on wether the component will work or not. Beside user friendlyness, there's nothing, a tool can do for you. We could enrich the user-friendlyness by simply providing defaults, whereever possible. This is especially helpful for cmp entity beans. It might also be a good deal, if we replace reflection by parsing the class files. This would result in getting no ClassNotFoundExceptions and NoClassDefFoundErrors anymore. We could also add some wizards for assembly of new components. Perhaps some more integrity checks. I've tried to work with WAS 3.5 and 4.0 (I had to!). The GUI looks nice but IMHO, it's also not usable for development. Maybe it's helpful for administrators .. But, that's just MHO. If everybody thinks, we should have a completely new GUI .. I don't mind. Just do it. Holger ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] A new user interface for JBoss
On Wed, 8 Aug 2001, Schaefer, Andreas wrote: > Did you work with EJX. I tried to use it and it has some > nice features but in the case of EJX (at least for me) it > is too complicated and NO docu. > I liked the idea of using Beans and the Bean Framework but > the actual version of EJX is clunky and not user friendly > (you cannot create the JAR files if they are not there but > only adjust existing ones). > When you want to reanimate EJX please do so but keep in > mind that this is a big job and we need someone dedicated > to it. Below, I listed some tasks, that have to be done with EJX. I think, it's easier to attend these tasks instead of beginning a completely new Tool. EJX: o remember frame dimensions o remember recent directory o more informative frame titles o focus management ejb-jar: o have different ResourceManagers for xml-descriptors and ejb-jars. The latter will allow to assemble a set of classes into a jar. (holger) jboss: o use reflection or scan class files to determine finders and cmp fields (holger) o env-entries jaws: still missing: o app-client (holger) o web o ear to be discussed: o should the jboss- and jaws-resource manager only work on jars or also on standalone xml-files o what else? I've put my name behind some of those points. I'd like to see more names behind the remaining tasks .. BTW, where are the sources for the EjbJar ResourceManager? I only found jBossEjbJar and decompiled the ejxejb.jar Holger Engels ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: To the unix gurus out there
.. the following should do it: for f in `find src -name "*.java"` do sed 's/JBoss, the OpenSource EJB server/JBoss, the OpenSource J2EE webOS/g' $f > $f.2 mv $f.2 $f done You can concatenate everything into one line, if you separate it with ; If you dont't trust it (even I don't ;-), leave out the 'mv ..'-line for the first. You will end in having a .java.2 for every .java. Check them for correctness and afterwards reinsert the line. Holger ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] A new user interface for JBoss
Sorry, I don't quite understand .. what was so bad about the ejx approach? I recognized ejx as a _generic_ powerful, simply to use framework for building xml-editors. I think, it would be a better idea, to build upon the existing editors and make them more user friendly, verbose and fool prove. Maybe, we'll have to enhance ejx itself somehow, but IMHO it's better to invest in generic code, than maintaining a rather specific code base for descriptors, that may change in future. Concerning the management GUI, I have another suggestion. If we agree, that the GUI should be html-based further on (I'm in favour of it), we could use the wingS framework therefore. Have a look at: http://www.wings.to.com Creating GUI with wingS is as easy and comfortable, as with Swing. You have an SComponent pendant for nearly every JComponent, the same Events, Listeners, Models, etc. Holger ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
