Re: problem with Geronimo-1.0

[Ranjan, Rakesh \(Cognizant\)]

Thanks Aaron for GMail account invitation. I will setup a
gmail account.

 

Sorry for posting the wrong code. The correct code is 

 

Kernel kernel=KernelRegistry.getSingleKernel();

ObjectName gbQuery =
JMXUtil.getObjectName("*:j2eeType=TransactionManager,*");

Set gbeanNames = kernel.listGBeans(gbQuery);

for (Iterator i = gbeanNames.iterator(); i.hasNext();) {

  ObjectName gbeanName = (ObjectName)
i.next();

  System.out.println(gbeanName);

/* The above print statement is giving 

geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionManager,

name=TransactionManaer 

*/

}

TransactionManager tm = (TransactionManager)
kernel.getProxyManager().createProxy(gbeanName,TransactionManager.class);

 

Hey I have just written web aaplication. I have put the
above code in a java class. Then calling the above class from the JSP page.

 

I am just getting the following Exception trace :

 

java.lang.IllegalArgumentException: 

 

Could not get GBeanInfo for target object:
geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionManager,

name=TransactionManager 

 

 

 


 
  
  Re: problem with Geronimo-1.0 
  
  
   
  
  
   
  
 
 


Reply (Restricted by the Administrator)
| Show Only this Message 



Rakesh, 

It would help to get the information I asked for: "a more complete 
chunk of your code, plus all the pertinent output and a full stack 
trace.  Also, please mention what you've deployed into the server (if 
anything) other than this application."  Again, it's impossible to 
debug your problem without knowing what your code is doing. 

Let me try to explain in more detail.  Here's the code you posted: 

Set gbeanNames = kernel.listGBeans(gbQuery); 
for (Iterator i = gbeanNames.iterator(); i.hasNext();) { 
      ObjectName gbeanName = (ObjectName) i.next(); 
      System.out.println(gbeanName1); 
} 
TransactionManager tm = (TransactionManager) 
kernel.getProxyManager().createProxy(gbeanName, 
TransactionManager.class); 

Now, the gbeanName variable in the for loop is declared in the for 
loop, so it's not the same as the gbeanName variable in the 
createProxy call.  Further, the println in the loop is using a 
variable called gbeanName1.  So in these three lines, there are three 
different variables being used.  Of them, we only see where gbeanName 
in the loop is assigned, but it's never used.  We need to know (and 
you need to find out) where the values gbeanName1 and gbeanName (the 
one outside of the loop) are assigned.  Note that YOU ARE NOT USING 
THE RESULT OF THE listGBeans CALL FOR ANYTHING (except to control the 
number of times you print gbeanName1) in the code you supplied, so 
when people suggest that listGBeans is broken that conclusion is not 
supported by the code you posted.  That's why I'm asking you to post 
more, and hunt down how those variables are being assigned. 

On 1/4/06, Ranjan, Rakesh
(Cognizant) <[EMAIL PROTECTED]> wrote: 
> Hi, 
> 
>  Sorry Aaron about confidential information footers. But i cann't do
anything because it is generated by the mail server. 

Presumably your company doesn't want you sending information to the 
world from your company e-mail account if they attach that to every 
message.  I sent you an invitation to use GMail for your personal 
correspondance.  :) 

Thanks, 
    Aaron 

> The value contained in the variable 'gbeanName' is : 
> 
> 
> 
> geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionManager,

> 
> name=TransactionManaer 
> 
> 
>  I have tried the query using the full object name: 
> 
> 
> 
>
geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-server/1.0/car,J2EEServer=geronimo,
j2eeType=TransactionManager, name=TransactionManager 
> 
> 
> 
> Its working correctly. I am able to get the TransactionManager instance
using the full GBean name. 
> 
> But  i would like to know why this thing is not working with
kernel.listGBeans(). Is it a bug in Geronimo-1.0 ? 
> 
>  Rakesh Ranjan 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Re: problem with Geronimo-1.0 
> 
> Grr, more confidential information footers.  Please don't do that to 
>  public mailing lists!  If your information is confidential,
don't send 
>  it to the world, and if it's not confidential, please don't assault
us 
>  with the legalese! 
> 
>  Anyway, now that that's off my chest, Geronimo cannot (well, 
>  definitely *should* not) produce an incorrect ObjectName out of thin

>  air, so you need to figure out where you're getting the ObjectName 
>  containing org/apache/geronimo/Server from.  In the code
snippet you 
>  showed, you do a lookup and print all the results, but then you try
to 
>  create a proxy using a variable called gbeanName (which I suspect is

>  what's failing) and you never showed us what that variable holds and

>  where you got the value 

Re: geronimo-web.xml, container-config, container-specific namespaces

[Aaron Mulder]

Well...  is it possible to make this not specific to WADI?  Perhaps
make it a generic "clustering manager" tag, and is "just so happens"
that the only classes we let you configure so far are the WADI ones? 
Ideally, we'd put some generic interface in the Geronimo space, and
then the WADI ones would implement or extend that, so if we ever
wanted to integrate other clustering options we'd leave that door
open.

Thanks,
Aaron

On 1/4/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Actually...this is quite simple...
>
> Use the generic web.  Have a new tag...call it , or whatever.
>
> Each of the container's builders can then have a flag set that is passed
> into its web context.  The web context can then set its own
> implementation...i.e. for Jetty, it then can create and apply its own
> org.codehaus.wadi.jetty5.JettyManager and for Tomcat it can create and
> apply its org.codehaus.wadi.tomcat55.TomcatManager.  No need for GBeans
> if WADI is to become a first class citizen.  The Tomcat GBean is purely
> for the ability to declaratively swap out managers.
>
> Thus, this will allow for a single ability to set up a generic tag that
> both containers can understand how to act upon.
>
> Jeff
>
> David Jencks wrote:
> > It is possible (I think) to do what you want, but I do not recommend
> > it.  I would prefer that you use external plans, and write 2 new modules
> > inside configs, to deploy your sample to jetty and to tomcat.  Take the
> > geronimo-web.xml out of the app and put it in src/plan/plan.xml.
> >
> > However, if you wish to defy me :-) you can use the generic schema
> > http://geronimo.apache.org/xml/ns/j2ee/web-1.0  (geronimo-web-1.0.xsd)
> > with sections in a container-config for the jetty and tomcat specific
> > parts.  These would use the namespace/schemas e.g.
> > http://geronimo.apache.org/xml/ns/web/jetty/config-1.0
> > (geronimo-jetty-config-1.0.xsd).
> >
> > A problem with this approach might be that you are including a gbean in
> > the tomcat config that is not needed in the jetty config.  I don't
> > understand why this would be there anyway, but I don't think you can
> > have gbeans in the container-config part.
> >
> > Is it possible to adjust the jetty and tomcat clustering configs to be
> > roughly the same and include the element in geronimo-web-1.0.xsd?
> >
> > hope this helps
> > david jencks
> >
> > On Jan 4, 2006, at 10:19 AM, Jules Gosnell wrote:
> >
> >> Aaron, David, or anyone in the know :-)
> >>
> >> Maybe you can help me with this:
> >>
> >> I have a WADI demo webapp.
> >>
> >> To get it running with Jetty, I need a WEB-INF/geronimo-web.xml that
> >> looks like this:
> >>
> >> http://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.0";
> >> configId="wadi">
> >>
> >>/wadi
> >>false
> >>
> >> org.codehaus.wadi.jetty5.JettyManager
> >>
> >> 
> >>
> >> To get it running with Tomcat, I have to have a geronimo-web.xml that
> >> looks like this:
> >>
> >> http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0";
> >> configId="wadi">
> >>
> >>/wadi
> >>false
> >>WADI
> >>
> >> >> class="org.apache.geronimo.tomcat.cluster.WADIGBean"/>
> >>
> >> 
> >>
> >>
> >> What I would like, is a single geronimo-web.xml that contains both
> >> Jetty and TC configs, merged.
> >>
> >> Do you know if this is possible, if so, would you mind pointing me in
> >> the right direction ?
> >>
> >> Much appreciated,
> >>
> >>
> >> Jules
> >>
> >>
> >>
> >> Aaron Mulder wrote:
> >>
> >>> David J,
> >>>
> >>> I thought when you added the separate Tomcat and Jetty namespaces, you
> >>> were going to remove the container-config section from the generic
> >>> geronimo-web.xml, but it seems that it's still there.  Jeff thinks
> >>> maybe it's for something like the console, where we want it to work in
> >>> both Tomcat and Jetty yet we might still require some
> >>> container-specific extensions (makes sense to me).
> >>>
> >>> If we're going to keep the generic geronimo-web.xml and keep the
> >>> container-config section in it, can we drop the container-specific
> >>> namespaces?  I think you favored the namespaces because if you use a
> >>> container-specific namespace then any container-specific settings
> >>> could be validated in XML, but I think that's pretty useless if it
> >>> only applies if you're willing to force your app to only deploy in one
> >>> container or the other.  (That is to say, if you want your web app to
> >>> run in either Tomcat or Jetty -- which is probably the normal case,
> >>> then you can't use a container-specific namespace so it doesn't matter
> >>> what the benefits of container-specific namespaces are.)
> >>>
> >>> The only way I can see the container-specific namespaces being
> >>> beneficial is if the container-config became an "any" and then we
> >>> namespaced the content that went within it -- so the overall file
> >>> always used the generic namespace but then you used a
> >>> container-specific one for the contents of the container-config
>

Re: Question about default subject in tomcat integration

[Jeff Genender]

David Jencks wrote:
> 
> On Jan 4, 2006, at 2:49 PM, Jeff Genender wrote:
> 
>> DJ,
>>
>> Didn't you write the DefaultSubjectValve? ;-)
> 
> That was three months ago! How do you expect me to remember such ancient
> history ??? :-)
> 
> So, it looks to me as if GERONIMO-1012 was, as I thought, not complete
> and you shouldn't have closed it :-)

Well it worked!  That was good enough for me ;-)

> 
> Will continue investigating.  Do you know of any way to install a valve
> AFTER the ones tomcat installs for you, or a way to change what those
> valves are?  I think putting the DefaultSubjectValve after the
> authentication happens would fix the problems.

When an addValve() is done, it goes to the end of the pipeline.  So its
already after authenticating valves.

Can you explain a little more in detail of the issue regarding when the
defaultSubject needs to be there (or doesn't), then I can probably help
with a solution here.

Jeff

> 
> thanks
> david jencks
> 
>>
>> Jeff
>>
>> David Jencks wrote:
>>> In GeronimoStandardContext this is the code that sets up the
>>> DefaultSubjectValve:
>>>
>>> //This is definitely a hack, but I don't see a
>>> reasonable way to install the defaultSubject.
>>> //Obviously this won't work if there are permissions.
>>> Setting the default subject if there are
>>> //permissions breaks authentication.
>>> boolean hasPermissions =
>>> securityHolder.getChecked().elements().hasMoreElements() ||
>>>
>>> securityHolder.getExcluded().elements().hasMoreElements();
>>> Valve defaultSubjectValve;
>>> if (!hasPermissions && defaultSubject != null) {
>>> defaultSubjectValve = new
>>> DefaultSubjectValve(defaultSubject);
>>> } else {
>>> //this will clear the thread of any read subject
>>> added by some other web app
>>> defaultSubjectValve = new DefaultSubjectValve(null);
>>> }
>>> addValve(defaultSubjectValve);
>>>
>>>
>>> In DefaultSubjectValve, the operative code is:
>>>
>>> public void invoke(Request request, Response response) throws
>>> IOException, ServletException {
>>> boolean setSubject = ContextManager.getCurrentCaller() == null;
>>> if (setSubject) {
>>> ContextManager.setCurrentCaller(defaultSubject);
>>> ContextManager.setNextCaller(defaultSubject);
>>> try {
>>> getNext().invoke(request, response);
>>> } finally {
>>> ContextManager.setCurrentCaller(null);
>>> ContextManager.setNextCaller(null);
>>> }
>>> } else {
>>> getNext().invoke(request, response);
>>> }
>>> }
>>>
>>>
>>> This doesn't make any sense to me.  If
>>> DefaultSubjectValve.defaultSubject is null, then DefaultSubjectValve
>>> will clear nextCaller if currentCaller is null, otherwise do nothing.  I
>>> doubt this is critical functionality.  However, it appears to me that
>>> the code in GeronimoStandardContext that sets
>>> DefaultSubjectValve.defaultSubject to null if the web app has checked
>>> constraints appears to me to prevent the default subject from being set
>>> for that portion of the app that is unsecured, which is where I thought
>>> it was important.
>>>
>>> Could someone explain just how always using the actual defaultSubject
>>> breaks authentication?
>>>
>>> thanks
>>> david jencks

Re: Question about default subject in tomcat integration

[David Jencks]

On Jan 4, 2006, at 2:49 PM, Jeff Genender wrote:


DJ,

Didn't you write the DefaultSubjectValve? ;-)


That was three months ago! How do you expect me to remember such  
ancient history ??? :-)


So, it looks to me as if GERONIMO-1012 was, as I thought, not  
complete and you shouldn't have closed it :-)


Will continue investigating.  Do you know of any way to install a  
valve AFTER the ones tomcat installs for you, or a way to change what  
those valves are?  I think putting the DefaultSubjectValve after the  
authentication happens would fix the problems.


thanks
david jencks



Jeff

David Jencks wrote:

In GeronimoStandardContext this is the code that sets up the
DefaultSubjectValve:

//This is definitely a hack, but I don't see a
reasonable way to install the defaultSubject.
//Obviously this won't work if there are permissions.
Setting the default subject if there are
//permissions breaks authentication.
boolean hasPermissions =
securityHolder.getChecked().elements().hasMoreElements() ||

