Re: File based AutorizationMap
On 8/21/06, Sepand M [EMAIL PROTECTED] wrote: I've seen that before, but I can't understand what's going on Its loading an authorization map into the broker or how to load the XML into the broker (if that's what's meant to be done). Try use that example XML to configure your broker? -- James --- http://radio.weblogs.com/0112098/
Re: Thoughts on a JBI POJO Engine
James,
I like the idea of sticking to the JSR's where possible - and in fact
I'll run over JSR-250 to see what we can use. Also I agree that the
EJB3/SCA style resource injection might be better - one of the reasons
for the more verbal example was just to make it clear a little more
clear what was going on :)
As for the exchange processor mapping I think that the second option,
with annotated parameters looks sweet, and would also give us a
little room for doing some neat mapping stuff like -
@ExchangeProcessor
public void foo(@MessageContentXPath(\customer\name) String name)
{
}
This this would allow mapping of a payload to a method, however
when if comes to JAXB2 type mappings and the SomeResponse/SomeRequest
example you put in - I'm not sure that this isn't stepping on the toes
of the SCA/JSR-181 Service Engines? I suppose one of the things here
was providing:
a) a clean mechanism for writing POJO's that what to interact with the
JBI infrastructure and have been specifically implemented to do so
b) POJO's that what to interact with messaging (not XML-RPC) but more
akin to legacy messaging structures that are being passed around and
allowing you to persist them.
However, I can see that the JAXB example would be interesting since
you could generate any structure. Also in the second example when you
use the mapping approach - how do you know which MEP's the POJO can
handle?
P
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Just a bit of brainstorming of ideas here.
I was looking at this example
@ExchangeProcessor(patterns = { MessageExchangePattern.INOUT },
parameterMappings = { ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOutProcessor(MessageExchange me) {
// Do something here
}
@ExchangeProcessor(patterns = { MessageExchangePattern.INONLY,
MessageExchangePattern.ROBUSTINOULY },
parameterMappings = {
ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOnlyProcessor(Source payload) {
// Do something here
}
and wondering how to simplify a little.
My first thought was to use an annotation for each kind of exchange to
be supported...
@InOnlyExchange @RobustInOnlyExchange
public void foo(MessageExchange exchange) {
}
(I realised we'd get class name clashes so added the 'Exchange'
postfix to the annotation names. Then I figured it might be simpler to
just use a typesafe API...
@ExchangeProcessor
public void foo(InOnly exchange) {
}
@ExchangeProcessor
public void bar(RobustInOnly exchange) {
}
I guess sometimes folks might not want to see/use the exchange or
might wish to support multiple patterns for one method so some kinda
annotation to indicate the exchange pattern is still useful.
Also how about annotating parameters as being bound to the exchange...
@ExchangeProcessor
public void foo(@MessageProperty('cheese') String foo,
@ExchangeProperty(beer) Integer bar, @MessageContent Source payload)
{
}
While the @MessageContent may at first not appear that useful, we
could allow some automatic tranformations from common types to message
contents such as DOM or JAXB marshalling etc
e.g.
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
where SomeRequest and SomeResponse could be marshalled to/from Source via JAXB2.
This would allow folks to process exchanges without using any of the
JBI APIs if they wish - or inject a MessageExchange or
NormalizedMessage into a parameter if required.
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Great stuff Philip!
More feedback as I start digesting this fully and reading this whole
thread but my first reaction is could we try to stick to standard
annotations where possible - such as those defined in JSR 250? e.g.
http://geronimo.apache.org/xbean/annotation-based-dependency-injection.html
so
@ServiceStartup - @PostConstruct
@ServiceShutdown - @PreDestroy
am also wondering how many of the other annotations are really
required on injected fields - could we just use @Resource to indicate
stuff that is mandatory to be dependency injected (like EJB3s). I'm
sure some of the annotations are required though; am just wondering
how many of them are
On 8/18/06, Philip Dodds [EMAIL PROTECTED] wrote:
I have knocked up some thoughts on a JBI POJO engine that could be
used to provide a mechanism for annotating POJO specifically for more
messaging level operations that the JSR181 service engine is aimed
for.
The idea is to provide a simple framework to replace the Spring Client
Toolkit that is now defunt.
Have a look at the idea -
http://goopen.org/confluence/display/SM/JBI+Pojo+Service+Engine
And all comments/thoughts are welcome!!
P
--
James
---
http://radio.weblogs.com/0112098/
--
James
---
http://radio.weblogs.com/0112098/
Re: Thoughts on a JBI POJO Engine
On 8/21/06, Philip Dodds [EMAIL PROTECTED] wrote:
James,
I like the idea of sticking to the JSR's where possible - and in fact
I'll run over JSR-250 to see what we can use. Also I agree that the
EJB3/SCA style resource injection might be better - one of the reasons
for the more verbal example was just to make it clear a little more
clear what was going on :)
Agreed. I think some of the resources injected will need their own
annotations. EJB3 does this for a few kinds of resources too. I'd be
cool if we could avoid custom annotations where possible though.
There seems to be some inconsistency in the use of annotations in this
area - some specs insist on new annotations others just use @Resource
- i've never quite figured out the reasoning behind the difference :).
As for the exchange processor mapping I think that the second option,
with annotated parameters looks sweet, and would also give us a
little room for doing some neat mapping stuff like -
@ExchangeProcessor
public void foo(@MessageContentXPath(\customer\name) String name)
{
}
Ooh thats neat - I like that! :)
This this would allow mapping of a payload to a method, however
when if comes to JAXB2 type mappings and the SomeResponse/SomeRequest
example you put in - I'm not sure that this isn't stepping on the toes
of the SCA/JSR-181 Service Engines?
Yeah.
I guess ultimately I'd like application developers to not have to
mentally think about switching from SCA ot JSR 181 to JBI too much;
they should hopefully have similar look and feels. It'd be nice to
have a kinda unified set of annotations to use or at least share as
many as possible. So hopefully we could reuse JAXB2 across all 3
models; SCA, JBI and JSR 181.
So for mapping the content of a NormalizedMessage it'd be good to support
* Source
* DOM / dom4j / XOM et al
* SDO
* JAXB2/XStream
* maybe text?
e.g. if using the JBI annotations I don't see why we can't also use
the JAXB2 mapping stuff.
We might wanna use XPath with JAXB2 as well...
I suppose one of the things here
was providing:
a) a clean mechanism for writing POJO's that what to interact with the
JBI infrastructure and have been specifically implemented to do so
b) POJO's that what to interact with messaging (not XML-RPC) but more
akin to legacy messaging structures that are being passed around and
allowing you to persist them.
However, I can see that the JAXB example would be interesting since
you could generate any structure. Also in the second example when you
use the mapping approach - how do you know which MEP's the POJO can
handle?
I figured if a result is returned then it'd be an InOut by default
unless an annotation is added to explicitly specify the MEP such as
InOptionalOut
So we could write an InOut processor as
@ExchangeProcessor
public Document foo(Document in, @MessageParam String foo) {... }
--
James
---
http://radio.weblogs.com/0112098/
Re: Thoughts on a JBI POJO Engine
Brainstorming again - here's some thoughts on some sensible defaults
we could use for MEPs to keep things as simple as possible...
By default methods which are void are InOnly and methods that are
non-void are InOut unless there is a typesafe MessageExchange
parameter or an annotation used to overload things.
e.g. these are InOnly...
@ExchangeProcessor
void foo(MessageExchange e) {}
@ExchangeProcessor
void foo(InOnly e) {}
@ExchangeProcessor
void foo(@MessageContent Document doc) {}
// these are InOut
@ExchangeProcessor
void foo(InOut e) {}
@ExchangeProcessor
Document foo(@MessageContent Document doc) {}
@ExchangeProcessor(pattern=Pattern.IN_OUT)
void foo(MessageExchange e) {}
etc
I wonder if we should support parameters for the in and out values? e.g.
@ExchangeProcessor
void foo(@In NormalizedMessage in, @Out NormalizedMessage) {}
or
@ExchangeProcessor
void foo(@MessageContent Document in, @OutMessageContent Document out) {}
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
On 8/21/06, Philip Dodds [EMAIL PROTECTED] wrote:
James,
I like the idea of sticking to the JSR's where possible - and in fact
I'll run over JSR-250 to see what we can use. Also I agree that the
EJB3/SCA style resource injection might be better - one of the reasons
for the more verbal example was just to make it clear a little more
clear what was going on :)
Agreed. I think some of the resources injected will need their own
annotations. EJB3 does this for a few kinds of resources too. I'd be
cool if we could avoid custom annotations where possible though.
There seems to be some inconsistency in the use of annotations in this
area - some specs insist on new annotations others just use @Resource
- i've never quite figured out the reasoning behind the difference :).
As for the exchange processor mapping I think that the second option,
with annotated parameters looks sweet, and would also give us a
little room for doing some neat mapping stuff like -
@ExchangeProcessor
public void foo(@MessageContentXPath(\customer\name) String name)
{
}
Ooh thats neat - I like that! :)
This this would allow mapping of a payload to a method, however
when if comes to JAXB2 type mappings and the SomeResponse/SomeRequest
example you put in - I'm not sure that this isn't stepping on the toes
of the SCA/JSR-181 Service Engines?
Yeah.
I guess ultimately I'd like application developers to not have to
mentally think about switching from SCA ot JSR 181 to JBI too much;
they should hopefully have similar look and feels. It'd be nice to
have a kinda unified set of annotations to use or at least share as
many as possible. So hopefully we could reuse JAXB2 across all 3
models; SCA, JBI and JSR 181.
So for mapping the content of a NormalizedMessage it'd be good to support
* Source
* DOM / dom4j / XOM et al
* SDO
* JAXB2/XStream
* maybe text?
e.g. if using the JBI annotations I don't see why we can't also use
the JAXB2 mapping stuff.
We might wanna use XPath with JAXB2 as well...
I suppose one of the things here
was providing:
a) a clean mechanism for writing POJO's that what to interact with the
JBI infrastructure and have been specifically implemented to do so
b) POJO's that what to interact with messaging (not XML-RPC) but more
akin to legacy messaging structures that are being passed around and
allowing you to persist them.
However, I can see that the JAXB example would be interesting since
you could generate any structure. Also in the second example when you
use the mapping approach - how do you know which MEP's the POJO can
handle?
I figured if a result is returned then it'd be an InOut by default
unless an annotation is added to explicitly specify the MEP such as
InOptionalOut
So we could write an InOut processor as
@ExchangeProcessor
public Document foo(Document in, @MessageParam String foo) {... }
--
James
---
http://radio.weblogs.com/0112098/
--
James
---
http://radio.weblogs.com/0112098/
Re: Thoughts on a JBI POJO Engine
Guillaume,
I agree that we need to define the difference between components more
clearly - I suppose in my mind the JBI component under discussion here
is basically a mechanism when you are focussing on XML messaging in a
format that can not be changed or where you want to interact with the
JBI message bus to provide either InOnly reciept of messages or to
build a consumer that will run through a provided WorkManager.
The JSR181 components to be have always had explicit business
interfaces and work more akin to Web Services or EJB's then MDB's
(sorry for the switching back to the old days). I was hoping that
people building integration service units would simply want to be
playing with payloads or mapping in some specific bits of information
from an XML document (people who would be familiar familiar with XPath
and DOM say) and would want to act on that information and reply with
a Document or create an exchange to another service. While I suppose
IMHO the JSR181 is more for people wishing to expose Business Services
to the bus, and would be used by people designing application
endpoints - which would be defining the payload of the messages not
simply being given the payload?
The different would be in the purposing and flexibilty of the POJO's -
the JBI would be quick (and maybe a little dirty) which it could work
on any payload of message etc and could interact with a InOut
exchange, get the property from the exchange, update the Fault and
Error etc. While the JSR181 would be a way to expose business
services to the bus (whereby your focus is on WSDL, and structured
data).
I realize you can do any payload in JSR181 but I'm wondering whether
that is simply pushing the JSR181 container into doing more than it is
best suited?
P
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
While I fully agree to simplify the annotations used,
if you begin to map parameters to properties or xml content,
you end up to jsr181 component.
I have already planned to add annotations a la jaxws to allow
properties to be mapped to parameters in jsr181. A kind of
JBI annotations set for jaxws (compared to the existing SOAP annotations).
But if we begin to handle xml mapping here, we would end
with 2 components with little differences.
For example, the
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
could be further simplified to
@WebMethod
public SomeResponse doSomething(@WebParam SomeRequest foo) { ... }
which is exactly what the jsr181 component do ;)
Note that the jsr181 component should already by able to
handle Source types as a parameter (which would map to
the full payload), and we should be able to add a MessageExchange
parameter which would receive the exchange without disturbing
other parameters (xfire already does that for xfire specific
classes, such as the context).
We need to clearly agree on what we want to show and hide from
the jbi spec in this component. I don't think we need another SE
that do xml marshalling (we'd better enhance the existing one).
The main things to define imho are:
* how to return the answer if using an InOut
* when the pojo acts as a consumer, how will it receive the answer
from an InOut exchange it has previsouly sent
I really think there is something to do with beanflow.
I will try to think about that a bit more.
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Just a bit of brainstorming of ideas here.
I was looking at this example
@ExchangeProcessor(patterns = { MessageExchangePattern.INOUT },
parameterMappings = { ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOutProcessor(MessageExchange me) {
// Do something here
}
@ExchangeProcessor(patterns = { MessageExchangePattern.INONLY,
MessageExchangePattern.ROBUSTINOULY },
parameterMappings = {
ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOnlyProcessor(Source payload) {
// Do something here
}
and wondering how to simplify a little.
My first thought was to use an annotation for each kind of exchange to
be supported...
@InOnlyExchange @RobustInOnlyExchange
public void foo(MessageExchange exchange) {
}
(I realised we'd get class name clashes so added the 'Exchange'
postfix to the annotation names. Then I figured it might be simpler to
just use a typesafe API...
@ExchangeProcessor
public void foo(InOnly exchange) {
}
@ExchangeProcessor
public void bar(RobustInOnly exchange) {
}
I guess sometimes folks might not want to see/use the exchange or
might wish to support multiple patterns for one method so some kinda
annotation to indicate the exchange pattern is still useful.
Also how about annotating parameters as being bound to the exchange...
@ExchangeProcessor
public void foo(@MessageProperty('cheese') String foo,
@ExchangeProperty(beer) Integer bar, @MessageContent Source payload)
{
}
While the
Re: Thoughts on a JBI POJO Engine
I like the logic - also I like the idea that a service could annotate
two methods and thus end up with the ability to process an InOut and a
InOnly via two different methods on the same class. The only question
I suppose it what happens if you want to be able to provide both from
the same method - say a file reading service that gets the filename in
an XML path and then reading and passing the file to a providing
service then can either return an XML representing the number of
records or not (depending on the MEP?).
Just a thought
P
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Brainstorming again - here's some thoughts on some sensible defaults
we could use for MEPs to keep things as simple as possible...
By default methods which are void are InOnly and methods that are
non-void are InOut unless there is a typesafe MessageExchange
parameter or an annotation used to overload things.
e.g. these are InOnly...
@ExchangeProcessor
void foo(MessageExchange e) {}
@ExchangeProcessor
void foo(InOnly e) {}
@ExchangeProcessor
void foo(@MessageContent Document doc) {}
// these are InOut
@ExchangeProcessor
void foo(InOut e) {}
@ExchangeProcessor
Document foo(@MessageContent Document doc) {}
@ExchangeProcessor(pattern=Pattern.IN_OUT)
void foo(MessageExchange e) {}
etc
I wonder if we should support parameters for the in and out values? e.g.
@ExchangeProcessor
void foo(@In NormalizedMessage in, @Out NormalizedMessage) {}
or
@ExchangeProcessor
void foo(@MessageContent Document in, @OutMessageContent Document out) {}
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
On 8/21/06, Philip Dodds [EMAIL PROTECTED] wrote:
James,
I like the idea of sticking to the JSR's where possible - and in fact
I'll run over JSR-250 to see what we can use. Also I agree that the
EJB3/SCA style resource injection might be better - one of the reasons
for the more verbal example was just to make it clear a little more
clear what was going on :)
Agreed. I think some of the resources injected will need their own
annotations. EJB3 does this for a few kinds of resources too. I'd be
cool if we could avoid custom annotations where possible though.
There seems to be some inconsistency in the use of annotations in this
area - some specs insist on new annotations others just use @Resource
- i've never quite figured out the reasoning behind the difference :).
As for the exchange processor mapping I think that the second option,
with annotated parameters looks sweet, and would also give us a
little room for doing some neat mapping stuff like -
@ExchangeProcessor
public void foo(@MessageContentXPath(\customer\name) String name)
{
}
Ooh thats neat - I like that! :)
This this would allow mapping of a payload to a method, however
when if comes to JAXB2 type mappings and the SomeResponse/SomeRequest
example you put in - I'm not sure that this isn't stepping on the toes
of the SCA/JSR-181 Service Engines?
Yeah.
I guess ultimately I'd like application developers to not have to
mentally think about switching from SCA ot JSR 181 to JBI too much;
they should hopefully have similar look and feels. It'd be nice to
have a kinda unified set of annotations to use or at least share as
many as possible. So hopefully we could reuse JAXB2 across all 3
models; SCA, JBI and JSR 181.
So for mapping the content of a NormalizedMessage it'd be good to support
* Source
* DOM / dom4j / XOM et al
* SDO
* JAXB2/XStream
* maybe text?
e.g. if using the JBI annotations I don't see why we can't also use
the JAXB2 mapping stuff.
We might wanna use XPath with JAXB2 as well...
I suppose one of the things here
was providing:
a) a clean mechanism for writing POJO's that what to interact with the
JBI infrastructure and have been specifically implemented to do so
b) POJO's that what to interact with messaging (not XML-RPC) but more
akin to legacy messaging structures that are being passed around and
allowing you to persist them.
However, I can see that the JAXB example would be interesting since
you could generate any structure. Also in the second example when you
use the mapping approach - how do you know which MEP's the POJO can
handle?
I figured if a result is returned then it'd be an InOut by default
unless an annotation is added to explicitly specify the MEP such as
InOptionalOut
So we could write an InOut processor as
@ExchangeProcessor
public Document foo(Document in, @MessageParam String foo) {... }
--
James
---
http://radio.weblogs.com/0112098/
--
James
---
http://radio.weblogs.com/0112098/
Re: Thoughts on a JBI POJO Engine
I would love that, but such annotations are forbidden :(
Only primitive types, string, class, enums, annotations (or arrays of these)
can be used as annotations attributes.
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Interesting! I really love the @Destination injection BTW :)
I wonder about using futures a little more to make the code a little
simpler. Something like the following - where we wrap up an async
request-response as a child Step or Future...
public class MyWorkflow {
Message request;
FutureMessage answer1;
FutureMessage answer2;
@Destination(uri=service:urn:service)
private Destination service1;
@Destination(uri=service:urn:service)
private Destination service2;
@Request
public void receiveRequest(Message message) throws Exception {
request = message;
answer1 = service1.sendAsync(copy(request));
answer2 = service2.sendAsync(copy(request));
}
@Join(futures = { answer1, answer2 })
@Answer()
public Message answer() {
Message m1 = answer1.get();
Message m2 = answer2.get();
// Do something with answer1 and answer2
return new Message()
}
}
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
Here is something i'd like to be able to do.
This is really pseudo code, and some kind of beanflow oriented annotations.
This service would simply send two concurrent requests and wait for their
answers to reply to the main request. Of course, this would be much easier
if you use syncSend but you would not have a real workflow ;)
public class MyWorkflow {
Message request;
Message answer1;
Message answer2;
@Destination(uri=service:urn:service)
private Destination service1;
@Destination(uri=service:urn:service)
private Destination service2;
@Request
@NextStep(steps = { invokeService, invokerService2 }) // This
would auto-fork
public void receiveRequest(Message message) throws Exception {
request = message;
}
@NextStep(step = receiveService1)
public void invokeService1() {
service1.send(copy(request));
// return response to receiveService1
}
public void receiveService1(Message message) {
answer1 = message;
}
@NextStep(step = receiveService2)
public void invokeService2() {
service2.send(copy(request));
}
public void receiveService2(Message message) {
answer2 = message;
}
@Join(steps = { receiveService1, receiveService2 })
@Answer()
public void answer() {
// Do something with answer1 and answer2
return new Message()
}
}
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
While I fully agree to simplify the annotations used,
if you begin to map parameters to properties or xml content,
you end up to jsr181 component.
I have already planned to add annotations a la jaxws to allow
properties to be mapped to parameters in jsr181. A kind of
JBI annotations set for jaxws (compared to the existing SOAP annotations).
But if we begin to handle xml mapping here, we would end
with 2 components with little differences.
For example, the
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
could be further simplified to
@WebMethod
public SomeResponse doSomething(@WebParam SomeRequest foo) { ... }
which is exactly what the jsr181 component do ;)
Note that the jsr181 component should already by able to
handle Source types as a parameter (which would map to
the full payload), and we should be able to add a MessageExchange
parameter which would receive the exchange without disturbing
other parameters (xfire already does that for xfire specific
classes, such as the context).
We need to clearly agree on what we want to show and hide from
the jbi spec in this component. I don't think we need another SE
that do xml marshalling (we'd better enhance the existing one).
The main things to define imho are:
* how to return the answer if using an InOut
* when the pojo acts as a consumer, how will it receive the answer
from an InOut exchange it has previsouly sent
I really think there is something to do with beanflow.
I will try to think about that a bit more.
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Just a bit of brainstorming of ideas here.
I was looking at this example
@ExchangeProcessor(patterns = { MessageExchangePattern.INOUT },
parameterMappings = { ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOutProcessor(MessageExchange me) {
// Do something here
}
@ExchangeProcessor(patterns = { MessageExchangePattern.INONLY,
MessageExchangePattern.ROBUSTINOULY },
parameterMappings = {
ParameterMapping.IN_MESSAGE_CONTENT })
public void
Re: Thoughts on a JBI POJO Engine
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
I would love that, but such annotations are forbidden :(
Only primitive types, string, class, enums, annotations (or arrays of these)
can be used as annotations attributes.
Yeah - we could use the String names of fields/properties which are
futures / steps.
@Join(futures = { answer1, answer2 })
@Answer()
public Message answer() {
Message m1 = answer1.get();
Message m2 = answer2.get();
...
}
Or the join could be done programatically
@Request
public void receiveRequest(Message message) throws Exception {
request = message;
answer1 = service1.sendAsync(copy(request));
answer2 = service2.sendAsync(copy(request));
// call the answer method when we have both futures joined
join(answer, answer1, answer2);
}
But the annotation based one is cleaner and more loosly coupled
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Interesting! I really love the @Destination injection BTW :)
I wonder about using futures a little more to make the code a little
simpler. Something like the following - where we wrap up an async
request-response as a child Step or Future...
public class MyWorkflow {
Message request;
FutureMessage answer1;
FutureMessage answer2;
@Destination(uri=service:urn:service)
private Destination service1;
@Destination(uri=service:urn:service)
private Destination service2;
@Request
public void receiveRequest(Message message) throws Exception {
request = message;
answer1 = service1.sendAsync(copy(request));
answer2 = service2.sendAsync(copy(request));
}
@Join(futures = { answer1, answer2 })
@Answer()
public Message answer() {
Message m1 = answer1.get();
Message m2 = answer2.get();
// Do something with answer1 and answer2
return new Message()
}
}
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
Here is something i'd like to be able to do.
This is really pseudo code, and some kind of beanflow oriented annotations.
This service would simply send two concurrent requests and wait for their
answers to reply to the main request. Of course, this would be much easier
if you use syncSend but you would not have a real workflow ;)
public class MyWorkflow {
Message request;
Message answer1;
Message answer2;
@Destination(uri=service:urn:service)
private Destination service1;
@Destination(uri=service:urn:service)
private Destination service2;
@Request
@NextStep(steps = { invokeService, invokerService2 }) // This
would auto-fork
public void receiveRequest(Message message) throws Exception {
request = message;
}
@NextStep(step = receiveService1)
public void invokeService1() {
service1.send(copy(request));
// return response to receiveService1
}
public void receiveService1(Message message) {
answer1 = message;
}
@NextStep(step = receiveService2)
public void invokeService2() {
service2.send(copy(request));
}
public void receiveService2(Message message) {
answer2 = message;
}
@Join(steps = { receiveService1, receiveService2 })
@Answer()
public void answer() {
// Do something with answer1 and answer2
return new Message()
}
}
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
While I fully agree to simplify the annotations used,
if you begin to map parameters to properties or xml content,
you end up to jsr181 component.
I have already planned to add annotations a la jaxws to allow
properties to be mapped to parameters in jsr181. A kind of
JBI annotations set for jaxws (compared to the existing SOAP annotations).
But if we begin to handle xml mapping here, we would end
with 2 components with little differences.
For example, the
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
could be further simplified to
@WebMethod
public SomeResponse doSomething(@WebParam SomeRequest foo) { ... }
which is exactly what the jsr181 component do ;)
Note that the jsr181 component should already by able to
handle Source types as a parameter (which would map to
the full payload), and we should be able to add a MessageExchange
parameter which would receive the exchange without disturbing
other parameters (xfire already does that for xfire specific
classes, such as the context).
We need to clearly agree on what we want to show and hide from
the jbi spec in this component. I don't think we need another SE
that do xml marshalling (we'd better enhance the existing one).
The main things to define imho are:
* how to return the answer if using an InOut
* when the pojo acts as a consumer, how will
Exceptions in servicemix-jms with WebSphereMQ
Hi Folks, I have a problem connecting service mix via the servicemix-jms component to a WebSphereMQ Queue. My provider configuration is as follows: !-- Reads a message from the NMR and writes them to XNEAIDV3.SMIX.TEST.2 -- jms:endpoint service=dz:MyProviderService endpoint=myProvider role=provider destinationStyle=queue jmsProviderDestinationName=XNEAIDV3.SMIX.TEST.2 connectionFactory=#jmsFactory / The message sent is as follows: ?xml version=1.0 encoding=UTF-8? sample id=0 here is some testdata /sample I get the following exception: javax.jms.MessageFormatException: MQJMS1058: Invalid message property name: Content-Type at com.ibm.jms.JMSMessage.newMessageFormatException(JMSMessage.java:4674) at com.ibm.jms.JMSMessage.setStringProperty(JMSMessage.java:5658) at org.apache.servicemix.jms.multiplexing.MultiplexingProviderProcessor.process(MultiplexingProviderProcessor.java:182) at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:398) at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:43) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:623) at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:169) at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:177) at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:227) at org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:291) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:595) As far as I understand the code, in line 182 of MultiplexingProviderProcessor the property Content-Type is set to the value defined in the normalized message (according to http://issues.apache.org/activemq/browse/SM-502). But Content-Type is not a proper name for a JMS property (at least according to SM-398 and SM-403, I did not check the JMS spec myself) and WebSphereMQ chokes immediately. The discussion of SM-502 indicates that the Content-Type property is required for SOAP and SAAJ. However, my configuration does not use SOAP at all (which shall be the default case according to the docs). I am also not sure whether it is needed to set the content type property to the JMS message. I would expect the content-type as a part of the message payload itself but I am by no means an expert of the SOAP/JMS on the wire format. A final remark: In contrast to the marshaler in the older lightweight jms component, there is no checking of valid header names in the loop immediately before line 182. This looks like an additionally potential error source. A simple workaround is to catch and silently ignore exceptions when setting the message properties. Cheers, Klaus. -- View this message in context: http://www.nabble.com/Exceptions-in-servicemix-jms-with-WebSphereMQ-tf2141329.html#a5910358 Sent from the ServiceMix - Dev forum at Nabble.com.
Prerequisites for Eclipse Plugin v1.1 still mentioned as WTP 1.0.1 on http://geronimo.apache.org/devtools.html
In the Welcome page for Geronimo Development Tools: http://geronimo.apache.org/devtools.html , the Prerequisites for Eclipse Plugin are still mentioned as WebTools Platform Runtime 1.01 driver. Please update this to Web Tools Platform 1.5.0 driver.-- Thx,Shiva
[jira] Created: (GERONIMO-2337) Incompatible Callback between CertificatePropertiesFileLoginModule and FileAuditLoginModule
Incompatible Callback between CertificatePropertiesFileLoginModule and FileAuditLoginModule Key: GERONIMO-2337 URL: http://issues.apache.org/jira/browse/GERONIMO-2337 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 1.1 Reporter: Heinz Drews Priority: Minor During creation of a realm with Console an auditing module can be added. Console uses FileAuditLoginModule, this can not be changed. FileAuditLoginModule adds a Callback which is not compatible with CertificateCallbackHandler/CertificateChainCallbackHandler. This causes LoginExceptions. Console should be modified to allow change and removal of the audit module. A CertificateAuditLoginModule should be added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Fwd: [stomp-dev] messages are not redelivered in activemq-4.0.2
Begin forwarded message: From: Jeff Tupholme [EMAIL PROTECTED] Date: August 18, 2006 9:17:17 AM PDT To: [EMAIL PROTECTED] Subject: [stomp-dev] messages are not redelivered in activemq-4.0.2 Reply-To: [EMAIL PROTECTED] Hoping for some help in understanding STOMP semantics. incubator-activemq-4.0.2 My test application sends two messages to queueA, starts a new connection which subscribes to queueA, then processes each message in its own transaction. When a transaction is aborted I expected its message to be redelivered but this doesn't happen. Opening a new connection and resubscribing picks up the aborted message but it is not marked as being redelivered. In the Java test code for ActiveMQ it appears that a message within a rolled-back transaction is redelivered to the session almost immediately (./incubator-activemq-4.0.2/src/test/java/org/apache/ activemq/usecases/Trans actionRollbackOrderTest.java). I noticed that each time my program sends a message ACK ActiveMQ throws NullPointerException (see below). At this point I'm not sure how much functionality STOMP is intended to offer so I might be wrong to report this as a bug. Before I report another bug - Is it supposed to be possible to interleave transactions on a single connection? Thanks! Pseudo-code msg1 = receiver.NextMsg() msg1.Begin() -- begin transaction and acknowledge the message msg1.Abort() -- abort transaction msg2 = receiver.NextMsg() msg2.Begin() -- begin transaction and acknowledge the message msg2.Commit() msg3 = receiver.NextMsg() -- expecting msg1 to be redelivered STOMP Protocol Trace CONNECT user: usr passcode: password . CONNECTED session:ID:ubuntu-32784-1155902931062-3:163 . SUBSCRIBE destination: /queue/queueA ack: client . MESSAGE destination:/queue/queueA type:null reply-to:null timestamp:1155915641587 priority:0 expires:0 correlation-id:null message-id:ID:ubuntu-32784-1155902931062-3:160:-1:1:1 0 . MESSAGE destination:/queue/queueA type:null reply-to:null timestamp:1155915641795 priority:0 expires:0 correlation-id:null message-id:ID:ubuntu-32784-1155902931062-3:160:-1:1:2 1 . BEGIN transaction: ba0c02205582f84dfffa90cf75fd2395 . ACK message-id: ID:ubuntu-32784-1155902931062-3:160:-1:1:1 transaction: ba0c02205582f84dfffa90cf75fd2395 . ABORT transaction: ba0c02205582f84dfffa90cf75fd2395 . BEGIN transaction: 3d4bf8b18ca395e9aaa63a7853f3d3af . ACK message-id: ID:ubuntu-32784-1155902931062-3:160:-1:1:2 transaction: 3d4bf8b18ca395e9aaa63a7853f3d3af . COMMIT transaction: 3d4bf8b18ca395e9aaa63a7853f3d3af . CONNECT user: usr passcode: password . CONNECTED session:ID:ubuntu-32784-1155902931062-3:163 . SUBSCRIBE destination: /queue/queueA ack: client . MESSAGE destination:/queue/queueA type:null reply-to:null timestamp:1155915641587 priority:0 expires:0 correlation-id:null message-id:ID:ubuntu-32784-1155902931062-3:160:-1:1:1 0 . MESSAGE destination:/queue/queueA type:null reply-to:null timestamp:1155915641795 priority:0 expires:0 correlation-id:null message-id:ID:ubuntu-32784-1155902931062-3:160:-1:1:2 1 . BEGIN transaction: ba0c02205582f84dfffa90cf75fd2395 . ACK message-id: ID:ubuntu-32784-1155902931062-3:160:-1:1:1 transaction: ba0c02205582f84dfffa90cf75fd2395 . ABORT transaction: ba0c02205582f84dfffa90cf75fd2395 . BEGIN transaction: 3d4bf8b18ca395e9aaa63a7853f3d3af . ACK message-id: ID:ubuntu-32784-1155902931062-3:160:-1:1:2 transaction: 3d4bf8b18ca395e9aaa63a7853f3d3af . COMMIT transaction: 3d4bf8b18ca395e9aaa63a7853f3d3af . Java Exception stack trace -- Async error occurred: java.lang.NullPointerException java.lang.NullPointerException at org.apache.activemq.broker.region.PrefetchSubscription.acknowledge (PrefetchS ubscription.java:122) at org.apache.activemq.broker.region.AbstractRegion.acknowledge (AbstractRegion. java:233) at org.apache.activemq.broker.region.RegionBroker.acknowledge (RegionBroker.java :362) at org.apache.activemq.broker.TransactionBroker.acknowledge (TransactionBroker.j ava:176) at org.apache.activemq.broker.BrokerFilter.acknowledge (BrokerFilter.java:65) at org.apache.activemq.broker.BrokerFilter.acknowledge (BrokerFilter.java:65) at org.apache.activemq.broker.MutableBrokerFilter.acknowledge (MutableBrokerFilt er.java:78) at org.apache.activemq.broker.AbstractConnection.processMessageAck (AbstractConn ection.java:382) at org.apache.activemq.command.MessageAck.visit (MessageAck.java:178) at org.apache.activemq.broker.AbstractConnection.service (AbstractConnection.jav a:226) at org.apache.activemq.broker.TransportConnection$1.onCommand (TransportConnecti on.java:62) at org.apache.activemq.transport.ResponseCorrelator.onCommand (ResponseCorrelato r.java:91) at org.apache.activemq.transport.TransportFilter.onCommand (TransportFilter.java :63) at org.apache.activemq.transport.InactivityMonitor.onCommand (InactivityMonitor. java:122) at
Re: m2 build - validating
On Aug 20, 2006, at 3:36 PM, Bill Dudney wrote: Hi All, Sorry its taken me so long to get this posted. I had a bunch of travel related headaches thur and fri of last week... I've adopted http://issues.apache.org/jira/browse/GERONIMO-2326 as the JIRA to track the first part of the problem (the datasource deployment stuff) with the current trunk and deployment. I've just attached a patch to the issue that makes a small change to the CAR plugin to include RAR's in the dependencies that are copied into the assembly repository. I am fairly sure this needs to be done as the RAR's end up in the repository on 1.1 and the DatabaseInfo class requires them to be there (albeit with a comment that says EVIL!!! :). However there might be something going on there I'm not aware of. This is basically a wrong thing to do. A dependency on the rar file doesn't do anything except require it to be there, which is bogus since in fact once the car file is generated it doesn't have to be there. The tranql rars (and the activemq rar) are included only for the convenience of users wishing to deploy additional datasources without downloading the rar file themselves. There's been discussion for a really long time about not copying the contents of j2ee artifacts into the car file but instead including them in the classloader in some other way. This sounds nice but is fraught with difficulties such as -how do you make a classloader that reads the jars in a war lib dir inside an ear (nested jar classloading) -or, how do you figure out to unpack the j2ee artifacts in the repo - how do you set up a variety of classloaders that only load some stuff from an ear: e.g. right now an ear classloader doesn't see anything in any web apps. these are all soluble but will take a bunch of work to decide what to do and implement. One quick note on this change. The RAR's do end up copied into the CAR (without this change) but, the DatabaseInfo class is expecting (at least) the Derby related RAR's to be directly in the repo. Take a look here http://tinyurl.com/jynnh. the list of *RAR_NAME fields are all used to load the RAR's directly from the repository (http:// tinyurl.com/kyhve getRAR static method on line 1036). As the comments says this is rather hard coded. I've not had time to get brain cells focused on the solution. Seems that we should be able to do some kind of maven magic though to find the tranql/tranql- connector/rar instead of hardcoding the path. But again I don't know the history so perhaps there is a reason for the EVIL :) I think that the code for 1.1 is greatly improved over what's in trunk, and I hope aaron ports it soon. Again, using rar's as dependencies is a bad idea. I think something got left out of the m2 build, in the m1 build there was a way to specify that some jars just get put in the repo even though they aren't dependencies of any car. I don't know if this is possible in m2, but the tranql rars are not getting installed at least on my machine. So the patch attached to 2326 gets us almost there, but there is still the issue with the IncompatiblClassChangeError coming up. I posted a partial stack trace in the issue. Any pointers, thoughts or other things that could help me track that one down are most welcome. I have to bail for a couple of hours but will be back on line around 7:00MST for a bit. Also David J, if you could take a look at the pom changes and make sure they are in line with your recommendations. I could not find another car to have system-database depended on that would bring in the dependencies and system-database looked to be the most logical place to add add a jar dependency. I added the jar's to the gbean- deployer/pom.xml because the CNFExceptions were coming from classes in this package and again no obvious CAR to add to the mix. Unfortunately I don't like almost all your proposed pom changes. We do need to add the geronimo-test-ddbean jar to some module, but I think it should be added to j2ee-deployer since jsr-88 is pretty irrelevant to gbean deployment. With just this change I'm getting an NPE rather than a CNFE (which I got with unchanged trunk g). I have yet to reproduce the IncompatibleClassChangeError but I don't see any way it can be caused by anything other than using 2 different versions of a jar somehow. Perhaps one of the jars in lib is a different version than what is in the g. repo??? If you can figure out what class it is that might be helpful. I'm to tired to work on this more tonight, I'll try to look more in the morning. thanks david jencks Thanks! bd- On Aug 17, 2006, at 3:07 PM, Jason Dillon wrote: And it seems I have the magic incantation now :-) Going to see how well I can cast it on the car plugin later today. --jason On Aug 17, 2006, at 11:51 AM, anita kulshreshtha wrote: --- Jason Dillon [EMAIL PROTECTED]
[jira] Commented: (GERONIMO-1692) Creating Web Connectors using Console
[ http://issues.apache.org/jira/browse/GERONIMO-1692?page=comments#action_12429363 ] Ilya Kanonirov commented on GERONIMO-1692: -- The issue duplicates the GERONIMO-1500 one which has been resolved. Please close this issue. Creating Web Connectors using Console - Key: GERONIMO-1692 URL: http://issues.apache.org/jira/browse/GERONIMO-1692 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1 Environment: WinXP SP2, J2SDK 1.4.2_10, Geronimo with Tomcat Reporter: Ilya Kanonirov When creating any type of Web Connector at the Web Server page in the Geronimo Console, the parameter Max Threads is always saved to var/config/config.xml with default value 50. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1692) Creating Web Connectors using Console
[ http://issues.apache.org/jira/browse/GERONIMO-1692?page=all ] Vamsavardhana Reddy resolved GERONIMO-1692. --- Resolution: Duplicate Creating Web Connectors using Console - Key: GERONIMO-1692 URL: http://issues.apache.org/jira/browse/GERONIMO-1692 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1 Environment: WinXP SP2, J2SDK 1.4.2_10, Geronimo with Tomcat Reporter: Ilya Kanonirov When creating any type of Web Connector at the Web Server page in the Geronimo Console, the parameter Max Threads is always saved to var/config/config.xml with default value 50. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-327) Orphanded/lost queue messages in various failover tests in two broker configuration
[ https://issues.apache.org/activemq/browse/AMQ-327?page=all ] John Heitmann reassigned AMQ-327: - Assignee: John Heitmann (was: Rob Davies) Orphanded/lost queue messages in various failover tests in two broker configuration --- Key: AMQ-327 URL: https://issues.apache.org/activemq/browse/AMQ-327 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0 Environment: w2k RH 9.0 jdk1.4.2 Reporter: Dennis Cook Assigned To: John Heitmann Fix For: 4.1 Attachments: AMQ-327.tar.gz Seems like the messages being passed to a broker where no client is connected when the failed broker is re-established. This message is lost until a client is connected to this broker. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [stomp-dev] messages are not redelivered in activemq-4.0.2
I replied to this one on the Stomp list http://www.nabble.com/Re%3A-messages-are-not-redelivered-in-activemq-4.0.2-p5902314.html On 8/18/06, Brian McCallister [EMAIL PROTECTED] wrote: Begin forwarded message: From: Jeff Tupholme [EMAIL PROTECTED] Date: August 18, 2006 9:17:17 AM PDT To: [EMAIL PROTECTED] Subject: [stomp-dev] messages are not redelivered in activemq-4.0.2 Reply-To: [EMAIL PROTECTED] Hoping for some help in understanding STOMP semantics. incubator-activemq-4.0.2 My test application sends two messages to queueA, starts a new connection which subscribes to queueA, then processes each message in its own transaction. When a transaction is aborted I expected its message to be redelivered but this doesn't happen. Opening a new connection and resubscribing picks up the aborted message but it is not marked as being redelivered. In the Java test code for ActiveMQ it appears that a message within a rolled-back transaction is redelivered to the session almost immediately (./incubator-activemq-4.0.2/src/test/java/org/apache/ activemq/usecases/Trans actionRollbackOrderTest.java). I noticed that each time my program sends a message ACK ActiveMQ throws NullPointerException (see below). At this point I'm not sure how much functionality STOMP is intended to offer so I might be wrong to report this as a bug. Before I report another bug - Is it supposed to be possible to interleave transactions on a single connection? Thanks! Pseudo-code msg1 = receiver.NextMsg() msg1.Begin() -- begin transaction and acknowledge the message msg1.Abort() -- abort transaction msg2 = receiver.NextMsg() msg2.Begin() -- begin transaction and acknowledge the message msg2.Commit() msg3 = receiver.NextMsg() -- expecting msg1 to be redelivered STOMP Protocol Trace CONNECT user: usr passcode: password . CONNECTED session:ID:ubuntu-32784-1155902931062-3:163 . SUBSCRIBE destination: /queue/queueA ack: client . MESSAGE destination:/queue/queueA type:null reply-to:null timestamp:1155915641587 priority:0 expires:0 correlation-id:null message-id:ID:ubuntu-32784-1155902931062-3:160:-1:1:1 0 . MESSAGE destination:/queue/queueA type:null reply-to:null timestamp:1155915641795 priority:0 expires:0 correlation-id:null message-id:ID:ubuntu-32784-1155902931062-3:160:-1:1:2 1 . BEGIN transaction: ba0c02205582f84dfffa90cf75fd2395 . ACK message-id: ID:ubuntu-32784-1155902931062-3:160:-1:1:1 transaction: ba0c02205582f84dfffa90cf75fd2395 . ABORT transaction: ba0c02205582f84dfffa90cf75fd2395 . BEGIN transaction: 3d4bf8b18ca395e9aaa63a7853f3d3af . ACK message-id: ID:ubuntu-32784-1155902931062-3:160:-1:1:2 transaction: 3d4bf8b18ca395e9aaa63a7853f3d3af . COMMIT transaction: 3d4bf8b18ca395e9aaa63a7853f3d3af . CONNECT user: usr passcode: password . CONNECTED session:ID:ubuntu-32784-1155902931062-3:163 . SUBSCRIBE destination: /queue/queueA ack: client . MESSAGE destination:/queue/queueA type:null reply-to:null timestamp:1155915641587 priority:0 expires:0 correlation-id:null message-id:ID:ubuntu-32784-1155902931062-3:160:-1:1:1 0 . MESSAGE destination:/queue/queueA type:null reply-to:null timestamp:1155915641795 priority:0 expires:0 correlation-id:null message-id:ID:ubuntu-32784-1155902931062-3:160:-1:1:2 1 . BEGIN transaction: ba0c02205582f84dfffa90cf75fd2395 . ACK message-id: ID:ubuntu-32784-1155902931062-3:160:-1:1:1 transaction: ba0c02205582f84dfffa90cf75fd2395 . ABORT transaction: ba0c02205582f84dfffa90cf75fd2395 . BEGIN transaction: 3d4bf8b18ca395e9aaa63a7853f3d3af . ACK message-id: ID:ubuntu-32784-1155902931062-3:160:-1:1:2 transaction: 3d4bf8b18ca395e9aaa63a7853f3d3af . COMMIT transaction: 3d4bf8b18ca395e9aaa63a7853f3d3af . Java Exception stack trace -- Async error occurred: java.lang.NullPointerException java.lang.NullPointerException at org.apache.activemq.broker.region.PrefetchSubscription.acknowledge (PrefetchS ubscription.java:122) at org.apache.activemq.broker.region.AbstractRegion.acknowledge (AbstractRegion. java:233) at org.apache.activemq.broker.region.RegionBroker.acknowledge (RegionBroker.java :362) at org.apache.activemq.broker.TransactionBroker.acknowledge (TransactionBroker.j ava:176) at org.apache.activemq.broker.BrokerFilter.acknowledge (BrokerFilter.java:65) at org.apache.activemq.broker.BrokerFilter.acknowledge (BrokerFilter.java:65) at org.apache.activemq.broker.MutableBrokerFilter.acknowledge (MutableBrokerFilt er.java:78) at org.apache.activemq.broker.AbstractConnection.processMessageAck (AbstractConn ection.java:382) at org.apache.activemq.command.MessageAck.visit (MessageAck.java:178) at org.apache.activemq.broker.AbstractConnection.service (AbstractConnection.jav a:226) at
Re: Thoughts on a JBI POJO Engine
Great stuff Philip! More feedback as I start digesting this fully and reading this whole thread but my first reaction is could we try to stick to standard annotations where possible - such as those defined in JSR 250? e.g. http://geronimo.apache.org/xbean/annotation-based-dependency-injection.html so @ServiceStartup - @PostConstruct @ServiceShutdown - @PreDestroy am also wondering how many of the other annotations are really required on injected fields - could we just use @Resource to indicate stuff that is mandatory to be dependency injected (like EJB3s). I'm sure some of the annotations are required though; am just wondering how many of them are On 8/18/06, Philip Dodds [EMAIL PROTECTED] wrote: I have knocked up some thoughts on a JBI POJO engine that could be used to provide a mechanism for annotating POJO specifically for more messaging level operations that the JSR181 service engine is aimed for. The idea is to provide a simple framework to replace the Spring Client Toolkit that is now defunt. Have a look at the idea - http://goopen.org/confluence/display/SM/JBI+Pojo+Service+Engine And all comments/thoughts are welcome!! P -- James --- http://radio.weblogs.com/0112098/
Re: JSR196
Checked in at http://svn.apache.org/repos/asf/geronimo/sandbox/geronimo-jaspi/ On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Done. See http://svn.apache.org/viewvc?rev=433122view=rev I have also began to write an implementation of the AuthConfigFactory. I will try to check it in somewhere soon, though the real work is on the providers, not the factory ;) On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I have found a few incoherences wrt to the specs. I will check them in. On 8/19/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: I'm going to start goofing around with this. I'll start by putting the specs into geronimo/specs/branches. You can monitor the work: https://issues.apache.org/jira/browse/GERONIMO-2336 Regards, Alan -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
JMS enhancements supporting MapMessage
I explored the source for the JMS binding component and found that MapMessages are not supported. I would suggest that MapMessages support are added to the JMS component. A simple way to use this is to create a very simple XML-mapping format for a map message. For example a root element with a subelement named according to the keys in the MapMessage and the content of the element the value of the entry for the simple types and the XML-beans format for Objects, arrays could also be encoded according to the XML-beans standard mapMessage nameJohn Doe/name addressMain Street 1A/address anIntArray !-- The XML-beans encoding of an array object -- /anIntArray theGuiFrameSettings !-- the XML-beans encoding of the GUI frames object /theGuiFrameSettings /mapMessage What do you think? Is anybody willing to do this? If not I could give it a try, though I expect it would need to be peer-reviewed quite thourougly as I have not done any development in ServiceMix before -- View this message in context: http://www.nabble.com/JMS-enhancements-supporting-MapMessage-tf2139494.html#a5904419 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: Thoughts on a JBI POJO Engine
Just a bit of brainstorming of ideas here.
I was looking at this example
@ExchangeProcessor(patterns = { MessageExchangePattern.INOUT },
parameterMappings = { ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOutProcessor(MessageExchange me) {
// Do something here
}
@ExchangeProcessor(patterns = { MessageExchangePattern.INONLY,
MessageExchangePattern.ROBUSTINOULY },
parameterMappings = {
ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOnlyProcessor(Source payload) {
// Do something here
}
and wondering how to simplify a little.
My first thought was to use an annotation for each kind of exchange to
be supported...
@InOnlyExchange @RobustInOnlyExchange
public void foo(MessageExchange exchange) {
}
(I realised we'd get class name clashes so added the 'Exchange'
postfix to the annotation names. Then I figured it might be simpler to
just use a typesafe API...
@ExchangeProcessor
public void foo(InOnly exchange) {
}
@ExchangeProcessor
public void bar(RobustInOnly exchange) {
}
I guess sometimes folks might not want to see/use the exchange or
might wish to support multiple patterns for one method so some kinda
annotation to indicate the exchange pattern is still useful.
Also how about annotating parameters as being bound to the exchange...
@ExchangeProcessor
public void foo(@MessageProperty('cheese') String foo,
@ExchangeProperty(beer) Integer bar, @MessageContent Source payload)
{
}
While the @MessageContent may at first not appear that useful, we
could allow some automatic tranformations from common types to message
contents such as DOM or JAXB marshalling etc
e.g.
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
where SomeRequest and SomeResponse could be marshalled to/from Source via JAXB2.
This would allow folks to process exchanges without using any of the
JBI APIs if they wish - or inject a MessageExchange or
NormalizedMessage into a parameter if required.
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Great stuff Philip!
More feedback as I start digesting this fully and reading this whole
thread but my first reaction is could we try to stick to standard
annotations where possible - such as those defined in JSR 250? e.g.
http://geronimo.apache.org/xbean/annotation-based-dependency-injection.html
so
@ServiceStartup - @PostConstruct
@ServiceShutdown - @PreDestroy
am also wondering how many of the other annotations are really
required on injected fields - could we just use @Resource to indicate
stuff that is mandatory to be dependency injected (like EJB3s). I'm
sure some of the annotations are required though; am just wondering
how many of them are
On 8/18/06, Philip Dodds [EMAIL PROTECTED] wrote:
I have knocked up some thoughts on a JBI POJO engine that could be
used to provide a mechanism for annotating POJO specifically for more
messaging level operations that the JSR181 service engine is aimed
for.
The idea is to provide a simple framework to replace the Spring Client
Toolkit that is now defunt.
Have a look at the idea -
http://goopen.org/confluence/display/SM/JBI+Pojo+Service+Engine
And all comments/thoughts are welcome!!
P
--
James
---
http://radio.weblogs.com/0112098/
--
James
---
http://radio.weblogs.com/0112098/
Re: JMS enhancements supporting MapMessage
On 8/21/06, Jeppe [EMAIL PROTECTED] wrote: I explored the source for the JMS binding component and found that MapMessages are not supported. I would suggest that MapMessages support are added to the JMS component. A simple way to use this is to create a very simple XML-mapping format for a map message. For example a root element with a subelement named according to the keys in the MapMessage and the content of the element the value of the entry for the simple types and the XML-beans format for Objects, arrays could also be encoded according to the XML-beans standard mapMessage nameJohn Doe/name addressMain Street 1A/address anIntArray !-- The XML-beans encoding of an array object -- /anIntArray theGuiFrameSettings !-- the XML-beans encoding of the GUI frames object /theGuiFrameSettings /mapMessage What do you think? Sounds good to me. You might wanna allow an XSD type to be specified so that the values can be ints / floats / doubles and so forth rather than all strings. Is anybody willing to do this? If not I could give it a try, though I expect it would need to be peer-reviewed quite thourougly as I have not done any development in ServiceMix before We welcome patches, particularly from first timers! So please have a try and we'll take a look http://incubator.apache.org/servicemix/contributing.html -- James --- http://radio.weblogs.com/0112098/
[jira] Updated: (GERONIMO-2271) Security Realm deployed as part of a web app listed as Serverwide
[ http://issues.apache.org/jira/browse/GERONIMO-2271?page=all ] Vamsavardhana Reddy updated GERONIMO-2271: -- Attachment: GERONIMO-2271.patch GERONIMO-2271.patch: Fixes the problem by using the parent configuration type. parent configuration type = SERVICE means the realm is serverwide. Security Realm deployed as part of a web app listed as Serverwide --- Key: GERONIMO-2271 URL: http://issues.apache.org/jira/browse/GERONIMO-2271 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.2, 1.1, 1.1.1, 1.1.x Environment: Win XP, G1.1.1-SNAPSHOT Tomcat Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.1.x, 1.1.2 Attachments: GERONIMO-2271.patch I have deployed a web application with its own security realm. The new security realm is shown as Serverwide in Security Realms portlet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2271) Security Realm deployed as part of a web app listed as Serverwide
[ http://issues.apache.org/jira/browse/GERONIMO-2271?page=all ] Vamsavardhana Reddy updated GERONIMO-2271: -- Patch Info: [Patch Available] Security Realm deployed as part of a web app listed as Serverwide --- Key: GERONIMO-2271 URL: http://issues.apache.org/jira/browse/GERONIMO-2271 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.2, 1.1, 1.1.1, 1.1.x Environment: Win XP, G1.1.1-SNAPSHOT Tomcat Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.1.x, 1.1.2 Attachments: GERONIMO-2271.patch I have deployed a web application with its own security realm. The new security realm is shown as Serverwide in Security Realms portlet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2326) unable to deploy a database pool
[ http://issues.apache.org/jira/browse/GERONIMO-2326?page=all ] Bill Dudney updated GERONIMO-2326: -- Affects Version/s: (was: 1.1.1) To test the patch 1) after applying it rebuild the car plugin 2) rebuild all the configs 3) reassbmble Also - removed the 1.1.1 reference as it was fixed by the changes for 2327 unable to deploy a database pool Key: GERONIMO-2326 URL: http://issues.apache.org/jira/browse/GERONIMO-2326 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Bill Dudney Attachments: 2326-deploy-datasource.patch Trying to deploy a jdbc datasource leads to a blank screen and the following stack trace in the log. The issue appears to be that URLPatternSpec does not like the URL generated by DatabasePoolPortlet from the info found in the DatabaseInfo.ALL_DATABASES array. java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebUserDataPermission.init(WebUserDataPermission.java:83) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasUserDataPermission(TomcatGeronimoRealm.java:131) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:460) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:322) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:552) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Replacement for DeadLetterPolicy in 4.1?
There is a replacement. But folks tend to not change that policy. It would be simpler to just disable that feature. I would rather spend time trying to expose the network of broker configuration. On 8/18/06, Jason Dillon [EMAIL PROTECTED] wrote: Is there a replacement for DeadLetterPolicy in 4.1? One of the G portlets is using it, not sure what the right fix is. Any advise? --jason -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Closed: (GERONIMO-2132) Move activemq gbean integration modules from ActiveMQ to Geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-2132?page=all ] Hiram Chirino closed GERONIMO-2132. --- Resolution: Fixed good point. closing. Move activemq gbean integration modules from ActiveMQ to Geronimo - Key: GERONIMO-2132 URL: http://issues.apache.org/jira/browse/GERONIMO-2132 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: ActiveMQ Reporter: Hiram Chirino Assigned To: Jason Dillon Fix For: 1.2 Attachments: amq4.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Thoughts on a JBI POJO Engine
I do think we agree ;)
The only thing i meant, was that this new component should focus on:
* messaging style (asynchronous)
* xml payload
* closer to jbi
whereas jsr181 is good for web service stuff (completely hiding jbi,
doing xml/java marshalling, rpc, etc..).
Stating that provides imho a clear difference between the two components.
On 8/21/06, Philip Dodds [EMAIL PROTECTED] wrote:
Guillaume,
I agree that we need to define the difference between components more
clearly - I suppose in my mind the JBI component under discussion here
is basically a mechanism when you are focussing on XML messaging in a
format that can not be changed or where you want to interact with the
JBI message bus to provide either InOnly reciept of messages or to
build a consumer that will run through a provided WorkManager.
The JSR181 components to be have always had explicit business
interfaces and work more akin to Web Services or EJB's then MDB's
(sorry for the switching back to the old days). I was hoping that
people building integration service units would simply want to be
playing with payloads or mapping in some specific bits of information
from an XML document (people who would be familiar familiar with XPath
and DOM say) and would want to act on that information and reply with
a Document or create an exchange to another service. While I suppose
IMHO the JSR181 is more for people wishing to expose Business Services
to the bus, and would be used by people designing application
endpoints - which would be defining the payload of the messages not
simply being given the payload?
The different would be in the purposing and flexibilty of the POJO's -
the JBI would be quick (and maybe a little dirty) which it could work
on any payload of message etc and could interact with a InOut
exchange, get the property from the exchange, update the Fault and
Error etc. While the JSR181 would be a way to expose business
services to the bus (whereby your focus is on WSDL, and structured
data).
I realize you can do any payload in JSR181 but I'm wondering whether
that is simply pushing the JSR181 container into doing more than it is
best suited?
P
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
While I fully agree to simplify the annotations used,
if you begin to map parameters to properties or xml content,
you end up to jsr181 component.
I have already planned to add annotations a la jaxws to allow
properties to be mapped to parameters in jsr181. A kind of
JBI annotations set for jaxws (compared to the existing SOAP annotations).
But if we begin to handle xml mapping here, we would end
with 2 components with little differences.
For example, the
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
could be further simplified to
@WebMethod
public SomeResponse doSomething(@WebParam SomeRequest foo) { ... }
which is exactly what the jsr181 component do ;)
Note that the jsr181 component should already by able to
handle Source types as a parameter (which would map to
the full payload), and we should be able to add a MessageExchange
parameter which would receive the exchange without disturbing
other parameters (xfire already does that for xfire specific
classes, such as the context).
We need to clearly agree on what we want to show and hide from
the jbi spec in this component. I don't think we need another SE
that do xml marshalling (we'd better enhance the existing one).
The main things to define imho are:
* how to return the answer if using an InOut
* when the pojo acts as a consumer, how will it receive the answer
from an InOut exchange it has previsouly sent
I really think there is something to do with beanflow.
I will try to think about that a bit more.
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Just a bit of brainstorming of ideas here.
I was looking at this example
@ExchangeProcessor(patterns = { MessageExchangePattern.INOUT },
parameterMappings = { ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOutProcessor(MessageExchange me) {
// Do something here
}
@ExchangeProcessor(patterns = { MessageExchangePattern.INONLY,
MessageExchangePattern.ROBUSTINOULY },
parameterMappings = {
ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOnlyProcessor(Source payload) {
// Do something here
}
and wondering how to simplify a little.
My first thought was to use an annotation for each kind of exchange to
be supported...
@InOnlyExchange @RobustInOnlyExchange
public void foo(MessageExchange exchange) {
}
(I realised we'd get class name clashes so added the 'Exchange'
postfix to the annotation names. Then I figured it might be simpler to
just use a typesafe API...
@ExchangeProcessor
public void foo(InOnly exchange) {
}
@ExchangeProcessor
public void
Re: Thoughts on a JBI POJO Engine
So just so I get it - are we still thinking of two engines? The
reason I ask is I'm not sure about an uber-engine that does everything
- simply because it sort of breaks that whole SE flexbiity and also
makes understanding it all a little more tricky.
I'm going to try and update the page today with some of the discussion
here so we can track where we are going :)
P
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
I do think we agree ;)
The only thing i meant, was that this new component should focus on:
* messaging style (asynchronous)
* xml payload
* closer to jbi
whereas jsr181 is good for web service stuff (completely hiding jbi,
doing xml/java marshalling, rpc, etc..).
Stating that provides imho a clear difference between the two components.
On 8/21/06, Philip Dodds [EMAIL PROTECTED] wrote:
Guillaume,
I agree that we need to define the difference between components more
clearly - I suppose in my mind the JBI component under discussion here
is basically a mechanism when you are focussing on XML messaging in a
format that can not be changed or where you want to interact with the
JBI message bus to provide either InOnly reciept of messages or to
build a consumer that will run through a provided WorkManager.
The JSR181 components to be have always had explicit business
interfaces and work more akin to Web Services or EJB's then MDB's
(sorry for the switching back to the old days). I was hoping that
people building integration service units would simply want to be
playing with payloads or mapping in some specific bits of information
from an XML document (people who would be familiar familiar with XPath
and DOM say) and would want to act on that information and reply with
a Document or create an exchange to another service. While I suppose
IMHO the JSR181 is more for people wishing to expose Business Services
to the bus, and would be used by people designing application
endpoints - which would be defining the payload of the messages not
simply being given the payload?
The different would be in the purposing and flexibilty of the POJO's -
the JBI would be quick (and maybe a little dirty) which it could work
on any payload of message etc and could interact with a InOut
exchange, get the property from the exchange, update the Fault and
Error etc. While the JSR181 would be a way to expose business
services to the bus (whereby your focus is on WSDL, and structured
data).
I realize you can do any payload in JSR181 but I'm wondering whether
that is simply pushing the JSR181 container into doing more than it is
best suited?
P
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
While I fully agree to simplify the annotations used,
if you begin to map parameters to properties or xml content,
you end up to jsr181 component.
I have already planned to add annotations a la jaxws to allow
properties to be mapped to parameters in jsr181. A kind of
JBI annotations set for jaxws (compared to the existing SOAP annotations).
But if we begin to handle xml mapping here, we would end
with 2 components with little differences.
For example, the
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
could be further simplified to
@WebMethod
public SomeResponse doSomething(@WebParam SomeRequest foo) { ... }
which is exactly what the jsr181 component do ;)
Note that the jsr181 component should already by able to
handle Source types as a parameter (which would map to
the full payload), and we should be able to add a MessageExchange
parameter which would receive the exchange without disturbing
other parameters (xfire already does that for xfire specific
classes, such as the context).
We need to clearly agree on what we want to show and hide from
the jbi spec in this component. I don't think we need another SE
that do xml marshalling (we'd better enhance the existing one).
The main things to define imho are:
* how to return the answer if using an InOut
* when the pojo acts as a consumer, how will it receive the answer
from an InOut exchange it has previsouly sent
I really think there is something to do with beanflow.
I will try to think about that a bit more.
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Just a bit of brainstorming of ideas here.
I was looking at this example
@ExchangeProcessor(patterns = { MessageExchangePattern.INOUT },
parameterMappings = { ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOutProcessor(MessageExchange me) {
// Do something here
}
@ExchangeProcessor(patterns = { MessageExchangePattern.INONLY,
MessageExchangePattern.ROBUSTINOULY },
parameterMappings = {
ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOnlyProcessor(Source payload) {
// Do something here
Re: m2 build - validating
Hi David, On Aug 21, 2006, at 1:47 AM, David Jencks wrote: On Aug 20, 2006, at 3:36 PM, Bill Dudney wrote: Hi All, Sorry its taken me so long to get this posted. I had a bunch of travel related headaches thur and fri of last week... I've adopted http://issues.apache.org/jira/browse/GERONIMO-2326 as the JIRA to track the first part of the problem (the datasource deployment stuff) with the current trunk and deployment. I've just attached a patch to the issue that makes a small change to the CAR plugin to include RAR's in the dependencies that are copied into the assembly repository. I am fairly sure this needs to be done as the RAR's end up in the repository on 1.1 and the DatabaseInfo class requires them to be there (albeit with a comment that says EVIL!!! :). However there might be something going on there I'm not aware of. This is basically a wrong thing to do. A dependency on the rar file doesn't do anything except require it to be there, which is bogus since in fact once the car file is generated it doesn't have to be there. The tranql rars (and the activemq rar) are included only for the convenience of users wishing to deploy additional datasources without downloading the rar file themselves. Yes but the Datasource deployment code in trunk depends on the RAR's being in the repository, after spending some time digging around the 1.1.1 code there has been a lot of change in the way this stuff works. Would be great to get trunk and 1.1.1 more in line as it might fix many of the problems. There's been discussion for a really long time about not copying the contents of j2ee artifacts into the car file but instead including them in the classloader in some other way. This sounds nice but is fraught with difficulties such as -how do you make a classloader that reads the jars in a war lib dir inside an ear (nested jar classloading) -or, how do you figure out to unpack the j2ee artifacts in the repo - how do you set up a variety of classloaders that only load some stuff from an ear: e.g. right now an ear classloader doesn't see anything in any web apps. these are all soluble but will take a bunch of work to decide what to do and implement. i'm game to help with the work lets get started. One quick note on this change. The RAR's do end up copied into the CAR (without this change) but, the DatabaseInfo class is expecting (at least) the Derby related RAR's to be directly in the repo. Take a look here http://tinyurl.com/jynnh. the list of *RAR_NAME fields are all used to load the RAR's directly from the repository (http://tinyurl.com/kyhve getRAR static method on line 1036). As the comments says this is rather hard coded. I've not had time to get brain cells focused on the solution. Seems that we should be able to do some kind of maven magic though to find the tranql/ tranql-connector/rar instead of hardcoding the path. But again I don't know the history so perhaps there is a reason for the EVIL :) I think that the code for 1.1 is greatly improved over what's in trunk, and I hope aaron ports it soon. Again, using rar's as dependencies is a bad idea. I think something got left out of the m2 build, in the m1 build there was a way to specify that some jars just get put in the repo even though they aren't dependencies of any car. I don't know if this is possible in m2, but the tranql rars are not getting installed at least on my machine. Right the patch to the m2-car-plugin which is in the patch I attached to 2326 fixes this. Essentially the plugin was ignoring RAR files. With the patch it includes RAR's in the repository. So the patch attached to 2326 gets us almost there, but there is still the issue with the IncompatiblClassChangeError coming up. I posted a partial stack trace in the issue. Any pointers, thoughts or other things that could help me track that one down are most welcome. I have to bail for a couple of hours but will be back on line around 7:00MST for a bit. Also David J, if you could take a look at the pom changes and make sure they are in line with your recommendations. I could not find another car to have system-database depended on that would bring in the dependencies and system-database looked to be the most logical place to add add a jar dependency. I added the jar's to the gbean-deployer/pom.xml because the CNFExceptions were coming from classes in this package and again no obvious CAR to add to the mix. Unfortunately I don't like almost all your proposed pom changes. No problem, that is why I asked you to look as I figured you'd have an opinion :-) We do need to add the geronimo-test-ddbean jar to some module, but I think it should be added to j2ee-deployer since jsr-88 is pretty irrelevant to gbean deployment. Good point, I will move the test-ddbean depndency to the j2ee- deployer I think the
Re: Thoughts on a JBI POJO Engine
On 8/21/06, Philip Dodds [EMAIL PROTECTED] wrote: I like the logic - also I like the idea that a service could annotate two methods and thus end up with the ability to process an InOut and a InOnly via two different methods on the same class. The only question I suppose it what happens if you want to be able to provide both from the same method - say a file reading service that gets the filename in an XML path and then reading and passing the file to a providing service then can either return an XML representing the number of records or not (depending on the MEP?). Could you show some pseudocode for what you mean? Am not quite sure I follow :) -- James --- http://radio.weblogs.com/0112098/
Re: problem installing plugin for web console in g 1.1
Following up on this Joe. Joe Bohn wrote: One more time Does anybody know how/who/etc... to get the maven 2 info updated for ibiblio? Is there some way to avoid similar problems on ibiblio as we prepare to publish the 1.1.1 artifacts? Aaron, Do you think you might be able to get the geronimo 1.1 artifacts into the plugins repo soon to get around this problem? At the moment it looks like this prevents us from being able to install the console and liferay plugins on 1.1 not sure if any others are affected. Thanks, Joe Aaron Mulder wrote: I agree. I'll let you know when the site is updated. I won't be able to do it during the day, but tonight or over the weekend. Thanks, Aaron On 8/11/06, Joe Bohn [EMAIL PROTECTED] wrote: Does anybody know how to update the Maven metadata on ibiblio? It looks like this is incorrect for all of the 1.1 artifacts. Aaron, Thanks for looking into this. Have you added (or are you going to add) the full set of geronimo artifacts for 1.1 to your plugin repo as you mentioned? Can you let me know when they are there? It seems like it makes sense to have these on the geronimo plugins repo anyway, even once ibiblio is fixed. They are geronimo artifacts that may be needed by many Geronimo plugins and it would eliminate possible failures due to connectivity problems with ibiblio. Joe Aaron Mulder wrote: This is because the Maven metadata in the Maven 2 repository on ibiblio is wrong. I'm surprised -- I would have thought this was updated when we published our 1.1 JARs. Anyway, look here: http://www.ibiblio.org/maven2/geronimo/geronimo-timer/maven-metadata.xml Notice that there's no 1.1 listed, even though http://www.ibiblio.org/maven2/geronimo/geronimo-timer/1.1/ exists. So the path we took to get here is because we need a module and there's no version in the dependency, we find the first server that has a matching module and take the highest version it has. I can probably work around this by putting a full set of Geronimo artifacts on geronimoplugins.com (so we won't fall back to ibiblio for those modules), though again, the real fix is to correct the Maven metadata on ibiblio. I have no idea how to do that. Thanks, Aaron On 8/10/06, Joe Bohn [EMAIL PROTECTED] wrote: I hit an error attempting to install the plugin for the web console on a little-G tomcat image with the official Geronimo 1.1 release. Are there known problems with this capability? I assumed that this plugin is for this very purpose (since we already include the console with the j2ee image). It looked like the download and install went as expected but failed attempting to start the gbean. I think that somehow the wrong dependencies were installed for geronimo-timer (and perhaps geronimo-derby). For both of these version 1.0 was deployed rather than 1.1. Installation Complete! Used existing: geronimo/j2ee-server//car Used existing: geronimo/j2ee-security//car Used existing: geronimo/tomcat//car Used existing: geronimo/geronimo-management//jar Used existing: geronimo/geronimo-deploy-jsr88//jar Used existing: geronimo/geronimo-service-builder//jar Used existing: geronimo/geronimo-connector-builder//jar Used existing: geronimo/geronimo-naming-builder//jar Used existing: geronimo/geronimo-security-builder//jar Used existing: geronimo/geronimo-j2ee-schema//jar Used existing: xmlbeans/xbean/2.0.0/jar Used existing: stax/stax-api/1.0.1/jar Used existing: geronimo/geronimo-util//jar Installed new: geronimo/system-database//car Installed new: geronimo/geronimo-derby//jar Installed new: org.apache.derby/derby//jar Installed new: org.apache.derby/derbynet//jar Installed new: geronimo/geronimo-timer//jar Installed new: portlet-api/portlet-api/1.0/jar Installed new: org.apache.pluto/pluto/1.0.1/jar Installed new: geronimo/geronimo-console-core//jar Installed new: geronimo/geronimo-upgrade//jar Installed new: geronimo/geronimo-test-ddbean//jar Installed new: geronimo/geronimo-deploy-config//jar Installed new: activemq/activemq-gbean-management-g1_1/3.2.4/jar Installed new: activemq/activemq-gbean-g1_1/3.2.4/jar Installed new: activemq/activemq-core/3.2.4/jar Installed new: geronimo/geronimo-converter//jar Installed new: jdom/jdom//jar Now starting geronimo/webconsole-tomcat/1.1/car... org.apache.geronimo.kernel.config.LifecycleException: start of geronimo/webconsole-tomcat/1.1/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:529) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:493) at
Re: Thoughts on a JBI POJO Engine
Yes, I think so.
But maybe we could have some common code / annotations which could be reused.
Especially if we try to put pitchfork (EJB3) in jsr181, which would
introduce some
annotations driven injection.
On 8/21/06, Philip Dodds [EMAIL PROTECTED] wrote:
So just so I get it - are we still thinking of two engines? The
reason I ask is I'm not sure about an uber-engine that does everything
- simply because it sort of breaks that whole SE flexbiity and also
makes understanding it all a little more tricky.
I'm going to try and update the page today with some of the discussion
here so we can track where we are going :)
P
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
I do think we agree ;)
The only thing i meant, was that this new component should focus on:
* messaging style (asynchronous)
* xml payload
* closer to jbi
whereas jsr181 is good for web service stuff (completely hiding jbi,
doing xml/java marshalling, rpc, etc..).
Stating that provides imho a clear difference between the two components.
On 8/21/06, Philip Dodds [EMAIL PROTECTED] wrote:
Guillaume,
I agree that we need to define the difference between components more
clearly - I suppose in my mind the JBI component under discussion here
is basically a mechanism when you are focussing on XML messaging in a
format that can not be changed or where you want to interact with the
JBI message bus to provide either InOnly reciept of messages or to
build a consumer that will run through a provided WorkManager.
The JSR181 components to be have always had explicit business
interfaces and work more akin to Web Services or EJB's then MDB's
(sorry for the switching back to the old days). I was hoping that
people building integration service units would simply want to be
playing with payloads or mapping in some specific bits of information
from an XML document (people who would be familiar familiar with XPath
and DOM say) and would want to act on that information and reply with
a Document or create an exchange to another service. While I suppose
IMHO the JSR181 is more for people wishing to expose Business Services
to the bus, and would be used by people designing application
endpoints - which would be defining the payload of the messages not
simply being given the payload?
The different would be in the purposing and flexibilty of the POJO's -
the JBI would be quick (and maybe a little dirty) which it could work
on any payload of message etc and could interact with a InOut
exchange, get the property from the exchange, update the Fault and
Error etc. While the JSR181 would be a way to expose business
services to the bus (whereby your focus is on WSDL, and structured
data).
I realize you can do any payload in JSR181 but I'm wondering whether
that is simply pushing the JSR181 container into doing more than it is
best suited?
P
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
While I fully agree to simplify the annotations used,
if you begin to map parameters to properties or xml content,
you end up to jsr181 component.
I have already planned to add annotations a la jaxws to allow
properties to be mapped to parameters in jsr181. A kind of
JBI annotations set for jaxws (compared to the existing SOAP annotations).
But if we begin to handle xml mapping here, we would end
with 2 components with little differences.
For example, the
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
could be further simplified to
@WebMethod
public SomeResponse doSomething(@WebParam SomeRequest foo) { ... }
which is exactly what the jsr181 component do ;)
Note that the jsr181 component should already by able to
handle Source types as a parameter (which would map to
the full payload), and we should be able to add a MessageExchange
parameter which would receive the exchange without disturbing
other parameters (xfire already does that for xfire specific
classes, such as the context).
We need to clearly agree on what we want to show and hide from
the jbi spec in this component. I don't think we need another SE
that do xml marshalling (we'd better enhance the existing one).
The main things to define imho are:
* how to return the answer if using an InOut
* when the pojo acts as a consumer, how will it receive the answer
from an InOut exchange it has previsouly sent
I really think there is something to do with beanflow.
I will try to think about that a bit more.
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Just a bit of brainstorming of ideas here.
I was looking at this example
@ExchangeProcessor(patterns = { MessageExchangePattern.INOUT },
parameterMappings = { ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOutProcessor(MessageExchange me) {
Re: JMX Portlet
I'd rather have something in the Console that users can easily navigate to and not rely on JConsole. I know it will be there but its another tool to find. Paul McMahan wrote: Chris, this sounds like an interesting idea. As I recall, the discussion from a few months ago came down to removing the JMX debug application iff we could get the JConsole to work with Geronimo. And then I think that problem was addressed in GERONIMO-1329. So assuming that we can now connect JConsole to a Geronimo server would that affect what you might plan to implement in the admin console? i.e. since JConsole already provides some of this function, just not in way that's usable directly from the admin console. Also I'm wondering if Sun's plans to open source java soon might lead to some interesting possibilities, like maybe running JConsole in an applet from the console. But that is making a LOT of assumptions :-) Best wishes, Paul On 8/18/06, Chris Cardona [EMAIL PROTECTED] wrote: A few months ago the JMX debug application was removed and there was a suggestion to replace this with a JMX portlet in the console for Geronimo 1.2 (IIRC it was Dain who suggested this). I would like to work on this portlet with the following minimum capabilities: 1. Be able to list all the MBeans 2. Predefined searches for the different J2EE types: J2EEApplication, EJBModule, WebModule, Sertlet, JCAConnectionFactory, etc. 3. Be able to query MBeans (if possible with autocomplete feature) 4. View the attributes and operations of MBeans In addition, my plan was to use Ajax (Dojo and DWR) to make this portlet a little bit responsive. Any thoughts and suggestions? Best wishes, Chris __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Assigned: (GERONIMO-2271) Security Realm deployed as part of a web app listed as Serverwide
[ http://issues.apache.org/jira/browse/GERONIMO-2271?page=all ] Vamsavardhana Reddy reassigned GERONIMO-2271: - Assignee: Vamsavardhana Reddy Security Realm deployed as part of a web app listed as Serverwide --- Key: GERONIMO-2271 URL: http://issues.apache.org/jira/browse/GERONIMO-2271 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.2, 1.1, 1.1.1, 1.1.x Environment: Win XP, G1.1.1-SNAPSHOT Tomcat Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.2, 1.1.x, 1.1.2 Attachments: GERONIMO-2271.patch I have deployed a web application with its own security realm. The new security realm is shown as Serverwide in Security Realms portlet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-886) Timing bug could cause duplicate client id exception in network code.
Timing bug could cause duplicate client id exception in network code. - Key: AMQ-886 URL: https://issues.apache.org/activemq/browse/AMQ-886 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.0.3, 4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-887) Allow temp destination message bridging to be disable across demand based bridges.
Allow temp destination message bridging to be disable across demand based bridges. -- Key: AMQ-887 URL: https://issues.apache.org/activemq/browse/AMQ-887 Project: ActiveMQ Issue Type: New Feature Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2279) FileKeyStoreInstance: Does not save keyPasswords after removing an entry
[ http://issues.apache.org/jira/browse/GERONIMO-2279?page=all ] Vamsavardhana Reddy reassigned GERONIMO-2279: - Assignee: Vamsavardhana Reddy FileKeyStoreInstance: Does not save keyPasswords after removing an entry Key: GERONIMO-2279 URL: http://issues.apache.org/jira/browse/GERONIMO-2279 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 1.1 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Priority: Minor Fix For: 1.2, 1.1.2 Attachments: GERONIMO-2279.patch keyPasswords are not saved after the password of deleted entry is removed from the HashMap. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2278) Problems in editing Jetty SSL Connector and the edit page in Geronimo Console
[ http://issues.apache.org/jira/browse/GERONIMO-2278?page=all ] Vamsavardhana Reddy reassigned GERONIMO-2278: - Assignee: Vamsavardhana Reddy Problems in editing Jetty SSL Connector and the edit page in Geronimo Console - Key: GERONIMO-2278 URL: http://issues.apache.org/jira/browse/GERONIMO-2278 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.1.1 Environment: Win XP, G1.1.1-SNAPHOT, Jetty Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.2, 1.1.x Attachments: GERONIMO-2278-new.patch, GERONIMO-2278.patch Here is what I noticed. 1. Edit page does not show the current values for fields in the select boxes. 2. Changes made to the KeyStore field are not saved. 3. The page does not provide for editing the keyAlias. keyAlias is hardcoded as geronimo. Even if 2 from above is fixed, users are forced to use geronimo for the keyAlias. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Thoughts on a JBI POJO Engine
Here is something i'd like to be able to do.
This is really pseudo code, and some kind of beanflow oriented annotations.
This service would simply send two concurrent requests and wait for their
answers to reply to the main request. Of course, this would be much easier
if you use syncSend but you would not have a real workflow ;)
public class MyWorkflow {
Message request;
Message answer1;
Message answer2;
@Destination(uri=service:urn:service)
private Destination service1;
@Destination(uri=service:urn:service)
private Destination service2;
@Request
@NextStep(steps = { invokeService, invokerService2 }) // This
would auto-fork
public void receiveRequest(Message message) throws Exception {
request = message;
}
@NextStep(step = receiveService1)
public void invokeService1() {
service1.send(copy(request));
// return response to receiveService1
}
public void receiveService1(Message message) {
answer1 = message;
}
@NextStep(step = receiveService2)
public void invokeService2() {
service2.send(copy(request));
}
public void receiveService2(Message message) {
answer2 = message;
}
@Join(steps = { receiveService1, receiveService2 })
@Answer()
public void answer() {
// Do something with answer1 and answer2
return new Message()
}
}
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
While I fully agree to simplify the annotations used,
if you begin to map parameters to properties or xml content,
you end up to jsr181 component.
I have already planned to add annotations a la jaxws to allow
properties to be mapped to parameters in jsr181. A kind of
JBI annotations set for jaxws (compared to the existing SOAP annotations).
But if we begin to handle xml mapping here, we would end
with 2 components with little differences.
For example, the
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
could be further simplified to
@WebMethod
public SomeResponse doSomething(@WebParam SomeRequest foo) { ... }
which is exactly what the jsr181 component do ;)
Note that the jsr181 component should already by able to
handle Source types as a parameter (which would map to
the full payload), and we should be able to add a MessageExchange
parameter which would receive the exchange without disturbing
other parameters (xfire already does that for xfire specific
classes, such as the context).
We need to clearly agree on what we want to show and hide from
the jbi spec in this component. I don't think we need another SE
that do xml marshalling (we'd better enhance the existing one).
The main things to define imho are:
* how to return the answer if using an InOut
* when the pojo acts as a consumer, how will it receive the answer
from an InOut exchange it has previsouly sent
I really think there is something to do with beanflow.
I will try to think about that a bit more.
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Just a bit of brainstorming of ideas here.
I was looking at this example
@ExchangeProcessor(patterns = { MessageExchangePattern.INOUT },
parameterMappings = { ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOutProcessor(MessageExchange me) {
// Do something here
}
@ExchangeProcessor(patterns = { MessageExchangePattern.INONLY,
MessageExchangePattern.ROBUSTINOULY },
parameterMappings = {
ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOnlyProcessor(Source payload) {
// Do something here
}
and wondering how to simplify a little.
My first thought was to use an annotation for each kind of exchange to
be supported...
@InOnlyExchange @RobustInOnlyExchange
public void foo(MessageExchange exchange) {
}
(I realised we'd get class name clashes so added the 'Exchange'
postfix to the annotation names. Then I figured it might be simpler to
just use a typesafe API...
@ExchangeProcessor
public void foo(InOnly exchange) {
}
@ExchangeProcessor
public void bar(RobustInOnly exchange) {
}
I guess sometimes folks might not want to see/use the exchange or
might wish to support multiple patterns for one method so some kinda
annotation to indicate the exchange pattern is still useful.
Also how about annotating parameters as being bound to the exchange...
@ExchangeProcessor
public void foo(@MessageProperty('cheese') String foo,
@ExchangeProperty(beer) Integer bar, @MessageContent Source payload)
{
}
While the @MessageContent may at first not appear that useful, we
could allow some automatic tranformations from common types to message
contents such as DOM or JAXB marshalling etc
e.g.
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
where SomeRequest and SomeResponse could be marshalled to/from Source via
JAXB2.
This would allow folks to
Re: Fw: wiki.apache.org/geronimo going out of production
Good idea Cameron. On 8/20/06, Cameron Braid [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 building geronimoPaul McMahan wrote: +1 I'm all in favor of eliminating the obsolete wiki sites. Right now when I google geronimo wiki or building geronimo it comes back with links to the MoinMoin wiki, which ain't good. It may be a good idea to put a temporary redirector from the old MoinMoin wiki's domain, redirecting all urls to a page in confluence that explains that the content has been moved. Then, after a few weeks, when the spiders have updated their indexes, the domain could be decomissioned. Cameron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE6R/Dbbjq9wHLQrIRArtRAJ9g5SghV363uXZyBOgqBRy96ebMnACeOgJr +GT/SGVxi/giyg0Z9cvOi4Y= =Y79o -END PGP SIGNATURE-
[jira] Commented: (AMQ-886) Timing bug could cause duplicate client id exception in network code.
[ https://issues.apache.org/activemq/browse/AMQ-886?page=comments#action_36815 ] Hiram Chirino commented on AMQ-886: --- Applied fix to trunk in rev 433244 Timing bug could cause duplicate client id exception in network code. - Key: AMQ-886 URL: https://issues.apache.org/activemq/browse/AMQ-886 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1, 4.0.3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Thoughts on a JBI POJO Engine
Interesting! I really love the @Destination injection BTW :)
I wonder about using futures a little more to make the code a little
simpler. Something like the following - where we wrap up an async
request-response as a child Step or Future...
public class MyWorkflow {
Message request;
FutureMessage answer1;
FutureMessage answer2;
@Destination(uri=service:urn:service)
private Destination service1;
@Destination(uri=service:urn:service)
private Destination service2;
@Request
public void receiveRequest(Message message) throws Exception {
request = message;
answer1 = service1.sendAsync(copy(request));
answer2 = service2.sendAsync(copy(request));
}
@Join(futures = { answer1, answer2 })
@Answer()
public Message answer() {
Message m1 = answer1.get();
Message m2 = answer2.get();
// Do something with answer1 and answer2
return new Message()
}
}
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
Here is something i'd like to be able to do.
This is really pseudo code, and some kind of beanflow oriented annotations.
This service would simply send two concurrent requests and wait for their
answers to reply to the main request. Of course, this would be much easier
if you use syncSend but you would not have a real workflow ;)
public class MyWorkflow {
Message request;
Message answer1;
Message answer2;
@Destination(uri=service:urn:service)
private Destination service1;
@Destination(uri=service:urn:service)
private Destination service2;
@Request
@NextStep(steps = { invokeService, invokerService2 }) // This
would auto-fork
public void receiveRequest(Message message) throws Exception {
request = message;
}
@NextStep(step = receiveService1)
public void invokeService1() {
service1.send(copy(request));
// return response to receiveService1
}
public void receiveService1(Message message) {
answer1 = message;
}
@NextStep(step = receiveService2)
public void invokeService2() {
service2.send(copy(request));
}
public void receiveService2(Message message) {
answer2 = message;
}
@Join(steps = { receiveService1, receiveService2 })
@Answer()
public void answer() {
// Do something with answer1 and answer2
return new Message()
}
}
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
While I fully agree to simplify the annotations used,
if you begin to map parameters to properties or xml content,
you end up to jsr181 component.
I have already planned to add annotations a la jaxws to allow
properties to be mapped to parameters in jsr181. A kind of
JBI annotations set for jaxws (compared to the existing SOAP annotations).
But if we begin to handle xml mapping here, we would end
with 2 components with little differences.
For example, the
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
could be further simplified to
@WebMethod
public SomeResponse doSomething(@WebParam SomeRequest foo) { ... }
which is exactly what the jsr181 component do ;)
Note that the jsr181 component should already by able to
handle Source types as a parameter (which would map to
the full payload), and we should be able to add a MessageExchange
parameter which would receive the exchange without disturbing
other parameters (xfire already does that for xfire specific
classes, such as the context).
We need to clearly agree on what we want to show and hide from
the jbi spec in this component. I don't think we need another SE
that do xml marshalling (we'd better enhance the existing one).
The main things to define imho are:
* how to return the answer if using an InOut
* when the pojo acts as a consumer, how will it receive the answer
from an InOut exchange it has previsouly sent
I really think there is something to do with beanflow.
I will try to think about that a bit more.
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Just a bit of brainstorming of ideas here.
I was looking at this example
@ExchangeProcessor(patterns = { MessageExchangePattern.INOUT },
parameterMappings = { ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOutProcessor(MessageExchange me) {
// Do something here
}
@ExchangeProcessor(patterns = { MessageExchangePattern.INONLY,
MessageExchangePattern.ROBUSTINOULY },
parameterMappings = {
ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOnlyProcessor(Source payload) {
// Do something here
}
and wondering how to simplify a little.
My first thought was to use an annotation for each kind of exchange to
be supported...
@InOnlyExchange @RobustInOnlyExchange
public void foo(MessageExchange exchange) {
}
(I realised we'd get class name clashes so
Re: [VOTE] Drop the M1 build artifacts in Trunk
+1On Aug 18, 2006, at 11:37 AM, Matt Hogstrom wrote:Given that we are close to completing the M2 conversion and have some disruptive changes to make to trunk this vote is to capture the communities input on the structure of the Geronimo repository.Given that this is about our build environment and development structure for purposes of this vote all votes are binding.The vote is to remove Maven 1 build artificats from trunk and allow directory reoganizations starting on Wednesday August 23. Jason to notify dev list about pending changes. JIRA http://issues.apache.org/jira/browse/GERONIMO-2331 created to track issue.[ ] +1 Allow changes[ ] 0 No opinion[ ] -1 Keep M1 artifacts in place (provide rationale) -sachin
Re: Thoughts on a JBI POJO Engine
The destination annotation looks great ! I assume the main body of the
JBI POJO here is the request/answer annotations.
What I'm not sure about here is the use of fields - so this is a
stateful class? I was thinking that async would be a hybrid of the
destination and the processor?
public class Example1 {
@Destination(uri=service:urn:service, request=myFirstRequest)
private Destination service1;
public void sendRequest() {
service1.send(new Message());
}
@ExchangeProcessor(request=myFirstRequest)
public void sendRequest(@MessageContent Document in) {
// Got response
}
}
The premise being that if you have a async reply then you need to be stateless?
P
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
Here is something i'd like to be able to do.
This is really pseudo code, and some kind of beanflow oriented annotations.
This service would simply send two concurrent requests and wait for their
answers to reply to the main request. Of course, this would be much easier
if you use syncSend but you would not have a real workflow ;)
public class MyWorkflow {
Message request;
Message answer1;
Message answer2;
@Destination(uri=service:urn:service)
private Destination service1;
@Destination(uri=service:urn:service)
private Destination service2;
@Request
@NextStep(steps = { invokeService, invokerService2 }) // This
would auto-fork
public void receiveRequest(Message message) throws Exception {
request = message;
}
@NextStep(step = receiveService1)
public void invokeService1() {
service1.send(copy(request));
// return response to receiveService1
}
public void receiveService1(Message message) {
answer1 = message;
}
@NextStep(step = receiveService2)
public void invokeService2() {
service2.send(copy(request));
}
public void receiveService2(Message message) {
answer2 = message;
}
@Join(steps = { receiveService1, receiveService2 })
@Answer()
public void answer() {
// Do something with answer1 and answer2
return new Message()
}
}
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
While I fully agree to simplify the annotations used,
if you begin to map parameters to properties or xml content,
you end up to jsr181 component.
I have already planned to add annotations a la jaxws to allow
properties to be mapped to parameters in jsr181. A kind of
JBI annotations set for jaxws (compared to the existing SOAP annotations).
But if we begin to handle xml mapping here, we would end
with 2 components with little differences.
For example, the
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
could be further simplified to
@WebMethod
public SomeResponse doSomething(@WebParam SomeRequest foo) { ... }
which is exactly what the jsr181 component do ;)
Note that the jsr181 component should already by able to
handle Source types as a parameter (which would map to
the full payload), and we should be able to add a MessageExchange
parameter which would receive the exchange without disturbing
other parameters (xfire already does that for xfire specific
classes, such as the context).
We need to clearly agree on what we want to show and hide from
the jbi spec in this component. I don't think we need another SE
that do xml marshalling (we'd better enhance the existing one).
The main things to define imho are:
* how to return the answer if using an InOut
* when the pojo acts as a consumer, how will it receive the answer
from an InOut exchange it has previsouly sent
I really think there is something to do with beanflow.
I will try to think about that a bit more.
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Just a bit of brainstorming of ideas here.
I was looking at this example
@ExchangeProcessor(patterns = { MessageExchangePattern.INOUT },
parameterMappings = { ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOutProcessor(MessageExchange me) {
// Do something here
}
@ExchangeProcessor(patterns = { MessageExchangePattern.INONLY,
MessageExchangePattern.ROBUSTINOULY },
parameterMappings = {
ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOnlyProcessor(Source payload) {
// Do something here
}
and wondering how to simplify a little.
My first thought was to use an annotation for each kind of exchange to
be supported...
@InOnlyExchange @RobustInOnlyExchange
public void foo(MessageExchange exchange) {
}
(I realised we'd get class name clashes so added the 'Exchange'
postfix to the annotation names. Then I figured it might be simpler to
just use a typesafe API...
@ExchangeProcessor
public void foo(InOnly exchange) {
}
@ExchangeProcessor
public void
[jira] Commented: (AMQ-887) Allow temp destination message bridging to be disable across demand based bridges.
[ https://issues.apache.org/activemq/browse/AMQ-887?page=comments#action_36816 ] Hiram Chirino commented on AMQ-887: --- Since there currently exists a problme where the network bridges fail when temp destinations are used across them, the default setting should be to diable temp destination bridging untill we get that fixed. Allow temp destination message bridging to be disable across demand based bridges. -- Key: AMQ-887 URL: https://issues.apache.org/activemq/browse/AMQ-887 Project: ActiveMQ Issue Type: New Feature Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Thoughts on a JBI POJO Engine
I guess you could reuse the EJB3 annotations for stateless / stateful metadata?
On 8/21/06, Philip Dodds [EMAIL PROTECTED] wrote:
The destination annotation looks great ! I assume the main body of the
JBI POJO here is the request/answer annotations.
What I'm not sure about here is the use of fields - so this is a
stateful class? I was thinking that async would be a hybrid of the
destination and the processor?
public class Example1 {
@Destination(uri=service:urn:service, request=myFirstRequest)
private Destination service1;
public void sendRequest() {
service1.send(new Message());
}
@ExchangeProcessor(request=myFirstRequest)
public void sendRequest(@MessageContent Document in) {
// Got response
}
}
The premise being that if you have a async reply then you need to be stateless?
P
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
Here is something i'd like to be able to do.
This is really pseudo code, and some kind of beanflow oriented annotations.
This service would simply send two concurrent requests and wait for their
answers to reply to the main request. Of course, this would be much easier
if you use syncSend but you would not have a real workflow ;)
public class MyWorkflow {
Message request;
Message answer1;
Message answer2;
@Destination(uri=service:urn:service)
private Destination service1;
@Destination(uri=service:urn:service)
private Destination service2;
@Request
@NextStep(steps = { invokeService, invokerService2 }) // This
would auto-fork
public void receiveRequest(Message message) throws Exception {
request = message;
}
@NextStep(step = receiveService1)
public void invokeService1() {
service1.send(copy(request));
// return response to receiveService1
}
public void receiveService1(Message message) {
answer1 = message;
}
@NextStep(step = receiveService2)
public void invokeService2() {
service2.send(copy(request));
}
public void receiveService2(Message message) {
answer2 = message;
}
@Join(steps = { receiveService1, receiveService2 })
@Answer()
public void answer() {
// Do something with answer1 and answer2
return new Message()
}
}
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
While I fully agree to simplify the annotations used,
if you begin to map parameters to properties or xml content,
you end up to jsr181 component.
I have already planned to add annotations a la jaxws to allow
properties to be mapped to parameters in jsr181. A kind of
JBI annotations set for jaxws (compared to the existing SOAP annotations).
But if we begin to handle xml mapping here, we would end
with 2 components with little differences.
For example, the
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
could be further simplified to
@WebMethod
public SomeResponse doSomething(@WebParam SomeRequest foo) { ... }
which is exactly what the jsr181 component do ;)
Note that the jsr181 component should already by able to
handle Source types as a parameter (which would map to
the full payload), and we should be able to add a MessageExchange
parameter which would receive the exchange without disturbing
other parameters (xfire already does that for xfire specific
classes, such as the context).
We need to clearly agree on what we want to show and hide from
the jbi spec in this component. I don't think we need another SE
that do xml marshalling (we'd better enhance the existing one).
The main things to define imho are:
* how to return the answer if using an InOut
* when the pojo acts as a consumer, how will it receive the answer
from an InOut exchange it has previsouly sent
I really think there is something to do with beanflow.
I will try to think about that a bit more.
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Just a bit of brainstorming of ideas here.
I was looking at this example
@ExchangeProcessor(patterns = { MessageExchangePattern.INOUT },
parameterMappings = { ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOutProcessor(MessageExchange me) {
// Do something here
}
@ExchangeProcessor(patterns = { MessageExchangePattern.INONLY,
MessageExchangePattern.ROBUSTINOULY },
parameterMappings = {
ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOnlyProcessor(Source payload) {
// Do something here
}
and wondering how to simplify a little.
My first thought was to use an annotation for each kind of exchange to
be supported...
@InOnlyExchange @RobustInOnlyExchange
public void foo(MessageExchange exchange) {
}
(I realised we'd get class
Re: [VOTE] Specs organization, versioning, and releasing
Jason Dillon wrote:
On Aug 20, 2006, at 1:37 AM, Guillaume Nodet wrote:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId-version
specs/branches/
I guess I missed something, but what's the difference compared to the
current layout ? This only affect the tags, right ?
Yes, it affects tags primarily... as a side effect of how each module
will be released.
4. Releasing will be done with the maven release plugin ('mvn
release') and should occur at a stable point after any major change
to a spec module.
Currently, the release process is to publish a candidate release, test
it,
and once approved, move the *same* binaries to the distribution site.
Using the maven release plugin means that we will vote on a SNAPSHOT
and that plugin will upload new binaries with the release version.
Is that really what's wanted ?
I'm not sure that there is going to be a high barrier to releasing spec
jars (they are not quite the same as a server assembly)... and IMO it is
fine to vote (if needed) on the SNAPSHOT and then let the release plugin
make the release artifacts.
The only issue I see is if the final binaries are different other than removing the SNAPSHOT. I
know its all supposed to work but stranger things have happened. I guess that's the release
manager's job :)
--jason
Re: [VOTE] Specs organization, versioning, and releasing
Jason Dillon wrote:
PROPOSAL:
1. Each spec will no longer be split up into trunk+branches+tags. There
will instead be one trunk+branches+tags for all specs laid out as follows:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId-version
specs/branches/
What is the layout for branches? Right now it is the major version with all the specs underneath
it. For instance, there is 1_1, 1_1_1 (not sure why we use _'s here and .'s elsewhere). branches
would follow the same layout like:
specs/branches/geronimo-activation_1.0.2/1_1 as opposed to
specs/branches/1_1/geronimo-activation_1.0.2.
Or do you intend to leave branches alone?
2. Each plugin will continue to have its own version and will be
released independently.
3. The top-level will have it's own version, which will remain
independent. When there is a major configuration change in that pom,
the version will be changed and the pom will be republished.
4. Releasing will be done with the maven release plugin ('mvn release')
and should occur at a stable point after any major change to a spec module.
5. Change all module directories to match artifactIds.
MOTIVATION:
1. one trunk allows the entire set of specs to be checked out all at
once and built all at once.
* * *
[ ] +1 Allow changes
[ ] 0 No opinion
[ ] -1 No, leave the specs asis (provide rationale)
--jason
Re: Thoughts on a JBI POJO Engine
I suppose the more important question is how to implement stateful
POJO's - what demarcates the life of a POJO if it is stateful?
Do we assume that there is an InOut at the begining and therefore when
the POJO replies to the original message is life is complete? I'm
still not sure about stateful POJO's in the ESB?
I would like to see what people think in a large context about this?
P
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
I guess you could reuse the EJB3 annotations for stateless / stateful metadata?
On 8/21/06, Philip Dodds [EMAIL PROTECTED] wrote:
The destination annotation looks great ! I assume the main body of the
JBI POJO here is the request/answer annotations.
What I'm not sure about here is the use of fields - so this is a
stateful class? I was thinking that async would be a hybrid of the
destination and the processor?
public class Example1 {
@Destination(uri=service:urn:service, request=myFirstRequest)
private Destination service1;
public void sendRequest() {
service1.send(new Message());
}
@ExchangeProcessor(request=myFirstRequest)
public void sendRequest(@MessageContent Document in) {
// Got response
}
}
The premise being that if you have a async reply then you need to be
stateless?
P
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
Here is something i'd like to be able to do.
This is really pseudo code, and some kind of beanflow oriented annotations.
This service would simply send two concurrent requests and wait for their
answers to reply to the main request. Of course, this would be much easier
if you use syncSend but you would not have a real workflow ;)
public class MyWorkflow {
Message request;
Message answer1;
Message answer2;
@Destination(uri=service:urn:service)
private Destination service1;
@Destination(uri=service:urn:service)
private Destination service2;
@Request
@NextStep(steps = { invokeService, invokerService2 }) // This
would auto-fork
public void receiveRequest(Message message) throws Exception {
request = message;
}
@NextStep(step = receiveService1)
public void invokeService1() {
service1.send(copy(request));
// return response to receiveService1
}
public void receiveService1(Message message) {
answer1 = message;
}
@NextStep(step = receiveService2)
public void invokeService2() {
service2.send(copy(request));
}
public void receiveService2(Message message) {
answer2 = message;
}
@Join(steps = { receiveService1, receiveService2 })
@Answer()
public void answer() {
// Do something with answer1 and answer2
return new Message()
}
}
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
While I fully agree to simplify the annotations used,
if you begin to map parameters to properties or xml content,
you end up to jsr181 component.
I have already planned to add annotations a la jaxws to allow
properties to be mapped to parameters in jsr181. A kind of
JBI annotations set for jaxws (compared to the existing SOAP annotations).
But if we begin to handle xml mapping here, we would end
with 2 components with little differences.
For example, the
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
could be further simplified to
@WebMethod
public SomeResponse doSomething(@WebParam SomeRequest foo) { ... }
which is exactly what the jsr181 component do ;)
Note that the jsr181 component should already by able to
handle Source types as a parameter (which would map to
the full payload), and we should be able to add a MessageExchange
parameter which would receive the exchange without disturbing
other parameters (xfire already does that for xfire specific
classes, such as the context).
We need to clearly agree on what we want to show and hide from
the jbi spec in this component. I don't think we need another SE
that do xml marshalling (we'd better enhance the existing one).
The main things to define imho are:
* how to return the answer if using an InOut
* when the pojo acts as a consumer, how will it receive the answer
from an InOut exchange it has previsouly sent
I really think there is something to do with beanflow.
I will try to think about that a bit more.
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Just a bit of brainstorming of ideas here.
I was looking at this example
@ExchangeProcessor(patterns = { MessageExchangePattern.INOUT },
parameterMappings = { ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOutProcessor(MessageExchange me) {
// Do something here
}
Re: [RTC] WADI Integration for Jetty
Gianny, I will look at it this week. I had seen that it was out there for review but required more time than I had available in a single shot. Apologies for my tardiness. There is also some clustering work in sandbox that I think Jeff was working on. Are these complimentary efforts or completely separate? Gianny Damour wrote: Hi, I sent an email some time ago about some work being done to integrate WADI once again with Geronimo (subject was WADI Integration Preview). In the current stage, load-balancing is working reliably with two Geronimo instances behind an Apache server using mod_rewrite. I would like this piece of work to be reviewed and discussed. The JIRA is https://issues.apache.org/jira/browse/GERONIMO-2163. I have added some set-up comments such that it is easy to trial it. Note that you will need recent WADI dependencies (Jules, if you tell me how to deploy the WADI artefacts to the CodeHaus repo, then I am happy to do it). So far, what is provided is really basic (e.g. replication is not yet enabled), however I would like to see if people are generally happy with the current approach prior to enable other features. Thanks, Gianny
Re: Thoughts on a JBI POJO Engine
If you use synchronous send, you can be stateless, as the whole flow
will be executed in one step from receiving the request to answering it.
However, if you use asynchronous, you need to keep data so the bean
is statefull and you need one bean per invocation.
If you send 2 requests to 2 services, you need to keep one answer until
you receive the other one = stateful.
I like your request parameter on the destination / processor.
The only drawback is that you can only use a destination once,
but it makes things much cleaner.
On 8/21/06, Philip Dodds [EMAIL PROTECTED] wrote:
The destination annotation looks great ! I assume the main body of the
JBI POJO here is the request/answer annotations.
What I'm not sure about here is the use of fields - so this is a
stateful class? I was thinking that async would be a hybrid of the
destination and the processor?
public class Example1 {
@Destination(uri=service:urn:service, request=myFirstRequest)
private Destination service1;
public void sendRequest() {
service1.send(new Message());
}
@ExchangeProcessor(request=myFirstRequest)
public void sendRequest(@MessageContent Document in) {
// Got response
}
}
The premise being that if you have a async reply then you need to be stateless?
P
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
Here is something i'd like to be able to do.
This is really pseudo code, and some kind of beanflow oriented annotations.
This service would simply send two concurrent requests and wait for their
answers to reply to the main request. Of course, this would be much easier
if you use syncSend but you would not have a real workflow ;)
public class MyWorkflow {
Message request;
Message answer1;
Message answer2;
@Destination(uri=service:urn:service)
private Destination service1;
@Destination(uri=service:urn:service)
private Destination service2;
@Request
@NextStep(steps = { invokeService, invokerService2 }) // This
would auto-fork
public void receiveRequest(Message message) throws Exception {
request = message;
}
@NextStep(step = receiveService1)
public void invokeService1() {
service1.send(copy(request));
// return response to receiveService1
}
public void receiveService1(Message message) {
answer1 = message;
}
@NextStep(step = receiveService2)
public void invokeService2() {
service2.send(copy(request));
}
public void receiveService2(Message message) {
answer2 = message;
}
@Join(steps = { receiveService1, receiveService2 })
@Answer()
public void answer() {
// Do something with answer1 and answer2
return new Message()
}
}
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
While I fully agree to simplify the annotations used,
if you begin to map parameters to properties or xml content,
you end up to jsr181 component.
I have already planned to add annotations a la jaxws to allow
properties to be mapped to parameters in jsr181. A kind of
JBI annotations set for jaxws (compared to the existing SOAP annotations).
But if we begin to handle xml mapping here, we would end
with 2 components with little differences.
For example, the
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
could be further simplified to
@WebMethod
public SomeResponse doSomething(@WebParam SomeRequest foo) { ... }
which is exactly what the jsr181 component do ;)
Note that the jsr181 component should already by able to
handle Source types as a parameter (which would map to
the full payload), and we should be able to add a MessageExchange
parameter which would receive the exchange without disturbing
other parameters (xfire already does that for xfire specific
classes, such as the context).
We need to clearly agree on what we want to show and hide from
the jbi spec in this component. I don't think we need another SE
that do xml marshalling (we'd better enhance the existing one).
The main things to define imho are:
* how to return the answer if using an InOut
* when the pojo acts as a consumer, how will it receive the answer
from an InOut exchange it has previsouly sent
I really think there is something to do with beanflow.
I will try to think about that a bit more.
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Just a bit of brainstorming of ideas here.
I was looking at this example
@ExchangeProcessor(patterns = { MessageExchangePattern.INOUT },
parameterMappings = { ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOutProcessor(MessageExchange me) {
// Do something here
}
@ExchangeProcessor(patterns = { MessageExchangePattern.INONLY,
MessageExchangePattern.ROBUSTINOULY
[jira] Closed: (GERONIMO-1692) Creating Web Connectors using Console
[ http://issues.apache.org/jira/browse/GERONIMO-1692?page=all ] Matt Hogstrom closed GERONIMO-1692. --- Closing per Vamsi's comments Creating Web Connectors using Console - Key: GERONIMO-1692 URL: http://issues.apache.org/jira/browse/GERONIMO-1692 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1 Environment: WinXP SP2, J2SDK 1.4.2_10, Geronimo with Tomcat Reporter: Ilya Kanonirov When creating any type of Web Connector at the Web Server page in the Geronimo Console, the parameter Max Threads is always saved to var/config/config.xml with default value 50. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Prerequisites for Eclipse Plugin v1.1 still mentioned as WTP 1.0.1 on http://geronimo.apache.org/devtools.html
Thank you, will fix shortly.On Aug 21, 2006, at 2:18 AM, Shiva Kumar H R wrote:In the Welcome page for Geronimo Development Tools: http://geronimo.apache.org/devtools.html , the Prerequisites for Eclipse Plugin are still mentioned as "WebTools Platform Runtime 1.01 driver". Please update this to "Web Tools Platform 1.5.0 driver".-- Thx,Shiva -sachin
Re: m2 build - validating
On further investigation of the class incompatibility problem There are two class loaders at work and I think that is the problem; (org.apache.geronimo.kernel.classloader.JarFileClassLoader) [org.apache.geronimo.kernel.classloader.JarFileClassLoader id=org.apache.geronimo.configs/geronimo-gbean-deployer/1.2-SNAPSHOT/ car] (org.apache.geronimo.kernel.classloader.JarFileClassLoader) [org.apache.geronimo.kernel.classloader.JarFileClassLoader id=org.apache.geronimo.configs/webconsole-tomcat/1.2-SNAPSHOT/car] This particular problem goes away when the geronimo-test-ddbean and geronimo-j2ee-deployment_1.1_spec dependencies are moved to the j2ee- deployer. There is now a class not found exception being thrown but that is easily fixed. I'm getting close here and will post a new patch when its done. TTFN, -bd- On Aug 21, 2006, at 7:07 AM, Bill Dudney wrote: Hi David, On Aug 21, 2006, at 1:47 AM, David Jencks wrote: On Aug 20, 2006, at 3:36 PM, Bill Dudney wrote: Hi All, Sorry its taken me so long to get this posted. I had a bunch of travel related headaches thur and fri of last week... I've adopted http://issues.apache.org/jira/browse/GERONIMO-2326 as the JIRA to track the first part of the problem (the datasource deployment stuff) with the current trunk and deployment. I've just attached a patch to the issue that makes a small change to the CAR plugin to include RAR's in the dependencies that are copied into the assembly repository. I am fairly sure this needs to be done as the RAR's end up in the repository on 1.1 and the DatabaseInfo class requires them to be there (albeit with a comment that says EVIL!!! :). However there might be something going on there I'm not aware of. This is basically a wrong thing to do. A dependency on the rar file doesn't do anything except require it to be there, which is bogus since in fact once the car file is generated it doesn't have to be there. The tranql rars (and the activemq rar) are included only for the convenience of users wishing to deploy additional datasources without downloading the rar file themselves. Yes but the Datasource deployment code in trunk depends on the RAR's being in the repository, after spending some time digging around the 1.1.1 code there has been a lot of change in the way this stuff works. Would be great to get trunk and 1.1.1 more in line as it might fix many of the problems. There's been discussion for a really long time about not copying the contents of j2ee artifacts into the car file but instead including them in the classloader in some other way. This sounds nice but is fraught with difficulties such as -how do you make a classloader that reads the jars in a war lib dir inside an ear (nested jar classloading) -or, how do you figure out to unpack the j2ee artifacts in the repo - how do you set up a variety of classloaders that only load some stuff from an ear: e.g. right now an ear classloader doesn't see anything in any web apps. these are all soluble but will take a bunch of work to decide what to do and implement. i'm game to help with the work lets get started. One quick note on this change. The RAR's do end up copied into the CAR (without this change) but, the DatabaseInfo class is expecting (at least) the Derby related RAR's to be directly in the repo. Take a look here http://tinyurl.com/jynnh. the list of *RAR_NAME fields are all used to load the RAR's directly from the repository (http://tinyurl.com/kyhve getRAR static method on line 1036). As the comments says this is rather hard coded. I've not had time to get brain cells focused on the solution. Seems that we should be able to do some kind of maven magic though to find the tranql/tranql-connector/rar instead of hardcoding the path. But again I don't know the history so perhaps there is a reason for the EVIL :) I think that the code for 1.1 is greatly improved over what's in trunk, and I hope aaron ports it soon. Again, using rar's as dependencies is a bad idea. I think something got left out of the m2 build, in the m1 build there was a way to specify that some jars just get put in the repo even though they aren't dependencies of any car. I don't know if this is possible in m2, but the tranql rars are not getting installed at least on my machine. Right the patch to the m2-car-plugin which is in the patch I attached to 2326 fixes this. Essentially the plugin was ignoring RAR files. With the patch it includes RAR's in the repository. So the patch attached to 2326 gets us almost there, but there is still the issue with the IncompatiblClassChangeError coming up. I posted a partial stack trace in the issue. Any pointers, thoughts or other things that could help me track that one down are most welcome. I have to bail for a couple of hours but will be back on line around 7:00MST for a bit.
Re: Thoughts on a JBI POJO Engine
On 8/21/06, Philip Dodds [EMAIL PROTECTED] wrote:
I suppose the more important question is how to implement stateful
POJO's - what demarcates the life of a POJO if it is stateful?
Do we assume that there is an InOut at the begining and therefore when
the POJO replies to the original message is life is complete?
That was my thought. It' s the same thing for a bpel process instance.
The instance is created when receiving an incoming request and can be
persisted for long-running workflows.
I'm
still not sure about stateful POJO's in the ESB?
SCA also defines statefull POJOs. AFAIK, sca defines several scopes:
* stateless
* request
* session
* module
I would like to see what people think in a large context about this?
I think that stateful pojo are about ease of use for the end user.
Of course, you can achieve the same thing using a stateless pojo and
some maps as done in the EIP patterns.
P
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
I guess you could reuse the EJB3 annotations for stateless / stateful
metadata?
On 8/21/06, Philip Dodds [EMAIL PROTECTED] wrote:
The destination annotation looks great ! I assume the main body of the
JBI POJO here is the request/answer annotations.
What I'm not sure about here is the use of fields - so this is a
stateful class? I was thinking that async would be a hybrid of the
destination and the processor?
public class Example1 {
@Destination(uri=service:urn:service, request=myFirstRequest)
private Destination service1;
public void sendRequest() {
service1.send(new Message());
}
@ExchangeProcessor(request=myFirstRequest)
public void sendRequest(@MessageContent Document in) {
// Got response
}
}
The premise being that if you have a async reply then you need to be
stateless?
P
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
Here is something i'd like to be able to do.
This is really pseudo code, and some kind of beanflow oriented
annotations.
This service would simply send two concurrent requests and wait for their
answers to reply to the main request. Of course, this would be much
easier
if you use syncSend but you would not have a real workflow ;)
public class MyWorkflow {
Message request;
Message answer1;
Message answer2;
@Destination(uri=service:urn:service)
private Destination service1;
@Destination(uri=service:urn:service)
private Destination service2;
@Request
@NextStep(steps = { invokeService, invokerService2 }) // This
would auto-fork
public void receiveRequest(Message message) throws Exception {
request = message;
}
@NextStep(step = receiveService1)
public void invokeService1() {
service1.send(copy(request));
// return response to receiveService1
}
public void receiveService1(Message message) {
answer1 = message;
}
@NextStep(step = receiveService2)
public void invokeService2() {
service2.send(copy(request));
}
public void receiveService2(Message message) {
answer2 = message;
}
@Join(steps = { receiveService1, receiveService2 })
@Answer()
public void answer() {
// Do something with answer1 and answer2
return new Message()
}
}
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
While I fully agree to simplify the annotations used,
if you begin to map parameters to properties or xml content,
you end up to jsr181 component.
I have already planned to add annotations a la jaxws to allow
properties to be mapped to parameters in jsr181. A kind of
JBI annotations set for jaxws (compared to the existing SOAP
annotations).
But if we begin to handle xml mapping here, we would end
with 2 components with little differences.
For example, the
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
could be further simplified to
@WebMethod
public SomeResponse doSomething(@WebParam SomeRequest foo) { ... }
which is exactly what the jsr181 component do ;)
Note that the jsr181 component should already by able to
handle Source types as a parameter (which would map to
the full payload), and we should be able to add a MessageExchange
parameter which would receive the exchange without disturbing
other parameters (xfire already does that for xfire specific
classes, such as the context).
We need to clearly agree on what we want to show and hide from
the jbi spec in this component. I don't think we need another SE
that do xml marshalling (we'd better enhance the existing one).
The main things to define imho are:
* how to return the answer if using an InOut
*
Re: [VOTE] Specs organization, versioning, and releasing
+1
On 8/18/06, Jason Dillon [EMAIL PROTECTED] wrote:
PROPOSAL:
1. Each spec will no longer be split up into trunk+branches+tags.
There will instead be one trunk+branches+tags for all specs laid out
as follows:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId-version
specs/branches/
2. Each plugin will continue to have its own version and will be
released independently.
3. The top-level will have it's own version, which will remain
independent. When there is a major configuration change in that pom,
the version will be changed and the pom will be republished.
4. Releasing will be done with the maven release plugin ('mvn
release') and should occur at a stable point after any major change
to a spec module.
5. Change all module directories to match artifactIds.
MOTIVATION:
1. one trunk allows the entire set of specs to be checked out all at
once and built all at once.
* * *
[ ] +1 Allow changes
[ ] 0 No opinion
[ ] -1 No, leave the specs asis (provide rationale)
--jason
Re: Complex Message Transformations
Ditto - on difficult maintance task Here is our solution - http://www.nabble.com/forum/ViewPost.jtp?post=5906613framed=y http://www.nabble.com/forum/ViewPost.jtp?post=5906613framed=y For maintaining it we would like to use a standalone data model - outside servicemix and again Ditto - but I'm also not sure if this would violate the EIP concept. Where does this EIP concept is defined? Regards, Radu. Joern Schimmelpfeng wrote: Hello, I have a question related to the usage of the transformation component. We are trying to attach a complex WS datasource to ServiceMix. Our data souce has round about 50 services with different messages. So this measns that we need to provide 50 XSLT files for transforming a message for a WS request and we need another 50 XSLT files for transforming the responses. Our service assembly today is that way that we use a router slip, two transformers and a WS Client for integrating just one service, so need to replicate that 50 times. As you can imagine this leads to a pretty difficult maintance task and perhaps also to an unecessary high overhead inside ServiceMix. So my question is, if there is a way to enhance the transfomation component so that it is able to select the correct XSLT file itself depending on the message content and direction (e.g Request/Response). I feel myself able to enhance the transformation component that way, but I'm also not sure if this would violate the EIP concept. Please can you give me some guidance how others solved this issue or if a more complex transformation component would be a valuable goal to implement? Thanks for any help on that issue Joern -- View this message in context: http://www.nabble.com/Complex-Message-Transformations-tf2120280.html#a5908675 Sent from the ServiceMix - Dev forum at Nabble.com.
Patches in RTC (Geronimo - 2006-08-21)
Geronimo - Monday, August 21, 2006 5 Patches in RTC [XBEAN-45] Move classloaders to their own module - Assignee: Alan Cabrera - Reporter: Alan Cabrera - Created: Sat Aug 19 11:54:54 PDT 2006 - Updated: Sat Aug 19 11:55:17 PDT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/XBEAN-45 [GERONIMO-2015] Let's replace JKS to PKCS12 key store type - Assignee: Unassigned - Reporter: Nikolay Chugunov - Created: Fri May 12 14:54:17 PDT 2006 - Updated: Thu Aug 10 10:59:06 PDT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2015 [GERONIMO-2332] RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all - Assignee: David Jencks - Reporter: David Jencks - Created: Fri Aug 18 13:13:47 PDT 2006 - Updated: Sun Aug 20 05:43:31 PDT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2332 [GERONIMO-2163] WADI Integration for Jetty - Assignee: Gianny Damour - Reporter: Gianny Damour - Created: Sun Jul 02 14:16:35 PDT 2006 - Updated: Sun Aug 20 03:11:02 PDT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2163 [GERONIMO-2248] Applications portlets: List Parent and Child components against each component - Assignee: Unassigned - Reporter: Vamsavardhana Reddy - Created: Sun Jul 30 08:15:34 PDT 2006 - Updated: Sat Aug 19 10:44:11 PDT 2006 - Votes: 1 1 Donald Woods - http://issues.apache.org/jira/browse/GERONIMO-2248 NOTE: This email is generated and does not constitute and offical vote or vote result. All official voting is done on the dev list. If you do not see your issue here, click the Begin RTC Review link under the Available Workflow Actions of the JIRA page. If you do not see your vote here, click the Vote link under the Operations section of the JIRA page. *** ALL COMMUNITY MEMBERS ARE ENCOURAGED TO VOTE *** Template: http://svn.apache.org/repos/asf/geronimo/gbuild/jirareports/patchesInRtc.vm
Multiple HTTP Component(s)?
The behavior of servicemix-components/http component and the servicemix-http component appear to differ. Can someone explain the difference between these two? Both appear to provide HTTP client/server functionality. In general, what is the status of the components under servicemix-components? We are interested in using rss and jabber as well, and could potentially contribute one or more of our own. I know there was some discussion on minimizing the number of components in the code-base, and to break out component development elsewhere. Was this resolved? -brian Brian ONeill Technical Architect, Gestalt LLC [EMAIL PROTECTED] 215.588.6024 (m)
Re: [VOTE] Specs organization, versioning, and releasing
[X] +1 Allow changes
Joe
Jason Dillon wrote:
PROPOSAL:
1. Each spec will no longer be split up into trunk+branches+tags.
There will instead be one trunk+branches+tags for all specs laid out as
follows:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId-version
specs/branches/
2. Each plugin will continue to have its own version and will be
released independently.
3. The top-level will have it's own version, which will remain
independent. When there is a major configuration change in that pom,
the version will be changed and the pom will be republished.
4. Releasing will be done with the maven release plugin ('mvn
release') and should occur at a stable point after any major change to
a spec module.
5. Change all module directories to match artifactIds.
MOTIVATION:
1. one trunk allows the entire set of specs to be checked out all at
once and built all at once.
* * *
[ ] +1 Allow changes
[ ] 0 No opinion
[ ] -1 No, leave the specs asis (provide rationale)
--jason
[jira] Commented: (GERONIMO-2275) login-domain-principal or realm-principal in default-principal cause deployment errors
[ http://issues.apache.org/jira/browse/GERONIMO-2275?page=comments#action_12429437 ] Vamsavardhana Reddy commented on GERONIMO-2275: --- Verified the fix in branches 1.1. Fix is needed in 1.1.1 too. login-domain-principal or realm-principal in default-principal cause deployment errors -- Key: GERONIMO-2275 URL: http://issues.apache.org/jira/browse/GERONIMO-2275 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment, security Affects Versions: 1.1, 1.1.1 Environment: Win XP, G1.1.1-SNAPSHOT, Tomcat Reporter: Vamsavardhana Reddy Assigned To: Aaron Mulder Fix For: 1.2, 1.1.2 I am getting NullPointerExceptions while deploying web applications with deployment plan having login-domain-principal or realm-principal as default-principal. Stacktrace given below. 18:27:38,580 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.apache.geronimo.security.deployment.SecurityBuilder.buildPrincipal(SecurityBuilder.java:229) at org.apache.geronimo.security.deployment.SecurityBuilder.buildDefaultPrincipal(SecurityBuilder.java:205) at org.apache.geronimo.security.deployment.SecurityBuilder.buildSecurityConfig(SecurityBuilder.java:196) at org.apache.geronimo.security.deployment.SecurityBuilder.buildSecurityConfiguration(SecurityBuilder.java:60) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.initContext(TomcatModuleBuilder.java:260) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder$$FastClassByCGLIB$$6f85ec2c.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$9d0e1f31.initContext(generated) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.initContext(SwitchingModuleBuilder.java:156) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$9d0e1f31.initContext(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:500) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$a8fb27a3.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at
[jira] Updated: (GERONIMO-2275) login-domain-principal or realm-principal in default-principal cause deployment errors
[ http://issues.apache.org/jira/browse/GERONIMO-2275?page=all ] Vamsavardhana Reddy updated GERONIMO-2275: -- Affects Version/s: 1.1.1 login-domain-principal or realm-principal in default-principal cause deployment errors -- Key: GERONIMO-2275 URL: http://issues.apache.org/jira/browse/GERONIMO-2275 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment, security Affects Versions: 1.1, 1.1.1 Environment: Win XP, G1.1.1-SNAPSHOT, Tomcat Reporter: Vamsavardhana Reddy Assigned To: Aaron Mulder Fix For: 1.2, 1.1.2 I am getting NullPointerExceptions while deploying web applications with deployment plan having login-domain-principal or realm-principal as default-principal. Stacktrace given below. 18:27:38,580 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.apache.geronimo.security.deployment.SecurityBuilder.buildPrincipal(SecurityBuilder.java:229) at org.apache.geronimo.security.deployment.SecurityBuilder.buildDefaultPrincipal(SecurityBuilder.java:205) at org.apache.geronimo.security.deployment.SecurityBuilder.buildSecurityConfig(SecurityBuilder.java:196) at org.apache.geronimo.security.deployment.SecurityBuilder.buildSecurityConfiguration(SecurityBuilder.java:60) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.initContext(TomcatModuleBuilder.java:260) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder$$FastClassByCGLIB$$6f85ec2c.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$9d0e1f31.initContext(generated) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.initContext(SwitchingModuleBuilder.java:156) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$9d0e1f31.initContext(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:500) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$a8fb27a3.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at
Re: [VOTE] Specs organization, versioning, and releasing
On Aug 21, 2006, at 6:55 AM, Matt Hogstrom wrote: Jason Dillon wrote: PROPOSAL: 1. Each spec will no longer be split up into trunk+branches+tags. There will instead be one trunk+branches+tags for all specs laid out as follows: specs/trunk/pom.xml specs/trunk/artifactId specs/tags/artifactId-version specs/branches/ What is the layout for branches? Right now it is the major version with all the specs underneath it. For instance, there is 1_1, 1_1_1 (not sure why we use _'s here and .'s elsewhere). branches would follow the same layout like: specs/branches/geronimo-activation_1.0.2/1_1 as opposed to specs/ branches/1_1/geronimo-activation_1.0.2. Or do you intend to leave branches alone? I don't plan to touch branches for now... if I did do something I would change '_' to '.' I think that we need to evaluate how to best organize branches based on the new release scheme when it comes time to need a branch. --jason
[jira] Commented: (GERONIMO-2332) RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all
[ http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12429452 ] David Jencks commented on GERONIMO-2332: Theres a fairly serious problem with this proposal in that it involves generating source code that does not then have the required apache headers and checking it into svn. Is there a way to use m2 to change the headers on all the files? I don't think john's minor point about the possibility of getting an empty jar is relevant since whoever is setting this up will check the generated files into svn so that no one else has to run the generate source profile (at least until sun updates the schemas and we decide to use updated versions). As this points out another problem is that we have no record of how we got the generated classes: sun has fixed problems in the schemas in the past without changing anything that we can identify from the generated code. As a result of these factors I'm -0.99 on this proposal at the moment. RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all Key: GERONIMO-2332 URL: http://issues.apache.org/jira/browse/GERONIMO-2332 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: specs Affects Versions: 1.2, 1.1.1, 1.1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2, 1.1.1, 1.1.2 Attachments: GERONIMO-2332-1.1.patch, GERONIMO-2332-openejb-2.1.patch, GERONIMO-2332-trunk.patch, geronimo-schema_1.4_spec-generated-src.zip, geronimo-schema_1.4_spec-src.zip See GERONIMO-2307. It seems that the option with the least legal exposure is to not distribute and sun schema files and not have any in our svn. This is a proposed spec module that uses a m2 profile to pull the schemas from suns website (where they are freely available), run xmlbeans on them, and remove the copies of the schemas that xmlbeasn helpfully tries to include in the output. We can then check this stuff into svn. A normal non-profile build then just builds these sources into a jar. We can replace the xmlbeans step in j2ee-schema with a geronimo dependency on this new spec jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: RTC don't ship any sun schemas or dtds - GERONIMO-2332
I've thought about this some more and have some major reservations about this approach. - The generated code wont have apache headers, so we can't actually check in into svn. There might be a way to fix this with a script of some kind. - More seriously, this will eliminate traceability to the source schema. Sun has in the past fixed errors in the schema without changing anything that can be recognized from the generated source. (I think they changed a date in a comment). This is a major problem IMNSHO. So, I think we need to keep the source schemas in svn. One way to do this would be to move this module into the tck project and publish the binary jar from there. If we found a way to change the headers we might be able to publish a source jar too. So, I'm -0.999 on this proposal at the moment... I think we need to find a way to get the source schemas into svn. thanks david jencks On Aug 19, 2006, at 9:49 AM, David Jencks wrote: GERONIMO-2332 didn't show up in the list of RTC issues sent out today, and I don't see the Begin RTC Review button any ideas? Anyway, please vote so we can get this taken care of. thanks david jencks On Aug 18, 2006, at 4:15 PM, David Jencks wrote: I've implemented the proposal to not ship any sun schemas or dtds to avoid licensing questions and to check in the xmlbeans generated files. Please vote promptly. I've provided patches for trunk and branches/1.1. I expect that the 1.1 patch should work for 1.1.1 also, I'm hoping someone else will check for me. Before releasing 1.1.1 including this work we'd have to release the proposed new specs jar with the generated xmlbeans classes in it: this would involve changing the version number to 1.0 in several places. http://issues.apache.org/jira/browse/GERONIMO-2332 thanks david jencks
[jira] Created: (AMQ-888) Licence headers missing from several source files.
Licence headers missing from several source files.
--
Key: AMQ-888
URL: https://issues.apache.org/activemq/browse/AMQ-888
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 4.0
Reporter: Hiram Chirino
Assigned To: Hiram Chirino
Fix For: 4.1, 4.0.2
robert burrell donkin reported:
{quote}
missing license headers from some of the files i checked at random
gives me concerns. for example:
maven-bundle-plugin/src/main/java/org/apache/activemq/maven/BundleMojo.java
activemq-web-demo worries me: there are a lot of files without license
headers and some which have them were not created at the ASF (which is
ok but gives me concerns about the rest).
i would like to see the issue of licenses in the source tidied up
before this release ships. i haven't gone through every file but IMO
this needs to be done.
{quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-888) Licence headers missing from several source files.
[ https://issues.apache.org/activemq/browse/AMQ-888?page=all ]
Hiram Chirino updated AMQ-888:
--
Attachment: findunlicensed.pl
Using the attached perl script to find the source files that do not have a
licence header attached.
Licence headers missing from several source files.
--
Key: AMQ-888
URL: https://issues.apache.org/activemq/browse/AMQ-888
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 4.0
Reporter: Hiram Chirino
Assigned To: Hiram Chirino
Fix For: 4.1, 4.0.2
Attachments: findunlicensed.pl
robert burrell donkin reported:
{quote}
missing license headers from some of the files i checked at random
gives me concerns. for example:
maven-bundle-plugin/src/main/java/org/apache/activemq/maven/BundleMojo.java
activemq-web-demo worries me: there are a lot of files without license
headers and some which have them were not created at the ASF (which is
ok but gives me concerns about the rest).
i would like to see the issue of licenses in the source tidied up
before this release ships. i haven't gone through every file but IMO
this needs to be done.
{quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: RTC don't ship any sun schemas or dtds - GERONIMO-2332
Why not publish the src jar in addition to the binary? -dain On Aug 21, 2006, at 9:56 AM, David Jencks wrote: I've thought about this some more and have some major reservations about this approach. - The generated code wont have apache headers, so we can't actually check in into svn. There might be a way to fix this with a script of some kind. - More seriously, this will eliminate traceability to the source schema. Sun has in the past fixed errors in the schema without changing anything that can be recognized from the generated source. (I think they changed a date in a comment). This is a major problem IMNSHO. So, I think we need to keep the source schemas in svn. One way to do this would be to move this module into the tck project and publish the binary jar from there. If we found a way to change the headers we might be able to publish a source jar too. So, I'm -0.999 on this proposal at the moment... I think we need to find a way to get the source schemas into svn. thanks david jencks On Aug 19, 2006, at 9:49 AM, David Jencks wrote: GERONIMO-2332 didn't show up in the list of RTC issues sent out today, and I don't see the Begin RTC Review button any ideas? Anyway, please vote so we can get this taken care of. thanks david jencks On Aug 18, 2006, at 4:15 PM, David Jencks wrote: I've implemented the proposal to not ship any sun schemas or dtds to avoid licensing questions and to check in the xmlbeans generated files. Please vote promptly. I've provided patches for trunk and branches/1.1. I expect that the 1.1 patch should work for 1.1.1 also, I'm hoping someone else will check for me. Before releasing 1.1.1 including this work we'd have to release the proposed new specs jar with the generated xmlbeans classes in it: this would involve changing the version number to 1.0 in several places. http://issues.apache.org/jira/browse/GERONIMO-2332 thanks david jencks
[jira] Commented: (AMQ-888) Licence headers missing from several source files.
[
https://issues.apache.org/activemq/browse/AMQ-888?page=comments#action_36818 ]
Hiram Chirino commented on AMQ-888:
---
added a bunch of licence headers
* in trunk in rev 433286
* in 4.0 branch in rev 433295
Licence headers missing from several source files.
--
Key: AMQ-888
URL: https://issues.apache.org/activemq/browse/AMQ-888
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 4.0
Reporter: Hiram Chirino
Assigned To: Hiram Chirino
Fix For: 4.1, 4.0.2
Attachments: findunlicensed.pl
robert burrell donkin reported:
{quote}
missing license headers from some of the files i checked at random
gives me concerns. for example:
maven-bundle-plugin/src/main/java/org/apache/activemq/maven/BundleMojo.java
activemq-web-demo worries me: there are a lot of files without license
headers and some which have them were not created at the ASF (which is
ok but gives me concerns about the rest).
i would like to see the issue of licenses in the source tidied up
before this release ships. i haven't gone through every file but IMO
this needs to be done.
{quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: File based AutorizationMap
Actually, a text based map would be redundant if there's an XML map already in place. I can't seem to find the XML map anywhere. Could you tell me where it is? Thanks, Sepand On 8/21/06, James Strachan [EMAIL PROTECTED] wrote: Sounds good to me :). We've got the XML based one but by all means write a simple text based one instead. incidentally it might help to reduce the amount of code to reuse a properties file? e.g. queue://foo.bar = group1, group2 the left hand side can be turned into an ActiveMQ destination using this helper method... http://incubator.apache.org/activemq/maven/activemq-core/apidocs/org/apache/activemq/command/ActiveMQDestination.html#createDestination(java.lang.String,%20byte) Looking forward to your patches :) On 8/18/06, Sepand M [EMAIL PROTECTED] wrote: To take it a bit further, I'd like to create something like a TextBasedAuthorizationMap and have most of the functionality in there. This would allow for different back-ends (like a database) to be attached. On 8/18/06, Sepand M [EMAIL PROTECTED] wrote: Hi everyone, I've been looking through the code and have noticed that the only AuthorizationMaps are DefaultAuthorizationMap and SimpleAuthorizationMap. And neither of these allows for text-based configuration of access. I'm wondering if such a thing exists and if I should create one if it doesn't. I'm thinking the config file would be something like: Queue:::group:admins Queue:USERS::group:users Topic:::group:admins ... where each line is an addition to the map and each line is made of: Queue/Topic:destination name::group/user :group/user name (the delimitor choice is open for debate) Anyone agree? -- James --- http://radio.weblogs.com/0112098/
Re: File based AutorizationMap
On 8/21/06, Sepand M [EMAIL PROTECTED] wrote: Actually, a text based map would be redundant if there's an XML map already in place. I can't seem to find the XML map anywhere. Could you tell me where it is? See the exampe here... http://incubator.apache.org/activemq/security.html -- James --- http://radio.weblogs.com/0112098/
[jira] Commented: (GERONIMO-2332) RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all
[ http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12429472 ] Alan Cabrera commented on GERONIMO-2332: Agreed. This is starting to look like the tail is wagging the dog. What is the problem that we are trying to solve? Shall we bring this up on the dev list? RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all Key: GERONIMO-2332 URL: http://issues.apache.org/jira/browse/GERONIMO-2332 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: specs Affects Versions: 1.2, 1.1.1, 1.1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2, 1.1.1, 1.1.2 Attachments: GERONIMO-2332-1.1.patch, GERONIMO-2332-openejb-2.1.patch, GERONIMO-2332-trunk.patch, geronimo-schema_1.4_spec-generated-src.zip, geronimo-schema_1.4_spec-src.zip See GERONIMO-2307. It seems that the option with the least legal exposure is to not distribute and sun schema files and not have any in our svn. This is a proposed spec module that uses a m2 profile to pull the schemas from suns website (where they are freely available), run xmlbeans on them, and remove the copies of the schemas that xmlbeasn helpfully tries to include in the output. We can then check this stuff into svn. A normal non-profile build then just builds these sources into a jar. We can replace the xmlbeans step in j2ee-schema with a geronimo dependency on this new spec jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r433304 - /geronimo/xbean/branches/colossus/xbean-naming/
You know you can add this to ~/.subversion/config so you don't need to add this to all directories... right? --jason On Aug 21, 2006, at 10:41 AM, [EMAIL PROTECTED] wrote: Author: dain Date: Mon Aug 21 10:41:41 2006 New Revision: 433304 URL: http://svn.apache.org/viewvc?rev=433304view=rev Log: set svn:ignore Modified: geronimo/xbean/branches/colossus/xbean-naming/ (props changed) Propchange: geronimo/xbean/branches/colossus/xbean-naming/ -- --- svn:ignore (added) +++ svn:ignore Mon Aug 21 10:41:41 2006 @@ -0,0 +1,10 @@ + +*.iml +*.ipr +*.iws +.project +.classpath +maven.log +junit*.properties +target +.wtpmodules
GERONIMO-1526
For the following JIRA, where all the module builders assume a jar file, what if we change all methods that take a JarFile to something like the following?public interface IDeployableModule { public String getURI(); public File getRoot(); public File[] getResourceFolders(); public File[] getClassesFolders(); public boolean isBinary(); public IDeployableModule[] getChildModules();}-sachin
Re: wiki.apache.org/geronimo going out of production
Just nuke the old wiki and be done with it already... :-\ --jason On Aug 21, 2006, at 6:44 AM, Paul McMahan wrote: Good idea Cameron. On 8/20/06, Cameron Braid [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 building geronimoPaul McMahan wrote: +1 I'm all in favor of eliminating the obsolete wiki sites. Right now when I google geronimo wiki or building geronimo it comes back with links to the MoinMoin wiki, which ain't good. It may be a good idea to put a temporary redirector from the old MoinMoin wiki's domain, redirecting all urls to a page in confluence that explains that the content has been moved. Then, after a few weeks, when the spiders have updated their indexes, the domain could be decomissioned. Cameron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE6R/Dbbjq9wHLQrIRArtRAJ9g5SghV363uXZyBOgqBRy96ebMnACeOgJr +GT/SGVxi/giyg0Z9cvOi4Y= =Y79o -END PGP SIGNATURE-
Re: RTC don't ship any sun schemas or dtds - GERONIMO-2332
Can we go back to the root of the problem which is the distribution of the schemas? This may have already been put to bed but, can't we get permission from Sun to distribute these puppies? Regards, Alan Dain Sundstrom wrote: Why not publish the src jar in addition to the binary? -dain On Aug 21, 2006, at 9:56 AM, David Jencks wrote: I've thought about this some more and have some major reservations about this approach. - The generated code wont have apache headers, so we can't actually check in into svn. There might be a way to fix this with a script of some kind. - More seriously, this will eliminate traceability to the source schema. Sun has in the past fixed errors in the schema without changing anything that can be recognized from the generated source. (I think they changed a date in a comment). This is a major problem IMNSHO. So, I think we need to keep the source schemas in svn. One way to do this would be to move this module into the tck project and publish the binary jar from there. If we found a way to change the headers we might be able to publish a source jar too. So, I'm -0.999 on this proposal at the moment... I think we need to find a way to get the source schemas into svn. thanks david jencks On Aug 19, 2006, at 9:49 AM, David Jencks wrote: GERONIMO-2332 didn't show up in the list of RTC issues sent out today, and I don't see the Begin RTC Review button any ideas? Anyway, please vote so we can get this taken care of. thanks david jencks On Aug 18, 2006, at 4:15 PM, David Jencks wrote: I've implemented the proposal to not ship any sun schemas or dtds to avoid licensing questions and to check in the xmlbeans generated files. Please vote promptly. I've provided patches for trunk and branches/1.1. I expect that the 1.1 patch should work for 1.1.1 also, I'm hoping someone else will check for me. Before releasing 1.1.1 including this work we'd have to release the proposed new specs jar with the generated xmlbeans classes in it: this would involve changing the version number to 1.0 in several places. http://issues.apache.org/jira/browse/GERONIMO-2332 thanks david jencks
[jira] Commented: (GERONIMO-2332) RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all
[ http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12429479 ] Matt Hogstrom commented on GERONIMO-2332: - I like this approach but it sounds like there are some kinks to be worked out. What if we re-type the specs by hand and then check them into branches/1.1.1. We'll cary that notion forward for the 1.1.x tree and address this larger problem in trunk. Thoughts? RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all Key: GERONIMO-2332 URL: http://issues.apache.org/jira/browse/GERONIMO-2332 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: specs Affects Versions: 1.2, 1.1.1, 1.1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2, 1.1.1, 1.1.2 Attachments: GERONIMO-2332-1.1.patch, GERONIMO-2332-openejb-2.1.patch, GERONIMO-2332-trunk.patch, geronimo-schema_1.4_spec-generated-src.zip, geronimo-schema_1.4_spec-src.zip See GERONIMO-2307. It seems that the option with the least legal exposure is to not distribute and sun schema files and not have any in our svn. This is a proposed spec module that uses a m2 profile to pull the schemas from suns website (where they are freely available), run xmlbeans on them, and remove the copies of the schemas that xmlbeasn helpfully tries to include in the output. We can then check this stuff into svn. A normal non-profile build then just builds these sources into a jar. We can replace the xmlbeans step in j2ee-schema with a geronimo dependency on this new spec jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
4.0.1 Consumer hangs while stopping
I ran a test where one publisher sent 10 messages to a topic with 500 connected subscribers (run as 500 threads from a single VM, but in a different VM than the producer). Each consumer knows how many messages to expect, and tries to shut down once it receives the last message. The consumers were registered using MessageConsumer.setMessageListener(...) At the end of the run, the consumer VM didn't shut down. Looking at a thread dump, it seems like a couple of the consumers are blocked on I/O and aren't going to shut down (though the majority did shut down). I've confirmed that all the consumers received all the messages they were expecting, and did attempt to shut down (you can see ActiveMQSession.close in the thread dump). Any suggestions to avoid this? Thanks, Aaron ActiveMQ Session Task daemon prio=1 tid=0x082a1cd0 nid=0x3723 in Object.wait() [0x7bac5000..0x7bac6050] at java.lang.Object.wait(Native Method) - waiting on 0x97b91310 (a org.apache.activemq.thread.PooledTaskRunner$1) at java.lang.Object.wait(Object.java:474) at org.apache.activemq.thread.PooledTaskRunner.shutdown(PooledTaskRunner.java:88) - locked 0x97b91310 (a org.apache.activemq.thread.PooledTaskRunner$1) at org.apache.activemq.ActiveMQSessionExecutor.stop(ActiveMQSessionExecutor.java:113) at org.apache.activemq.ActiveMQSession.dispose(ActiveMQSession.java:539) - locked 0x9612ff30 (a org.apache.activemq.ActiveMQSession) at org.apache.activemq.ActiveMQSession.close(ActiveMQSession.java:516) at org.activemq.tests.ActiveMQClient.close(ActiveMQClient.java:77) at org.activemq.tests.Consumer$2$1.onMessage(Consumer.java:76) at org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:795) at org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:96) at org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:149) at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:110) at org.apache.activemq.thread.PooledTaskRunner.access$100(PooledTaskRunner.java:25) at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) ActiveMQ Session Task daemon prio=1 tid=0x0832fb50 nid=0x370e in Object.wait() [0x7c4d9000..0x7c4d9e50] at java.lang.Object.wait(Native Method) - waiting on 0x97c56170 (a org.apache.activemq.thread.PooledTaskRunner$1) at java.lang.Object.wait(Object.java:474) at org.apache.activemq.thread.PooledTaskRunner.shutdown(PooledTaskRunner.java:88) - locked 0x97c56170 (a org.apache.activemq.thread.PooledTaskRunner$1) at org.apache.activemq.ActiveMQSessionExecutor.stop(ActiveMQSessionExecutor.java:113) at org.apache.activemq.ActiveMQSession.dispose(ActiveMQSession.java:539) - locked 0x96c3a0a8 (a org.apache.activemq.ActiveMQSession) at org.apache.activemq.ActiveMQSession.close(ActiveMQSession.java:516) at org.activemq.tests.ActiveMQClient.close(ActiveMQClient.java:77) at org.activemq.tests.Consumer$2$1.onMessage(Consumer.java:76) at org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:795) at org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:96) at org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:149) at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:110) at org.apache.activemq.thread.PooledTaskRunner.access$100(PooledTaskRunner.java:25) at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) ActiveMQ Transport: tcp://localhost/127.0.0.1:61616 prio=1 tid=0x8185b4f0 nid=0x3623 runnable [0x7e498000..0x7e498e50] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:48) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:55) at java.io.DataInputStream.readInt(DataInputStream.java:353) at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:274) at
[jira] Commented: (GERONIMO-2332) RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all
[ http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12429482 ] Alan Cabrera commented on GERONIMO-2332: Wow, if we could do this and it will fly with Sun, then this is *THE* way to go. RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all Key: GERONIMO-2332 URL: http://issues.apache.org/jira/browse/GERONIMO-2332 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: specs Affects Versions: 1.2, 1.1.1, 1.1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2, 1.1.1, 1.1.2 Attachments: GERONIMO-2332-1.1.patch, GERONIMO-2332-openejb-2.1.patch, GERONIMO-2332-trunk.patch, geronimo-schema_1.4_spec-generated-src.zip, geronimo-schema_1.4_spec-src.zip See GERONIMO-2307. It seems that the option with the least legal exposure is to not distribute and sun schema files and not have any in our svn. This is a proposed spec module that uses a m2 profile to pull the schemas from suns website (where they are freely available), run xmlbeans on them, and remove the copies of the schemas that xmlbeasn helpfully tries to include in the output. We can then check this stuff into svn. A normal non-profile build then just builds these sources into a jar. We can replace the xmlbeans step in j2ee-schema with a geronimo dependency on this new spec jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: wiki.apache.org/geronimo going out of production
On 8/21/06, Jason Dillon [EMAIL PROTECTED] wrote: Just nuke the old wiki and be done with it already... +1 (no need to keep it until crawlers or any spiders or so will have the links updated) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: GERONIMO-1526
Minus the "I" prefix... seems okay. What about using URLs instead of Files?--jasonOn Aug 21, 2006, at 10:53 AM, Sachin Patel wrote:For the following JIRA, where all the module builders assume a jar file, what if we change all methods that take a JarFile to something like the following?public interface IDeployableModule { public String getURI(); public File getRoot(); public File[] getResourceFolders(); public File[] getClassesFolders(); public boolean isBinary(); public IDeployableModule[] getChildModules();}-sachin
Re: 4.0.1 Consumer hangs while stopping
On 8/21/06, Aaron Mulder [EMAIL PROTECTED] wrote: I ran a test where one publisher sent 10 messages to a topic with 500 connected subscribers (run as 500 threads from a single VM, but in a different VM than the producer). Each consumer knows how many messages to expect, and tries to shut down once it receives the last message. The consumers were registered using MessageConsumer.setMessageListener(...) At the end of the run, the consumer VM didn't shut down. Looking at a thread dump, it seems like a couple of the consumers are blocked on I/O and aren't going to shut down (though the majority did shut down). I've confirmed that all the consumers received all the messages they were expecting, and did attempt to shut down (you can see ActiveMQSession.close in the thread dump). Any suggestions to avoid this? Thanks, Aaron ActiveMQ Session Task daemon prio=1 tid=0x082a1cd0 nid=0x3723 in Object.wait() [0x7bac5000..0x7bac6050] at java.lang.Object.wait(Native Method) - waiting on 0x97b91310 (a org.apache.activemq.thread.PooledTaskRunner$1) at java.lang.Object.wait(Object.java:474) at org.apache.activemq.thread.PooledTaskRunner.shutdown(PooledTaskRunner.java:88) - locked 0x97b91310 (a org.apache.activemq.thread.PooledTaskRunner$1) at org.apache.activemq.ActiveMQSessionExecutor.stop(ActiveMQSessionExecutor.java:113) at org.apache.activemq.ActiveMQSession.dispose(ActiveMQSession.java:539) - locked 0x9612ff30 (a org.apache.activemq.ActiveMQSession) at org.apache.activemq.ActiveMQSession.close(ActiveMQSession.java:516) at org.activemq.tests.ActiveMQClient.close(ActiveMQClient.java:77) at org.activemq.tests.Consumer$2$1.onMessage(Consumer.java:76) at org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:795) It doesn't look too good closing the session inside a MessageListener - any chance you could change that code? - James --- http://radio.weblogs.com/0112098/
[jira] Resolved: (GERONIMO-2327) Need to encode colons for JACC web permissions
[ http://issues.apache.org/jira/browse/GERONIMO-2327?page=all ] Alan Cabrera resolved GERONIMO-2327. Resolution: Fixed Need to encode colons for JACC web permissions -- Key: GERONIMO-2327 URL: http://issues.apache.org/jira/browse/GERONIMO-2327 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1.1, 1.2 Reporter: Alan Cabrera Assigned To: Alan Cabrera Fix For: 1.1.1, 1.2 Need to encode colons for JACC web permissions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Classloading branch
I prefer we don't use a plural for a module or package name, so how about we call the module xbean-classloader? -dain On Aug 20, 2006, at 12:13 PM, Guillaume Nodet wrote: Should the xbean-classloaders module have a package named org.apache.xbean.classloaders instead of keeping the old one org.apache.xbean.server.classloader It would break compatibility, but if it deserved a new module ... On 8/20/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: Alan D. Cabrera wrote: I'm going to take a crack at breaking out the classloading code into a separate module. Should be simple enough. I'll solicit comments when I'm done and we can do an RTC vote afterwards, if all goes well. Done, xbean/branches/classloader. Comments anyone? Regards, Alan -- Cheers, Guillaume Nodet
[jira] Updated: (GERONIMO-2326) unable to deploy a database pool
[ http://issues.apache.org/jira/browse/GERONIMO-2326?page=all ] Alan Cabrera updated GERONIMO-2326: --- Fix Version/s: 1.1.2 1.2 Affects Version/s: 1.1.2 Assignee: Alan Cabrera unable to deploy a database pool Key: GERONIMO-2326 URL: http://issues.apache.org/jira/browse/GERONIMO-2326 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2, 1.1.2 Reporter: Bill Dudney Assigned To: Alan Cabrera Fix For: 1.1.2, 1.2 Attachments: 2326-deploy-datasource.patch Trying to deploy a jdbc datasource leads to a blank screen and the following stack trace in the log. The issue appears to be that URLPatternSpec does not like the URL generated by DatabasePoolPortlet from the info found in the DatabaseInfo.ALL_DATABASES array. java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebUserDataPermission.init(WebUserDataPermission.java:83) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasUserDataPermission(TomcatGeronimoRealm.java:131) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:460) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:322) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:552) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: RTC don't ship any sun schemas or dtds - GERONIMO-2332
Sure if you want to wait 0-6 months for a response. -dain On Aug 21, 2006, at 11:00 AM, Alan D. Cabrera wrote: Can we go back to the root of the problem which is the distribution of the schemas? This may have already been put to bed but, can't we get permission from Sun to distribute these puppies? Regards, Alan Dain Sundstrom wrote: Why not publish the src jar in addition to the binary? -dain On Aug 21, 2006, at 9:56 AM, David Jencks wrote: I've thought about this some more and have some major reservations about this approach. - The generated code wont have apache headers, so we can't actually check in into svn. There might be a way to fix this with a script of some kind. - More seriously, this will eliminate traceability to the source schema. Sun has in the past fixed errors in the schema without changing anything that can be recognized from the generated source. (I think they changed a date in a comment). This is a major problem IMNSHO. So, I think we need to keep the source schemas in svn. One way to do this would be to move this module into the tck project and publish the binary jar from there. If we found a way to change the headers we might be able to publish a source jar too. So, I'm -0.999 on this proposal at the moment... I think we need to find a way to get the source schemas into svn. thanks david jencks On Aug 19, 2006, at 9:49 AM, David Jencks wrote: GERONIMO-2332 didn't show up in the list of RTC issues sent out today, and I don't see the Begin RTC Review button any ideas? Anyway, please vote so we can get this taken care of. thanks david jencks On Aug 18, 2006, at 4:15 PM, David Jencks wrote: I've implemented the proposal to not ship any sun schemas or dtds to avoid licensing questions and to check in the xmlbeans generated files. Please vote promptly. I've provided patches for trunk and branches/1.1. I expect that the 1.1 patch should work for 1.1.1 also, I'm hoping someone else will check for me. Before releasing 1.1.1 including this work we'd have to release the proposed new specs jar with the generated xmlbeans classes in it: this would involve changing the version number to 1.0 in several places. http://issues.apache.org/jira/browse/GERONIMO-2332 thanks david jencks
Re: 4.0.1 Consumer hangs while stopping
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote: It doesn't look too good closing the session inside a MessageListener - any chance you could change that code? OK, I tried registering the JMS objects with a different thread that will then wake up and close them, and that seems to work fine. Thanks, Aaron
Re: 4.0.1 Consumer hangs while stopping
Great, thanks for letting us know. On 8/21/06, Aaron Mulder [EMAIL PROTECTED] wrote: On 8/21/06, James Strachan [EMAIL PROTECTED] wrote: It doesn't look too good closing the session inside a MessageListener - any chance you could change that code? OK, I tried registering the JMS objects with a different thread that will then wake up and close them, and that seems to work fine. Thanks, Aaron -- James --- http://radio.weblogs.com/0112098/
Re: GERONIMO-1526
On Aug 21, 2006, at 2:18 PM, Jason Dillon wrote:Minus the "I" prefix... seems okay. What about using URLs instead of Files?Yep, agree.--jasonOn Aug 21, 2006, at 10:53 AM, Sachin Patel wrote:For the following JIRA, where all the module builders assume a jar file, what if we change all methods that take a JarFile to something like the following?public interface IDeployableModule { public String getURI(); public File getRoot(); public File[] getResourceFolders(); public File[] getClassesFolders(); public boolean isBinary(); public IDeployableModule[] getChildModules();}-sachin -sachin
XBean site using new G-theme
I've just finished the initial re-theme-ification of the XBean site to use the AutoExport template we are using for GMOxSITE. It will eventually make it to: http://geronimo.apache.org/xbean but for now you can see what it looks like here: http://xbean.goopen.org * * * A few things... I had to drop some of the tabs, only using Home and Downloads right now. Since these are images, I can not easily pull content from the wiki to add arbitrary tabs. I will look into fixing, creating border images, so we can drop text into the boxes. I also could not figure out a nice looking way to add the XBean title to the main banner... seems that it does not fit well into the layout. Probably best to get a new graphic that incorporates the G and XBean elements. Might need to get some help from Epiq to get a updated layout that allows use to use the same theme across sub-projects the main site. * * * Take a peek and let me know what you folks think. --jason
Re: XBean site using new G-theme
Oh, I also dropped the search for now... its not very good at actually searching the content of the space :-( --jason On Aug 21, 2006, at 12:07 PM, Jason Dillon wrote: I've just finished the initial re-theme-ification of the XBean site to use the AutoExport template we are using for GMOxSITE. It will eventually make it to: http://geronimo.apache.org/xbean but for now you can see what it looks like here: http://xbean.goopen.org * * * A few things... I had to drop some of the tabs, only using Home and Downloads right now. Since these are images, I can not easily pull content from the wiki to add arbitrary tabs. I will look into fixing, creating border images, so we can drop text into the boxes. I also could not figure out a nice looking way to add the XBean title to the main banner... seems that it does not fit well into the layout. Probably best to get a new graphic that incorporates the G and XBean elements. Might need to get some help from Epiq to get a updated layout that allows use to use the same theme across sub- projects the main site. * * * Take a peek and let me know what you folks think. --jason
Re: Classloading branch
Yeah, it sounds better. On 8/21/06, Dain Sundstrom [EMAIL PROTECTED] wrote: I prefer we don't use a plural for a module or package name, so how about we call the module xbean-classloader? -dain On Aug 20, 2006, at 12:13 PM, Guillaume Nodet wrote: Should the xbean-classloaders module have a package named org.apache.xbean.classloaders instead of keeping the old one org.apache.xbean.server.classloader It would break compatibility, but if it deserved a new module ... On 8/20/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: Alan D. Cabrera wrote: I'm going to take a crack at breaking out the classloading code into a separate module. Should be simple enough. I'll solicit comments when I'm done and we can do an RTC vote afterwards, if all goes well. Done, xbean/branches/classloader. Comments anyone? Regards, Alan -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: GERONIMO-1526
I'd also drop the public modifier for methods... its redundant ;-)--jasonOn Aug 21, 2006, at 10:53 AM, Sachin Patel wrote:For the following JIRA, where all the module builders assume a jar file, what if we change all methods that take a JarFile to something like the following?public interface IDeployableModule { public String getURI(); public File getRoot(); public File[] getResourceFolders(); public File[] getClassesFolders(); public boolean isBinary(); public IDeployableModule[] getChildModules();}-sachin
[jira] Commented: (GERONIMO-2332) RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all
[ http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12429499 ] David Jencks commented on GERONIMO-2332: I don't think we can type the schemas up without typos that will change the meaning compared to the sun schemas. I realized that my xml comparison tool only compares documents where the elements are all in the same order, and I'm not about to try to write one that can decide if two schemas are equivalent. RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all Key: GERONIMO-2332 URL: http://issues.apache.org/jira/browse/GERONIMO-2332 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: specs Affects Versions: 1.2, 1.1.1, 1.1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2, 1.1.1, 1.1.2 Attachments: GERONIMO-2332-1.1.patch, GERONIMO-2332-openejb-2.1.patch, GERONIMO-2332-trunk.patch, geronimo-schema_1.4_spec-generated-src.zip, geronimo-schema_1.4_spec-src.zip See GERONIMO-2307. It seems that the option with the least legal exposure is to not distribute and sun schema files and not have any in our svn. This is a proposed spec module that uses a m2 profile to pull the schemas from suns website (where they are freely available), run xmlbeans on them, and remove the copies of the schemas that xmlbeasn helpfully tries to include in the output. We can then check this stuff into svn. A normal non-profile build then just builds these sources into a jar. We can replace the xmlbeans step in j2ee-schema with a geronimo dependency on this new spec jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: XBean site using new G-theme
Amazing ! Thx a lot, Jason. On 8/21/06, Jason Dillon [EMAIL PROTECTED] wrote: I've just finished the initial re-theme-ification of the XBean site to use the AutoExport template we are using for GMOxSITE. It will eventually make it to: http://geronimo.apache.org/xbean but for now you can see what it looks like here: http://xbean.goopen.org * * * A few things... I had to drop some of the tabs, only using Home and Downloads right now. Since these are images, I can not easily pull content from the wiki to add arbitrary tabs. I will look into fixing, creating border images, so we can drop text into the boxes. I also could not figure out a nice looking way to add the XBean title to the main banner... seems that it does not fit well into the layout. Probably best to get a new graphic that incorporates the G and XBean elements. Might need to get some help from Epiq to get a updated layout that allows use to use the same theme across sub-projects the main site. * * * Take a peek and let me know what you folks think. --jason -- Cheers, Guillaume Nodet
Re: XBean site using new G-theme
On 8/21/06, Jason Dillon [EMAIL PROTECTED] wrote: I've just finished the initial re-theme-ification of the XBean site to use the AutoExport template we are using for GMOxSITE. It will eventually make it to: http://geronimo.apache.org/xbean but for now you can see what it looks like here: http://xbean.goopen.org * * * A few things... I had to drop some of the tabs, only using Home and Downloads right now. Since these are images, I can not easily pull content from the wiki to add arbitrary tabs. I will look into fixing, creating border images, so we can drop text into the boxes. I also could not figure out a nice looking way to add the XBean title to the main banner... seems that it does not fit well into the layout. Probably best to get a new graphic that incorporates the G and XBean elements. Might need to get some help from Epiq to get a updated layout that allows use to use the same theme across sub-projects the main site. * * * Take a peek and let me know what you folks think. Nice work, Jason! Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
Re: Where should g. jee5 stuff go?
You can put it here for now http://svn.apache.org/repos/asf/geronimo/ specs/branches/jee5_exp/ When Jason's done with the new spec layout, I'll be working on moving those in to trunk. -David On Aug 20, 2006, at 5:41 PM, David Jencks wrote: I've implemented the jta 1.1 feature locally and want to do the ejb 3/jpa container managed persistence stuff. Where should I put it? jta 1.1 adds one interface to jta 1.0.1B with AFAICT no other changes (I haven't actually been able to locate the spec, just the javadoc). Anyone know if we can run the j2ee 1.4 tck using jee5 spec jars? If not, I think we'll have to do something like copy the tm module to somewhere else for jee5 work. Maybe a copy of tm in sandbox? I worry about getting out of sync with m2 related reorganizations. My first guess at the CMP is to do most of the work in the tm module. but I might change my mind at any time. thanks david jencks
Re: GERONIMO-1526
Some java docs would help me understand what these methods are
supposed to do.
-dain
On Aug 21, 2006, at 10:53 AM, Sachin Patel wrote:
For the following JIRA, where all the module builders assume a jar
file, what if we change all methods that take a JarFile to
something like the following?
public interface IDeployableModule {
public String getURI();
public File getRoot();
public File[] getResourceFolders();
public File[] getClassesFolders();
public boolean isBinary();
public IDeployableModule[] getChildModules();
}
-sachin
Re: XBean site using new G-theme
Very cool! On Aug 21, 2006, at 12:07 PM, Jason Dillon wrote: Probably best to get a new graphic that incorporates the G and XBean elements. Might need to get some help from Epiq to get a updated layout that allows use to use the same theme across sub- projects the main site. I'd love to get an [X] logo just like the [G] logo (except with an x of course). -dain