securityHolder.getExcluded().elements().hasMoreElements();
Valve defaultSubjectValve;
if (!hasPermissions && defaultSubject != null) {
defaultSubjectValve = new
DefaultSubjectValve(defaultSubject);
} else {
//this will clear the thread of any read subject
added by some other web app
defaultSubjectValve = new DefaultSubjectValve 
(null);

}
addValve(defaultSubjectValve);


In DefaultSubjectValve, the operative code is:

public void invoke(Request request, Response response) throws
IOException, ServletException {
boolean setSubject = ContextManager.getCurrentCaller() ==  
null;

if (setSubject) {
ContextManager.setCurrentCaller(defaultSubject);
ContextManager.setNextCaller(defaultSubject);
try {
getNext().invoke(request, response);
} finally {
ContextManager.setCurrentCaller(null);
ContextManager.setNextCaller(null);
}
} else {
getNext().invoke(request, response);
}
}


This doesn't make any sense to me.  If
DefaultSubjectValve.defaultSubject is null, then DefaultSubjectValve
will clear nextCaller if currentCaller is null, otherwise do  
nothing.  I

doubt this is critical functionality.  However, it appears to me that
the code in GeronimoStandardContext that sets
DefaultSubjectValve.defaultSubject to null if the web app has checked
constraints appears to me to prevent the default subject from  
being set
for that portion of the app that is unsecured, which is where I  
thought

it was important.

Could someone explain just how always using the actual defaultSubject
breaks authentication?

thanks
david jencks

Re: geronimo-web.xml, container-config, container-specific namespaces

[Jeff Genender]

Hi,

Actually...this is quite simple...

Use the generic web.  Have a new tag...call it , or whatever.

Each of the container's builders can then have a flag set that is passed
into its web context.  The web context can then set its own
implementation...i.e. for Jetty, it then can create and apply its own
org.codehaus.wadi.jetty5.JettyManager and for Tomcat it can create and
apply its org.codehaus.wadi.tomcat55.TomcatManager.  No need for GBeans
if WADI is to become a first class citizen.  The Tomcat GBean is purely
for the ability to declaratively swap out managers.

Thus, this will allow for a single ability to set up a generic tag that
both containers can understand how to act upon.

Jeff

David Jencks wrote:
> It is possible (I think) to do what you want, but I do not recommend
> it.  I would prefer that you use external plans, and write 2 new modules
> inside configs, to deploy your sample to jetty and to tomcat.  Take the
> geronimo-web.xml out of the app and put it in src/plan/plan.xml.
> 
> However, if you wish to defy me :-) you can use the generic schema
> http://geronimo.apache.org/xml/ns/j2ee/web-1.0  (geronimo-web-1.0.xsd)
> with sections in a container-config for the jetty and tomcat specific
> parts.  These would use the namespace/schemas e.g.
> http://geronimo.apache.org/xml/ns/web/jetty/config-1.0
> (geronimo-jetty-config-1.0.xsd).
> 
> A problem with this approach might be that you are including a gbean in
> the tomcat config that is not needed in the jetty config.  I don't
> understand why this would be there anyway, but I don't think you can
> have gbeans in the container-config part.
> 
> Is it possible to adjust the jetty and tomcat clustering configs to be
> roughly the same and include the element in geronimo-web-1.0.xsd?
> 
> hope this helps
> david jencks
> 
> On Jan 4, 2006, at 10:19 AM, Jules Gosnell wrote:
> 
>> Aaron, David, or anyone in the know :-)
>>
>> Maybe you can help me with this:
>>
>> I have a WADI demo webapp.
>>
>> To get it running with Jetty, I need a WEB-INF/geronimo-web.xml that
>> looks like this:
>>
>> http://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.0";
>> configId="wadi">
>>
>>/wadi
>>false
>>   
>> org.codehaus.wadi.jetty5.JettyManager
>>
>> 
>>
>> To get it running with Tomcat, I have to have a geronimo-web.xml that
>> looks like this:
>>
>> http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0";
>> configId="wadi">
>>
>>/wadi
>>false
>>WADI
>>
>>> class="org.apache.geronimo.tomcat.cluster.WADIGBean"/>
>>
>> 
>>
>>
>> What I would like, is a single geronimo-web.xml that contains both
>> Jetty and TC configs, merged.
>>
>> Do you know if this is possible, if so, would you mind pointing me in
>> the right direction ?
>>
>> Much appreciated,
>>
>>
>> Jules
>>
>>
>>
>> Aaron Mulder wrote:
>>
>>> David J,
>>>
>>> I thought when you added the separate Tomcat and Jetty namespaces, you
>>> were going to remove the container-config section from the generic
>>> geronimo-web.xml, but it seems that it's still there.  Jeff thinks
>>> maybe it's for something like the console, where we want it to work in
>>> both Tomcat and Jetty yet we might still require some
>>> container-specific extensions (makes sense to me).
>>>
>>> If we're going to keep the generic geronimo-web.xml and keep the
>>> container-config section in it, can we drop the container-specific
>>> namespaces?  I think you favored the namespaces because if you use a
>>> container-specific namespace then any container-specific settings
>>> could be validated in XML, but I think that's pretty useless if it
>>> only applies if you're willing to force your app to only deploy in one
>>> container or the other.  (That is to say, if you want your web app to
>>> run in either Tomcat or Jetty -- which is probably the normal case,
>>> then you can't use a container-specific namespace so it doesn't matter
>>> what the benefits of container-specific namespaces are.)
>>>
>>> The only way I can see the container-specific namespaces being
>>> beneficial is if the container-config became an "any" and then we
>>> namespaced the content that went within it -- so the overall file
>>> always used the generic namespace but then you used a
>>> container-specific one for the contents of the container-config
>>> element only.
>>>
>>> Am I missing something?
>>>
>>> Thanks,
>>>Aaron
>>>
>>
>>
>> --"Open Source is a self-assembling organism. You dangle a piece of
>> string into a super-saturated solution and a whole operating-system
>> crystallises out around it."
>>
>> /**
>> * Jules Gosnell
>> * Partner
>> * Core Developers Network (Europe)
>> *
>> *www.coredevelopers.net
>> *
>> * Open Source Training & Support.
>> **/
>>

Re: Question about default subject in tomcat integration

[Jeff Genender]

DJ,

Didn't you write the DefaultSubjectValve? ;-)

Jeff

David Jencks wrote:
> In GeronimoStandardContext this is the code that sets up the
> DefaultSubjectValve:
> 
> //This is definitely a hack, but I don't see a
> reasonable way to install the defaultSubject.
> //Obviously this won't work if there are permissions. 
> Setting the default subject if there are
> //permissions breaks authentication.
> boolean hasPermissions =
> securityHolder.getChecked().elements().hasMoreElements() ||
>
> securityHolder.getExcluded().elements().hasMoreElements();
> Valve defaultSubjectValve;
> if (!hasPermissions && defaultSubject != null) {
> defaultSubjectValve = new
> DefaultSubjectValve(defaultSubject);
> } else {
> //this will clear the thread of any read subject
> added by some other web app
> defaultSubjectValve = new DefaultSubjectValve(null);
> }
> addValve(defaultSubjectValve);
> 
> 
> In DefaultSubjectValve, the operative code is:
> 
> public void invoke(Request request, Response response) throws
> IOException, ServletException {
> boolean setSubject = ContextManager.getCurrentCaller() == null;
> if (setSubject) {
> ContextManager.setCurrentCaller(defaultSubject);
> ContextManager.setNextCaller(defaultSubject);
> try {
> getNext().invoke(request, response);
> } finally {
> ContextManager.setCurrentCaller(null);
> ContextManager.setNextCaller(null);
> }
> } else {
> getNext().invoke(request, response);
> }
> }
> 
> 
> This doesn't make any sense to me.  If
> DefaultSubjectValve.defaultSubject is null, then DefaultSubjectValve
> will clear nextCaller if currentCaller is null, otherwise do nothing.  I
> doubt this is critical functionality.  However, it appears to me that
> the code in GeronimoStandardContext that sets
> DefaultSubjectValve.defaultSubject to null if the web app has checked
> constraints appears to me to prevent the default subject from being set
> for that portion of the app that is unsecured, which is where I thought
> it was important.
> 
> Could someone explain just how always using the actual defaultSubject
> breaks authentication?
> 
> thanks
> david jencks

Question about default subject in tomcat integration

[David Jencks]

In GeronimoStandardContext this is the code that sets up the  
DefaultSubjectValve:


//This is definitely a hack, but I don't see a  
reasonable way to install the defaultSubject.
//Obviously this won't work if there are  
permissions.  Setting the default subject if there are

//permissions breaks authentication.
boolean hasPermissions = securityHolder.getChecked 
().elements().hasMoreElements() ||
securityHolder.getExcluded().elements 
().hasMoreElements();

Valve defaultSubjectValve;
if (!hasPermissions && defaultSubject != null) {
defaultSubjectValve = new DefaultSubjectValve 
(defaultSubject);

} else {
//this will clear the thread of any read subject  
added by some other web app
defaultSubjectValve = new DefaultSubjectValve 
(null);

}
addValve(defaultSubjectValve);


In DefaultSubjectValve, the operative code is:

public void invoke(Request request, Response response) throws  
IOException, ServletException {

boolean setSubject = ContextManager.getCurrentCaller() == null;
if (setSubject) {
ContextManager.setCurrentCaller(defaultSubject);
ContextManager.setNextCaller(defaultSubject);
try {
getNext().invoke(request, response);
} finally {
ContextManager.setCurrentCaller(null);
ContextManager.setNextCaller(null);
}
} else {
getNext().invoke(request, response);
}
}


This doesn't make any sense to me.  If  
DefaultSubjectValve.defaultSubject is null, then DefaultSubjectValve  
will clear nextCaller if currentCaller is null, otherwise do  
nothing.  I doubt this is critical functionality.  However, it  
appears to me that the code in GeronimoStandardContext that sets  
DefaultSubjectValve.defaultSubject to null if the web app has checked  
constraints appears to me to prevent the default subject from being  
set for that portion of the app that is unsecured, which is where I  
thought it was important.


Could someone explain just how always using the actual defaultSubject  
breaks authentication?


thanks
david jencks

[jira] Created: (GERONIMO-1418) allow user to specify deployment targets by "nickname"

[toby cabot (JIRA)]

allow user to specify deployment targets by "nickname"
--

 Key: GERONIMO-1418
 URL: http://issues.apache.org/jira/browse/GERONIMO-1418
 Project: Geronimo
Type: Improvement
  Components: deployment  
Versions: 1.1
 Environment: fedora core 2
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
geronimo 1.0 branch
Reporter: toby cabot
Priority: Minor
 Attachments: geronimo-target-nickname.txt

This is a follow-on to the patch I submitted that allows Geronimo to have 2 
configuration stores.  Now that I can specify the config-store on the command 
line with the --targets switch I'm getting sick of typing the full target name 
(e.g. 
geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-system/1.0/car,J2EEServer=geronimo,j2eeType=ConfigurationStore,name=Customer).
  This patch allows the user to specify any part of the target name (e.g. 
Customer) instead of the whole target name.  It's pretty crude, so if there's a 
more elegant way to do something like this I'm all ears.

-- 
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-1418) allow user to specify deployment targets by "nickname"

[toby cabot (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-1418?page=all ]

toby cabot updated GERONIMO-1418:
-

Attachment: geronimo-target-nickname.txt

> allow user to specify deployment targets by "nickname"
> --
>
>  Key: GERONIMO-1418
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1418
>  Project: Geronimo
> Type: Improvement
>   Components: deployment
> Versions: 1.1
>  Environment: fedora core 2
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
> geronimo 1.0 branch
> Reporter: toby cabot
> Priority: Minor
>  Attachments: geronimo-target-nickname.txt
>
> This is a follow-on to the patch I submitted that allows Geronimo to have 2 
> configuration stores.  Now that I can specify the config-store on the command 
> line with the --targets switch I'm getting sick of typing the full target 
> name (e.g. 
> geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-system/1.0/car,J2EEServer=geronimo,j2eeType=ConfigurationStore,name=Customer).
>   This patch allows the user to specify any part of the target name (e.g. 
> Customer) instead of the whole target name.  It's pretty crude, so if there's 
> a more elegant way to do something like this I'm all ears.

-- 
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: [Fwd: [Vote] 1.0 Release - Do we ship it?]

[Aaron Mulder]

+/-0 : The database pool creation portlet doesn't work for the
Embedded Derby driver in Tomcat.  It doesn't log an error either, just
bails midway through.  I'm not sure what's going on -- the same
procedure worked fine in Jetty, and a third-party database like
PostgreSQL doesn't have that same problem.  I wonder if our Jetty
config includes some Derby dependencies that the Tomcat config
doesn't?  I'll poke around a bit.  I guess no one's probably willing
to hold up the release on account of this...  :)

Aaron

On 1/3/06, Sachin Patel <[EMAIL PROTECTED]> wrote:
> forwarding this on behalf of Matt...
>
>
> - sachin
>
>
>
>
> Begin forwarded message:
>
> From: Matt Hogstrom <[EMAIL PROTECTED]>
> Date: January 3, 2006 9:47:28 AM EST
> To: [EMAIL PROTECTED]
> Subject: [Fwd: [Vote] 1.0 Release - Do we ship it?]
>
>
> Can you forward thsi for me?  I'm still getting SPAM errors.  I've sent a
> note to Ken to see if he can help me decipher what's going on.
>
>  Original Message 
> Subject: [Vote] 1.0 Release - Do we ship it?
> Date: Tue, 03 Jan 2006 09:21:30 -0500
> From: Matt Hogstrom <[EMAIL PROTECTED]>
> To: dev@geronimo.apache.org
>
> All,
>
> We have had the last candidate out and available since 12/22.  I personally
> have
> had a chance to put the 12/22 build under performance stress and I'm
> satisfied
> that the build is stable and runs in a variety of modes using DayTrader.
>
> Despite the Christmas Holidays I have seen some traffic related to htis
> release
> on the list so some folks have been kicking it around as well.  At this time
> I'd
> like to call a vote to release 1.0.
>
> [ ] +1 Release 1.0
> [ ] -1 Do not release 1.0 (Reasons included)
>
> Looks like we got through the last remaining significant bugs and thansk to
> all
> who worked up to the end to get this release out there.
>
> Matt
>
>
>
>
>

Re: Nightly builds and publish drivers

[Aaron Mulder]

We've also talked about the need to be able to run tests against an
effectively complete server (deployment tests, tests of small things
where it's too painful to start 10,000 GBeans manually in order to try
out one tiny test, and a replacement for/update of the OpenEJB
integration tests).  I think it would be a great start to get
something running along those lines.  That could then be the
foundation of the kind of test suite you're suggesting to verify a
build.

Aaron

On 1/4/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote:
> Now that we have the continuum performing nightly builds, it will be nice to
> make some more enhancements to the process. Some of the things that come to
> mind are
>
>  1. run a set of basic bringup type verification tests against the drivers
> from the nightly builds. These tests would be of a degree slightly higher
> than the in-built itests and would indicate the general health of the
> driver. Some of these sniff tests could be (feel free to modify the list)
>
> install G
>
> start G
>
> start console
>
> deploy an app
> test ejb container
> test web container
> test webservices
> stop G 2. publish the drivers that passed the above tests so that people can
> download and play with it on a regular basis. This will obviate the need for
> people to build G from source, a process which sometimes takes an
> indeterminate amount of time due to network delays etc.
>
>  3. Further down the line, we can even think about hooking up TCK to this
> chain.
>
>
>  I volunteer myself to work on this. But I'd sincerely appreciate your
> thoughts and comments, advice and suggestions.
>
>  I also have a few doubts about our nightly builds which I'd like to get
> confirmed.
>  a) do you still have to trigger the builds manually or does it run per an
> automated schedule ?
>  b) can the above tests be tagged on to the end of the build process in
> Continuum itself or should we explore at other options ?
>
>
>  Cheers
>  Prasad.
>

Nightly builds and publish drivers

[Prasad Kashyap]

Now that we have the continuum performing nightly builds, it will be
nice to make some more enhancements to the process. Some of the things
that come to mind are

1. run a set of basic bringup type verification tests against the
drivers from the nightly builds. These tests would be of a degree
slightly higher than the in-built itests and would indicate the general
health of the driver. Some of these sniff tests could be (feel free to
modify the list)

  install G
  
  start G
  
  start console
  
  deploy an app
  test ejb container
  test web container
  test webservices
  stop G

2. publish the drivers that passed the above tests so that people can
download and play with it on a regular basis. This will obviate the
need for people to build G from source, a process which sometimes takes
an indeterminate amount of time due to network delays etc.

3. Further down the line, we can even think about hooking up TCK to this chain.


I volunteer myself to work on this. But I'd sincerely appreciate your thoughts and comments, advice and suggestions.

I also have a few doubts about our nightly builds which I'd like to get confirmed.
a) do you still have to trigger the builds manually or does it run per an automated schedule ?
b) can the above tests be tagged on to the end of the build process in Continuum itself or should we explore at other options ?


Cheers
Prasad.

Re: geronimo-web.xml, container-config, container-specific namespaces

[Aaron Mulder]

Yeah, I was going to say, let's merge the manager and session-manager
elements from the 2 separate plans into a single session-manager
element in the geronimo-web plan.  Though it looks like one takes a
class name and the other takes a GBean name, so we'd have to figure
that out.  I assume that the combined element should take a class name
and then we can have a "delegating" implementation of that class that
references a GBean instead, but then we have to figure out which GBean
to point it to...  And I also don't know what to say about the GBean
that you only want to start if the app runs in Tomcat (but is there a
reason not to include that GBean in a separate Tomcat or Tomcat
Clustering configuration instead of in the application itself?).

Jules, can you suggest what the common schema elements would look like
if we were going to put only one set of configuration information into
the generic geronimo-web.xml plan, and then have both Jetty and Tomcat
read the same configuration information from there?

Thanks,
Aaron

On 1/4/06, David Jencks <[EMAIL PROTECTED]> wrote:
> It is possible (I think) to do what you want, but I do not recommend
> it.  I would prefer that you use external plans, and write 2 new
> modules inside configs, to deploy your sample to jetty and to
> tomcat.  Take the geronimo-web.xml out of the app and put it in src/
> plan/plan.xml.
>
> However, if you wish to defy me :-) you can use the generic schema
> http://geronimo.apache.org/xml/ns/j2ee/web-1.0  (geronimo-
> web-1.0.xsd) with sections in a container-config for the jetty and
> tomcat specific parts.  These would use the namespace/schemas e.g.
> http://geronimo.apache.org/xml/ns/web/jetty/config-1.0 (geronimo-
> jetty-config-1.0.xsd).
>
> A problem with this approach might be that you are including a gbean
> in the tomcat config that is not needed in the jetty config.  I don't
> understand why this would be there anyway, but I don't think you can
> have gbeans in the container-config part.
>
> Is it possible to adjust the jetty and tomcat clustering configs to
> be roughly the same and include the element in geronimo-web-1.0.xsd?
>
> hope this helps
> david jencks
>
> On Jan 4, 2006, at 10:19 AM, Jules Gosnell wrote:
>
> > Aaron, David, or anyone in the know :-)
> >
> > Maybe you can help me with this:
> >
> > I have a WADI demo webapp.
> >
> > To get it running with Jetty, I need a WEB-INF/geronimo-web.xml
> > that looks like this:
> >
> > http://geronimo.apache.org/xml/ns/j2ee/web/
> > jetty-1.0" configId="wadi">
> >
> >/wadi
> >false
> >org.codehaus.wadi.jetty5.JettyManager > manager>
> >
> > 
> >
> > To get it running with Tomcat, I have to have a geronimo-web.xml
> > that looks like this:
> >
> > http://geronimo.apache.org/xml/ns/j2ee/web/
> > tomcat-1.0" configId="wadi">
> >
> >/wadi
> >false
> >WADI
> >
> > > class="org.apache.geronimo.tomcat.cluster.WADIGBean"/>
> >
> > 
> >
> >
> > What I would like, is a single geronimo-web.xml that contains both
> > Jetty and TC configs, merged.
> >
> > Do you know if this is possible, if so, would you mind pointing me
> > in the right direction ?
> >
> > Much appreciated,
> >
> >
> > Jules
> >
> >
> >
> > Aaron Mulder wrote:
> >
> >> David J,
> >>
> >> I thought when you added the separate Tomcat and Jetty namespaces,
> >> you
> >> were going to remove the container-config section from the generic
> >> geronimo-web.xml, but it seems that it's still there.  Jeff thinks
> >> maybe it's for something like the console, where we want it to
> >> work in
> >> both Tomcat and Jetty yet we might still require some
> >> container-specific extensions (makes sense to me).
> >>
> >> If we're going to keep the generic geronimo-web.xml and keep the
> >> container-config section in it, can we drop the container-specific
> >> namespaces?  I think you favored the namespaces because if you use a
> >> container-specific namespace then any container-specific settings
> >> could be validated in XML, but I think that's pretty useless if it
> >> only applies if you're willing to force your app to only deploy in
> >> one
> >> container or the other.  (That is to say, if you want your web app to
> >> run in either Tomcat or Jetty -- which is probably the normal case,
> >> then you can't use a container-specific namespace so it doesn't
> >> matter
> >> what the benefits of container-specific namespaces are.)
> >>
> >> The only way I can see the container-specific namespaces being
> >> beneficial is if the container-config became an "any" and then we
> >> namespaced the content that went within it -- so the overall file
> >> always used the generic namespace but then you used a
> >> container-specific one for the contents of the container-config
> >> element only.
> >>
> >> Am I missing something?
> >>
> >> Thanks,
> >>Aaron
> >>
> >
> >
> > --
> > "Open Source is a self-assembling organism. You dangle a piece of
> > string into a super-saturated solution and a whole operating-sys

Re: DB Info portlet is not working!!??

[Paul McMahan]

You may need to svn update.  This was fixed in GERONIMO-1373.
   http://issues.apache.org/jira/browse/GERONIMO-1373

Best wishes, Paul
On 1/4/06, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote:
I notice that the DB Info portlet in Geronimo Console is not displaying
any information.  No error is logged to geronimo.log .  Only
java.sql.SQLException is output to the command window running
Geronimo.  Has anybody else came across this?

Re: DB Info portlet is not working!!??

[Aaron Mulder]

On 1/4/06, David Jencks <[EMAIL PROTECTED]> wrote:
> We need some way of avoiding these variable version numbers hardcoded in
> numerous places.

That's one of the unconverted portlets.  As we convert them, we
replace the hardcoded object names with lookups (generally by
interface).  The only real thorny problem is the hardcoded RAR names
for deploying new DB pools & JMS resources and so on.  I'm not sure
how to make that dynamic, though maybe we can use a config file that
gets processed by velocity?

Aaron

> On Jan 4, 2006, at 8:34 AM, Vamsavardhana Reddy wrote:
> Joe,
>
>  The objectname referenced is same as the one from your last mail.  Problem
> might be something else.
>
>  -Vamsi
>
> On 1/4/06, Joe Bohn <[EMAIL PROTECTED]> wrote:
> > I just checked and it appears that this change is included in trunk (if
> > you have a recent enough version).   Perhaps the objectname changed yet
> > again.  I don't have a working version of trunk at the moment to check
> > and see if I get the same error or not.  Can you check to see if you
> > have the fix included in your image.  That should let us know if the
> > error is the old one or something new.
> >
> > Check your version of
> >
> applications/console-standard/src/java/org/apache/geronimo/console/internaldb/DerbyConnectionUtil.java
> > and see if the objectname referenced is
> >
> geronimo.server:J2EEApplication=null,J2EEServer=geronimo,JCAResource=geronimo/system-database/1.0/car,j2eeType=JCAManagedConnectionFactory,name=SystemDatasource
> >
> > Joe
> >
> > Vamsavardhana Reddy wrote:
> > > The version I am using is built from trunk.
> > >
> > > -Vamsi
> > >
> > > On 1/4/06, *Joe Bohn* <[EMAIL PROTECTED]
> > > > wrote:
> > >
> > > What version of Geronimo are you using?
> > >
> > > There was a problem with this that was fixed in 1.0 by Paul McMahan
> > > http://issues.apache.org/jira/browse/GERONIMO-1373
> > >  >
> > >
> > > Perhaps this patch didn't get applied to trunk.
> > >
> > > Joe
> > >
> > > Vamsavardhana Reddy wrote:
> > >  > I notice that the DB Info portlet in Geronimo Console is not
> > > displaying
> > >  > any information.  No error is logged to geronimo.log .  Only
> > >  > java.sql.SQLException is output to the command window running
> > > Geronimo.
> > >  > Has anybody else came across this?
> > >
> > > --
> > > Joe Bohn
> > > [EMAIL PROTECTED] 
> > >
> > > "He is no fool who gives what he cannot keep, to gain what he cannot
> > > lose."   -- Jim Elliot
> > >
> > >
> >
> > --
> > Joe Bohn
> > [EMAIL PROTECTED]
> >
> > "He is no fool who gives what he cannot keep, to gain what he cannot
> > lose."   -- Jim Elliot
> >
>
>
>

Re: WebContainer Statistics

[Aaron Mulder]

On 1/4/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote:
> Aaron, Joe and others,
>I have few questions about the WebConnector. I must
> admit that I have not kept track of the patches that
> were submitted. May be some of these issues have
> already been decided.
> 1. Are there any plans to make
> NetworkConnector/WebConnector a J2EEManagedObject? If
> yes, their statistics can be made available without
> the changes proposed in 2.

Yes.  Eventually, pretty much everything in the JSR-77 namespace
should be a J2EEManagedObject.

Thanks,
Aaron

> 2. If not, The connector statistics can be made
> available via WebContainer as follows (using JSR 77
> notations) -
>   WebContainerStats :
>+  getConnectors() : WebConnectorStats[]
>+  get.:  ...Statistic
>+  :  .
>
>WebConnectorStats:
>+ .
>
> To do this, StatsImpl will also have to be
> changed -
> . Add a method addStat(String name, Stats value)
> . Change Statistic[] getStatistics() method to
> take care of the new structure.
> These changes will be required in the
> future to implement things like JMSStats defined in
> JSR77.6.24.
> I would like to use either 1 or 2 to make
> Tomcat Connector Statistics available.
>
> Thanks
> Anita
>
>
>
> __
> Yahoo! DSL – Something to write home about.
> Just $16.99/mo. or less.
> dsl.yahoo.com
>
>

Re: geronimo-web.xml, container-config, container-specific namespaces

[David Jencks]

It is possible (I think) to do what you want, but I do not recommend  
it.  I would prefer that you use external plans, and write 2 new  
modules inside configs, to deploy your sample to jetty and to  
tomcat.  Take the geronimo-web.xml out of the app and put it in src/ 
plan/plan.xml.


However, if you wish to defy me :-) you can use the generic schema  
http://geronimo.apache.org/xml/ns/j2ee/web-1.0  (geronimo- 
web-1.0.xsd) with sections in a container-config for the jetty and  
tomcat specific parts.  These would use the namespace/schemas e.g.  
http://geronimo.apache.org/xml/ns/web/jetty/config-1.0 (geronimo- 
jetty-config-1.0.xsd).


A problem with this approach might be that you are including a gbean  
in the tomcat config that is not needed in the jetty config.  I don't  
understand why this would be there anyway, but I don't think you can  
have gbeans in the container-config part.


Is it possible to adjust the jetty and tomcat clustering configs to  
be roughly the same and include the element in geronimo-web-1.0.xsd?


hope this helps
david jencks

On Jan 4, 2006, at 10:19 AM, Jules Gosnell wrote:


Aaron, David, or anyone in the know :-)

Maybe you can help me with this:

I have a WADI demo webapp.

To get it running with Jetty, I need a WEB-INF/geronimo-web.xml  
that looks like this:


http://geronimo.apache.org/xml/ns/j2ee/web/ 
jetty-1.0" configId="wadi">


   /wadi
   false
   org.codehaus.wadi.jetty5.JettyManagermanager>




To get it running with Tomcat, I have to have a geronimo-web.xml  
that looks like this:


http://geronimo.apache.org/xml/ns/j2ee/web/ 
tomcat-1.0" configId="wadi">


   /wadi
   false
   WADI

   class="org.apache.geronimo.tomcat.cluster.WADIGBean"/>





What I would like, is a single geronimo-web.xml that contains both  
Jetty and TC configs, merged.


Do you know if this is possible, if so, would you mind pointing me  
in the right direction ?


Much appreciated,


Jules



Aaron Mulder wrote:


David J,

I thought when you added the separate Tomcat and Jetty namespaces,  
you

were going to remove the container-config section from the generic
geronimo-web.xml, but it seems that it's still there.  Jeff thinks
maybe it's for something like the console, where we want it to  
work in

both Tomcat and Jetty yet we might still require some
container-specific extensions (makes sense to me).

If we're going to keep the generic geronimo-web.xml and keep the
container-config section in it, can we drop the container-specific
namespaces?  I think you favored the namespaces because if you use a
container-specific namespace then any container-specific settings
could be validated in XML, but I think that's pretty useless if it
only applies if you're willing to force your app to only deploy in  
one

container or the other.  (That is to say, if you want your web app to
run in either Tomcat or Jetty -- which is probably the normal case,
then you can't use a container-specific namespace so it doesn't  
matter

what the benefits of container-specific namespaces are.)

The only way I can see the container-specific namespaces being
beneficial is if the container-config became an "any" and then we
namespaced the content that went within it -- so the overall file
always used the generic namespace but then you used a
container-specific one for the contents of the container-config
element only.

Am I missing something?

Thanks,
   Aaron




--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
*www.coredevelopers.net
*
* Open Source Training & Support.
**/

Re: geronimo-web.xml, container-config, container-specific namespaces

[Jules Gosnell]

Aaron, David, or anyone in the know :-)

Maybe you can help me with this:

I have a WADI demo webapp.

To get it running with Jetty, I need a WEB-INF/geronimo-web.xml that 
looks like this:


http://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.0"; 
configId="wadi">


   /wadi
   false
   org.codehaus.wadi.jetty5.JettyManager



To get it running with Tomcat, I have to have a geronimo-web.xml that 
looks like this:


http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0"; 
configId="wadi">


   /wadi
   false
   WADI

   class="org.apache.geronimo.tomcat.cluster.WADIGBean"/>





What I would like, is a single geronimo-web.xml that contains both Jetty 
and TC configs, merged.


Do you know if this is possible, if so, would you mind pointing me in 
the right direction ?


Much appreciated,


Jules



Aaron Mulder wrote:


David J,

I thought when you added the separate Tomcat and Jetty namespaces, you
were going to remove the container-config section from the generic
geronimo-web.xml, but it seems that it's still there.  Jeff thinks
maybe it's for something like the console, where we want it to work in
both Tomcat and Jetty yet we might still require some
container-specific extensions (makes sense to me).

If we're going to keep the generic geronimo-web.xml and keep the
container-config section in it, can we drop the container-specific
namespaces?  I think you favored the namespaces because if you use a
container-specific namespace then any container-specific settings
could be validated in XML, but I think that's pretty useless if it
only applies if you're willing to force your app to only deploy in one
container or the other.  (That is to say, if you want your web app to
run in either Tomcat or Jetty -- which is probably the normal case,
then you can't use a container-specific namespace so it doesn't matter
what the benefits of container-specific namespaces are.)

The only way I can see the container-specific namespaces being
beneficial is if the container-config became an "any" and then we
namespaced the content that went within it -- so the overall file
always used the generic namespace but then you used a
container-specific one for the contents of the container-config
element only.

Am I missing something?

Thanks,
   Aaron
 




--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
*www.coredevelopers.net
*
* Open Source Training & Support.
**/

Re: offline deployment?

[David Jencks]

On Jan 3, 2006, at 7:34 AM, toby cabot wrote:


Hi Folks,

I guess it's possible that I'm the only person that used offline
deployment, at least I don't see a lot of people clamoring to bring it
back.  It's very useful for me, though, so I'd like to find out if
there's a possibility of bringing it back onto HEAD (and hopefully the
1.0 branch, too).  I'll probably need to hack something for my needs
but I'd just as soon do it in a way that's Geronimo-savvy.


It's definitely something we need in some form.


From discussion on this list it looks as if the preferred approach is
to try to use the same approach that the build-time maven plugins do.
From my naive reading of the code, it looks as if that happens in two
passes: first the geronimo-packaging-plugin takes a deployable
resource (ear, war, etc) and generates a configuration archive from
that, then the geronimo-assembly-plugin moves the car into the
ConfigurationStore.  The configurations are mentioned in config.xml
(hand-coded?) which causes them to get started when Geronimo runs.  I
see notes in the code that the packaging plugin uses the Maven
repository, so in order to work on machines without Maven I imagine
that we'd need to use the Geronimo repository instead.

Is this more-or-less on the right track?  I'd appreciate any tips or
pointers, especially if I'm about to head off in the wrong direction.


That's about right.  I tried to make both the packaging and assembly  
plugins modular so that the class that does the work accepts  
arbitrary repository and config-store implementations so that all  
that is needed for the offline config-builder or assembler is to  
construct something using the geronimo repo and config store rather  
than the maven ones.  My idea was to control these plugins primarily  
with a properties file, but allowing overrides using command line  
properties.  I recall writing a primitive version of the command line  
packager but never tested it and I'm not sure if I committed it  
before my hard drive broke.


Something similar should work for the assembler.  One question I have  
about this is, where do the dependencies come from?  The maven  
assembly plugin makes sure all the dependencies for the config are  
copied from the maven repo into the geronimo repo.  I guess a command  
line version of this should fail if the dependencies aren't already  
in the repo?  Or should it accept some other repo anyway?  Or use a  
remote maven repo?  I don't know.


One missing piece that perhaps can be added to the assembly plugin as  
well is modification of config.xml.  I suppose a good start would be  
to have a flag that indicates whether the config should be loaded or  
not, and, similarly to the online deployer, either add an element to  
config.xml or set load="true" if the flag says to load the config.


Unless someone twists my arm severely I was planning on looking at  
this again after 2 other items, jetspeed integration and a  
transaction manager patch: if you wanted to get started on this first  
I'd be very happy :-).  Command line tools are not something I know  
how to make useable so I'm sure anything I came up with would need  
editing by others anyway.


many thanks,
david jencks



Thanks,
Toby

Re: javamail InternetAddress parsing.

[Bruce Snyder]

On 1/4/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:

> Nice work.  My preference would be RFC822.  However, I do wonder how
> many people might get bitten by this - that are depending on the broken
> behavior.  Sun's JavaMail has been around for quite a while.  Maybe a
> "org.apache.geronimo.be.broken.like.sun" property to allow people that
> do depend on it to turn it on?

Exactly what I was going to suggest. Make sure that the spec APIs
reflect the spec and make the implementation cover the bugginess of
Sun's impl.

Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL 
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)

Re: javamail InternetAddress parsing.

[David Jencks]

I'd prefer RFC822 compliance.  I have no way to judge whether a  
compatibility mode for sun's implementation would be needed but would  
prefer  not to complicate our code with it if at all possible.


thanks
david jencks

On Jan 4, 2006, at 4:07 AM, Rick McGuire wrote:

I'm trying to write a fuller implementation of the  
InternetAddress.parseHeader() method for the Geronimo javamail  
implementation.  I've been writing some tests to see how the Sun  
javamail implementation is handling various addresses, and then  
rolling these tests into the Geronimo junit tests for InternetAddress.
While doing this, I ran the existing junit tests against the Sun  
javamail package and discovered that the Sun version failed some of  
the Geronimo unit tests!  Specifically, any of the group address  
tests in InternetAddressTest where the group did not contain a  
leading phrase did not get recognized as a group address.  Thus the  
tests for ":[EMAIL PROTECTED];" and ":[EMAIL PROTECTED], [EMAIL PROTECTED];" failed when  
run against the Sun javamail version.


It would be fairly simple to fix the Geronimo version to match the  
Sun results and fix the tests as well, but I'm not convinced that  
either version is handling this correctly.  RFC822 specifies that  
the tag phrase before the ":" in an address is required.  So  
":[EMAIL PROTECTED];" is not a valid group, but "group:[EMAIL PROTECTED]'" is.  The  
Geronimo versions appears to be incorrect, both in the  
implementation and the unit test.
However, according the Sun version is parsing ":[EMAIL PROTECTED];" as  
being a simple internet address, retaining both the ":" and ";" as  
part of the address.  Strict conformance to RFC822 would consider  
this to be an error rather than a simple address, and I don't  
believe most mail servers would accept that syntax.
So, what should I target here?  Compatibility with the Sun version,  
or conformance to the RFC822 specification?


Rick

Re: DB Info portlet is not working!!??

[David Jencks]

In trunk, the objectname should have 1.0-SNAPSHOT rather than 1.0.  I hope in a day or two someone will update this to 1.1-SNAPSHOT.We need some way of avoiding these variable version numbers hardcoded in numerous places.thanksdavid jencksOn Jan 4, 2006, at 8:34 AM, Vamsavardhana Reddy wrote:Joe,  The objectname referenced is same as the one from your last mail.  Problem might be something else.  -VamsiOn 1/4/06, Joe Bohn <[EMAIL PROTECTED]> wrote: I just checked and it appears that this change is included in trunk (ifyou have a recent enough version).   Perhaps the objectname changed yetagain.  I don't have a working version of trunk at the moment to check and see if I get the same error or not.  Can you check to see if youhave the fix included in your image.  That should let us know if theerror is the old one or something new.Check your version ofapplications/console-standard/src/java/org/apache/geronimo/console/internaldb/DerbyConnectionUtil.java and see if the objectname referenced isgeronimo.server:J2EEApplication=null,J2EEServer=geronimo,JCAResource=geronimo/system-database/1.0/car,j2eeType=JCAManagedConnectionFactory,name=SystemDatasourceJoe Vamsavardhana Reddy wrote:> The version I am using is built from trunk.>> -Vamsi>> On 1/4/06, *Joe Bohn* <[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote:>> What version of Geronimo are you using?>> There was a problem with this that was fixed in 1.0 by Paul McMahan > http://issues.apache.org/jira/browse/GERONIMO-1373> >> Perhaps this patch didn't get applied to trunk.>> Joe>> Vamsavardhana Reddy wrote:>  > I notice that the DB Info portlet in Geronimo Console is not > displaying>  > any information.  No error is logged to geronimo.log .  Only>  > java.sql.SQLException is output to the command window running> Geronimo.>  > Has anybody else came across this? >> --> Joe Bohn> [EMAIL PROTECTED] [EMAIL PROTECTED]>>> "He is no fool who gives what he cannot keep, to gain what he cannot > lose."   -- Jim Elliot>>--Joe Bohn[EMAIL PROTECTED]"He is no fool who gives what he cannot keep, to gain what he cannot lose."   -- Jim Elliot

Re: javamail InternetAddress parsing.

[Rick McGuire]

Rajith Attapattu wrote:

I came across the same problem when trying to implement POP3 version 
of the Message.
 
For now I relied on the Sun impl of the MimeMessage and it did have 
problems of parsing the headers properly especially the InternetAddress.
 
So is Rick going to work on this and have our own MimeMessage impl ???


We're going to be relying on our own implementation of all of the 
javamail classes.  Unfortunately, as I discovered, the Geronimo version 
is not complete yet.  I'm working on completing the implementation of 
InternetAddress, plus some changes in Transport.  If you know what needs 
to be fixed in MimeMessage, you ahead and begin work on that.


 
If so then I can simply extend and do the POP3 stuff with it. But I am 
willing to help to since it's just not nice to sit back and let Rick 
do the dirty work.
So Rick if you can tell me when I can chip in then we can finish it 
quickly and then I can finish with the POP3 as well.
 
Regards,
 
Rajith Attapattu.
 
On 1/4/06, *Geir Magnusson Jr* <[EMAIL PROTECTED] 
> wrote:




Jacek Laskowski wrote:
> 2006/1/4, Geir Magnusson Jr <[EMAIL PROTECTED]
>:
>
>
>>Nice work.  My preference would be RFC822.  However, I do wonder how
>>many people might get bitten by this - that are depending on the
broken
>>behavior.  Sun's JavaMail has been around for quite a
while.  Maybe a
>>"org.apache.geronimo.be.broken.like.sun" property to allow
people that
>>do depend on it to turn it on?
>
>
> Seriously, that /might/ be helpful, e.g. while migrating apps to
Geronimo.
>

I was dead serious :)

Right now, it appears that we have more people working on JavaMail
implementation than Sun does.  Granted, theirs is complete, but still.
This is an area where it would be nice to see an OSS community
working,
and it's darn useful software as well.

*If* Sun's bug is something people depend on, then we wouldn't want to
make our software unusable by them - we'd also be letting them know
their apps aren't RFC compliant, and they'd have the option to fix at
their choosing.

geir

Re: DB Info portlet is not working!!??

[Vamsavardhana Reddy]

Joe,

The objectname referenced is same as the one from your last mail.  Problem might be something else.

-VamsiOn 1/4/06, Joe Bohn <[EMAIL PROTECTED]> wrote:
I just checked and it appears that this change is included in trunk (ifyou have a recent enough version).   Perhaps the objectname changed yetagain.  I don't have a working version of trunk at the moment to check
and see if I get the same error or not.  Can you check to see if youhave the fix included in your image.  That should let us know if theerror is the old one or something new.Check your version ofapplications/console-standard/src/java/org/apache/geronimo/console/internaldb/DerbyConnectionUtil.java
and see if the objectname referenced isgeronimo.server:J2EEApplication=null,J2EEServer=geronimo,JCAResource=geronimo/system-database/1.0/car,j2eeType=JCAManagedConnectionFactory,name=SystemDatasourceJoe
Vamsavardhana Reddy wrote:> The version I am using is built from trunk.>> -Vamsi>> On 1/4/06, *Joe Bohn* <[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote:>> What version of Geronimo are you using?>> There was a problem with this that was fixed in 1.0 by Paul McMahan
> http://issues.apache.org/jira/browse/GERONIMO-1373> >> Perhaps this patch didn't get applied to trunk.>> Joe>> Vamsavardhana Reddy wrote:>  > I notice that the DB Info portlet in Geronimo Console is not
> displaying>  > any information.  No error is logged to geronimo.log .  Only>  > java.sql.SQLException is output to the command window running> Geronimo.>  > Has anybody else came across this?
>> --> Joe Bohn> [EMAIL PROTECTED] [EMAIL PROTECTED]>>> "He is no fool who gives what he cannot keep, to gain what he cannot
> lose."   -- Jim Elliot>>--Joe Bohn[EMAIL PROTECTED]"He is no fool who gives what he cannot keep, to gain what he cannot
lose."   -- Jim Elliot

Re: [daytrader] 1.0 Release Candidate - get exception when logging in

[Jacek Laskowski]

2006/1/4, Matt Hogstrom <[EMAIL PROTECTED]>:
> John,
>
> You do need to populate the database first.  I'll modify the App to Suggest 
> that
> action to people.  We didn't want to ship a populated database as it bloats 
> the
> download image size.

Hi Matt,

What about a separate welcome page with a link that would trigger an
action to populate the db at first? That's a similar concept to what
is found in PetStore and Adventure Builder.

Jacek

Re: [Fwd: [Vote] 1.0 Release - Do we ship it?]

[Geir Magnusson Jr]

I'm not sure that's true if changes were made post the initial vote. 
Formally, you want the PMC to vote on what is going to be released, and 
if it changed from the "lets do a release" to "here's the release", we 
want the additional vote to at least protect the release manager - that 
person is then just acting on behalf of the ASF (via the PMCs wishes) 
rather than independently.


See my other post on this subject because it's an interesting problem.

geir

Davanum Srinivas wrote:

Matt,

You have already been authorized to make the release, even this vote
was strictly not necessary. It's you call as to when to make the
actual release binaries and send announcements.

thanks,
dims

On 1/4/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:


Thanks to those who have provided their input thus far.  For those who are
interested in casting a vote.  Please take the time to download and test the
server out.

Can someone help out on the process to follow in terms of quorum and time?

Here are the votes so far:

+1
Sachin Patel
Davanum Srinivas
Jeff Genender
Alan Cabrera
David Blevins
David Jencks
Bruce Snyder
Kevan Miller
Dain Sundstrom
Matt Hogstrom
Gianny Damour
John Sisson
Jacek Laskowski

-1
None





--
Davanum Srinivas : http://wso2.com/blogs/

Release procedure (was Re: [Fwd: [Vote] 1.0 Release - Do we ship it?])

[Geir Magnusson Jr.]

my vote was of course with the expectation that it passes the TCK...

This brings up an interesting question, and a novel one since passing  
the TCK is an additional step on our release procedures that most  
projects don't worry about and it is very critical for us.


1) Right now, we vote on releasing a certain rev # in SVN head.  I  
think this is important to continue to do independent of the TCK,  
because it establishes a base of agreement before the heavy lifting  
of TCK passing is done.  (Of course, CI might help ensure that the  
official TCK step is less work/less surprises)


2) We then branch/tag/whatever, produce a binary, and run the TCK.

So now comes the question, what next?  We've learned that offering  
the tested binaries to the public as a release candidate is good -  
people find problems.  So do we do that from now on as a matter of  
course for some time (x days) and then vote on the final release?


That way we all agree to live with whatever bugs were found in the  
release candidate (if there were any found) or decide that they were  
too severe, and we fix and then try again.


Are there alternatives?

geir

On Jan 3, 2006, at 12:35 PM, Alan D. Cabrera wrote:


Date: Tue, 03 Jan 2006 09:21:30 -0500
From: Matt Hogstrom <[EMAIL PROTECTED]>

All,

We have had the last candidate out and available since 12/22.  I  
personally have
had a chance to put the 12/22 build under performance stress and  
I'm satisfied
that the build is stable and runs in a variety of modes using  
DayTrader.


Despite the Christmas Holidays I have seen some traffic related  
to htis release
on the list so some folks have been kicking it around as well.   
At this time I'd

like to call a vote to release 1.0.

[ ] +1 Release 1.0
[ ] -1 Do not release 1.0 (Reasons included)


Does it pass the TCK?  I will vote no until it does.


Regards,
Alan




--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: [Fwd: [Vote] 1.0 Release - Do we ship it?]

[Geir Magnusson Jr.]

+1

Matt, have you considered using a gmail account until you fix this?


On Jan 3, 2006, at 9:48 AM, Sachin Patel wrote:


forwarding this on behalf of Matt...

- sachin



Begin forwarded message:


From: Matt Hogstrom <[EMAIL PROTECTED]>
Date: January 3, 2006 9:47:28 AM EST
To: [EMAIL PROTECTED]
Subject: [Fwd: [Vote] 1.0 Release - Do we ship it?]

Can you forward thsi for me?  I'm still getting SPAM errors.  I've  
sent a note to Ken to see if he can help me decipher what's going on.


 Original Message 
Subject: [Vote] 1.0 Release - Do we ship it?
Date: Tue, 03 Jan 2006 09:21:30 -0500
From: Matt Hogstrom <[EMAIL PROTECTED]>
To: dev@geronimo.apache.org

All,

We have had the last candidate out and available since 12/22.  I  
personally have
had a chance to put the 12/22 build under performance stress and  
I'm satisfied
that the build is stable and runs in a variety of modes using  
DayTrader.


Despite the Christmas Holidays I have seen some traffic related to  
htis release
on the list so some folks have been kicking it around as well.  At  
this time I'd

like to call a vote to release 1.0.

[ ] +1 Release 1.0
[ ] -1 Do not release 1.0 (Reasons included)

Looks like we got through the last remaining significant bugs and  
thansk to all

who worked up to the end to get this release out there.

Matt







--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: DB Info portlet is not working!!??

[Joe Bohn]

I just checked and it appears that this change is included in trunk (if 
you have a recent enough version).   Perhaps the objectname changed yet 
again.  I don't have a working version of trunk at the moment to check 
and see if I get the same error or not.  Can you check to see if you 
have the fix included in your image.  That should let us know if the 
error is the old one or something new.


Check your version of 
applications/console-standard/src/java/org/apache/geronimo/console/internaldb/DerbyConnectionUtil.java

and see if the objectname referenced is
geronimo.server:J2EEApplication=null,J2EEServer=geronimo,JCAResource=geronimo/system-database/1.0/car,j2eeType=JCAManagedConnectionFactory,name=SystemDatasource

Joe

Vamsavardhana Reddy wrote:

The version I am using is built from trunk.

-Vamsi

On 1/4/06, *Joe Bohn* <[EMAIL PROTECTED] 
> wrote:


What version of Geronimo are you using?

There was a problem with this that was fixed in 1.0 by Paul McMahan
http://issues.apache.org/jira/browse/GERONIMO-1373


Perhaps this patch didn't get applied to trunk.

Joe

Vamsavardhana Reddy wrote:
 > I notice that the DB Info portlet in Geronimo Console is not
displaying
 > any information.  No error is logged to geronimo.log .  Only
 > java.sql.SQLException is output to the command window running
Geronimo.
 > Has anybody else came across this?

--
Joe Bohn
[EMAIL PROTECTED] 

"He is no fool who gives what he cannot keep, to gain what he cannot
lose."   -- Jim Elliot




--
Joe Bohn
[EMAIL PROTECTED]

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Re: POP3 and IMAP support

[Rajith Attapattu]

http://issues.apache.org/jira/browse/GERONIMO-1341?page=all
 
Thanks Bruce,
 
Looking forward for your comments !!!Regards,
 
Rajith Attapattu.
 
On 1/3/06, Bruce Snyder <[EMAIL PROTECTED]> wrote:
On 1/3/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:> On Jan 3, 2006, at 1:07 PM, Rajith Attapattu wrote:
>> >  Dain when are u going to apply the patch (with the POP3  impl) ??> > I assume it's after 1.0 release.>> I actually forgot about it.  I'm kind of in the middle of something,
> so I won't be able to get to it this week.>> Bruce, can you apply the patch?Yes, what's the number for the JIRA issue?Bruce--perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E);'Apache Geronimo (http://geronimo.apache.org/)

WebContainer Statistics

[anita kulshreshtha]

Aaron, Joe and others, 
   I have few questions about the WebConnector. I must
admit that I have not kept track of the patches that
were submitted. May be some of these issues have
already been decided. 
1. Are there any plans to make
NetworkConnector/WebConnector a J2EEManagedObject? If
yes, their statistics can be made available without
the changes proposed in 2. 
2. If not, The connector statistics can be made
available via WebContainer as follows (using JSR 77
notations) -
  WebContainerStats :
   +  getConnectors() : WebConnectorStats[]
   +  get.:  ...Statistic
   +  :  .

   WebConnectorStats:
   + .

To do this, StatsImpl will also have to be
changed - 
. Add a method addStat(String name, Stats value) 
. Change Statistic[] getStatistics() method to
take care of the new structure.
These changes will be required in the
future to implement things like JMSStats defined in
JSR77.6.24. 
I would like to use either 1 or 2 to make
Tomcat Connector Statistics available.

Thanks
Anita



__ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 

Re: javamail InternetAddress parsing.

[Rajith Attapattu]

I came across the same problem when trying to implement POP3 version of the Message.
 
For now I relied on the Sun impl of the MimeMessage and it did have problems of parsing the headers properly especially the InternetAddress.
 
So is Rick going to work on this and have our own MimeMessage impl ???
 
If so then I can simply extend and do the POP3 stuff with it. But I am willing to help to since it's just not nice to sit back and let Rick do the dirty work.
So Rick if you can tell me when I can chip in then we can finish it quickly and then I can finish with the POP3 as well.
 
Regards,
 
Rajith Attapattu.
 
On 1/4/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
Jacek Laskowski wrote:> 2006/1/4, Geir Magnusson Jr <[EMAIL PROTECTED]
>:Nice work.  My preference would be RFC822.  However, I do wonder how>>many people might get bitten by this - that are depending on the broken>>behavior.  Sun's JavaMail has been around for quite a while.  Maybe a
>>"org.apache.geronimo.be.broken.like.sun" property to allow people that>>do depend on it to turn it on?>>> Seriously, that /might/ be helpful, e.g. while migrating apps to Geronimo.
>I was dead serious :)Right now, it appears that we have more people working on JavaMailimplementation than Sun does.  Granted, theirs is complete, but still.This is an area where it would be nice to see an OSS community working,
and it's darn useful software as well.*If* Sun's bug is something people depend on, then we wouldn't want tomake our software unusable by them - we'd also be letting them knowtheir apps aren't RFC compliant, and they'd have the option to fix at
their choosing.geir

Re: DB Info portlet is not working!!??

[Vamsavardhana Reddy]

The version I am using is built from trunk.

-VamsiOn 1/4/06, Joe Bohn <[EMAIL PROTECTED]> wrote:
What version of Geronimo are you using?There was a problem with this that was fixed in 1.0 by Paul McMahanhttp://issues.apache.org/jira/browse/GERONIMO-1373
Perhaps this patch didn't get applied to trunk.JoeVamsavardhana Reddy wrote:> I notice that the DB Info portlet in Geronimo Console is not displaying> any information.  No error is logged to 
geronimo.log .  Only> java.sql.SQLException is output to the command window running Geronimo.> Has anybody else came across this?--Joe Bohn[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannotlose."   -- Jim Elliot

Re: DB Info portlet is not working!!??

[Joe Bohn]

What version of Geronimo are you using?

There was a problem with this that was fixed in 1.0 by Paul McMahan
http://issues.apache.org/jira/browse/GERONIMO-1373

Perhaps this patch didn't get applied to trunk.

Joe

Vamsavardhana Reddy wrote:
I notice that the DB Info portlet in Geronimo Console is not displaying 
any information.  No error is logged to geronimo.log .  Only 
java.sql.SQLException is output to the command window running Geronimo.  
Has anybody else came across this?


--
Joe Bohn
[EMAIL PROTECTED]

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Re: [Fwd: [Vote] 1.0 Release - Do we ship it?]

[Davanum Srinivas]

Matt,

You have already been authorized to make the release, even this vote
was strictly not necessary. It's you call as to when to make the
actual release binaries and send announcements.

thanks,
dims

On 1/4/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
> Thanks to those who have provided their input thus far.  For those who are
> interested in casting a vote.  Please take the time to download and test the
> server out.
>
> Can someone help out on the process to follow in terms of quorum and time?
>
> Here are the votes so far:
>
> +1
> Sachin Patel
> Davanum Srinivas
> Jeff Genender
> Alan Cabrera
> David Blevins
> David Jencks
> Bruce Snyder
> Kevan Miller
> Dain Sundstrom
> Matt Hogstrom
> Gianny Damour
> John Sisson
> Jacek Laskowski
>
> -1
> None
>


--
Davanum Srinivas : http://wso2.com/blogs/

Re: [Fwd: [Vote] 1.0 Release - Do we ship it?]

[Matt Hogstrom]

Thanks to those who have provided their input thus far.  For those who are 
interested in casting a vote.  Please take the time to download and test the 
server out.


Can someone help out on the process to follow in terms of quorum and time?

Here are the votes so far:

+1
Sachin Patel
Davanum Srinivas
Jeff Genender
Alan Cabrera
David Blevins
David Jencks
Bruce Snyder
Kevan Miller
Dain Sundstrom
Matt Hogstrom
Gianny Damour
John Sisson
Jacek Laskowski

-1
None

Re: [daytrader] 1.0 Release Candidate - get exception when logging in

[Matt Hogstrom]

John,

You do need to populate the database first.  I'll modify the App to Suggest that 
action to people.  We didn't want to ship a populated database as it bloats the 
download image size.


John Sisson wrote:

Hi Matt,

I installed the 1.0 release candidate (tomcat build) on Solaris x86.  I 
accessed the daytrader page, clicked on the "Go Trade!" link and then 
clicked on the "Log in" button.  I then got a 
javax.ejb.ObjectNotFoundException stack trace.


I found that if I went to the "Configuration" screen in daytrader and 
ran the "(Re)-populate Trade Database" that everything seems to works fine.


Is the database meant to be already populated when Geronimo is 
installed?  I was under the impression it should be because the 
daytrader/docs/tradeFAQ.html file it mentions "The Trade database is 
initially populated ..".


I also tried building the 1.0.0 tag myself and got the same problem.

Regards,

John

Re: problem with Geronimo-1.0

[Aaron Mulder]

Rakesh,

It would help to get the information I asked for: "a more complete
chunk of your code, plus all the pertinent output and a full stack
trace.  Also, please mention what you've deployed into the server (if
anything) other than this application."  Again, it's impossible to
debug your problem without knowing what your code is doing.

Let me try to explain in more detail.  Here's the code you posted:

Set gbeanNames = kernel.listGBeans(gbQuery);
for (Iterator i = gbeanNames.iterator(); i.hasNext();) {
  ObjectName gbeanName = (ObjectName) i.next();
  System.out.println(gbeanName1);
}
TransactionManager tm = (TransactionManager)
kernel.getProxyManager().createProxy(gbeanName,
TransactionManager.class);

Now, the gbeanName variable in the for loop is declared in the for
loop, so it's not the same as the gbeanName variable in the
createProxy call.  Further, the println in the loop is using a
variable called gbeanName1.  So in these three lines, there are three
different variables being used.  Of them, we only see where gbeanName
in the loop is assigned, but it's never used.  We need to know (and
you need to find out) where the values gbeanName1 and gbeanName (the
one outside of the loop) are assigned.  Note that YOU ARE NOT USING
THE RESULT OF THE listGBeans CALL FOR ANYTHING (except to control the
number of times you print gbeanName1) in the code you supplied, so
when people suggest that listGBeans is broken that conclusion is not
supported by the code you posted.  That's why I'm asking you to post
more, and hunt down how those variables are being assigned.

On 1/4/06, Ranjan, Rakesh (Cognizant) <[EMAIL PROTECTED]> wrote:
> Hi,
>
>  Sorry Aaron about confidential information footers. But i cann't do anything 
> because it is generated by the mail server.

Presumably your company doesn't want you sending information to the
world from your company e-mail account if they attach that to every
message.  I sent you an invitation to use GMail for your personal
correspondance.  :)

Thanks,
Aaron

> The value contained in the variable 'gbeanName' is :
>
>
>
> geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionManager,
>
> name=TransactionManaer
>
>
>  I have tried the query using the full object name:
>
>
>
> geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-server/1.0/car,J2EEServer=geronimo,
>  j2eeType=TransactionManager, name=TransactionManager
>
>
>
> Its working correctly. I am able to get the TransactionManager instance using 
> the full GBean name.
>
> But  i would like to know why this thing is not working with 
> kernel.listGBeans(). Is it a bug in Geronimo-1.0 ?
>
>  Rakesh Ranjan
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Re: problem with Geronimo-1.0
>
> Grr, more confidential information footers.  Please don't do that to
>  public mailing lists!  If your information is confidential, don't send
>  it to the world, and if it's not confidential, please don't assault us
>  with the legalese!
>
>  Anyway, now that that's off my chest, Geronimo cannot (well,
>  definitely *should* not) produce an incorrect ObjectName out of thin
>  air, so you need to figure out where you're getting the ObjectName
>  containing org/apache/geronimo/Server from.  In the code snippet you
>  showed, you do a lookup and print all the results, but then you try to
>  create a proxy using a variable called gbeanName (which I suspect is
>  what's failing) and you never showed us what that variable holds and
>  where you got the value in that variable.  Maybe it's hardcoded or in
>  a config file or something?  You also didn't should the output of your
>  program where it prints all the matching transaction manager names.
>  You also didn't give a proper stack trace.  So it's real hard to
>  troubleshoot from here.  You might want to run it under a debugger and
>  figure out where the o/a/g/Server is coming from.
>
>  If none of this helps you figure out what's going on, please post a
>  more complete chunk of your code, plus all the pertinent output and a
>  full stack trace.  Also, please mention what you've deployed into the
>  server (if anything) other than this application.
>
>  Thanks,
>  Aaron
>
>  On 1/4/06, Ranjan, Rakesh (Cognizant) <[EMAIL PROTECTED]> wrote:
>  >
>  >
>  >
>  > Hi friends,
>  >
>  > I am trying to get a reference to Geronimo TransactionManager. For this, I 
> have done the following things : -
>  >
>  > a)   Getting a reference to the kernel using the KernelRegistry class.
>  >
>  > b)   Then searching the TransactionManager GBean using a pattern.
>  >
>  > c)   Finally getting the TransactionManager reference using the 
> searched Gbean.
>  >
>  >
>  >
>  >
>  >
>  > Here the code snippet :
>  >
>  >
>  >
>  > Kernel kernel=KernelRegistry.getSingleKernel();
>  >
>  > ObjectName gbQuery = 
> JMXUtil.getObjectName("*:j2eeType=TransactionManager,*");
>  >
>  > Set gbeanNames = kernel.listGBeans(gbQuery);
>

DB Info portlet is not working!!??

[Vamsavardhana Reddy]

I notice that the DB Info portlet in Geronimo Console is not displaying
any information.  No error is logged to geronimo.log .  Only
java.sql.SQLException is output to the command window running
Geronimo.  Has anybody else came across this?

[jira] Updated: (GERONIMO-1133) UUID primary key generator

[Rakesh Ranjan (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-1133?page=all ]

Rakesh Ranjan updated GERONIMO-1133:


Description: 
This is a custom-generator GBean which implements 
org.tranql.pkgenerator.PrimaryKeyGenerator. This GBean is able to create 
automatically generated UUID primary key for unknown primary keys. It uses. the 
org.apache.axis components.uuid.FastUUIDGen class for generating the UUID 
primary key.

As we know JBoss use a automatically generated UUID primary key for unknown 
primary keys. That's why we are able to deploy the adventure builder 
application successfully on JBoss. But it create problem when we deploy it in 
Geronimo. Using this GBean that issue can be resolved. I have tested it with a 
the adventure builder application . It is working perfectly. 

We can use this GBean in openejb-jar.xml as follows : -

create a jar archive 'keygenerator.jar' and copy it inside the directory ' 
$GERONIMO_HOME\repository\keygenerator\jars\ '

then deploy the GBean as follows : 


http://geronimo.apache.org/xml/ns/deployment"; 
configId="geronimoKeyGenerator">


keygenerator/jars/keygenerator.jar


axis/jars/axis-1.3-svn293059-geronimo.jar






Then use the deployed GBean in the openejb-jar.xml as follows : 
-







geronimo.server:J2EEApplication=null,J2EEModule=geronimoKeyGenerator,J2EEServer=geronimo,j2eeType=GBean,name=UUIDGBean



java.lang.String

  

  



  was:Many application written for JBoss use a automatically generated UUID 
primary key for unknown primary keys.  We need a UUID generator so these 
applications can easily migrate to Geronimo.


> UUID primary key generator
> --
>
>  Key: GERONIMO-1133
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1133
>  Project: Geronimo
> Type: New Feature
>   Components: OpenEJB
> Versions: 1.0-M5
> Reporter: Dain Sundstrom
> Assignee: Gianny Damour
>  Fix For: 1.1
>  Attachments: UUIDGBean.java, keygenerator.xml
>
> This is a custom-generator GBean which implements 
> org.tranql.pkgenerator.PrimaryKeyGenerator. This GBean is able to create 
> automatically generated UUID primary key for unknown primary keys. It uses. 
> the org.apache.axis components.uuid.FastUUIDGen class for generating the UUID 
> primary key.
> As we know JBoss use a automatically generated UUID primary key for unknown 
> primary keys. That's why we are able to deploy the adventure builder 
> application successfully on JBoss. But it create problem when we deploy it in 
> Geronimo. Using this GBean that issue can be resolved. I have tested it with 
> a the adventure builder application . It is working perfectly. 
> We can use this GBean in openejb-jar.xml as follows : -
> create a jar archive 'keygenerator.jar' and copy it inside the directory ' 
> $GERONIMO_HOME\repository\keygenerator\jars\ '
> then deploy the GBean as follows : 
> 
> http://geronimo.apache.org/xml/ns/deployment"; 
> configId="geronimoKeyGenerator">
> 
>   keygenerator/jars/keygenerator.jar
> 
> 
>   axis/jars/axis-1.3-svn293059-geronimo.jar
> 
> 
> 
> 
> Then use the deployed GBean in the openejb-jar.xml as follows : 
> -
> 
> 
> 
> geronimo.server:J2EEApplication=null,J2EEModule=geronimoKeyGenerator,J2EEServer=geronimo,j2eeType=GBean,name=UUIDGBean
> 
> java.lang.String
>   
>   

-- 
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-1133) UUID primary key generator

[Rakesh Ranjan (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-1133?page=all ]

Rakesh Ranjan updated GERONIMO-1133:


Attachment: UUIDGBean.java
keygenerator.xml

> UUID primary key generator
> --
>
>  Key: GERONIMO-1133
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1133
>  Project: Geronimo
> Type: New Feature
>   Components: OpenEJB
> Versions: 1.0-M5
> Reporter: Dain Sundstrom
> Assignee: Gianny Damour
>  Fix For: 1.1
>  Attachments: UUIDGBean.java, keygenerator.xml
>
> Many application written for JBoss use a automatically generated UUID primary 
> key for unknown primary keys.  We need a UUID generator so these applications 
> can easily migrate to Geronimo.

-- 
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

Removing an archive from repository

[Vamsavardhana Reddy]

As of now the Repository Viewer portlet in Geronimo Console provides a
mechanism to add/install an archive.  Should there be a provision
to remove/uninstall an archive from the repository?

Re: javamail InternetAddress parsing.

[Geir Magnusson Jr]

Jacek Laskowski wrote:

2006/1/4, Geir Magnusson Jr <[EMAIL PROTECTED]>:



Nice work.  My preference would be RFC822.  However, I do wonder how
many people might get bitten by this - that are depending on the broken
behavior.  Sun's JavaMail has been around for quite a while.  Maybe a
"org.apache.geronimo.be.broken.like.sun" property to allow people that
do depend on it to turn it on?



Seriously, that /might/ be helpful, e.g. while migrating apps to Geronimo.



I was dead serious :)

Right now, it appears that we have more people working on JavaMail 
implementation than Sun does.  Granted, theirs is complete, but still. 
This is an area where it would be nice to see an OSS community working, 
and it's darn useful software as well.


*If* Sun's bug is something people depend on, then we wouldn't want to 
make our software unusable by them - we'd also be letting them know 
their apps aren't RFC compliant, and they'd have the option to fix at 
their choosing.


geir

Re: GBean for auto generation of primary key

[Ranjan, Rakesh \(Cognizant\)]

 
  
   
  
  
   
  
  
   
  
 
 
 
  
   
  
  
   
  
  
  Hi Jacek,
   
  I think the issue for which I am talking about is
  resolved now. Yet I am sending that mail again.
   
  Rakesh
   
  I have a
  written a custom-generator GBean which implements org.tranql.pkgenerator.PrimaryKeyGenerator. This
  GBean is able to create automatically generated UUID primary key for unknown
  primary keys. It uses. the org.apache.axis components.uuid.FastUUIDGen class for
  generating the UUID primary key.
  As we know JBoss
  use a automatically generated UUID primary key for unknown primary keys.
  That’s why we are able to deploy the adventure builder application
  successfully on JBoss. But it create problem when we deploy it in Geronimo.
  Using this GBean that issue can be resolved. I have tested it with a the
  adventure builder application . It is working perfectly. 
  We can use this
  GBean in openejb-jar.xml
  as follows : -
  
  
  id
  
  
  
  geronimo.server:J2EEApplication=null,J2EEModule=geronimoKeyGenerator,J2EEServer=geronimo,j2eeType=GBean,name=UUIDGBean
  
  java.lang.String
    
    
  
    
  
   
  So,
  I hope adventure builder deployment issue will be resolved very soon
  
 
 
  
   
  
  
   
  
  
   
  
 
 


Re: GBean for auto generation of primary key

 

Reply (Restricted by the Administrator)
| Show Only this Message 



2005/12/16, Ranjan, Rakesh
(Cognizant) <[EMAIL PROTECTED]>: 

> So, I hope adventure builder deployment issue will be resolved very soon. 

Hi, 

I must've missed it, but what issue are you talking about? 

> Rakesh Ranjan 

Jacek 

 







This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. 
Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly 
prohibited and may be unlawful.

  Visit us at http://www.cognizant.com

Re: problem with Geronimo-1.0

[Ranjan, Rakesh \(Cognizant\)]

“T” is missing only in the mail. But this is not
the problem. It’s a copying mistake.

 

Rakesh Ranjan

 

 

Re: problem with Geronimo-1.0

 

 Is there a typo in the code snippet you gave us 
: 
 TransactionManager tm = (TransactionManager) 
kernel.getProxyManager().createProxy(gbeanName, 
ransactionManager.class); 
     The missing "T" in the TransactionManager.class 

Thanks 
Anita 
      

--- Aaron Mulder <[EMAIL PROTECTED]> 
wrote: 

> Grr, more confidential information footers.  Please 
> don't do that to 
> public mailing lists!  If your information is 
> confidential, don't send 
> it to the world, and if it's not confidential, 
> please don't assault us 
> with the legalese! 
> 
> Anyway, now that that's off my chest, Geronimo 
> cannot (well, 
> definitely *should* not) produce an incorrect 
> ObjectName out of thin 
> air, so you need to figure out where you're getting 
> the ObjectName 
> containing org/apache/geronimo/Server from.  In the 
> code snippet you 
> showed, you do a lookup and print all the results, 
> but then you try to 
> create a proxy using a variable called gbeanName 
> (which I suspect is 
> what's failing) and you never showed us what that 
> variable holds and 
> where you got the value in that variable.  Maybe 
> it's hardcoded or in 
> a config file or something?  You also didn't should 
> the output of your 
> program where it prints all the matching transaction 
> manager names. 
> You also didn't give a proper stack trace.  So it's 
> real hard to 
> troubleshoot from here.  You might want to run it 
> under a debugger and 
> figure out where the o/a/g/Server is coming from. 
> 
> If none of this helps you figure out what's going 
> on, please post a 
> more complete chunk of your code, plus all the 
> pertinent output and a 
> full stack trace.  Also, please mention what you've 
> deployed into the 
> server (if anything) other than this application. 
> 
> Thanks, 
>     Aaron 
> 
> On 1/4/06, Ranjan, Rakesh
(Cognizant) 
> <[EMAIL PROTECTED]> wrote: 
> > 
> > 
> > 
> > Hi friends, 
> > 
> > I am trying to get a reference to Geronimo 
> TransactionManager. For this, I have done the 
> following things : - 
> > 
> > a)       Getting a reference to the kernel using 
> the KernelRegistry class. 
> > 
> > b)       Then searching the TransactionManager 
> GBean using a pattern. 
> > 
> > c)       Finally getting the TransactionManager 
> reference using the searched Gbean. 
> > 
> > 
> > 
> > 
> > 
> > Here the code snippet : 
> > 
> > 
> > 
> > Kernel kernel=KernelRegistry.getSingleKernel(); 
> > 
> > ObjectName gbQuery = 
> 
JMXUtil.getObjectName("*:j2eeType=TransactionManager,*"); 
> > 
> > Set gbeanNames = kernel.listGBeans(gbQuery); 
> > 
> > for (Iterator i = gbeanNames.iterator(); 
> i.hasNext();) { 
> > 
> >       ObjectName gbeanName = (ObjectName) 
> i.next(); 
> > 
> >       System.out.println(gbeanName1); 
> > 
> > } 
> > 
> > TransactionManager tm = (TransactionManager) 
> kernel.getProxyManager().createProxy(gbeanName, 
> ransactionManager.class); 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > When I am using this with the Geronimo-1.0-M5, 
> this is working correctly. But with Geronimo-1.0 , 
> this is not working correctly. 
> > 
> > 
> > 
> > With Geronimo-1.0, I am getting the following 
> Exception : 
> > 
> > 
> > 
> > java.lang.IllegalArgumentException: 
> > 
> >  Could not get GBeanInfo for target object: 
> > 
> > 
> 
geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionManager,name=TransactionManager

> > 
> > 
> > 
> > I think kernel.listGBeans() is not working 
> correctly in case of Geronimo-1.0. According to the 
> above code, the GBean is 
> > 
> > 
> 
geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionManager,name=TransactionManager

> > 
> > 
> > 
> > But as much I know, it should be 
> > 
> > 
> > 
> > 
> 
geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-server/1.0/car,J2EEServer=geronimo,j2eeType=TransactionManager,name=TransactionManager

> > 
> > 
> > 
> > Can anybody please help me whether there is any 
> fault with Geronimo-1.0 or something else. 
> > 
> > 
> > 
> > 
> > 
> > Regards, 
> > 
> > Rakesh Ranjan 
> > 
> > 
> > This e-mail and any files transmitted with it are 
> for the sole use of the intended recipient(s) and 
> may contain confidential and privileged information. 
> >  If you are not the intended recipient, please 
> contact the sender by reply e-mail and destroy all 
> copies of the original message. 
> >  Any unauthorized review, use, disclosure, 
> dissemination, forwarding, printing or copying of 
> this email or any action taken in reliance on this 
> e-mail is strictly 
> >  prohibited and may be unlawful. 
> > 
> >    Visit us at http://www.cognizant.com 
> > 
> 







This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may c

Re: offline deployment?

[toby cabot]

On Tue, Jan 03, 2006 at 03:58:55PM -0800, Dain Sundstrom wrote:
> Will the hot deployment directory satisfy you needs?

I tried to think of an approach using hot deployment that would work,
but none are as clean as offline deployment.  But I'm probably a
corner case: I use Geronimo embedded in a system with lots of other
software around it, running in a sealed box rather than a typical
PC-like environment.  I cross-develop; with offline deployment I can
distribute my application into Geronimo during the build process, then
move it to a target machine and run it on a read-only partition.  Of
course I have to move various logs, etc to /var but that's easily done
by tweaks to various plan.xml files.  I've also done some experiments
recently to allow Geronimo to have multiple config-stores so I can
have my core software in read-only storage and deploy other stuff to
/var.

Using hot deployment would be much more complex as I'd have to modify
the hot deployer to read from /var and deploy to a read-write config
store.  It also leaves a lot of processing to the target machines that
currently happens on development machines.  It's do-able but I like
that with offline distribute my code is in a read-only config store so
it can't be messed with.

I've got a workaround with online distribution but it's a clumsier
build process since I have to fire up the server, wait some arbitrary
time for the deployer to become available, distribute, and shut down
the server.  I can probably live with that but offline distribution is
much cleaner.

I recognize that my requirements aren't typical so I'm happy to (as
with multiple config stores) do some work to help make it happen.  I
just don't want to go off half-cocked and end up with something that's
a crime against the Geronimo architecture.  What do you think of the
approach that I mentioned in my previous email?  Am I barking up the
right tree?

Thanks,
Toby

Re: problem with Geronimo-1.0

[anita kulshreshtha]

  Is there a typo in the code snippet you gave us
:
 TransactionManager tm = (TransactionManager) 
kernel.getProxyManager().createProxy(gbeanName,
ransactionManager.class);
 The missing "T" in the TransactionManager.class

Thanks
Anita
  

--- Aaron Mulder <[EMAIL PROTECTED]>
wrote:

> Grr, more confidential information footers.  Please
> don't do that to
> public mailing lists!  If your information is
> confidential, don't send
> it to the world, and if it's not confidential,
> please don't assault us
> with the legalese!
> 
> Anyway, now that that's off my chest, Geronimo
> cannot (well,
> definitely *should* not) produce an incorrect
> ObjectName out of thin
> air, so you need to figure out where you're getting
> the ObjectName
> containing org/apache/geronimo/Server from.  In the
> code snippet you
> showed, you do a lookup and print all the results,
> but then you try to
> create a proxy using a variable called gbeanName
> (which I suspect is
> what's failing) and you never showed us what that
> variable holds and
> where you got the value in that variable.  Maybe
> it's hardcoded or in
> a config file or something?  You also didn't should
> the output of your
> program where it prints all the matching transaction
> manager names. 
> You also didn't give a proper stack trace.  So it's
> real hard to
> troubleshoot from here.  You might want to run it
> under a debugger and
> figure out where the o/a/g/Server is coming from.
> 
> If none of this helps you figure out what's going
> on, please post a
> more complete chunk of your code, plus all the
> pertinent output and a
> full stack trace.  Also, please mention what you've
> deployed into the
> server (if anything) other than this application.
> 
> Thanks,
> Aaron
> 
> On 1/4/06, Ranjan, Rakesh (Cognizant)
> <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > Hi friends,
> >
> > I am trying to get a reference to Geronimo
> TransactionManager. For this, I have done the
> following things : -
> >
> > a)   Getting a reference to the kernel using
> the KernelRegistry class.
> >
> > b)   Then searching the TransactionManager
> GBean using a pattern.
> >
> > c)   Finally getting the TransactionManager
> reference using the searched Gbean.
> >
> >
> >
> >
> >
> > Here the code snippet :
> >
> >
> >
> > Kernel kernel=KernelRegistry.getSingleKernel();
> >
> > ObjectName gbQuery =
>
JMXUtil.getObjectName("*:j2eeType=TransactionManager,*");
> >
> > Set gbeanNames = kernel.listGBeans(gbQuery);
> >
> > for (Iterator i = gbeanNames.iterator();
> i.hasNext();) {
> >
> >   ObjectName gbeanName = (ObjectName)
> i.next();
> >
> >   System.out.println(gbeanName1);
> >
> > }
> >
> > TransactionManager tm = (TransactionManager)
> kernel.getProxyManager().createProxy(gbeanName,
> ransactionManager.class);
> >
> >
> >
> >
> >
> >
> >
> > When I am using this with the Geronimo-1.0-M5,
> this is working correctly. But with Geronimo-1.0 ,
> this is not working correctly.
> >
> >
> >
> > With Geronimo-1.0, I am getting the following
> Exception :
> >
> >
> >
> > java.lang.IllegalArgumentException:
> >
> >  Could not get GBeanInfo for target object:
> >
> >
>
geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionManager,name=TransactionManager
> >
> >
> >
> > I think kernel.listGBeans() is not working
> correctly in case of Geronimo-1.0. According to the
> above code, the GBean is
> >
> >
>
geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionManager,name=TransactionManager
> >
> >
> >
> > But as much I know, it should be
> >
> >
> >
> >
>
geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-server/1.0/car,J2EEServer=geronimo,j2eeType=TransactionManager,name=TransactionManager
> >
> >
> >
> > Can anybody please help me whether there is any
> fault with Geronimo-1.0 or something else.
> >
> >
> >
> >
> >
> > Regards,
> >
> > Rakesh Ranjan
> >
> >
> > This e-mail and any files transmitted with it are
> for the sole use of the intended recipient(s) and
> may contain confidential and privileged information.
> >  If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all
> copies of the original message.
> >  Any unauthorized review, use, disclosure,
> dissemination, forwarding, printing or copying of
> this email or any action taken in reliance on this
> e-mail is strictly
> >  prohibited and may be unlawful.
> >
> >Visit us at http://www.cognizant.com
> >
> 




__ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 

Re: javamail InternetAddress parsing.

[Rick McGuire]

Jacek Laskowski wrote:


2006/1/4, Geir Magnusson Jr <[EMAIL PROTECTED]>:

 


Nice work.  My preference would be RFC822.  However, I do wonder how
many people might get bitten by this - that are depending on the broken
behavior.  Sun's JavaMail has been around for quite a while.  Maybe a
"org.apache.geronimo.be.broken.like.sun" property to allow people that
do depend on it to turn it on?
   



Seriously, that /might/ be helpful, e.g. while migrating apps to Geronimo.

 


geir
   



Jacek

 

Well, it might be easy to do that, since these are just error paths 
anyway.   I think I'll write my code now for strict conformance and 
handle a "buggy.behavior" property later.

Re: javamail InternetAddress parsing.

[Jacek Laskowski]

2006/1/4, Geir Magnusson Jr <[EMAIL PROTECTED]>:

> Nice work.  My preference would be RFC822.  However, I do wonder how
> many people might get bitten by this - that are depending on the broken
> behavior.  Sun's JavaMail has been around for quite a while.  Maybe a
> "org.apache.geronimo.be.broken.like.sun" property to allow people that
> do depend on it to turn it on?

Seriously, that /might/ be helpful, e.g. while migrating apps to Geronimo.

> geir

Jacek

Re: javamail InternetAddress parsing.

[Geir Magnusson Jr]

Rick McGuire wrote:
I'm trying to write a fuller implementation of the 
InternetAddress.parseHeader() method for the Geronimo javamail 
implementation.  I've been writing some tests to see how the Sun 
javamail implementation is handling various addresses, and then rolling 
these tests into the Geronimo junit tests for InternetAddress.
While doing this, I ran the existing junit tests against the Sun 
javamail package and discovered that the Sun version failed some of the 
Geronimo unit tests!  Specifically, any of the group address tests in 
InternetAddressTest where the group did not contain a leading phrase did 
not get recognized as a group address.  Thus the tests for ":[EMAIL PROTECTED];" 
and ":[EMAIL PROTECTED], [EMAIL PROTECTED];" failed when run against the Sun javamail 
version.


It would be fairly simple to fix the Geronimo version to match the Sun 
results and fix the tests as well, but I'm not convinced that either 
version is handling this correctly.  RFC822 specifies that the tag 
phrase before the ":" in an address is required.  So ":[EMAIL PROTECTED];" is 
not a valid group, but "group:[EMAIL PROTECTED]'" is.  The Geronimo versions 
appears to be incorrect, both in the implementation and the unit test.
However, according the Sun version is parsing ":[EMAIL PROTECTED];" as being a 
simple internet address, retaining both the ":" and ";" as part of the 
address.  Strict conformance to RFC822 would consider this to be an 
error rather than a simple address, and I don't believe most mail 
servers would accept that syntax.
So, what should I target here?  Compatibility with the Sun version, or 
conformance to the RFC822 specification?




Nice work.  My preference would be RFC822.  However, I do wonder how 
many people might get bitten by this - that are depending on the broken 
behavior.  Sun's JavaMail has been around for quite a while.  Maybe a 
"org.apache.geronimo.be.broken.like.sun" property to allow people that 
do depend on it to turn it on?


:)

geir


Rick

Re: GBean for auto generation of primary key

[Jacek Laskowski]

2005/12/16, Ranjan, Rakesh (Cognizant) <[EMAIL PROTECTED]>:

> So, I hope adventure builder deployment issue will be resolved very soon.

Hi,

I must've missed it, but what issue are you talking about?

> Rakesh Ranjan

Jacek

Re: javamail InternetAddress parsing.

[Jacek Laskowski]

2006/1/4, Rick McGuire <[EMAIL PROTECTED]>:

> So, what should I target here?  Compatibility with the Sun version, or
> conformance to the RFC822 specification?

Hi,

I think we should stick to RFC822, which is the only definitive source
of information on how JavaMail should work. Besides, Sun's JavaMail
specification may contain bugs.

Before rendering any judgement, I'd be glad to hear other opinions, too.

> Rick

Jacek

Re: problem with Geronimo-1.0

[Ranjan, Rakesh \(Cognizant\)]

Hi,


Sorry Aaron about confidential information footers. But i cann’t do
anything because it is generated by the mail server.

 

The value contained in the variable ‘gbeanName’ is :

 

geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionManager,

name=TransactionManaer


I have tried the query using the full object name:

 

geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-server/1.0/car,J2EEServer=geronimo,
j2eeType=TransactionManager, name=TransactionManager

 

Its working correctly. I am able to get the TransactionManager instance
using the full GBean name.

But  i would like to know why this thing is not working with
kernel.listGBeans(). Is it a bug in Geronimo-1.0 ? 

Rakesh Ranjan 

 

 

 

 

 

 

 

 

 

Re: problem with Geronimo-1.0

Grr, more confidential information footers.  Please don't do that
to 
public mailing lists!  If your information is confidential, don't send 
it to the world, and if it's not confidential, please don't assault us 
with the legalese! 

Anyway, now that that's off my chest, Geronimo cannot (well, 
definitely *should* not) produce an incorrect ObjectName out of thin 
air, so you need to figure out where you're getting the ObjectName 
containing org/apache/geronimo/Server from.  In the code snippet you 
showed, you do a lookup and print all the results, but then you try to 
create a proxy using a variable called gbeanName (which I suspect is 
what's failing) and you never showed us what that variable holds and 
where you got the value in that variable.  Maybe it's hardcoded or in 
a config file or something?  You also didn't should the output of your 
program where it prints all the matching transaction manager names. 
You also didn't give a proper stack trace.  So it's real hard to 
troubleshoot from here.  You might want to run it under a debugger and 
figure out where the o/a/g/Server is coming from. 

If none of this helps you figure out what's going on, please post a 
more complete chunk of your code, plus all the pertinent output and a 
full stack trace.  Also, please mention what you've deployed into the 
server (if anything) other than this application. 

Thanks, 
    Aaron 

On 1/4/06, Ranjan, Rakesh
(Cognizant) <[EMAIL PROTECTED]> wrote: 
> 
> 
> 
> Hi friends, 
> 
> I am trying to get a reference to Geronimo TransactionManager. For this, I
have done the following things : - 
> 
> a)       Getting a reference to the kernel using the
KernelRegistry class. 
> 
> b)       Then searching the TransactionManager GBean using
a pattern. 
> 
> c)       Finally getting the TransactionManager reference
using the searched Gbean. 
> 
> 
> 
> 
> 
> Here the code snippet : 
> 
> 
> 
> Kernel kernel=KernelRegistry.getSingleKernel(); 
> 
> ObjectName gbQuery = JMXUtil.getObjectName("*:j2eeType=TransactionManager,*");

> 
> Set gbeanNames = kernel.listGBeans(gbQuery); 
> 
> for (Iterator i = gbeanNames.iterator(); i.hasNext();) { 
> 
>       ObjectName gbeanName = (ObjectName) i.next(); 
> 
>       System.out.println(gbeanName1); 
> 
> } 
> 
> TransactionManager tm = (TransactionManager)
kernel.getProxyManager().createProxy(gbeanName, ransactionManager.class); 
> 
> 
> 
> 
> 
> 
> 
> When I am using this with the Geronimo-1.0-M5, this is working correctly.
But with Geronimo-1.0 , this is not working correctly. 
> 
> 
> 
> With Geronimo-1.0, I am getting the following Exception : 
> 
> 
> 
> java.lang.IllegalArgumentException: 
> 
>  Could not get GBeanInfo for target object: 
> 
> geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionManager,name=TransactionManager

> 
> 
> 
> I think kernel.listGBeans() is not working correctly in case of
Geronimo-1.0. According to the above code, the GBean is 
> 
> geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionManager,name=TransactionManager

> 
> 
> 
> But as much I know, it should be 
> 
> 
> 
>
geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-server/1.0/car,J2EEServer=geronimo,j2eeType=TransactionManager,name=TransactionManager

> 
> 
> 
> Can anybody please help me whether there is any fault with Geronimo-1.0 or
something else. 
> 
> 
> 
> 
> 
> Regards, 
> 
> Rakesh Ranjan 
> 
> 
> This e-mail and any files transmitted with it are for the sole use of the
intended recipient(s) and may contain confidential and privileged information. 
>  If you are not the intended recipient, please contact the sender by
reply e-mail and destroy all copies of the original message. 
>  Any unauthorized review, use, disclosure, dissemination, forwarding,
printing or copying of this email or any action taken in reliance on this
e-mail is strictly 
>  prohibited and may be unlawful. 
> 
>    Visit us at http://www.cognizant.com

> 

 







This e-mail and any files transmitted with it are for the sole use of the intended recipient

javamail InternetAddress parsing.

[Rick McGuire]

I'm trying to write a fuller implementation of the 
InternetAddress.parseHeader() method for the Geronimo javamail 
implementation.  I've been writing some tests to see how the Sun 
javamail implementation is handling various addresses, and then rolling 
these tests into the Geronimo junit tests for InternetAddress. 

While doing this, I ran the existing junit tests against the Sun 
javamail package and discovered that the Sun version failed some of the 
Geronimo unit tests!  Specifically, any of the group address tests in 
InternetAddressTest where the group did not contain a leading phrase did 
not get recognized as a group address.  Thus the tests for ":[EMAIL PROTECTED];" 
and ":[EMAIL PROTECTED], [EMAIL PROTECTED];" failed when run against the Sun javamail 
version.


It would be fairly simple to fix the Geronimo version to match the Sun 
results and fix the tests as well, but I'm not convinced that either 
version is handling this correctly.  RFC822 specifies that the tag 
phrase before the ":" in an address is required.  So ":[EMAIL PROTECTED];" is 
not a valid group, but "group:[EMAIL PROTECTED]'" is.  The Geronimo versions 
appears to be incorrect, both in the implementation and the unit test. 

However, according the Sun version is parsing ":[EMAIL PROTECTED];" as being a 
simple internet address, retaining both the ":" and ";" as part of the 
address.  Strict conformance to RFC822 would consider this to be an 
error rather than a simple address, and I don't believe most mail 
servers would accept that syntax. 

So, what should I target here?  Compatibility with the Sun version, or 
conformance to the RFC822 specification?


Rick

Re: problem with Geronimo-1.0

[Jacek Laskowski]

2006/1/4, Ranjan, Rakesh (Cognizant) <[EMAIL PROTECTED]>:

> ObjectName gbQuery = JMXUtil.getObjectName("*:j2eeType=TransactionManager,*");
...
> When I am using this with the Geronimo-1.0-M5, this is working correctly. But 
> with Geronimo-1.0 , this is not working correctly.

> java.lang.IllegalArgumentException:
>
>  Could not get GBeanInfo for target object:
>
> geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionManager,name=TransactionManager
>
>
>
> I think kernel.listGBeans() is not working correctly in case of Geronimo-1.0. 
> According to the above code, the GBean is
>
> geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionManager,name=TransactionManager
>
>
>
> But as much I know, it should be
>
>
>
> geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-server/1.0/car,J2EEServer=geronimo,j2eeType=TransactionManager,name=TransactionManager

Hi,

Have you tried to query using the full object name? I think it should
work. The above seems to imply a bug in listGBeans(). If noone takes
care of it by tonight, I'll  be looking into it.

> Rakesh Ranjan

Jacek

Re: POP3 and IMAP support

[Rick McGuire]

Rajith Attapattu wrote:

 
 I was wondering what the current status is for IMAP??
 
 I will work on the remaining issues of the POP3 implementation.
 
 Dain when are u going to apply the patch (with the POP3  impl) ?? I 
assume it's after 1.0 release.
 
 Regards,
 
 Rajith Attapattu.
 
 


I've got a good start on SMTP authentication and STARTTLS support, but 
got sidetracked a bit when I discovered that there were a number of 
unimplemented/incompletely implemented methods in the javamail spec 
code.  I'm working right now on filling in some of those gaps.


Rick

Re: Fwd: [Fwd: [Vote] 1.0 Release - Do we ship it?]

[Gianny Damour]

+1 Release 1.0

Gianny

Sachin Patel wrote:


forwarding this on behalf of Matt...

- sachin



Begin forwarded message:


*From: *Matt Hogstrom <[EMAIL PROTECTED] >
*Date: *January 3, 2006 9:47:28 AM EST
*To: [EMAIL PROTECTED] 
*Subject: **[Fwd: [Vote] 1.0 Release - Do we ship it?]*

Can you forward thsi for me?  I'm still getting SPAM errors.  I've 
sent a note to Ken to see if he can help me decipher what's going on.


 Original Message 
Subject: [Vote] 1.0 Release - Do we ship it?
Date: Tue, 03 Jan 2006 09:21:30 -0500
From: Matt Hogstrom <[EMAIL PROTECTED] >
To: dev@geronimo.apache.org 

All,

We have had the last candidate out and available since 12/22.  I 
personally have
had a chance to put the 12/22 build under performance stress and I'm 
satisfied

that the build is stable and runs in a variety of modes using DayTrader.

Despite the Christmas Holidays I have seen some traffic related to 
htis release
on the list so some folks have been kicking it around as well.  At 
this time I'd

like to call a vote to release 1.0.

[ ] +1 Release 1.0
[ ] -1 Do not release 1.0 (Reasons included)

Looks like we got through the last remaining significant bugs and 
thansk to all

who worked up to the end to get this release out there.

Matt

problem with Geronimo-1.0

[Ranjan, Rakesh \(Cognizant\)]

Hi friends,

I am trying to get a reference to Geronimo
TransactionManager. For this, I have done the following things : -

a)   Getting a
reference to the kernel using the KernelRegistry class.

b)   Then
searching the TransactionManager GBean using a pattern.

c)   Finally
getting the TransactionManager reference using the searched Gbean.

 

 

Here the code snippet : 

 

Kernel
kernel=KernelRegistry.getSingleKernel();

ObjectName gbQuery =
JMXUtil.getObjectName("*:j2eeType=TransactionManager,*");

Set gbeanNames = kernel.listGBeans(gbQuery);

for (Iterator i = gbeanNames.iterator();
i.hasNext();) {

  ObjectName
gbeanName = (ObjectName) i.next();

 
System.out.println(gbeanName1);

}

TransactionManager tm =
(TransactionManager) kernel.getProxyManager().createProxy(gbeanName,
ransactionManager.class);

 

 

 

When I am using this with the Geronimo-1.0-M5, this is
working correctly. But with Geronimo-1.0 , this is not working correctly.

 

With Geronimo-1.0, I am getting the following Exception :

 

java.lang.IllegalArgumentException:

 Could not get GBeanInfo for target
object: 

geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionManager,name=TransactionManager

 

I think kernel.listGBeans() is not working correctly in case
of Geronimo-1.0. According to the above code, the GBean is 

geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionManager,name=TransactionManager

 

But as much I know, it should be 

 

geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-server/1.0/car,J2EEServer=geronimo,j2eeType=TransactionManager,name=TransactionManager


 

Can anybody please help me whether there is any fault with
Geronimo-1.0 or something else.





 

Regards,

Rakesh Ranjan





 







This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. 
Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly 
prohibited and may be unlawful.

  Visit us at http://www.cognizant.com