Re: Writing an architecture overview doc
Great idea! please go for it! On 29 Aug 2006, at 23:24, Sepand M wrote: Hi, I'm thinking of writing an overview of the ActiveMQ communication and security systems. Before I start, does one already exist? Do you think it would be useful? - Sepand
Re: Stomp durable topics - implementation
Hmm, I can look into this but won't have a good opportunity to until after September 9 (a week and half from now). If you dig into the stomp transport stuff, it shouldn't be terribly difficult to put in, but... that is a guesstimate. If it hasn't been done by Sept 9 I can dig through, but cannot promise to before then :-( -Brian On Aug 29, 2006, at 1:11 PM, Sandeep Chayapathi wrote: apologies for cross posting this. I think this is a bug and hence Im posting the same in the dev mailing list: Hi all, This is regarding my last query (http://www.nabble.com/forum/ViewPost.jtp?post=6040430framed=y http://www.nabble.com/forum/ViewPost.jtp?post=6040430framed=y). I was grokking the source code, vis-a-vis Stomp and durable topic, looks like the documentation regarding the custom headers, is not in sync with the source code, i.e nohwere in the source code could I find a reference to the following custom headers: activemq.subscriptionName and subscriberName. Any idea on how much effort is required to implement these ? I might be wrong, it would help if anyone can point me in the right direction. Thanks. - Sandeep
[jira] Created: (AMQ-904) SecurityContext doesn't work with WebLogic Principals
SecurityContext doesn't work with WebLogic Principals - Key: AMQ-904 URL: https://issues.apache.org/activemq/browse/AMQ-904 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.1 Reporter: Aaron Mulder SecurityContext.isInOneOf attempts to determine whether a user has one of a set of possible principals. It does this by using HashSet.retainAll, which relies on equals and hashcode. This doesn't work for WebLogic principals (the variable set in that method always ends up empty). I'm not totally clear on why, but I notice that the principals generated by a WebLogic authentication have signature data, while the principals created as the eligible principals using the same WebLogic classes (weblogic.security.principal.WLSGroupImpl) have null signature data. I speculate that WebLogic signs the principals it creates and that equals and/or hashCode consider the signature. It would be ideal if SecurityContext.isInOneOf manually compared the principal class and principal name instead of relying on the equals and/or hashCode methods of the underlying principal class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-877) Patch: refactoring to allow alternative (using different storage interface) Destinations implementations.
[ https://issues.apache.org/activemq/browse/AMQ-877?page=all ]
Maxim Fateev updated AMQ-877:
-
Attachment: destinationFactoryActiveMQ_438704.patch
The updated patch is attached.
Patch: refactoring to allow alternative (using different storage interface)
Destinations implementations.
-
Key: AMQ-877
URL: https://issues.apache.org/activemq/browse/AMQ-877
Project: ActiveMQ
Issue Type: Improvement
Components: Broker
Affects Versions: 4.x
Reporter: Maxim Fateev
Assigned To: Rob Davies
Fix For: 4.1
Attachments: destinationFactoryActiveMQ_438704.patch,
destinationFactoryActiveMQPatch.txt
We were looking at alternate message persistence mechanisms that can co-exist
in current ActiveMQ code base and we are thinking of a mechanism that is
somewhat incompatible with the current MessageStore and PersistenceAdapter
APIs. Unfortunately, the current ActiveMQ broker doesn't allow for such a
change as the PersistenceAdapter and MessageStore interfaces are referenced
directly by the RegionBroker and by both the Queue and Topic region
implementations. Therefore, we are proposing a relatively small backwards
compatible refactoring of the broker code that would eliminate all
dependencies on the PersistenceAdapter and MessageStore interfaces from those
classes that do not use them directly. This refactoring would also allow
creation of a custom Destination implementation that may use an alternative
persistence mechanism on a destination by destination basis (which is exactly
what we need to do).
The main idea behind the refactoring is to replace many references to
PersistenceAdapter with a new interface: DestinationFactory:
public abstract class DestinationFactory {
abstract public Destination createDestination(ConnectionContext
context, ActiveMQDestination destination, DestinationStatistics
destinationStatistics) throws Exception;
abstract public Set getDestinations();
abstract public SubscriptionInfo[]
getAllDurableSubscriptions(ActiveMQTopic topic) throws IOException;
abstract public long getLastMessageBrokerSequenceId() throws
IOException;
abstract public void setRegionBroker(RegionBroker regionBroker);
}
Note that DestinationFactory doesn't mandate any specific persistence
mechanism. The classes that would reference it instead of PersistenceAdapter
are: RegionBroker, AbstractRegion, QueueRegion, and TopicRegion. Also, the
AbstractRegion.createDestination method would be changed from abstract to an
implementation that uses DestinationFactory to create a destination.
BrokerService could be changed to use DestinationFactory if one is
provided. If none is provided, it will create a DestinationFactory
implementation that instantiates Queue and Topic using PersistenceAdapter as
it does currently. Hence, full backwards compatibility will be maintained.
Patch is attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Geronimo Schema Documentation
Hi, Can anyone describe what is the meaning container-configType element of geronimo-web-1.1.xsd? Regards, Lasantha Ranaweera
Re: Geronimo Schema Documentation
container-configType is an element type for container-config element in geronimo-web. It is used to provide container (tomcat or jetty) specific attributes. Those attributes which are valid for either container. For example:container-configtomcat xmlns=http://geronimo.apache.org/xml/ns/web/tomcat/config-1.0host tomcat.server.com/host/tomcat/container-configthanksRakeshOn 8/30/06, Lasantha Ranaweera [EMAIL PROTECTED] wrote: Hi,Can anyone describe what is the meaning container-configType elementof geronimo-web-1.1.xsd?Regards,Lasantha Ranaweera
[jira] Created: (AMQ-902) Exception thrown when compiling activemq-optional.
Exception thrown when compiling activemq-optional. -- Key: AMQ-902 URL: https://issues.apache.org/activemq/browse/AMQ-902 Project: ActiveMQ Issue Type: Bug Components: Transport Reporter: Fritz Oconer Assigned To: Fritz Oconer Priority: Critical The exception below is thrown when compiling activemq-optional. [WARNING] Unable to get resource from repository central (http://ibiblio.org/maven2/) [INFO] [compiler:compile] Compiling 12 source files to D:\logicblaze\working-source\activemq\activemq-optional\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure D:\logicblaze\working-source\activemq\activemq-optional\src\main\java\org\apache\activemq\transport\https\HttpsTransportServer.java:[51,36] cannot find symbol symbol : method setAlgorithm(java.lang.String) location: class org.mortbay.jetty.security.SslSocketConnector There was an update made on jetty dependency version from 6.0.0rc0 to 6.0.0rc2 wherein the method setAlgorithm(String) of org.mortbay.jetty.security.SslSocketConnector was changed to a more specific methods setSecureRandomAlgorithm(String), setSslKeyManagerFactoryAlgorithm(String) and setSslTrustManagerFactoryAlgorithm(String). This change caused the class HttpsTransportServer. to throw an exception since it can no longer find the setAlgorithm(String) method. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: CIMERO eclipse plugin
We have update the plugin version yesterday. Download the 2.4.0 plugin version to have all the component. Regards Cédric. Gert Vanthienen wrote: L.S., I have downloaded the CIMERO plug-in from http://goopen.org/confluence/display/SM/CIMERO+Editor and installed it. It works very good, but in my workbench, it only shows a part of the components that are available in the screenshots on the same page. Is there still a problem with this plug-in? Have I done something wrong while installing it or is the documentation out-of-sync with the current state of development on this plug-in? Regards, Gert Vanthienen [EMAIL PROTECTED] Jerome Camilleri wrote: Grant McDonald wrote: Guys, I was wondering if a future direction for this plugin would be to provide BPEL tooling as well? From the point of view of someone who has both hand written BPEL and servicemix config the integration of graphical servicemix message routing and BPEL process design would be a godsend. There may even be open source tooling solutions out there that could be leveraged in this fashion. Grant M. With Cimero plugin you can very easly create graphically a configuration of a ServiceMix flow. In this version the list of BC supported was : Transformer Router Tracer Enricher Aggregator Splitter MessageFilter list of SE supported : Mail WebService FTP Server RSS Flow Screen Output JMS Server Timer Like another SE a BPEL Service should be add into Cimero. But Cimero is not a graphical editor for BPEL process. Regards Jérôme
Re: [VOTE] XBean 2.6 release
OK :(I will try to fix Spring rc3 compatibility in the mean timeOn 8/30/06, Jason Dillon [EMAIL PROTECTED] wrote:I think we are gonna have to release Genesis 1.1 and then use that for the XBean 2.6 release.--jasonOn Aug 29, 2006, at 6:15 PM, Dain Sundstrom wrote: I agree.If the 1.0 genesis that xbean was built against is published, we can continue the vote, otherwise I'm afraid we will have to respin the release and start the vote over. -dain On Aug 29, 2006, at 6:08 PM, Alan D. Cabrera wrote: -1 Sorry, I just caught this.Geronimo Genesis has not been officially released but we are using a 1.0 release version. Regards, Alan Alan D. Cabrera wrote: +1 thanks for following up on this. Regards, Alan Guillaume Nodet wrote: I have uploaded a new 2.6 release at the same location, which fix the missing LICENSE/NOTICE files problem. Dain, please, could you recheck (and remove your -1) ? On 8/28/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I have tagged the xbean-2.6 branch http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-2.6/ and uploaded a version at http://people.apache.org/~gnodet/xbean-2.6/org/apache/xbean/ Please vote. Here's my +1 As soon as the vote is off, I will upload the release to the m2 repo at http://people.apache.org/repo/m2-ibiblio-rsync-repository/ -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet-- Cheers,Guillaume Nodet
Re: Geronimo Schema Documentation
Thanks Rakesh. :-) Rakesh Midha wrote: "container-configType" is an element type for "container-config" element in geronimo-web. It is used to provide container (tomcat or jetty) specific attributes. Those attributes which are valid for either container. For example: container-config tomcat xmlns="http://geronimo.apache.org/xml/ns/web/tomcat/config-1.0" host tomcat.server.com/host /tomcat /container-config thanks Rakesh On 8/30/06, Lasantha Ranaweera [EMAIL PROTECTED] wrote: Hi, Can anyone describe what is the meaning "container-configType" element of geronimo-web-1.1.xsd? Regards, Lasantha Ranaweera
geronimo-application-client.xsd Global Declarations
Hi I have given the XML Representation of the geronimo-application-client.xsd(Gv1.1) Global declarations application-client Element and can any body please review and made corrections please? Thanks Kanchana Global Declarations Element: application-client Name application-client Type geronimo:application-clientType Nillable no Abstract no XML Instance Representation geronimo:application-client moduleId= xs:string [1] groupId= xs:string [0..1] clientmoduleId= xs:string [1] clientgroupId= xs:string [0..1] sys:import ... /sys:import [0..*] geronimo:include sys:dependencyType /geronimo:include [0..*] sys:dependency ... /sys:dependency [0..*] naming:ejb-ref ... /naming:ejb-ref [0..*] naming:service-ref ... /naming:service-ref [0..*] naming:resource-ref ... /naming:resource-ref [0..*] naming:resource-env-ref ... /naming:resource-env-ref [0..*] naming:message-destination ... /naming:message-destination [0..*] security:default-principal ... /security:default-principal [0..1] Start Sequence [0..1] geronimo:realm-name xs:string /geronimo:realm-name [1] geronimo:callback-handler xs:string /geronimo:callback-handler [0..1] End Sequence geronimo:resource geronimo:resourceType /geronimo:resource [0..*] sys:gbean ... /sys:gbean [0..*] /geronimo:application-client
What does this do?
Just when I think I have a complete handle on how GBeans work, someone
throws me a curve ball. In the process of reworking how the CORBA
objects are configured, I found the following in jetty config (and
repeated in the tomcat config):
module
name=org.apache.geronimo.configs/j2ee-corba/${pom.version}/car
load=false
gbean name=NameServer
attribute name=dbDirvar/cosnaming.db/attribute
attribute name=port${PlanCOSNamingPort}/attribute
/gbean
gbean name=Server
attribute name=args-ORBInitRef,
NameService=corbaloc::${PlanCOSNamingHost}:${PlanCOSNamingPort}/NameService/attribute
/gbean
gbean name=UnprotectedServer
attribute name=args-ORBInitRef,
NameService=corbaloc::${PlanCOSNamingHost}:${PlanCOSNamingPort}/NameService/attribute
/gbean
/module
I missed this earlier because there's no GBean class name, so my
searches for CorbaBean didn't turn anything up. Are these lines just a
modification for an existing GBean located somewhere else in the
configuration? Does this just modify attributes of the GBean before it
is started, or does this create a copy of the referenced GBean with the
new attributes merged in? I'm not even sure why these lines are here.
The values being set are the same as the original configuration. Is
there some other side effect involved?
Rick
[jira] Commented: (AMQ-895) JMS to JMS Bridge never reconnects under remote broker restarts.
[
https://issues.apache.org/activemq/browse/AMQ-895?page=comments#action_36879 ]
Manuel Teira commented on AMQ-895:
--
Previous error was produced by bug:
https://issues.apache.org/activemq/browse/AMQ-901
Checking todays svn trunk version finished with a successful compilation.
However, reconnection seems not to work.
The scenario is as follows:
===Scenario #1===
ActiveMQ broker with a bridged Sun MQ Broker.
* Start ActiveMQ
* Send a message to a bridged queue.
** The message gets into the queue, the jmx console shows:
EnqueueCount: 1
DequeueCount: 0
QueueSize: 1
* Start SunMQ
* Send a new message to the bridged queue.
** Messages are not delivered to the SunMQ broker.
===Scenario #2===
ActiveMQ broker with a bridged SunMQ Broker.
* Start SunMQ
* Start ActiveMQ
* Send a message to a bridged queue.
** The message is bridged to SunMQ Broker queue. The jmx console shows:
ConsumerCount: 1
EnqueueCount: 1
DequeueCount: 1
QueueSize: 0
* Stop SunMQ
* Send a new message to the bridged queue.
** Message is not delivered to the SunMQ broker.
** The jmx console shows, for the queue:
ConsumerCount: 1
EnqueueCount: 2
DequeueCount: 2
QueueSize: 1
**The log shows:
[DEBUG][2006/08/30.12:40:57.849][ActiveMQ Transport Server:
tcp://localhost:61635]Sending: WireFormatInfo { version=2,
properties={TightEncodingEnabled=true, TcpNoDelayEnabled=true,
SizePrefixDisabled=false, StackTraceEnabled=true, MaxInactivityDuration=3,
CacheEnabled=true}, magic=[A,c,t,i,v,e,M,Q]}
[DEBUG][2006/08/30.12:40:57.849][ActiveMQ Transport Server:
tcp://localhost:61635]Sending: WireFormatInfo { version=2,
properties={TightEncodingEnabled=true, TcpNoDelayEnabled=true,
SizePrefixDisabled=false, StackTraceEnabled=true, MaxInactivityDuration=3,
CacheEnabled=true}, magic=[A,c,t,i,v,e,M,Q]}
[DEBUG][2006/08/30.12:40:57.887][ActiveMQ Transport:
tcp:///127.0.0.1:47305]Received WireFormat: WireFormatInfo { version=2,
properties={StackTraceEnabled=true, TightEncodingEnabled=true,
TcpNoDelayEnabled=true, SizePrefixDisabled=false, MaxInactivityDuration=3,
CacheEnabled=true}, magic=[A,c,t,i,v,e,M,Q]}
[DEBUG][2006/08/30.12:40:57.888][ActiveMQ Transport:
tcp:///127.0.0.1:47305]tcp:///127.0.0.1:47305 before negotiation:
OpenWireFormat{version=1, cacheEnabled=false, stackTraceEnabled=false,
tightEncodingEnabled=false, sizePrefixDisabled=false}
[DEBUG][2006/08/30.12:40:57.889][ActiveMQ Transport:
tcp:///127.0.0.1:47305]tcp:///127.0.0.1:47305 after negotiation:
OpenWireFormat{version=2, cacheEnabled=true, stackTraceEnabled=true,
tightEncodingEnabled=true, sizePrefixDisabled=false}
[DEBUG][2006/08/30.12:40:57.887][ActiveMQ Transport:
tcp:///127.0.0.1:47305]Received WireFormat: WireFormatInfo { version=2,
properties={StackTraceEnabled=true, TightEncodingEnabled=true,
TcpNoDelayEnabled=true, SizePrefixDisabled=false, MaxInactivityDuration=3,
CacheEnabled=true}, magic=[A,c,t,i,v,e,M,Q]}
[DEBUG][2006/08/30.12:40:57.888][ActiveMQ Transport:
tcp:///127.0.0.1:47305]tcp:///127.0.0.1:47305 before negotiation:
OpenWireFormat{version=1, cacheEnabled=false, stackTraceEnabled=false,
tightEncodingEnabled=false, sizePrefixDisabled=false}
[DEBUG][2006/08/30.12:40:57.889][ActiveMQ Transport:
tcp:///127.0.0.1:47305]tcp:///127.0.0.1:47305 after negotiation:
OpenWireFormat{version=2, cacheEnabled=true, stackTraceEnabled=true,
tightEncodingEnabled=true, sizePrefixDisabled=false}
[DEBUG][2006/08/30.12:40:58.479][ActiveMQ Transport:
tcp:///127.0.0.1:47305]Adding consumer: ID:trabucco-47304-1156934456973-1:0:-1:1
[DEBUG][2006/08/30.12:40:58.479][ActiveMQ Transport:
tcp:///127.0.0.1:47305]Adding consumer: ID:trabucco-47304-1156934456973-1:0:-1:1
[DEBUG][2006/08/30.12:40:58.976][ActiveMQ Transport:
tcp:///127.0.0.1:47305]Removing consumer:
ID:trabucco-47304-1156934456973-1:0:-1:1
[ERROR][2006/08/30.12:40:59.266][ActiveMQ Session Task]failed to forward
message on attempt: 1 reason: javax.jms.IllegalStateException: [C4064]: Cannot
perform operation, producer is closed. message: ActiveMQBytesMessage {commandId
= 5, responseRequired = true, messageId =
ID:trabucco-47304-1156934456973-1:0:1:1:1, originalDestination = null,
originalTransactionId = null, producerId =
ID:trabucco-47304-1156934456973-1:0:1:1, destination = queue://SUNRECV,
transactionId = null, expiration = 0, timestamp = 1156934458928, arrival = 0,
correlationId = null, replyTo = null, persistent = true, type = null, priority
= 4, groupID = null, groupSequence = 0, targetConsumerId = null, compressed =
false, userID = null, content = [EMAIL PROTECTED], marshalledProperties = null,
dataStructure = null, redeliveryCounter = 0, size = 529, properties = null,
readOnlyProperties = true, readOnlyBody = true} ActiveMQBytesMessage{ bytesOut
= null, dataOut = null, dataIn = null }([C4064]: Cannot perform operation,
producer is closed.)
[DEBUG][2006/08/30.12:40:58.976][ActiveMQ
Re: Upgrade Derby to 10.1.3.1?
On 8/30/06, Jason Dillon [EMAIL PROTECTED] wrote: The latest release appears to run fine... any objections to updating server/trunk to use it? Which JIRA issue is this? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Commented: (GERONIMODEVTOOLS-104) When TomcatWebContainer moved default location - plugin cannot publish projects
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-104?page=comments#action_12431561 ] Sachin Patel commented on GERONIMODEVTOOLS-104: --- You can't open the editor because you did not use qualified names, technically the non qualified plans are technically invalid and thus any generated model code cannot open them until the plan is made qualified. I really need for you to provide me a full example as an attachement of both the applicaton and the web app as a test case. When TomcatWebContainer moved default location - plugin cannot publish projects --- Key: GERONIMODEVTOOLS-104 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-104 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 1.1.0 Environment: IBM VM 1.5, Win2k SP4, Eclipse 3.2.0, Little-G 1.1 Reporter: Oleg Gusakov I defined Tomcat engine on the application level (in geronimo-application.xml) because I need to define a lot of virtual hosts. When I try to deploy a project into the server - I get org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve reference Container in gbean default/gtest2/1.0/car?J2EEApplication=null,j2eeType=WebModule,name=default/gtest2/1.0/car to a gbean matching the pattern [?name=TomcatWebContainer#] caused by org.apache.geronimo.kernel.GBeanNotFoundException: No matches for referencePatterns: [?name=TomcatWebContainer#] Two problems here (or one as they have the same root cause): - plugin should be able to present user a choice of available web containers to deploy to - what if I rename bean container (can I?) and it becomes MyTomcatContainer35 ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (XBEAN-49) XBeanNamespaceHandler incompatible with spring 2.0 rc3
[ http://issues.apache.org/jira/browse/XBEAN-49?page=all ] Guillaume Nodet reassigned XBEAN-49: Assignee: Guillaume Nodet XBeanNamespaceHandler incompatible with spring 2.0 rc3 -- Key: XBEAN-49 URL: http://issues.apache.org/jira/browse/XBEAN-49 Project: XBean Issue Type: Bug Components: spring Affects Versions: 2.7 Environment: Spring 2.0 rc3 Reporter: michael mitchell Assigned To: Guillaume Nodet Because of API changes made to springs BeanDefinitionParserDelegate, XBeanNamespaceHandler in no longer compatible. -- 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
OpenWire C++ - access to JMS Message Headers
Hi Folks! I'm using the OpenWire C++ client submitted by Amazon to allow me to use JMS with my legacy C++ applications. I'm a newbie to all of this but have managed to get the C++ example programs exchanging messages over distributed activeMQ instances on multiple machines. All great! What I want to know is, am I able to access the JMS Message Headers from the OpenWire C++ API? Say I wanted to know the JMSUserID? It should more or less mimic the JMS API, I know but I'm having a bit of trouble getting the header values extracted from the messages I'm publishing. Thanks in advance for any help, YMC -- View this message in context: http://www.nabble.com/OpenWire-C%2B%2B---access-to-JMS-Message-Headers-tf2189502.html#a6057663 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: What does this do?
The actual Gbean's looks like are defined inconfigs/j2ee-corba/target/plan/plan.xml.. so my guess is yes, its just setting attributes them.On Aug 30, 2006, at 6:04 AM, Rick McGuire wrote:Just when I think I have a complete handle on how GBeans work, someone throws me a curve ball. In the process of reworking how the CORBA objects are configured, I found the following in jetty config (and repeated in the tomcat config): module name="org.apache.geronimo.configs/j2ee-corba/${pom.version}/car" load="false" gbean name="NameServer" attribute name="dbDir"var/cosnaming.db/attribute attribute name="port"${PlanCOSNamingPort}/attribute /gbean gbean name="Server" attribute name="args"-ORBInitRef, NameService=corbaloc::${PlanCOSNamingHost}:${PlanCOSNamingPort}/NameService/attribute /gbean gbean name="UnprotectedServer" attribute name="args"-ORBInitRef, NameService=corbaloc::${PlanCOSNamingHost}:${PlanCOSNamingPort}/NameService/attribute /gbean /moduleI missed this earlier because there's no GBean class name, so my searches for CorbaBean didn't turn anything up. Are these lines just a modification for an existing GBean located somewhere else in the configuration? Does this just modify attributes of the GBean before it is started, or does this create a copy of the referenced GBean with the new attributes merged in? I'm not even sure why these lines are here. The values being set are the same as the original configuration. Is there some other side effect involved?Rick -sachin
Re: Upgrade Derby to 10.1.3.1?
Jacek Laskowski wrote: On 8/30/06, Jason Dillon [EMAIL PROTECTED] wrote: The latest release appears to run fine... any objections to updating server/trunk to use it? Which JIRA issue is this? Jacek See GERONIMO-2155 - but it covers also moving to the debug version of the library. John
Re: What does this do?
Rick,
These are just overrides to the attributes when the gbeans are started
in the assembly.
I can't speak to the particulars of these attributes ... but one reason
that attributes are sometimes specified in the assembly config.xml
even if the values are the same as the configuration is to make them
visible to the end user so that they can be easily modified in the
config.xml.
Joe
Rick McGuire wrote:
Just when I think I have a complete handle on how GBeans work, someone
throws me a curve ball. In the process of reworking how the CORBA
objects are configured, I found the following in jetty config (and
repeated in the tomcat config):
module
name=org.apache.geronimo.configs/j2ee-corba/${pom.version}/car
load=false
gbean name=NameServer
attribute name=dbDirvar/cosnaming.db/attribute
attribute name=port${PlanCOSNamingPort}/attribute
/gbean
gbean name=Server
attribute name=args-ORBInitRef,
NameService=corbaloc::${PlanCOSNamingHost}:${PlanCOSNamingPort}/NameService/attribute
/gbean
gbean name=UnprotectedServer
attribute name=args-ORBInitRef,
NameService=corbaloc::${PlanCOSNamingHost}:${PlanCOSNamingPort}/NameService/attribute
/gbean
/module
I missed this earlier because there's no GBean class name, so my
searches for CorbaBean didn't turn anything up. Are these lines just a
modification for an existing GBean located somewhere else in the
configuration? Does this just modify attributes of the GBean before it
is started, or does this create a copy of the referenced GBean with the
new attributes merged in? I'm not even sure why these lines are here.
The values being set are the same as the original configuration. Is
there some other side effect involved?
Rick
M2 Build Error
Hi All, Last few days I have been trying to build Geronimo from source code. I have been following the document Building Apache Geronimo with Maven 2 in Geronimo documentation. Every time build has failed when it tries to build OpenEJB Deployer component. It can't find out openejb - 2.2-SNAPSHOT related dependencies. Can anyone help me on this regard? :-\ Thanks, Lasantha Ranaweera
[jira] Commented: (AMQ-877) Patch: refactoring to allow alternative (using different storage interface) Destinations implementations.
[
https://issues.apache.org/activemq/browse/AMQ-877?page=comments#action_36880 ]
Rob Davies commented on AMQ-877:
it does look like the patch is slightly out of sync - could you re-generate
against head and re-attach ?
Patch: refactoring to allow alternative (using different storage interface)
Destinations implementations.
-
Key: AMQ-877
URL: https://issues.apache.org/activemq/browse/AMQ-877
Project: ActiveMQ
Issue Type: Improvement
Components: Broker
Affects Versions: 4.x
Reporter: Maxim Fateev
Assigned To: james strachan
Fix For: 4.1
Attachments: destinationFactoryActiveMQPatch.txt
We were looking at alternate message persistence mechanisms that can co-exist
in current ActiveMQ code base and we are thinking of a mechanism that is
somewhat incompatible with the current MessageStore and PersistenceAdapter
APIs. Unfortunately, the current ActiveMQ broker doesn't allow for such a
change as the PersistenceAdapter and MessageStore interfaces are referenced
directly by the RegionBroker and by both the Queue and Topic region
implementations. Therefore, we are proposing a relatively small backwards
compatible refactoring of the broker code that would eliminate all
dependencies on the PersistenceAdapter and MessageStore interfaces from those
classes that do not use them directly. This refactoring would also allow
creation of a custom Destination implementation that may use an alternative
persistence mechanism on a destination by destination basis (which is exactly
what we need to do).
The main idea behind the refactoring is to replace many references to
PersistenceAdapter with a new interface: DestinationFactory:
public abstract class DestinationFactory {
abstract public Destination createDestination(ConnectionContext
context, ActiveMQDestination destination, DestinationStatistics
destinationStatistics) throws Exception;
abstract public Set getDestinations();
abstract public SubscriptionInfo[]
getAllDurableSubscriptions(ActiveMQTopic topic) throws IOException;
abstract public long getLastMessageBrokerSequenceId() throws
IOException;
abstract public void setRegionBroker(RegionBroker regionBroker);
}
Note that DestinationFactory doesn't mandate any specific persistence
mechanism. The classes that would reference it instead of PersistenceAdapter
are: RegionBroker, AbstractRegion, QueueRegion, and TopicRegion. Also, the
AbstractRegion.createDestination method would be changed from abstract to an
implementation that uses DestinationFactory to create a destination.
BrokerService could be changed to use DestinationFactory if one is
provided. If none is provided, it will create a DestinationFactory
implementation that instantiates Queue and Topic using PersistenceAdapter as
it does currently. Hence, full backwards compatibility will be maintained.
Patch is attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: What does this do?
yes
Rick McGuire wrote:
Joe Bohn wrote:
Rick,
These are just overrides to the attributes when the gbeans are started
in the assembly.
Do those overrides get applied before the GBean is started?
I can't speak to the particulars of these attributes ... but one
reason that attributes are sometimes specified in the assembly
config.xml even if the values are the same as the configuration is to
make them visible to the end user so that they can be easily modified
in the config.xml.
Joe
Rick McGuire wrote:
Just when I think I have a complete handle on how GBeans work,
someone throws me a curve ball. In the process of reworking how the
CORBA objects are configured, I found the following in jetty config
(and repeated in the tomcat config):
module
name=org.apache.geronimo.configs/j2ee-corba/${pom.version}/car
load=false
gbean name=NameServer
attribute name=dbDirvar/cosnaming.db/attribute
attribute name=port${PlanCOSNamingPort}/attribute
/gbean
gbean name=Server
attribute name=args-ORBInitRef,
NameService=corbaloc::${PlanCOSNamingHost}:${PlanCOSNamingPort}/NameService/attribute
/gbean
gbean name=UnprotectedServer
attribute name=args-ORBInitRef,
NameService=corbaloc::${PlanCOSNamingHost}:${PlanCOSNamingPort}/NameService/attribute
/gbean
/module
I missed this earlier because there's no GBean class name, so my
searches for CorbaBean didn't turn anything up. Are these lines just
a modification for an existing GBean located somewhere else in the
configuration? Does this just modify attributes of the GBean before
it is started, or does this create a copy of the referenced GBean
with the new attributes merged in? I'm not even sure why these lines
are here. The values being set are the same as the original
configuration. Is there some other side effect involved?
Rick
[jira] Created: (AMQ-903) ActivemMQ slows down after a rather small number of messages
ActivemMQ slows down after a rather small number of messages Key: AMQ-903 URL: https://issues.apache.org/activemq/browse/AMQ-903 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0.1 Reporter: Daniel Aioanei Attachments: activemq.xml I have activemq with a postgresql backend running as a standalone server, and a client application that produces persistent messages in 50 threads. Each time I run my app it pushes as many msg as it can for about 62.5 seconds after which it quits. Although initially it works fast, every time I run my app it produces less messages: enqueue speed 50 threads: msg/second: 334.183334 second time: msg/second: 194.15 third time: msg/second: 123.0 fourth time: msg/second: 58.616667 fifth time: msg/second: 19.434 sixth time: msg/second: 33.816667 seventh time: msg/second: 11.783 eigth time: msg/second: 24.734 ninght time: msg/second: 10.883 After I ran the above test there seem to be 50241 msg in that queue. activemq= select count(1) from activemq_msgs ; count --- 50241 (1 row) activemq= select count(1) from activemq_acks ; count --- 0 (1 row) Note that I don't have any message consumers active for this test. Here is the way the client app connects: bean id=jmsResourceAdapter class=org.apache.activemq.ra.ActiveMQResourceAdapter property name=serverUrl value=tcp://localhost:61616?wireFormat.cacheEnabled=falseamp;wireFormat.tightEncodingEnabled=false / /bean -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-903) ActivemMQ slows down after a rather small number of messages
[ https://issues.apache.org/activemq/browse/AMQ-903?page=comments#action_36881 ] Daniel Aioanei commented on AMQ-903: Every time I ran my test app, the CPU usage staid on 100% so an artificial sleep-like delay doesn't seem to be involved. ActivemMQ slows down after a rather small number of messages Key: AMQ-903 URL: https://issues.apache.org/activemq/browse/AMQ-903 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0.1 Reporter: Daniel Aioanei Attachments: activemq.xml I have activemq with a postgresql backend running as a standalone server, and a client application that produces persistent messages in 50 threads. Each time I run my app it pushes as many msg as it can for about 62.5 seconds after which it quits. Although initially it works fast, every time I run my app it produces less messages: enqueue speed 50 threads: msg/second: 334.183334 second time: msg/second: 194.15 third time: msg/second: 123.0 fourth time: msg/second: 58.616667 fifth time: msg/second: 19.434 sixth time: msg/second: 33.816667 seventh time: msg/second: 11.783 eigth time: msg/second: 24.734 ninght time: msg/second: 10.883 After I ran the above test there seem to be 50241 msg in that queue. activemq= select count(1) from activemq_msgs ; count --- 50241 (1 row) activemq= select count(1) from activemq_acks ; count --- 0 (1 row) Note that I don't have any message consumers active for this test. Here is the way the client app connects: bean id=jmsResourceAdapter class=org.apache.activemq.ra.ActiveMQResourceAdapter property name=serverUrl value=tcp://localhost:61616?wireFormat.cacheEnabled=falseamp;wireFormat.tightEncodingEnabled=false / /bean -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: servicemix-http and normalization
Guillaume Nodet wrote: Some existing components may already expose a WSDL 1.1 (as WSDL 2.0 is not supported yet) which may contain a soap binding. While this is not a good thing, we need to cope with them. How difficult would it be to fix these components? It might be more worthwhile to attack the problem at the root... That' s the reason why I don't really like the mechanism to auto-discover the WSDL and engage the WSDL 1.1 normalization if the target endpoint WSDL contain a soap binding. I think this should be configured with a flag on the http consumer endpoint. And existing components should be enhanced to use this normalization (but that' s another problem). That's understood. I was looking for feedback on how to configure this behavior. I'll look into adding a flag on the http consumer endpoint. Another slight oversight I think, is that the SoapHelper#findOperation should only check the WSDL for the current endpoint, and this WSDL should be modified according to the binding used. We should also provide a way to easily configure the binding with default values (let's say just doclit / rpc) by setting a flag on the http endpoint. I'm not sure I follow here. Do you mean that #findOperation should not check the WSDL of the target ServiceEndpoint? If so, I can remove that. On the second point, it sounds like fixing the WSDL document is easier and better than adding configuration on the endpoint... unless I'm missing something. So, while I think this is a really good patch that enhance the current http component, it is part of a bigger feature. It may even be linked to WSDL 2.0 support, or full rest support. If I find enough time (may not be this week), I'll try to handle these two points in a simple way for the moment, so that this great and needed feature can be used. But if you want to take a look at it, feel free to do so. Also, I think I have seen some removed / commented features about security. I think this is a patch I applied recently... Ok, I'll double-check. alex
FYI, Spring 2.0-rc3 incompatibility
I have just fixed the incompatibility with spring 2.0-rc3. Unfortunately, the spring classes changed in an incompatible way, as the signature of some overriden methods has changed. To work around, that, I have splitted the xbean-spring-v2 in 3 modules, which are xbean-spring-v2 : base classes (we can only have one XBeanNamespaceHandler implementation) xbean-spring-v2a : delegate classes for spring 2.0-rc3 xbean-spring-v2b : delegate classes for spring = 2.0-rc3 The delegate classes are loaded at runtime, depending on the version used. Everything seems to work now. I also added a new module for intergration tests with spring 2.0-rc3. -- Cheers, Guillaume Nodet
[jira] Closed: (XBEAN-49) XBeanNamespaceHandler incompatible with spring 2.0 rc3
[ http://issues.apache.org/jira/browse/XBEAN-49?page=all ] Guillaume Nodet closed XBEAN-49. Fix Version/s: 2.6 Resolution: Fixed Author: gnodet Date: Wed Aug 30 07:14:53 2006 New Revision: 438491 URL: http://svn.apache.org/viewvc?rev=438491view=rev Log: XBEAN-49: Incompatibility with spring 2.0 rc3 XBeanNamespaceHandler incompatible with spring 2.0 rc3 -- Key: XBEAN-49 URL: http://issues.apache.org/jira/browse/XBEAN-49 Project: XBean Issue Type: Bug Components: spring Affects Versions: 2.7 Environment: Spring 2.0 rc3 Reporter: michael mitchell Assigned To: Guillaume Nodet Fix For: 2.6 Because of API changes made to springs BeanDefinitionParserDelegate, XBeanNamespaceHandler in no longer compatible. -- 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: M2 Build Error
Lasantha, I've been hitting this same problem. I think I can help you work around it but we don't have a fix yet (or at least I don't have one). I did some experiments with this and posted this note but haven't received a response yet: http://marc.theaimsgroup.com/?l=geronimo-devm=115680051431478w=2 I'm assuming you're seeing this on a bootstrap build. So, what I think you can do is the following: - run bootstrap from the root install location. - Ignore the fact that it tells you works ... it always lies. :-( You'll see a failure a few lines up on the openejb2 problem. - cd to target\external\openejb2 - mvn -Dmaven.test.skip=true - cd back to root - mvn clean install This should at least produce the assemblies but skips the tests. I've done something like this in the past and I'm confirming the directions now myself. If I've forgotten something I'll post again. Joe Lasantha Ranaweera wrote: Hi All, Last few days I have been trying to build Geronimo from source code. I have been following the document Building Apache Geronimo with Maven 2 in Geronimo documentation. Every time build has failed when it tries to build OpenEJB Deployer component. It can't find out openejb - 2.2-SNAPSHOT related dependencies. Can anyone help me on this regard? :-\ Thanks, Lasantha Ranaweera
Re: M2 Build Error
Hi Lasantha, Could you post some more detail (stack trace from mvn -e) and I'd be glad to try to help. Also if you could relate what platform you are on that might also provide some hints to the problem. TTFN, -bd- On Aug 30, 2006, at 7:27 AM, Lasantha Ranaweera wrote: Hi All, Last few days I have been trying to build Geronimo from source code. I have been following the document Building Apache Geronimo with Maven 2 in Geronimo documentation. Every time build has failed when it tries to build OpenEJB Deployer component. It can't find out openejb - 2.2-SNAPSHOT related dependencies. Can anyone help me on this regard? :-\ Thanks, Lasantha Ranaweera
[jira] Assigned: (AMQ-877) Patch: refactoring to allow alternative (using different storage interface) Destinations implementations.
[ https://issues.apache.org/activemq/browse/AMQ-877?page=all ]
Rob Davies reassigned AMQ-877:
--
Assignee: Rob Davies (was: james strachan)
Patch: refactoring to allow alternative (using different storage interface)
Destinations implementations.
-
Key: AMQ-877
URL: https://issues.apache.org/activemq/browse/AMQ-877
Project: ActiveMQ
Issue Type: Improvement
Components: Broker
Affects Versions: 4.x
Reporter: Maxim Fateev
Assigned To: Rob Davies
Fix For: 4.1
Attachments: destinationFactoryActiveMQPatch.txt
We were looking at alternate message persistence mechanisms that can co-exist
in current ActiveMQ code base and we are thinking of a mechanism that is
somewhat incompatible with the current MessageStore and PersistenceAdapter
APIs. Unfortunately, the current ActiveMQ broker doesn't allow for such a
change as the PersistenceAdapter and MessageStore interfaces are referenced
directly by the RegionBroker and by both the Queue and Topic region
implementations. Therefore, we are proposing a relatively small backwards
compatible refactoring of the broker code that would eliminate all
dependencies on the PersistenceAdapter and MessageStore interfaces from those
classes that do not use them directly. This refactoring would also allow
creation of a custom Destination implementation that may use an alternative
persistence mechanism on a destination by destination basis (which is exactly
what we need to do).
The main idea behind the refactoring is to replace many references to
PersistenceAdapter with a new interface: DestinationFactory:
public abstract class DestinationFactory {
abstract public Destination createDestination(ConnectionContext
context, ActiveMQDestination destination, DestinationStatistics
destinationStatistics) throws Exception;
abstract public Set getDestinations();
abstract public SubscriptionInfo[]
getAllDurableSubscriptions(ActiveMQTopic topic) throws IOException;
abstract public long getLastMessageBrokerSequenceId() throws
IOException;
abstract public void setRegionBroker(RegionBroker regionBroker);
}
Note that DestinationFactory doesn't mandate any specific persistence
mechanism. The classes that would reference it instead of PersistenceAdapter
are: RegionBroker, AbstractRegion, QueueRegion, and TopicRegion. Also, the
AbstractRegion.createDestination method would be changed from abstract to an
implementation that uses DestinationFactory to create a destination.
BrokerService could be changed to use DestinationFactory if one is
provided. If none is provided, it will create a DestinationFactory
implementation that instantiates Queue and Topic using PersistenceAdapter as
it does currently. Hence, full backwards compatibility will be maintained.
Patch is attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
Jason,
I'm not sure if this was intended or not ... but having these thirdparty
items under target results in the source being purged when doing an mvn
clean. This is unfortunate for those of us that are hitting the
failures on the openejb tests. My memory may not be correct but I
thought that prior to this change I could do the following:
- bootstrap (with the change to use the jspc 1.4.5-SNAPSHOT to avoid
the jspc problem).
- watch it fail to build openejb due to the test failures.
- run mvn clean install -Dmaven.test.skip=true
However, now that openejb is under target the clean deletes the source
and before it attempts to build and the result is that I still don't get
the openejb jar created in my local repo. Now I think I have to do the
following:
- bootstrap (with the change to use the jspc 1.4.5-SNAPSHOT to avoid
the jspc problem).
- watch it fail to build openejb due to the test failures.
- cd to target\external\openejb2
- run mvn -Dmaven.test.skip=true
- run mvn clean install
Am I doing something wrong?
Thanks,
Joe
[EMAIL PROTECTED] wrote:
Author: jdillon
Date: Sat Aug 26 20:25:18 2006
New Revision: 437291
URL: http://svn.apache.org/viewvc?rev=437291view=rev
Log:
Changed bootstrap to put external stuff into target/external instead of
thirdparty
Reduced ant output using -emacs and logger
Modified:
geronimo/server/trunk/bootstrap
geronimo/server/trunk/bootstrap.bat
geronimo/server/trunk/bootstrap.xml
Modified: geronimo/server/trunk/bootstrap
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/bootstrap?rev=437291r1=437290r2=437291view=diff
==
--- geronimo/server/trunk/bootstrap (original)
+++ geronimo/server/trunk/bootstrap Sat Aug 26 20:25:18 2006
@@ -19,5 +19,5 @@
PWD=`cygpath --windows $PWD`
fi
-ant $BUILD_OPTIONS -f bootstrap.xml $@
+ant $BUILD_OPTIONS -emacs -logger org.apache.tools.ant.NoBannerLogger -f bootstrap.xml
$@
Modified: geronimo/server/trunk/bootstrap.bat
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/bootstrap.bat?rev=437291r1=437290r2=437291view=diff
==
--- geronimo/server/trunk/bootstrap.bat (original)
+++ geronimo/server/trunk/bootstrap.bat Sat Aug 26 20:25:18 2006
@@ -10,7 +10,7 @@
set PROGNAME=%~nx0%
set ARGS=%*
-ant %BUILD_OPTIONS% -f bootstrap.xml %ARGS%
+ant %BUILD_OPTIONS% -emacs -logger org.apache.tools.ant.NoBannerLogger -f
bootstrap.xml %ARGS%
:END
Modified: geronimo/server/trunk/bootstrap.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/bootstrap.xml?rev=437291r1=437290r2=437291view=diff
==
--- geronimo/server/trunk/bootstrap.xml (original)
+++ geronimo/server/trunk/bootstrap.xml Sat Aug 26 20:25:18 2006
@@ -14,19 +14,19 @@
/sequential
/macrodef
-macrodef name=build-thirdparty
+macrodef name=build-external
attribute name=url/
attribute name=name/
sequential
-mkdir dir=${basedir}/thirdparty/
+mkdir dir=${basedir}/target/external/
-exec executable=svn dir=${basedir}/thirdparty
+exec executable=svn dir=${basedir}/target/external
arg value=co/
arg value=@{url}/
arg value=@{name}/
/exec
-mvn goal=install dir=${basedir}/thirdparty/@{name}/
+mvn goal=install dir=${basedir}/target/external/@{name}/
/sequential
/macrodef
@@ -42,6 +42,7 @@
target name=init depends=init:discover, init:windows, init:defaults
record name=${basedir}/bootstrap.log/
+
echoStarting bootstrap build.../echo
/target
@@ -88,14 +89,12 @@
!-- --
target name=clean depends=clean:init, clean:minimal, clean:full
-delete dir=${basedir}/thirdparty/
+delete dir=${basedir}/target/
mvn goal=clean/
/target
target name=clean:init depends=init
-echoCleaning.../echo
-
mkdir dir=${user.home}/.m2/repository/
/target
@@ -120,18 +119,18 @@
/target
-!-- == --
-!-- Thirdparty --
-!-- == --
+!-- = --
+!-- Externals --
+!-- = --
target name=specs depends=init
echoBuilding Specs.../echo
-build-thirdparty url=http://svn.apache.org/repos/asf/geronimo/specs/trunk;
name=specs/
+build-external url=http://svn.apache.org/repos/asf/geronimo/specs/trunk;
name=specs/
/target
target name=openejb2 depends=init
echoBuilding OpenEJB2.../echo
-build-thirdparty url=http://svn.codehaus.org/openejb/trunk/openejb2;
name=openejb2/
+build-external
Re: What does this do?
Any runtime changes to GBean attributes/references (through the
console, JMX, whatever) are saved to config.xml. Then they're applied
during the GBean loading process, overriding whatever the default
values may be. You can also edit the file manually while the server
is down. The point of pre-populating some values in config.xml is, as
Joe said, to make it obvious to a user where to change settings we
think they may be interested in. If we started with a relatively
empty file, it would be really hard to get the syntax right to e..g.
change a listen port, but if we add that to the default config.xml
then it becomes a search and replace operation. I suspect the CORBA
stuff is in there so the CORBA listen address/port can be changed.
FWIW, you can also add entirely new GBeans solely via config.xml,
though it's not typically done (mainly for things like if you add a
new network connector in the console and we want to add it to an
existing module).
Thanks,
Aaron
On 8/30/06, Rick McGuire [EMAIL PROTECTED] wrote:
Just when I think I have a complete handle on how GBeans work, someone
throws me a curve ball. In the process of reworking how the CORBA
objects are configured, I found the following in jetty config (and
repeated in the tomcat config):
module
name=org.apache.geronimo.configs/j2ee-corba/${pom.version}/car
load=false
gbean name=NameServer
attribute name=dbDirvar/cosnaming.db/attribute
attribute name=port${PlanCOSNamingPort}/attribute
/gbean
gbean name=Server
attribute name=args-ORBInitRef,
NameService=corbaloc::${PlanCOSNamingHost}:${PlanCOSNamingPort}/NameService/attribute
/gbean
gbean name=UnprotectedServer
attribute name=args-ORBInitRef,
NameService=corbaloc::${PlanCOSNamingHost}:${PlanCOSNamingPort}/NameService/attribute
/gbean
/module
I missed this earlier because there's no GBean class name, so my
searches for CorbaBean didn't turn anything up. Are these lines just a
modification for an existing GBean located somewhere else in the
configuration? Does this just modify attributes of the GBean before it
is started, or does this create a copy of the referenced GBean with the
new attributes merged in? I'm not even sure why these lines are here.
The values being set are the same as the original configuration. Is
there some other side effect involved?
Rick
[jira] Commented: (GERONIMO-2211) Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
[
http://issues.apache.org/jira/browse/GERONIMO-2211?page=comments#action_12431595
]
Anita Kulshreshtha commented on GERONIMO-2211:
--
The original code in GERONIMO-2071 had the following lines in pom.xml:
forkModeonce/forkMode
workingDirectory${basedir}/workingDirectory
I added these lines to rev 438055, enabled ConfigurationEntryTest and am
able to build sucessfully on windows and a login-audit.log
file is created.
Path: .
URL: https://svn.apache.org/repos/asf/geronimo/server/trunk
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 438055
Node Kind: directory
Schedule: normal
Last Changed Author: jdillon
Last Changed Rev: 437936
Last Changed Date: 2006-08-28 23:28:32 -0400 (Mon, 28 Aug 2006)
Properties Last Updated: 2006-08-29 08:13:22 -0400 (Tue, 29 Aug 2006)
Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
--
Key: GERONIMO-2211
URL: http://issues.apache.org/jira/browse/GERONIMO-2211
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 1.2
Reporter: Jason Dillon
Fix For: 1.2
A few tests failed in non-obvious ways when run under the m2 build. Need
someone who knows these tests better to inspect, resolve and enable the test
(remove the test exclusions in the pom).
The test fails with (on the console):
{noformat}
DEBUG [main] Starting boot
DEBUG [main] GBeanInstanceState for: geronimo/boot/none/car?role=kernel State
changed from stopped to starting
DEBUG [main] GBeanInstanceState for: geronimo/boot/none/car?role=kernel State
changed from starting to running
DEBUG [main] Booted
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=ServerInfo State
changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=ServerInfo State
changed from starting to running
DEBUG [main] GBeanInstanceState for: test/foo/1/car?new=LoginConfiguration
State changed from stopped to starting
DEBUG [main] Installed Geronimo login configuration
DEBUG [main] GBeanInstanceState for: test/foo/1/car?new=LoginConfiguration
State changed from starting to running
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=TestLoginService
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=TestLoginService
State changed from starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed from stopped
to starting
DEBUG [main] Remote login service started on: tcp://0.0.0.0:4242 clients can
connect to: tcp://0.0.0.0:4242
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed from
starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from starting to
running
DEBUG [main] Added Application Configuration Entry properties-client
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesSecurityRealm State changed from stopped to
starting
DEBUG [main] Waiting to start test/foo/1/car?name=PropertiesSecurityRealm
because no targets are running for reference LoginModuleConfiguration
matching the patterns test/foo/1/car?name=PropertiesLoginModuleUse
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=AuditLoginModule
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=AuditLoginModule
State changed from starting to running
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=AuditLoginModuleUse
State changed from stopped to starting
DEBUG [main] Waiting to start test/foo/1/car?name=AuditLoginModuleUse because
no targets are running for reference Next matching the patterns
test/foo/1/car?name=UPCredLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModuleUse State changed from stopped to
starting
DEBUG [main] Waiting to start test/foo/1/car?name=PropertiesLoginModuleUse
because no targets are running for reference Next matching the patterns
test/foo/1/car?name=AuditLoginModuleUse
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=UPCredLoginModule
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for:
windows build hell
We've been struggling with build problems on windows for some time now and things just keep on getting worse. I'm composing this note to summarize the problems that I'm aware of with work-arounds and possible solutions. I'm also fishing to see if anybody else has some ideas on how to resolve these issues. 1) Windows pathlength problem. Problem: There are miscellaneous failures that can typically be tracked down to the windows pathlength problem. The nature of our repository structure and deployment make this a big problem. It also seems like we're continuing to add more intermediate elements in path names as we try to get things more organized and conform to Maven 2 conventions. Work-around: The work-around is to keep the windows root path as small as possible. I now typically build from a root path of c:\g to avoid these problems. Possible Solution: For a longer term solution I'm planning to work on a new repository implementation in 1.2 that that isn't as redundant or verbose. 2) JSP compilation errors Problem: Embedded error: Unable to compile class for JSP Strange error message about JAVA_HOME, etc... Possible Solution/Work-around: Update the pom.xml in the root directory to use version 1.4.5-SNAPSHOT (from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff Genender is planning to make 1.4.5 an official release for this. We're not sure why it gets us around the problem so it may be a red herring. 3) Openejb2 test failures. Problem: Caused by: java.lang.NoSuchMethodException: org.openejb.deployment.DeploymentTestSuite.getName() Work-around: After bootstrap failure cd to root\target\external\openejb2 mvn -Dmaven.test.skip=true cd back to root mvn clean install Possible solution: Dain suggested adding the getName method to the test. However, when I attempted this I hit other errors. http://marc.theaimsgroup.com/?l=geronimo-devm=115680051431478w=2 I think it would be helpful if we could disable the openejb tests until this problem is resolved. 4) Blue screen of death (bsod) Problem: This has been reported by multiple users on various machines. When running an M1 or M2 build the user encounters a bsod due to a memory failure. PAGE_FAULT_IN_NONPAGED_AREA *** STOP: 0x0050 (0xBADDB148, 0x, 0x8056C77B, 0x) Dump of physical memory Work-around/Possible Solution: Haven't found one yet. I've tried updated drivers, replaced hardware, tried various heap size settings, etc At times this can be fairly frequent (every 3rd build attempt or so). I'm collecting bootstrap.log files from folks when this happens during a bootstrap to see if there is a common thread. So far, with the bootstrap logs, it always seems to happen at about the same place: Running tests after building a module (usually tomcat.ApplicationTest or TomcatModuleBuilderTest) and the final lines in the log are always the Creation of an MBeanServer like this: [exec] Running org.apache.geronimo.tomcat.ApplicationTest [exec] Created MBeanServer with ID: 5dcec6:10d5a184aed:-8000:jbohn2:1 Please respond to this note if you are seeing the bsod failures on windows. At first I thought this was just me and was hardware related. However, the more I talk to folks on windows the more I hear of other folks encountering this same problem. I've updated all drivers, replaced my entire system, and several other folks have reported seeing this on completely different systems. I think that pretty much rules out a hardware problem. ideas welcome! Joe
Re: windows build hell
Joe Bohn wrote:
2) JSP compilation errors
Problem:
Embedded error: Unable to compile class for JSP
Strange error message about JAVA_HOME, etc...
Possible Solution/Work-around:
Update the pom.xml in the root directory to use version 1.4.5-SNAPSHOT
(from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff Genender is
planning to make 1.4.5 an official release for this. We're not sure why
it gets us around the problem so it may be a red herring.
Its not a red herring. It gets you around the problem because in 1.4.5
I actually hunt down the tools.jar file...in a similar fashion as done
in Ant when running the jspc complier from there. i.e.:
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath
pathelement location=${java.home}/../lib/tools.jar/
...
I have to duplicate that in code. That's why 1.4.5 works.
The release is under vote. So far no -1s. I think I will be able to
release it today as the 72 hours is up. I'll let this list know when I
have released it.
Jeff
Re: windows build hell
inline.. --- Joe Bohn [EMAIL PROTECTED] wrote: We've been struggling with build problems on windows for some time now and things just keep on getting worse. I'm composing this note to summarize the problems that I'm aware of with work-arounds and possible solutions. I'm also fishing to see if anybody else has some ideas on how to resolve these issues. 1) Windows pathlength problem. Problem: There are miscellaneous failures that can typically be tracked down to the windows pathlength problem. The nature of our repository structure and deployment make this a big problem. It also seems like we're continuing to add more intermediate elements in path names as we try to get things more organized and conform to Maven 2 conventions. Work-around: The work-around is to keep the windows root path as small as possible. I now typically build from a root path of c:\g to avoid these problems. Possible Solution: For a longer term solution I'm planning to work on a new repository implementation in 1.2 that that isn't as redundant or verbose. +1 In the mean time could we warn our users that if they are using windows, they should use a short root path. If everyone agrees, I would like to edit the M2build page on cwiki. 2) JSP compilation errors Problem: Embedded error: Unable to compile class for JSP Strange error message about JAVA_HOME, etc... Possible Solution/Work-around: Update the pom.xml in the root directory to use version 1.4.5-SNAPSHOT (from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff Genender is planning to make 1.4.5 an official release for this. We're not sure why it gets us around the problem so it may be a red herring. I have seen this, but do not yet know why it happens. I would like to comment out the following lines until the problem is resolved. 1. applications/geronimo-examples/pom.xml modulegeronimo-jsp-examples/module 2. configs/pom.xml modulejsp-examples-jetty/module modulejsp-examples-tomcat/module These configs are not needed to start the server. 3) Openejb2 test failures. Problem: Caused by: java.lang.NoSuchMethodException: org.openejb.deployment.DeploymentTestSuite.getName() Work-around: After bootstrap failure cd to root\target\external\openejb2 mvn -Dmaven.test.skip=true cd back to root mvn clean install Possible solution: Dain suggested adding the getName method to the test. However, when I attempted this I hit other errors. http://marc.theaimsgroup.com/?l=geronimo-devm=115680051431478w=2 I think it would be helpful if we could disable the openejb tests until this problem is resolved. +1 4) Blue screen of death (bsod) Problem: This has been reported by multiple users on various machines. When running an M1 or M2 build the user encounters a bsod due to a memory failure. PAGE_FAULT_IN_NONPAGED_AREA *** STOP: 0x0050 (0xBADDB148, 0x, 0x8056C77B, 0x) Dump of physical memory Work-around/Possible Solution: Haven't found one yet. I've tried updated drivers, replaced hardware, tried various heap size settings, etc At times this can be fairly frequent (every 3rd build attempt or so). I'm collecting bootstrap.log files from folks when this happens during a bootstrap to see if there is a common thread. So far, with the bootstrap logs, it always seems to happen at about the same place: Running tests after building a module (usually tomcat.ApplicationTest or TomcatModuleBuilderTest) and the final lines in the log are always the Creation of an MBeanServer like this: [exec] Running org.apache.geronimo.tomcat.ApplicationTest [exec] Created MBeanServer with ID: 5dcec6:10d5a184aed:-8000:jbohn2:1 Please respond to this note if you are seeing the bsod failures on windows. At first I thought this was just me and was hardware related. However, the more I talk to folks on windows the more I hear of other folks encountering this same problem. I've updated all drivers, replaced my entire system, and several other folks have reported seeing this on completely different systems. I think that pretty much rules out a hardware problem. Hmm..., I have never seen this one. I am looking at the code and will get back to you if I find something strange. Thanks Anita ideas welcome! Joe __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: windows build hell
Thanks for the clarification Jeff (and pursuing the vote). Based upon
the most recent discussion on the jspc item I wasn't sure if you and
others were confortable with the fix. It certainly works for me! :-)
Joe
Jeff Genender wrote:
Joe Bohn wrote:
2) JSP compilation errors
Problem:
Embedded error: Unable to compile class for JSP
Strange error message about JAVA_HOME, etc...
Possible Solution/Work-around:
Update the pom.xml in the root directory to use version 1.4.5-SNAPSHOT
(from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff Genender is
planning to make 1.4.5 an official release for this. We're not sure why
it gets us around the problem so it may be a red herring.
Its not a red herring. It gets you around the problem because in 1.4.5
I actually hunt down the tools.jar file...in a similar fashion as done
in Ant when running the jspc complier from there. i.e.:
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath
pathelement location=${java.home}/../lib/tools.jar/
...
I have to duplicate that in code. That's why 1.4.5 works.
The release is under vote. So far no -1s. I think I will be able to
release it today as the 72 hours is up. I'll let this list know when I
have released it.
Jeff
Re: windows build hell
anita kulshreshtha wrote: 2) JSP compilation errors Problem: Embedded error: Unable to compile class for JSP Strange error message about JAVA_HOME, etc... Possible Solution/Work-around: Update the pom.xml in the root directory to use version 1.4.5-SNAPSHOT (from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff Genender is planning to make 1.4.5 an official release for this. We're not sure why it gets us around the problem so it may be a red herring. I have seen this, but do not yet know why it happens. I would like to comment out the following lines until the problem is resolved. 1. applications/geronimo-examples/pom.xml modulegeronimo-jsp-examples/module 2. configs/pom.xml modulejsp-examples-jetty/module modulejsp-examples-tomcat/module These configs are not needed to start the server. Joe explained the fix and I explain the reason. There is no need to remove compilation...we can move to 1.4.5-SNAPSHOT for the next 24 hours if need be.
Re: windows build hell
--- Jeff Genender [EMAIL PROTECTED] wrote: anita kulshreshtha wrote: 2) JSP compilation errors Problem: Embedded error: Unable to compile class for JSP Strange error message about JAVA_HOME, etc... Possible Solution/Work-around: Update the pom.xml in the root directory to use version 1.4.5-SNAPSHOT (from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff Genender is planning to make 1.4.5 an official release for this. We're not sure why it gets us around the problem so it may be a red herring. I have seen this, but do not yet know why it happens. I would like to comment out the following lines until the problem is resolved. 1. applications/geronimo-examples/pom.xml modulegeronimo-jsp-examples/module 2. configs/pom.xml modulejsp-examples-jetty/module modulejsp-examples-tomcat/module These configs are not needed to start the server. Joe explained the fix and I explain the reason. There is no need to remove compilation...we can move to 1.4.5-SNAPSHOT for the next 24 hours if need be. Thanks Jeff! Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Is jetty broken in latest snapshots?
I have tried both the August 29 and August 30 binary snapshots. With 3.0M2, I see a log message reporting jetty starting up. I can reach a port 8192 url as expected. With the snapshots, I see no such messages, and any attempt to reach a url on my servicemix machine with port 8192 results in a can't conect to server message. If this is a known issue, which snapshot has a working jetty integration? Jim -- View this message in context: http://www.nabble.com/Is-jetty-broken-in-latest-snapshots--tf2191258.html#a6063410 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: XBean and Genesis
+1 dain On Aug 30, 2006, at 1:08 AM, Guillaume Nodet wrote: It seems there are problems releasing Genesis, which XBean depends on. Should we remove this dependency and switch back to our old pom ? -- Cheers, Guillaume Nodet
Re: XBean and Genesis
+1 -David On Aug 30, 2006, at 1:08 AM, Guillaume Nodet wrote: It seems there are problems releasing Genesis, which XBean depends on. Should we remove this dependency and switch back to our old pom ? -- Cheers, Guillaume Nodet
Re: windows build hell
On Aug 30, 2006, at 11:36 AM, Joe Bohn wrote: We've been struggling with build problems on windows for some time now and things just keep on getting worse. I'm composing this note to summarize the problems that I'm aware of with work-arounds and possible solutions. I'm also fishing to see if anybody else has some ideas on how to resolve these issues. 1) Windows pathlength problem. Problem: There are miscellaneous failures that can typically be tracked down to the windows pathlength problem. The nature of our repository structure and deployment make this a big problem. It also seems like we're continuing to add more intermediate elements in path names as we try to get things more organized and conform to Maven 2 conventions. Work-around: The work-around is to keep the windows root path as small as possible. I now typically build from a root path of c:\g to avoid these problems. Possible Solution: For a longer term solution I'm planning to work on a new repository implementation in 1.2 that that isn't as redundant or verbose. I agree. Addressing this issue is overdue... I'd just been thinking about adding it to the 1.2 list, also... 3) Openejb2 test failures. Problem: Caused by: java.lang.NoSuchMethodException: org.openejb.deployment.DeploymentTestSuite.getName() Work-around: After bootstrap failure cd to root\target\external\openejb2 mvn -Dmaven.test.skip=true cd back to root mvn clean install Possible solution: Dain suggested adding the getName method to the test. However, when I attempted this I hit other errors. http://marc.theaimsgroup.com/?l=geronimo-devm=115680051431478w=2 I think it would be helpful if we could disable the openejb tests until this problem is resolved. It it's really useful, I guess it could be disabled. However, I think we should live with the workaround. Whatever is causing this problem needs to be identified and fixed. Is this a windows only problem? Or a general problem? 4) Blue screen of death (bsod) Building Geronimo may be the cause, but hard to fault Geronimo... You're on your own with this one... :-P --kevan
Re: XBean and Genesis
Done :) On 8/30/06, David Blevins [EMAIL PROTECTED] wrote: +1 -David On Aug 30, 2006, at 1:08 AM, Guillaume Nodet wrote: It seems there are problems releasing Genesis, which XBean depends on. Should we remove this dependency and switch back to our old pom ? -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: windows build hell
The jspc problem is not limited to windows. It just failed with the same error on a linux machine. Cheers Prasad On 8/30/06, anita kulshreshtha [EMAIL PROTECTED] wrote: --- Jeff Genender [EMAIL PROTECTED] wrote: anita kulshreshtha wrote: 2) JSP compilation errors Problem: Embedded error: Unable to compile class for JSP Strange error message about JAVA_HOME, etc... Possible Solution/Work-around: Update the pom.xml in the root directory to use version 1.4.5-SNAPSHOT (from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff Genender is planning to make 1.4.5 an official release for this. We're not sure why it gets us around the problem so it may be a red herring. I have seen this, but do not yet know why it happens. I would like to comment out the following lines until the problem is resolved. 1. applications/geronimo-examples/pom.xml modulegeronimo-jsp-examples/module 2. configs/pom.xml modulejsp-examples-jetty/module modulejsp-examples-tomcat/module These configs are not needed to start the server. Joe explained the fix and I explain the reason. There is no need to remove compilation...we can move to 1.4.5-SNAPSHOT for the next 24 hours if need be. Thanks Jeff! Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[VOTE] Release XBean 2.6 (retry)
I have uploaded new binaries of xbean.They are available at http://people.apache.org/~gnodet/xbean-2.6/The changes from the last cut includes a fix for spring 2.0-rc3, and the Genesis dependencywhich has been removed.I will sign and upload these artifacts to the official m2 repo, once the vote is over.-- Cheers,Guillaume Nodet
Re: [VOTE] Release XBean 2.6 (retry)
+1On 8/30/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I have uploaded new binaries of xbean.They are available at http://people.apache.org/~gnodet/xbean-2.6/ The changes from the last cut includes a fix for spring 2.0-rc3, and the Genesis dependencywhich has been removed.I will sign and upload these artifacts to the official m2 repo, once the vote is over.-- Cheers, Guillaume Nodet -- Cheers,Guillaume Nodet
[jira] Updated: (GERONIMO-2267) RepeatedFailureLockoutLoginModule: Does not function
[ http://issues.apache.org/jira/browse/GERONIMO-2267?page=all ] Vamsavardhana Reddy updated GERONIMO-2267: -- Fix Version/s: 1.1.2 (was: 1.1.1) This issue will be automatically addressed once GERONIMO-2294 is fixed. Changing the fix versions as per GERONIMO-2294. RepeatedFailureLockoutLoginModule: Does not function Key: GERONIMO-2267 URL: http://issues.apache.org/jira/browse/GERONIMO-2267 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 1.1 Environment: Win XP, G1.1.1-SNAPSHOT, Tomcat Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.1.2 I have created a security realm enabled for lockout after repeated failures. But the feature does not seem to work. I observed that RepeatedFailureLockoutLoginModule.login() is never invoked when a login attempt fails!!! -- 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-2352) j2ee-builder test deployment modules won't actually deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2352?page=all ] Bill Dudney updated GERONIMO-2352: -- Attachment: GERONIMO-2352.bdudney.patch apply from root mvn clean install if all tests pass the patch worked (effects modules/gerionmo-j2ee-builder). j2ee-builder test deployment modules won't actually deploy -- Key: GERONIMO-2352 URL: http://issues.apache.org/jira/browse/GERONIMO-2352 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Bill Dudney Attachments: GERONIMO-2352.bdudney.patch The ear/war/ejb-jar/rar files wont actually deploy to the server. I have a partial patch avalible but I'd like to get some discussion going on how to fix some of the problems, that is happening in the dev list. I will post the complete patch here when that discussion is wrapped up. -- 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
Keystore features - Create certificate request
Hi All, is there a way to create a certificate request in 1.1.1? I found GERONIMO-2218 but creating certificate request seems to have escaped from the patch. I have not found any other JIRA discussing this CSR issue ( that doesn't mean there isn't one ). Should I create a KeyStore portlet: Functionality missing from 1.0 [take 2] Cheers! Hernan
Re: j2ee-builder tests?
Hi Jason,
On Aug 29, 2006, at 3:18 PM, Jason Dillon wrote:
On Aug 29, 2006, at 12:07 PM, Bill Dudney wrote:
1) The dependency plugin version 2.0-SNAPSHOT is all that appears
to work. I could not find a functional 1.0 version of this plugin.
I guess the question here is what is the community stance on using
snapshots of plugins for the build? If this is not OK we need to
get on the maven lists and try to get a released version of the
dependency plugin. I found a couple of posts on the maven lists
that make me hope that a 2.0 release is going to happen soon but I
don't follow the maven community that closely so I'm not sure.
We are already using 1.0 of the dependency plugin...
plugin
groupIdorg.codehaus.mojo/groupId
artifactIddependency-maven-plugin/artifactId
version1.0/version
/plugin
I was using maven-dependency-plugin and following the docs here;
http://maven.apache.org/plugins/maven-dependency-plugin/
introduction.html
changed to match what is in the other poms (org.codehaus.mojo) and
works fine.
2) The j2ee-builder tests use a 'naked' ear that has been stripped
of its geronimo-application.xml file. Easy enough to do with ant
and we can do it with maven as well I'm sure but I was hoping
you'd have some ideas about how to do it more simply that what I
was thinking. Here are my two ideas;
a) adopt an approach similar to the boilerplate-{j2ee,minimal} in
the assembly build
b) use something in the dependency plugin that can strip various
elements from a jar file
c) unpack it then repack with the geronimo-application.xml file
excluded
What else is in the ear? Sounds like a normal jar module would be
fine.
ear depends on war, rar ejb, so there is virtually nothing in the
ear, just the geroinmo-application.xml and application.xml.
I'll submit the patch we can mess with these changes later.
3) There are a couple of more testing bits in the geronimo-j2ee-
builder module. I'm not sure what the best way to remove them is.
a) src/test-plan - has some bad plan files that ensure that
failure happens when expected. I think these should be moved into
src/test/resources and used from there in the tests but wanted to
get your take.
b) src/test-unpacked-ear is another set of deployment descriptors
and plans used for both positive and negative tests. Again these
could/should probably be moved into the src/test/resources
directory (when its created until then it looks like src/test is
the destination)
Um... okay... no opinion on this right now.
K - I moved them and updated the tests to use the stuff from the new
location.
You can delete modules/geronimo-j2ee-modules/{test-ear, test-ear13,
test-plan, test-unpacked-ear} after the patch is applied.
TTFN,
-bd-
--jason
Re: windows build hell
I had experienced all these errors, in addition, the one I get the most is an annoying out of mem error ... [DEBUG] Trace java.lang.OutOfMemoryError [INFO] -- [INFO] Total time: 38 seconds [INFO] Finished at: Wed Aug 30 15:50:06 EDT 2006 [INFO] Final Memory: 43M/63M [INFO] -- I tried to increase the mvn heap sz by adding to the command -DMAVEN_OPTS=-Xmx512m. It does not seem to work, any suggestions? Cheers! Hernan Joe Bohn wrote: We've been struggling with build problems on windows for some time now and things just keep on getting worse. I'm composing this note to summarize the problems that I'm aware of with work-arounds and possible solutions. I'm also fishing to see if anybody else has some ideas on how to resolve these issues. 1) Windows pathlength problem. Problem: There are miscellaneous failures that can typically be tracked down to the windows pathlength problem. The nature of our repository structure and deployment make this a big problem. It also seems like we're continuing to add more intermediate elements in path names as we try to get things more organized and conform to Maven 2 conventions. Work-around: The work-around is to keep the windows root path as small as possible. I now typically build from a root path of c:\g to avoid these problems. Possible Solution: For a longer term solution I'm planning to work on a new repository implementation in 1.2 that that isn't as redundant or verbose. 2) JSP compilation errors Problem: Embedded error: Unable to compile class for JSP Strange error message about JAVA_HOME, etc... Possible Solution/Work-around: Update the pom.xml in the root directory to use version 1.4.5-SNAPSHOT (from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff Genender is planning to make 1.4.5 an official release for this. We're not sure why it gets us around the problem so it may be a red herring. 3) Openejb2 test failures. Problem: Caused by: java.lang.NoSuchMethodException: org.openejb.deployment.DeploymentTestSuite.getName() Work-around: After bootstrap failure cd to root\target\external\openejb2 mvn -Dmaven.test.skip=true cd back to root mvn clean install Possible solution: Dain suggested adding the getName method to the test. However, when I attempted this I hit other errors. http://marc.theaimsgroup.com/?l=geronimo-devm=115680051431478w=2 I think it would be helpful if we could disable the openejb tests until this problem is resolved. 4) Blue screen of death (bsod) Problem: This has been reported by multiple users on various machines. When running an M1 or M2 build the user encounters a bsod due to a memory failure. PAGE_FAULT_IN_NONPAGED_AREA *** STOP: 0x0050 (0xBADDB148, 0x, 0x8056C77B, 0x) Dump of physical memory Work-around/Possible Solution: Haven't found one yet. I've tried updated drivers, replaced hardware, tried various heap size settings, etc At times this can be fairly frequent (every 3rd build attempt or so). I'm collecting bootstrap.log files from folks when this happens during a bootstrap to see if there is a common thread. So far, with the bootstrap logs, it always seems to happen at about the same place: Running tests after building a module (usually tomcat.ApplicationTest or TomcatModuleBuilderTest) and the final lines in the log are always the Creation of an MBeanServer like this: [exec] Running org.apache.geronimo.tomcat.ApplicationTest [exec] Created MBeanServer with ID: 5dcec6:10d5a184aed:-8000:jbohn2:1 Please respond to this note if you are seeing the bsod failures on windows. At first I thought this was just me and was hardware related. However, the more I talk to folks on windows the more I hear of other folks encountering this same problem. I've updated all drivers, replaced my entire system, and several other folks have reported seeing this on completely different systems. I think that pretty much rules out a hardware problem. ideas welcome! Joe
[VOTE] 1.1.1-rc1 for Release
CTS is complete and here is the RC1 for your reviewing pleasure. Please send your comments to the dev@geronimo.apache.org list. If there are no negative comments after Monday, September 5th at 0900 ET. We'll move this to be the final and release it. If there are issues, they will be addressed and another e-mail will be issued resetting for an rc2 vote. Thanks. *Source* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-1.1.1-rc1-src.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-1.1.1-rc1-src.zip *Specifications* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-j2ee-jacc_1.0_spec-1.1.1.jar *Schemas* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-schema-j2ee_1.4-1.0-src.jar http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-schema-j2ee_1.4-1.0.jar *Distributions* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty-j2ee-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty-j2ee-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty-minimal-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty-minimal-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat-j2ee-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat-j2ee-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat-minimal-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat-minimal-1.1.1-rc1.zip If you want to build you will need these jars also (will be released simultaneously with Geronimo) and these need to be placed in your local Maven repository. *OpenEJB Jars* http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-builder-2.1.1.jar http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-core-2.1.1.jar http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-pkgen-builder-2.1.1.jar
Re: windows build hell
I got rid of the OOME by putting MAVEN_OPTS=-Xmx512m into my ~/.mavenrc file TTFN, -bd- On Aug 30, 2006, at 2:04 PM, Hernan Cunico wrote: I had experienced all these errors, in addition, the one I get the most is an annoying out of mem error ... [DEBUG] Trace java.lang.OutOfMemoryError [INFO] -- [INFO] Total time: 38 seconds [INFO] Finished at: Wed Aug 30 15:50:06 EDT 2006 [INFO] Final Memory: 43M/63M [INFO] -- I tried to increase the mvn heap sz by adding to the command - DMAVEN_OPTS=-Xmx512m. It does not seem to work, any suggestions? Cheers! Hernan Joe Bohn wrote: We've been struggling with build problems on windows for some time now and things just keep on getting worse. I'm composing this note to summarize the problems that I'm aware of with work-arounds and possible solutions. I'm also fishing to see if anybody else has some ideas on how to resolve these issues. 1) Windows pathlength problem. Problem: There are miscellaneous failures that can typically be tracked down to the windows pathlength problem. The nature of our repository structure and deployment make this a big problem. It also seems like we're continuing to add more intermediate elements in path names as we try to get things more organized and conform to Maven 2 conventions. Work-around: The work-around is to keep the windows root path as small as possible. I now typically build from a root path of c:\g to avoid these problems. Possible Solution: For a longer term solution I'm planning to work on a new repository implementation in 1.2 that that isn't as redundant or verbose. 2) JSP compilation errors Problem: Embedded error: Unable to compile class for JSP Strange error message about JAVA_HOME, etc... Possible Solution/Work-around: Update the pom.xml in the root directory to use version 1.4.5- SNAPSHOT (from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff Genender is planning to make 1.4.5 an official release for this. We're not sure why it gets us around the problem so it may be a red herring. 3) Openejb2 test failures. Problem: Caused by: java.lang.NoSuchMethodException: org.openejb.deployment.DeploymentTestSuite.getName() Work-around: After bootstrap failure cd to root\target\external\openejb2 mvn -Dmaven.test.skip=true cd back to root mvn clean install Possible solution: Dain suggested adding the getName method to the test. However, when I attempted this I hit other errors. http://marc.theaimsgroup.com/?l=geronimo-devm=115680051431478w=2 I think it would be helpful if we could disable the openejb tests until this problem is resolved. 4) Blue screen of death (bsod) Problem: This has been reported by multiple users on various machines. When running an M1 or M2 build the user encounters a bsod due to a memory failure. PAGE_FAULT_IN_NONPAGED_AREA *** STOP: 0x0050 (0xBADDB148, 0x, 0x8056C77B, 0x) Dump of physical memory Work-around/Possible Solution: Haven't found one yet. I've tried updated drivers, replaced hardware, tried various heap size settings, etc At times this can be fairly frequent (every 3rd build attempt or so). I'm collecting bootstrap.log files from folks when this happens during a bootstrap to see if there is a common thread. So far, with the bootstrap logs, it always seems to happen at about the same place: Running tests after building a module (usually tomcat.ApplicationTest or TomcatModuleBuilderTest) and the final lines in the log are always the Creation of an MBeanServer like this: [exec] Running org.apache.geronimo.tomcat.ApplicationTest [exec] Created MBeanServer with ID: 5dcec6:10d5a184aed:-8000:jbohn2:1 Please respond to this note if you are seeing the bsod failures on windows. At first I thought this was just me and was hardware related. However, the more I talk to folks on windows the more I hear of other folks encountering this same problem. I've updated all drivers, replaced my entire system, and several other folks have reported seeing this on completely different systems. I think that pretty much rules out a hardware problem. ideas welcome! Joe
Re: windows build hell
Windows wont let you create a file with . as the initial character, that's why I'm trying to force it in the command line. Is there any other alternative in windows? Cheers! Hernan Bill Dudney wrote: I got rid of the OOME by putting MAVEN_OPTS=-Xmx512m into my ~/.mavenrc file TTFN, -bd- On Aug 30, 2006, at 2:04 PM, Hernan Cunico wrote: I had experienced all these errors, in addition, the one I get the most is an annoying out of mem error ... [DEBUG] Trace java.lang.OutOfMemoryError [INFO] -- [INFO] Total time: 38 seconds [INFO] Finished at: Wed Aug 30 15:50:06 EDT 2006 [INFO] Final Memory: 43M/63M [INFO] -- I tried to increase the mvn heap sz by adding to the command -DMAVEN_OPTS=-Xmx512m. It does not seem to work, any suggestions? Cheers! Hernan Joe Bohn wrote: We've been struggling with build problems on windows for some time now and things just keep on getting worse. I'm composing this note to summarize the problems that I'm aware of with work-arounds and possible solutions. I'm also fishing to see if anybody else has some ideas on how to resolve these issues. 1) Windows pathlength problem. Problem: There are miscellaneous failures that can typically be tracked down to the windows pathlength problem. The nature of our repository structure and deployment make this a big problem. It also seems like we're continuing to add more intermediate elements in path names as we try to get things more organized and conform to Maven 2 conventions. Work-around: The work-around is to keep the windows root path as small as possible. I now typically build from a root path of c:\g to avoid these problems. Possible Solution: For a longer term solution I'm planning to work on a new repository implementation in 1.2 that that isn't as redundant or verbose. 2) JSP compilation errors Problem: Embedded error: Unable to compile class for JSP Strange error message about JAVA_HOME, etc... Possible Solution/Work-around: Update the pom.xml in the root directory to use version 1.4.5-SNAPSHOT (from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff Genender is planning to make 1.4.5 an official release for this. We're not sure why it gets us around the problem so it may be a red herring. 3) Openejb2 test failures. Problem: Caused by: java.lang.NoSuchMethodException: org.openejb.deployment.DeploymentTestSuite.getName() Work-around: After bootstrap failure cd to root\target\external\openejb2 mvn -Dmaven.test.skip=true cd back to root mvn clean install Possible solution: Dain suggested adding the getName method to the test. However, when I attempted this I hit other errors. http://marc.theaimsgroup.com/?l=geronimo-devm=115680051431478w=2 I think it would be helpful if we could disable the openejb tests until this problem is resolved. 4) Blue screen of death (bsod) Problem: This has been reported by multiple users on various machines. When running an M1 or M2 build the user encounters a bsod due to a memory failure. PAGE_FAULT_IN_NONPAGED_AREA *** STOP: 0x0050 (0xBADDB148, 0x, 0x8056C77B, 0x) Dump of physical memory Work-around/Possible Solution: Haven't found one yet. I've tried updated drivers, replaced hardware, tried various heap size settings, etc At times this can be fairly frequent (every 3rd build attempt or so). I'm collecting bootstrap.log files from folks when this happens during a bootstrap to see if there is a common thread. So far, with the bootstrap logs, it always seems to happen at about the same place: Running tests after building a module (usually tomcat.ApplicationTest or TomcatModuleBuilderTest) and the final lines in the log are always the Creation of an MBeanServer like this: [exec] Running org.apache.geronimo.tomcat.ApplicationTest [exec] Created MBeanServer with ID: 5dcec6:10d5a184aed:-8000:jbohn2:1 Please respond to this note if you are seeing the bsod failures on windows. At first I thought this was just me and was hardware related. However, the more I talk to folks on windows the more I hear of other folks encountering this same problem. I've updated all drivers, replaced my entire system, and several other folks have reported seeing this on completely different systems. I think that pretty much rules out a hardware problem. ideas welcome! Joe
Re: windows build hell
You can create a filename starting with . from a command window. Paul On 8/30/06, Hernan Cunico [EMAIL PROTECTED] wrote: Windows wont let you create a file with . as the initial character, that's why I'm trying to force it in the command line. Is there any other alternative in windows? Cheers! Hernan Bill Dudney wrote: I got rid of the OOME by putting MAVEN_OPTS=-Xmx512m into my ~/.mavenrc file TTFN, -bd- On Aug 30, 2006, at 2:04 PM, Hernan Cunico wrote: I had experienced all these errors, in addition, the one I get the most is an annoying out of mem error ... [DEBUG] Trace java.lang.OutOfMemoryError [INFO] -- [INFO] Total time: 38 seconds [INFO] Finished at: Wed Aug 30 15:50:06 EDT 2006 [INFO] Final Memory: 43M/63M [INFO] -- I tried to increase the mvn heap sz by adding to the command -DMAVEN_OPTS=-Xmx512m. It does not seem to work, any suggestions? Cheers! Hernan Joe Bohn wrote: We've been struggling with build problems on windows for some time now and things just keep on getting worse. I'm composing this note to summarize the problems that I'm aware of with work-arounds and possible solutions. I'm also fishing to see if anybody else has some ideas on how to resolve these issues. 1) Windows pathlength problem. Problem: There are miscellaneous failures that can typically be tracked down to the windows pathlength problem. The nature of our repository structure and deployment make this a big problem. It also seems like we're continuing to add more intermediate elements in path names as we try to get things more organized and conform to Maven 2 conventions. Work-around: The work-around is to keep the windows root path as small as possible. I now typically build from a root path of c:\g to avoid these problems. Possible Solution: For a longer term solution I'm planning to work on a new repository implementation in 1.2 that that isn't as redundant or verbose. 2) JSP compilation errors Problem: Embedded error: Unable to compile class for JSP Strange error message about JAVA_HOME, etc... Possible Solution/Work-around: Update the pom.xml in the root directory to use version 1.4.5-SNAPSHOT (from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff Genender is planning to make 1.4.5 an official release for this. We're not sure why it gets us around the problem so it may be a red herring. 3) Openejb2 test failures. Problem: Caused by: java.lang.NoSuchMethodException: org.openejb.deployment.DeploymentTestSuite.getName() Work-around: After bootstrap failure cd to root\target\external\openejb2 mvn -Dmaven.test.skip=true cd back to root mvn clean install Possible solution: Dain suggested adding the getName method to the test. However, when I attempted this I hit other errors. http://marc.theaimsgroup.com/?l=geronimo-devm=115680051431478w=2 I think it would be helpful if we could disable the openejb tests until this problem is resolved. 4) Blue screen of death (bsod) Problem: This has been reported by multiple users on various machines. When running an M1 or M2 build the user encounters a bsod due to a memory failure. PAGE_FAULT_IN_NONPAGED_AREA *** STOP: 0x0050 (0xBADDB148, 0x, 0x8056C77B, 0x) Dump of physical memory Work-around/Possible Solution: Haven't found one yet. I've tried updated drivers, replaced hardware, tried various heap size settings, etc At times this can be fairly frequent (every 3rd build attempt or so). I'm collecting bootstrap.log files from folks when this happens during a bootstrap to see if there is a common thread. So far, with the bootstrap logs, it always seems to happen at about the same place: Running tests after building a module (usually tomcat.ApplicationTest or TomcatModuleBuilderTest) and the final lines in the log are always the Creation of an MBeanServer like this: [exec] Running org.apache.geronimo.tomcat.ApplicationTest [exec] Created MBeanServer with ID: 5dcec6:10d5a184aed:-8000:jbohn2:1 Please respond to this note if you are seeing the bsod failures on windows. At first I thought this was just me and was hardware related. However, the more I talk to folks on windows the more I hear of other folks encountering this same problem. I've updated all drivers, replaced my entire system, and several other folks have reported seeing this on completely different systems. I think that pretty much rules out a hardware problem. ideas welcome! Joe
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
All of you guys who are seeing strange failures... I suggest you not
use bootstrap, but instead run the steps by hand.
--jason
On Aug 30, 2006, at 7:38 AM, Joe Bohn wrote:
Jason,
I'm not sure if this was intended or not ... but having these
thirdparty items under target results in the source being purged
when doing an mvn clean. This is unfortunate for those of us that
are hitting the failures on the openejb tests. My memory may not
be correct but I thought that prior to this change I could do the
following:
- bootstrap (with the change to use the jspc 1.4.5-SNAPSHOT to
avoid the jspc problem).
- watch it fail to build openejb due to the test failures.
- run mvn clean install -Dmaven.test.skip=true
However, now that openejb is under target the clean deletes the
source and before it attempts to build and the result is that I
still don't get the openejb jar created in my local repo. Now I
think I have to do the following:
- bootstrap (with the change to use the jspc 1.4.5-SNAPSHOT to
avoid the jspc problem).
- watch it fail to build openejb due to the test failures.
- cd to target\external\openejb2
- run mvn -Dmaven.test.skip=true
- run mvn clean install
Am I doing something wrong?
Thanks,
Joe
[EMAIL PROTECTED] wrote:
Author: jdillon
Date: Sat Aug 26 20:25:18 2006
New Revision: 437291
URL: http://svn.apache.org/viewvc?rev=437291view=rev
Log:
Changed bootstrap to put external stuff into target/external
instead of thirdparty
Reduced ant output using -emacs and logger
Modified:
geronimo/server/trunk/bootstrap
geronimo/server/trunk/bootstrap.bat
geronimo/server/trunk/bootstrap.xml
Modified: geronimo/server/trunk/bootstrap
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/bootstrap?
rev=437291r1=437290r2=437291view=diff
=
=
--- geronimo/server/trunk/bootstrap (original)
+++ geronimo/server/trunk/bootstrap Sat Aug 26 20:25:18 2006
@@ -19,5 +19,5 @@
PWD=`cygpath --windows $PWD`
fi
-ant $BUILD_OPTIONS -f bootstrap.xml $@
+ant $BUILD_OPTIONS -emacs -logger
org.apache.tools.ant.NoBannerLogger -f bootstrap.xml $@
Modified: geronimo/server/trunk/bootstrap.bat
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/
bootstrap.bat?rev=437291r1=437290r2=437291view=diff
=
=
--- geronimo/server/trunk/bootstrap.bat (original)
+++ geronimo/server/trunk/bootstrap.bat Sat Aug 26 20:25:18 2006
@@ -10,7 +10,7 @@
set PROGNAME=%~nx0%
set ARGS=%*
-ant %BUILD_OPTIONS% -f bootstrap.xml %ARGS%
+ant %BUILD_OPTIONS% -emacs -logger
org.apache.tools.ant.NoBannerLogger -f bootstrap.xml %ARGS%
:END
Modified: geronimo/server/trunk/bootstrap.xml
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/
bootstrap.xml?rev=437291r1=437290r2=437291view=diff
=
=
--- geronimo/server/trunk/bootstrap.xml (original)
+++ geronimo/server/trunk/bootstrap.xml Sat Aug 26 20:25:18 2006
@@ -14,19 +14,19 @@
/sequential
/macrodef
-macrodef name=build-thirdparty
+macrodef name=build-external
attribute name=url/
attribute name=name/
sequential
-mkdir dir=${basedir}/thirdparty/
+mkdir dir=${basedir}/target/external/
-exec executable=svn dir=${basedir}/
thirdparty
+exec executable=svn dir=${basedir}/target/external
arg value=co/
arg value=@{url}/
arg value=@{name}/
/exec
-mvn goal=install dir=${basedir}/
thirdparty/@{name}/
+mvn goal=install dir=${basedir}/target/external/@
{name}/
/sequential
/macrodef
@@ -42,6 +42,7 @@
target name=init depends=init:discover,
init:windows, init:defaults
record name=${basedir}/bootstrap.log/
+ echoStarting bootstrap build.../echo
/target
@@ -88,14 +89,12 @@
!-- --
target name=clean depends=clean:init, clean:minimal,
clean:full
-delete dir=${basedir}/thirdparty/
+delete dir=${basedir}/target/
mvn goal=clean/
/target
target name=clean:init depends=init
-echoCleaning.../echo
- mkdir dir=${user.home}/.m2/repository/
/target
@@ -120,18 +119,18 @@
/target
-!-- == --
-!-- Thirdparty --
-!-- == --
+!-- = --
+!-- Externals --
+!-- = --
target name=specs depends=init
echoBuilding Specs.../echo
-build-thirdparty url=http://svn.apache.org/repos/asf/
geronimo/specs/trunk name=specs/
+build-external url=http://svn.apache.org/repos/asf/
geronimo/specs/trunk name=specs/
/target
target name=openejb2 depends=init
[jira] Commented: (GERONIMO-2211) Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
[
http://issues.apache.org/jira/browse/GERONIMO-2211?page=comments#action_12431694
]
Jason Dillon commented on GERONIMO-2211:
The working dir should not be set to ${basedir}, it should be left as
${basedir}/target.
Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
--
Key: GERONIMO-2211
URL: http://issues.apache.org/jira/browse/GERONIMO-2211
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 1.2
Reporter: Jason Dillon
Fix For: 1.2
A few tests failed in non-obvious ways when run under the m2 build. Need
someone who knows these tests better to inspect, resolve and enable the test
(remove the test exclusions in the pom).
The test fails with (on the console):
{noformat}
DEBUG [main] Starting boot
DEBUG [main] GBeanInstanceState for: geronimo/boot/none/car?role=kernel State
changed from stopped to starting
DEBUG [main] GBeanInstanceState for: geronimo/boot/none/car?role=kernel State
changed from starting to running
DEBUG [main] Booted
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=ServerInfo State
changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=ServerInfo State
changed from starting to running
DEBUG [main] GBeanInstanceState for: test/foo/1/car?new=LoginConfiguration
State changed from stopped to starting
DEBUG [main] Installed Geronimo login configuration
DEBUG [main] GBeanInstanceState for: test/foo/1/car?new=LoginConfiguration
State changed from starting to running
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=TestLoginService
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=TestLoginService
State changed from starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed from stopped
to starting
DEBUG [main] Remote login service started on: tcp://0.0.0.0:4242 clients can
connect to: tcp://0.0.0.0:4242
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed from
starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from starting to
running
DEBUG [main] Added Application Configuration Entry properties-client
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesSecurityRealm State changed from stopped to
starting
DEBUG [main] Waiting to start test/foo/1/car?name=PropertiesSecurityRealm
because no targets are running for reference LoginModuleConfiguration
matching the patterns test/foo/1/car?name=PropertiesLoginModuleUse
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=AuditLoginModule
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=AuditLoginModule
State changed from starting to running
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=AuditLoginModuleUse
State changed from stopped to starting
DEBUG [main] Waiting to start test/foo/1/car?name=AuditLoginModuleUse because
no targets are running for reference Next matching the patterns
test/foo/1/car?name=UPCredLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModuleUse State changed from stopped to
starting
DEBUG [main] Waiting to start test/foo/1/car?name=PropertiesLoginModuleUse
because no targets are running for reference Next matching the patterns
test/foo/1/car?name=AuditLoginModuleUse
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=UPCredLoginModule
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=UPCredLoginModule
State changed from starting to running
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=UPCredLoginModuleUse
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=UPCredLoginModuleUse
State changed from starting to running
DEBUG [main] Checking if parent is running:
parent=test/foo/1/car?name=AuditLoginModule
DEBUG [main] Parent is running: parent=test/foo/1/car?name=AuditLoginModule
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=AuditLoginModuleUse
State changed from starting to running
DEBUG [main] Checking if parent is running:
Re: windows build hell
What seems to have worked was to set that value as an environment variable set MAVEN_OPTS=-Xmx512m -XX:MaxPermSize=128m That took care of the OOME - Thanks Joe !!! Still having fun with other build errors though. Cheers! Hernan Paul McMahan wrote: You can create a filename starting with . from a command window. Paul On 8/30/06, Hernan Cunico [EMAIL PROTECTED] wrote: Windows wont let you create a file with . as the initial character, that's why I'm trying to force it in the command line. Is there any other alternative in windows? Cheers! Hernan Bill Dudney wrote: I got rid of the OOME by putting MAVEN_OPTS=-Xmx512m into my ~/.mavenrc file TTFN, -bd- On Aug 30, 2006, at 2:04 PM, Hernan Cunico wrote: I had experienced all these errors, in addition, the one I get the most is an annoying out of mem error ... [DEBUG] Trace java.lang.OutOfMemoryError [INFO] -- [INFO] Total time: 38 seconds [INFO] Finished at: Wed Aug 30 15:50:06 EDT 2006 [INFO] Final Memory: 43M/63M [INFO] -- I tried to increase the mvn heap sz by adding to the command -DMAVEN_OPTS=-Xmx512m. It does not seem to work, any suggestions? Cheers! Hernan Joe Bohn wrote: We've been struggling with build problems on windows for some time now and things just keep on getting worse. I'm composing this note to summarize the problems that I'm aware of with work-arounds and possible solutions. I'm also fishing to see if anybody else has some ideas on how to resolve these issues. 1) Windows pathlength problem. Problem: There are miscellaneous failures that can typically be tracked down to the windows pathlength problem. The nature of our repository structure and deployment make this a big problem. It also seems like we're continuing to add more intermediate elements in path names as we try to get things more organized and conform to Maven 2 conventions. Work-around: The work-around is to keep the windows root path as small as possible. I now typically build from a root path of c:\g to avoid these problems. Possible Solution: For a longer term solution I'm planning to work on a new repository implementation in 1.2 that that isn't as redundant or verbose. 2) JSP compilation errors Problem: Embedded error: Unable to compile class for JSP Strange error message about JAVA_HOME, etc... Possible Solution/Work-around: Update the pom.xml in the root directory to use version 1.4.5-SNAPSHOT (from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff Genender is planning to make 1.4.5 an official release for this. We're not sure why it gets us around the problem so it may be a red herring. 3) Openejb2 test failures. Problem: Caused by: java.lang.NoSuchMethodException: org.openejb.deployment.DeploymentTestSuite.getName() Work-around: After bootstrap failure cd to root\target\external\openejb2 mvn -Dmaven.test.skip=true cd back to root mvn clean install Possible solution: Dain suggested adding the getName method to the test. However, when I attempted this I hit other errors. http://marc.theaimsgroup.com/?l=geronimo-devm=115680051431478w=2 I think it would be helpful if we could disable the openejb tests until this problem is resolved. 4) Blue screen of death (bsod) Problem: This has been reported by multiple users on various machines. When running an M1 or M2 build the user encounters a bsod due to a memory failure. PAGE_FAULT_IN_NONPAGED_AREA *** STOP: 0x0050 (0xBADDB148, 0x, 0x8056C77B, 0x) Dump of physical memory Work-around/Possible Solution: Haven't found one yet. I've tried updated drivers, replaced hardware, tried various heap size settings, etc At times this can be fairly frequent (every 3rd build attempt or so). I'm collecting bootstrap.log files from folks when this happens during a bootstrap to see if there is a common thread. So far, with the bootstrap logs, it always seems to happen at about the same place: Running tests after building a module (usually tomcat.ApplicationTest or TomcatModuleBuilderTest) and the final lines in the log are always the Creation of an MBeanServer like this: [exec] Running org.apache.geronimo.tomcat.ApplicationTest [exec] Created MBeanServer with ID: 5dcec6:10d5a184aed:-8000:jbohn2:1 Please respond to this note if you are seeing the bsod failures on windows. At first I thought this was just me and was hardware related. However, the more I talk to folks on windows the more I hear of other folks encountering this same problem. I've updated all drivers, replaced my entire system, and several other folks have reported seeing this on completely different systems. I think that pretty much rules out a hardware problem. ideas welcome! Joe
Re: windows build hell
Of course you can create a file with . as the initial character in Windows... how do you think the ~/.m2/ directory gets created? _Windows Explorer_ might not like to allow that... but that does not mean that it is not possible to do so... its just crappy microsoft software trying to be intelligent and ending up being dumb as rocks... again. --jason On Aug 30, 2006, at 1:25 PM, Hernan Cunico wrote: Windows wont let you create a file with . as the initial character, that's why I'm trying to force it in the command line. Is there any other alternative in windows? Cheers! Hernan Bill Dudney wrote: I got rid of the OOME by putting MAVEN_OPTS=-Xmx512m into my ~/.mavenrc file TTFN, -bd- On Aug 30, 2006, at 2:04 PM, Hernan Cunico wrote: I had experienced all these errors, in addition, the one I get the most is an annoying out of mem error ... [DEBUG] Trace java.lang.OutOfMemoryError [INFO] -- [INFO] Total time: 38 seconds [INFO] Finished at: Wed Aug 30 15:50:06 EDT 2006 [INFO] Final Memory: 43M/63M [INFO] -- I tried to increase the mvn heap sz by adding to the command - DMAVEN_OPTS=-Xmx512m. It does not seem to work, any suggestions? Cheers! Hernan Joe Bohn wrote: We've been struggling with build problems on windows for some time now and things just keep on getting worse. I'm composing this note to summarize the problems that I'm aware of with work-arounds and possible solutions. I'm also fishing to see if anybody else has some ideas on how to resolve these issues. 1) Windows pathlength problem. Problem: There are miscellaneous failures that can typically be tracked down to the windows pathlength problem. The nature of our repository structure and deployment make this a big problem. It also seems like we're continuing to add more intermediate elements in path names as we try to get things more organized and conform to Maven 2 conventions. Work-around: The work-around is to keep the windows root path as small as possible. I now typically build from a root path of c:\g to avoid these problems. Possible Solution: For a longer term solution I'm planning to work on a new repository implementation in 1.2 that that isn't as redundant or verbose. 2) JSP compilation errors Problem: Embedded error: Unable to compile class for JSP Strange error message about JAVA_HOME, etc... Possible Solution/Work-around: Update the pom.xml in the root directory to use version 1.4.5- SNAPSHOT (from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff Genender is planning to make 1.4.5 an official release for this. We're not sure why it gets us around the problem so it may be a red herring. 3) Openejb2 test failures. Problem: Caused by: java.lang.NoSuchMethodException: org.openejb.deployment.DeploymentTestSuite.getName() Work-around: After bootstrap failure cd to root\target\external\openejb2 mvn -Dmaven.test.skip=true cd back to root mvn clean install Possible solution: Dain suggested adding the getName method to the test. However, when I attempted this I hit other errors. http://marc.theaimsgroup.com/?l=geronimo-devm=115680051431478w=2 I think it would be helpful if we could disable the openejb tests until this problem is resolved. 4) Blue screen of death (bsod) Problem: This has been reported by multiple users on various machines. When running an M1 or M2 build the user encounters a bsod due to a memory failure. PAGE_FAULT_IN_NONPAGED_AREA *** STOP: 0x0050 (0xBADDB148, 0x, 0x8056C77B, 0x) Dump of physical memory Work-around/Possible Solution: Haven't found one yet. I've tried updated drivers, replaced hardware, tried various heap size settings, etc At times this can be fairly frequent (every 3rd build attempt or so). I'm collecting bootstrap.log files from folks when this happens during a bootstrap to see if there is a common thread. So far, with the bootstrap logs, it always seems to happen at about the same place: Running tests after building a module (usually tomcat.ApplicationTest or TomcatModuleBuilderTest) and the final lines in the log are always the Creation of an MBeanServer like this: [exec] Running org.apache.geronimo.tomcat.ApplicationTest [exec] Created MBeanServer with ID: 5dcec6:10d5a184aed:-8000:jbohn2:1 Please respond to this note if you are seeing the bsod failures on windows. At first I thought this was just me and was hardware related. However, the more I talk to folks on windows the more I hear of other folks encountering this same problem. I've updated all drivers, replaced my entire system, and several other folks have reported seeing this on completely different systems. I think that pretty much rules out a hardware problem. ideas welcome! Joe
[jira] Updated: (GERONIMO-2163) WADI Integration for Jetty
[ http://issues.apache.org/jira/browse/GERONIMO-2163?page=all ] David Jencks updated GERONIMO-2163: --- Attachment: GERONIMO-2163-v6b.patch My patch fixes a couple of bugs in gianni's patch 6. - the jndi environment construction got broken -- no kernel aware references were working. - Avoid an npe when distributable is present but no clustering builder is installed. The behavior with NamespaceDrivenBuilders is slightly different than with Gianni's original approach. Previously the wadi builder would use defaults if no wadi config was specified. In the NDB implementation, at least a single element in the wadi-cluster namespace is needed to start the builder. WADI Integration for Jetty -- Key: GERONIMO-2163 URL: http://issues.apache.org/jira/browse/GERONIMO-2163 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Clustering Reporter: Gianny Damour Assigned To: Gianny Damour Priority: Minor Attachments: GERONIMO-2163-v3.patch, GERONIMO-2163-v3b.patch, GERONIMO-2163-v4-old.patch, GERONIMO-2163-v4.patch, GERONIMO-2163-v5-partial.patch, GERONIMO-2163-v5-plus.patch, GERONIMO-2163-v6.patch, GERONIMO-2163-v6b.patch, geronimo-wadi-integration-preview.patch, geronimo-wadi-integration-RTC.patch, geronimo.patch, setUpServers.tar.gz, wadi-geronimo-integration-preview.patch, wadi.patch, wadi.zip Email sent to the dev@ list. Hi, I have been working on a second integration attempt of WADI and I am posting here a high-level description of the current state of progress such that people can jump in. At this stage, this is a Jetty only attempt and I do believe that the same approach can be applied for Tomcat. The current integration provides (very unreliable) HttpSession state migration. It only works for a single Web-application; more effort is required on the WADI side to support multiple Web-applications and this will not impact the integration piece of code. I (more or less successfully) tested the integration with mod_proxy + mod_proxy_balancer and mod_proxy + mod_rewrite in front of three Geronimo servers running the WADI demo web-app. The code changes are: * new module to capture some clustering contracts - geronimo-clustering: there Node, SessionManager, Session and ClusteredInvocation are defined. * new module to provide a WADI implementation of the above - geronimo-clustering-wadi; * new module to capture clustering builder contracts - geronimo-clustering-builder: there is only one interesting interface JettyClusteringBuilder. This later defines a couple of methods to augment the environment of a Web module being built and add clustering specific GBeans; * new module to provide a WADI implementation of the above - Geronimo-clustering-builder-wadi; and * geronimo-jetty-builder and geronimo-jetty are impacted to hook in clustering. These two modules depend on geronimo-clustering and geronimo-clustering-builder and not on WADI specific modules. Two new modules are added: * jetty-clustering- wadi: this module defines default WADI GBeans such as Dispatcher, ReplicationManagerFactory, BackingStrategyFactory et cetera; and * jetty-clustering-builder-wadi: this module defines a builder to process Jetty DD and add various GBeans to the module being built. I think that the implementation is flexible enough to plug in another clustering implementation such as Kache. As a matter of fact, there are some severe reliability (e.g. locking issues) and integration (only one Web-app can be clustered) issues, which need to be fixed. So, this work is not yet ready to be RTC voted. Having said that, I have opened a JIRA such that people can have a look to the integration. Thanks, Gianny -- 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: Creating a secure connection system and using JMSXUserID support
Hi all, I've seen a similar patch going out so I'm giving an update on this one. Currently, it does the following: - Allows for wantClientAuth and needClientAuth on SslTransport and SslTransportServer classes. - SslTransport attaches the client's certificate chain to ConnectionInfo in the newly added (not by me) connection context field. - Adds ActiveMQSslConnectionFactory and SslBrokerService, which can be used to specify trust and key managers from within code (otherwise, you can use the default ActiveMQConnectionFactory and BrokerService classes and just give an ssl URI) - Adds a new JaasCertificateAuthenticationPlugin and the corresponding broker which allow for authentication based on the certificate - The above use the standard JAAS interface (with some new classes for handling SSL certs) - These classes can be tied into the existing authorization system and UserIDBroker (JaasCertificateAuthenticationBroker will set the securityContext's username to one associated with the certificate based on CertificateLoginModule). It has no problems right now, but I'd rather test it more thoroughly before sending the patch. I should be done within the next 2 weeks. - Sepand On 8/3/06, Sepand M [EMAIL PROTECTED] wrote: Hi, The DN will overwrite the client-provided username (if any) when the SslTransport writes it. On 8/3/06, Kelly Campbell [EMAIL PROTECTED] wrote: Sepand, One possible gotcha I haven't heard anyone bring up that we should address is to make sure that someone can't just fake the DN in the username field through a normal login and make the system think it's authenticated with the certificate. -Kelly On 8/3/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Sepand, 4.1 and 4.0 branches are not that different yet. If you need your solution for 4.0, go ahead and do it. Chances are we will only apply it only to 4.1 (since this a new feature). On 8/3/06, Sepand M [EMAIL PROTECTED] wrote: Thanks Hiram. That sounds great. I guess my last question is: what branch do I work off of? Personally, I would like to build my stuff on a stable release (4.0.1), but I've looked at the svn logs and you guys seem to be pretty active around the stuff I want to change so I'm not sure how my changes could be reintegrated once I'm done. Any thoughts? On 8/3/06, Hiram Chirino [EMAIL PROTECTED] wrote: Sepand, Do what you need to to get you project done, you cand send us tidbit as you get it done and we can work on merging it back to the main branch. The great thing is that you have a use case that we want to support, so if you put something together that work for you, I don't see why it would not just go whole hog into the main branch. On 8/3/06, Sepand M [EMAIL PROTECTED] wrote: Hi guys, Here are a few things: 1) I cannot use LDAP. We don't use it now, and don't want to later. I understand if you want to use it, but I can't. 2) From what I understand (and my understanding isn't too bad at this point), SSL sockets with needClientAuth just verify the client's cert against the CA. This means that the socket only does authentication and the rest is up to the broker (which seems perfect). 3) The other ideas we're getting like separating the user from the connection (which I don't fully understand) seem like they are overkill. To be done properly, they would need significant (not drastic, but significant) architectural rework (look at things like UserIDBroker, and how the user ID is currently obtained from the connection with the producer ID registration stuff) and are fairly independent of the SSL thing. Yeah I think this is overkill too. So here's my plan: I want to implement my original idea (it's in this thread a few posts up) with (at most) the addition of a subject/principal back end for authorization. I say at most because I've been working on my idea for a while and know exactly how to do it; adding the subject/principal thing is a good design choice but I'm hesitant to persue it since I don't know much about it and I have a deadline (and therefore, would rather avoid having to read about it). If someone knows their stuff regarding to JAAS and is willing to work on it, I would be very glad to incorporate that into the design. If not, I must begin working on my implementation by the end of the week (hopefully sooner). I would *REALLY* like to work with you guys, but I have deadlines to meet. I would also hate it if my work didn't make it into the project's main branch, but I would totally understand if you decided to go with your own ideas. On 8/3/06, Hiram Chirino [EMAIL PROTECTED] wrote: On 8/3/06, David Jencks [EMAIL PROTECTED] wrote: On Aug 2, 2006, at 4:35 PM, Sepand M wrote: Ok. So
Re: Anyone know how to make the kernel tests be quiet?
Um... looks like a few of these tests are explicitly enabling DEBUG and installing a ConsoleAppender... Logger.getRootLogger().addAppender(new ConsoleAppender(new PatternLayout(%p [%t] %m %n))); Logger.getRootLogger().setLevel(Level.DEBUG); I'm not sure how they were quiet before m2 with code like above in setUp(). --jason On Aug 28, 2006, at 4:29 PM, Jason Dillon wrote: Thats odd, because the default logging config is set to only allow WARN and ERROR to go to console, not DEBUG. Do these tests need to: GeronimoLogging.initialize(GeronimoLogging.INFO); Or something? --jason On Aug 28, 2006, at 10:14 AM, Dain Sundstrom wrote: Not me. They were quiet before the m2 change but it looks like logging got turned up. -dain On Aug 28, 2006, at 2:26 AM, Jason Dillon wrote: These tests make way... way to much noise. Anyone know how to make them shut up? --jason
Re: [VOTE] Release XBean 2.6 (retry)
+1 Thanks again for all this work! Regards, Alan Guillaume Nodet wrote: I have uploaded new binaries of xbean. They are available at http://people.apache.org/~gnodet/xbean-2.6/ http://people.apache.org/%7Egnodet/xbean-2.6/ The changes from the last cut includes a fix for spring 2.0-rc3, and the Genesis dependency which has been removed. I will sign and upload these artifacts to the official m2 repo, once the vote is over. -- Cheers, Guillaume Nodet
Re: Anyone know how to make the kernel tests be quiet?
This is fixed now... though it still spits out a few ERROR logs, which I am hoping are expected from the test... --jason On Aug 30, 2006, at 3:49 PM, Jason Dillon wrote: Um... looks like a few of these tests are explicitly enabling DEBUG and installing a ConsoleAppender... Logger.getRootLogger().addAppender(new ConsoleAppender(new PatternLayout(%p [%t] %m %n))); Logger.getRootLogger().setLevel(Level.DEBUG); I'm not sure how they were quiet before m2 with code like above in setUp(). --jason On Aug 28, 2006, at 4:29 PM, Jason Dillon wrote: Thats odd, because the default logging config is set to only allow WARN and ERROR to go to console, not DEBUG. Do these tests need to: GeronimoLogging.initialize(GeronimoLogging.INFO); Or something? --jason On Aug 28, 2006, at 10:14 AM, Dain Sundstrom wrote: Not me. They were quiet before the m2 change but it looks like logging got turned up. -dain On Aug 28, 2006, at 2:26 AM, Jason Dillon wrote: These tests make way... way to much noise. Anyone know how to make them shut up? --jason
Re: Anyone know how to make the kernel tests be quiet?
Looks like there is more going on which is causing tests to use some additional configuration for tests... Specifically, looks like something else is installing a ConsoleAppender... as if I comment out the CONSOLE definition from logging-config, then I still get console output. I'm also seeing that something is setting the root logger's level... as I've got the root configured to use DEBUG, but that will not output DEBUG logs to the test.log as I would expect. I have to explicitly configure org.apache.geronimo to use DEBUG, and then I see the logs in test.log... but now with some rouge ConsoleAppender it spits out a bunch of junk to the console. Highly frustrating... :-( --jason On Aug 30, 2006, at 3:53 PM, Jason Dillon wrote: This is fixed now... though it still spits out a few ERROR logs, which I am hoping are expected from the test... --jason On Aug 30, 2006, at 3:49 PM, Jason Dillon wrote: Um... looks like a few of these tests are explicitly enabling DEBUG and installing a ConsoleAppender... Logger.getRootLogger().addAppender(new ConsoleAppender(new PatternLayout(%p [%t] %m %n))); Logger.getRootLogger().setLevel(Level.DEBUG); I'm not sure how they were quiet before m2 with code like above in setUp(). --jason On Aug 28, 2006, at 4:29 PM, Jason Dillon wrote: Thats odd, because the default logging config is set to only allow WARN and ERROR to go to console, not DEBUG. Do these tests need to: GeronimoLogging.initialize(GeronimoLogging.INFO); Or something? --jason On Aug 28, 2006, at 10:14 AM, Dain Sundstrom wrote: Not me. They were quiet before the m2 change but it looks like logging got turned up. -dain On Aug 28, 2006, at 2:26 AM, Jason Dillon wrote: These tests make way... way to much noise. Anyone know how to make them shut up? --jason
[jira] Updated: (GERONIMO-2349) jta 1.1 support with container manager jpa support in transaction module
[ http://issues.apache.org/jira/browse/GERONIMO-2349?page=all ] David Jencks updated GERONIMO-2349: --- Attachment: GERONIMO-2349-v4-plus-2163.patch GERONIMO-2349-v4-plus-2163-openejb.patch persistencecontextref.zip This is a work-in-progress view of converting the ENCConfigBuilder to use NamingBuilders. Unfortunately I haven't kept my projects separate and the patches include GERONIMO-2163 (hint: vote for it :-) They work to some extent. The only bug I know about is that message-destination-refs don't work. I've also included a tiny sample app that shows that cm persistence-context-ref lookup works with a mock jpa provider. jta 1.1 support with container manager jpa support in transaction module Key: GERONIMO-2349 URL: http://issues.apache.org/jira/browse/GERONIMO-2349 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Affects Versions: 1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2 Attachments: GERONIMO-2349-1.patch, GERONIMO-2349-2.patch, GERONIMO-2349-3.patch, GERONIMO-2349-v4-plus-2163-openejb.patch, GERONIMO-2349-v4-plus-2163.patch, persistencecontextref.zip We need a strategy for supporting jta 1.1 and parts of jpa in the transaction module while still passing the j2ee 1.4 signature tests. Here's a proposal: - put the basis for support into the current transaction module, but don't use any jee5 interfaces - add an additional transaction-jta11 module that uses the new interfaces and extends the appropriate classes in transaction. I've started along this path. I'll put the new module in sandbox and supply a patch for the changes to the existing transaction module. -- 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: Anyone know how to make the kernel tests be quiet?
You should be able to turn on debugging, add a break point in the logging code and see which test is causing the problem. -dain On Aug 30, 2006, at 4:31 PM, Jason Dillon wrote: Looks like there is more going on which is causing tests to use some additional configuration for tests... Specifically, looks like something else is installing a ConsoleAppender... as if I comment out the CONSOLE definition from logging-config, then I still get console output. I'm also seeing that something is setting the root logger's level... as I've got the root configured to use DEBUG, but that will not output DEBUG logs to the test.log as I would expect. I have to explicitly configure org.apache.geronimo to use DEBUG, and then I see the logs in test.log... but now with some rouge ConsoleAppender it spits out a bunch of junk to the console. Highly frustrating... :-( --jason On Aug 30, 2006, at 3:53 PM, Jason Dillon wrote: This is fixed now... though it still spits out a few ERROR logs, which I am hoping are expected from the test... --jason On Aug 30, 2006, at 3:49 PM, Jason Dillon wrote: Um... looks like a few of these tests are explicitly enabling DEBUG and installing a ConsoleAppender... Logger.getRootLogger().addAppender(new ConsoleAppender(new PatternLayout(%p [%t] %m %n))); Logger.getRootLogger().setLevel(Level.DEBUG); I'm not sure how they were quiet before m2 with code like above in setUp(). --jason On Aug 28, 2006, at 4:29 PM, Jason Dillon wrote: Thats odd, because the default logging config is set to only allow WARN and ERROR to go to console, not DEBUG. Do these tests need to: GeronimoLogging.initialize(GeronimoLogging.INFO); Or something? --jason On Aug 28, 2006, at 10:14 AM, Dain Sundstrom wrote: Not me. They were quiet before the m2 change but it looks like logging got turned up. -dain On Aug 28, 2006, at 2:26 AM, Jason Dillon wrote: These tests make way... way to much noise. Anyone know how to make them shut up? --jason
Re: Keystore features - Create certificate request
See point no. 2, Ability to generate CertificateRequests. GERONIMO-2218 addresses this. You need to be viewing the privatekey details to be able to generate a CSR for the same, VamsiOn 8/31/06, Hernan Cunico [EMAIL PROTECTED] wrote: Hi All,is there a way to create a certificate request in 1.1.1?I found GERONIMO-2218 but creating certificate request seems to haveescaped from the patch.I have not found any other JIRA discussing this CSR issue ( that doesn't mean there isn't one ). Should I create aKeyStore portlet: Functionality missing from 1.0 [take 2]Cheers!Hernan
Re: Anyone know how to make the kernel tests be quiet?
I think this is related to the custom log4j bits on geronimo-kernel, which most modules depend on. Modules that do not depend on geronimo- kernel, like geronimo-util and geronimo-activation behave as I would expect. I'm gonna dig into it more, and will probably add a custom sys prop to disable the kernel's logging bits, so that we can set that for tests and thus get tests to use one log4j configuration. Though, I'd imagine that it this is done in a static, that other projects that use G components that also depend on geronimo-kernel will also end up with some additional log4j configuration that is unwanted. I don't want to start up a logging debate... so I think the optional disable the kernels default should be fine to get test logging back to normal, producing little console output and full debug to target/ test.log. --jason On Aug 30, 2006, at 4:50 PM, Dain Sundstrom wrote: You should be able to turn on debugging, add a break point in the logging code and see which test is causing the problem. -dain On Aug 30, 2006, at 4:31 PM, Jason Dillon wrote: Looks like there is more going on which is causing tests to use some additional configuration for tests... Specifically, looks like something else is installing a ConsoleAppender... as if I comment out the CONSOLE definition from logging-config, then I still get console output. I'm also seeing that something is setting the root logger's level... as I've got the root configured to use DEBUG, but that will not output DEBUG logs to the test.log as I would expect. I have to explicitly configure org.apache.geronimo to use DEBUG, and then I see the logs in test.log... but now with some rouge ConsoleAppender it spits out a bunch of junk to the console. Highly frustrating... :-( --jason On Aug 30, 2006, at 3:53 PM, Jason Dillon wrote: This is fixed now... though it still spits out a few ERROR logs, which I am hoping are expected from the test... --jason On Aug 30, 2006, at 3:49 PM, Jason Dillon wrote: Um... looks like a few of these tests are explicitly enabling DEBUG and installing a ConsoleAppender... Logger.getRootLogger().addAppender(new ConsoleAppender(new PatternLayout(%p [%t] %m %n))); Logger.getRootLogger().setLevel(Level.DEBUG); I'm not sure how they were quiet before m2 with code like above in setUp(). --jason On Aug 28, 2006, at 4:29 PM, Jason Dillon wrote: Thats odd, because the default logging config is set to only allow WARN and ERROR to go to console, not DEBUG. Do these tests need to: GeronimoLogging.initialize(GeronimoLogging.INFO); Or something? --jason On Aug 28, 2006, at 10:14 AM, Dain Sundstrom wrote: Not me. They were quiet before the m2 change but it looks like logging got turned up. -dain On Aug 28, 2006, at 2:26 AM, Jason Dillon wrote: These tests make way... way to much noise. Anyone know how to make them shut up? --jason
Re: Upgrade Derby to 10.1.3.1?
I was going to create an issue and the commit the change if there were no objections. --jason On Aug 30, 2006, at 4:38 AM, Jacek Laskowski wrote: On 8/30/06, Jason Dillon [EMAIL PROTECTED] wrote: The latest release appears to run fine... any objections to updating server/trunk to use it? Which JIRA issue is this? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [VOTE] Publish Genesis 1.0 to m2 central
Okay, I'm canceling this vote. I've removed the clover bits from Genesis, and added headers to scripts... will start a new vote for 1.1 soonish. Thanks for all of your input. Sorry I jumped the gun and created the release before the vote. --jason On Aug 29, 2006, at 9:10 AM, Kevan Miller wrote: On Aug 28, 2006, at 11:25 PM, Jason Dillon wrote: On Aug 28, 2006, at 7:59 PM, Kevan Miller wrote: I appreciate that, I applaud your efforts, and apologize if I'm being a PITA. However, we also have a responsibility as a community when releasing software. I'm trying to be sure we are addressing that responsibility. Mmmkay. I'm taking deep breaths... :-] For instance, I see that genesis-1.0 includes a software license for Clover? News to me, but I confess that genesis has been a bit of an unknown to me... from Product: Clover License: Open Source License, 0.x, 1.x Issued: Sun May 14 2006 21:59:13 CDT Expiry: Never Maintenance Expiry: Never Key: 965016739f4031c43d67e61b0 Name: Jason Dillon Org: Apache Geronimo Clause 5 of the Clover license says The Licensee may copy the Software for back-up purposes only. The Licensee may not assign or otherwise transfer the Software to any third party. IANAL ADNWTB, however, this gives me cause for concern. Can you explain what this is about? I have no idea what IANAL ADNWTB means. But Clover grants licenses for open source projects. I used the license they granted to me to be used to run the site builds. This is shared configuration, which was checked into genesis to simplify the configuration of modules which need it to run the plugin. Sorry.. I Am Not A Lawyer And Don't Want To Be I don't think we can put this license in on ibiblio. I also don't think it should be public in our source tree... I understand that this may make things more difficult, but it sure seems to me that we're violating the terms of the license agreement... Can you convince me otherwise? --kevan
Re: Upgrade Derby to 10.1.3.1?
FYI, issue is here: http://issues.apache.org/jira/browse/GERONIMO-2365 --jason On Aug 30, 2006, at 5:08 PM, Jason Dillon wrote: I was going to create an issue and the commit the change if there were no objections. --jason On Aug 30, 2006, at 4:38 AM, Jacek Laskowski wrote: On 8/30/06, Jason Dillon [EMAIL PROTECTED] wrote: The latest release appears to run fine... any objections to updating server/trunk to use it? Which JIRA issue is this? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Created: (GERONIMO-2365) Upgrade Derby to 10.1.3.1
Upgrade Derby to 10.1.3.1 - Key: GERONIMO-2365 URL: http://issues.apache.org/jira/browse/GERONIMO-2365 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Affects Versions: 1.2 Reporter: Jason Dillon Priority: Minor Fix For: 1.2 The latest release appears to run fine. We should upgrade our dependencies to use 10.1.3.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2365) Upgrade Derby to 10.1.3.1
[ http://issues.apache.org/jira/browse/GERONIMO-2365?page=all ] Jason Dillon reassigned GERONIMO-2365: -- Assignee: Jason Dillon Upgrade Derby to 10.1.3.1 - Key: GERONIMO-2365 URL: http://issues.apache.org/jira/browse/GERONIMO-2365 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Jason Dillon Assigned To: Jason Dillon Priority: Minor Fix For: 1.2 The latest release appears to run fine. We should upgrade our dependencies to use 10.1.3.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2211) Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
[ http://issues.apache.org/jira/browse/GERONIMO-2211?page=all ]
Jason Dillon reassigned GERONIMO-2211:
--
Assignee: Jason Dillon
Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
--
Key: GERONIMO-2211
URL: http://issues.apache.org/jira/browse/GERONIMO-2211
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: Jason Dillon
Fix For: 1.2
A few tests failed in non-obvious ways when run under the m2 build. Need
someone who knows these tests better to inspect, resolve and enable the test
(remove the test exclusions in the pom).
The test fails with (on the console):
{noformat}
DEBUG [main] Starting boot
DEBUG [main] GBeanInstanceState for: geronimo/boot/none/car?role=kernel State
changed from stopped to starting
DEBUG [main] GBeanInstanceState for: geronimo/boot/none/car?role=kernel State
changed from starting to running
DEBUG [main] Booted
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=ServerInfo State
changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=ServerInfo State
changed from starting to running
DEBUG [main] GBeanInstanceState for: test/foo/1/car?new=LoginConfiguration
State changed from stopped to starting
DEBUG [main] Installed Geronimo login configuration
DEBUG [main] GBeanInstanceState for: test/foo/1/car?new=LoginConfiguration
State changed from starting to running
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=TestLoginService
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=TestLoginService
State changed from starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed from stopped
to starting
DEBUG [main] Remote login service started on: tcp://0.0.0.0:4242 clients can
connect to: tcp://0.0.0.0:4242
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed from
starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from starting to
running
DEBUG [main] Added Application Configuration Entry properties-client
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesSecurityRealm State changed from stopped to
starting
DEBUG [main] Waiting to start test/foo/1/car?name=PropertiesSecurityRealm
because no targets are running for reference LoginModuleConfiguration
matching the patterns test/foo/1/car?name=PropertiesLoginModuleUse
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=AuditLoginModule
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=AuditLoginModule
State changed from starting to running
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=AuditLoginModuleUse
State changed from stopped to starting
DEBUG [main] Waiting to start test/foo/1/car?name=AuditLoginModuleUse because
no targets are running for reference Next matching the patterns
test/foo/1/car?name=UPCredLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModuleUse State changed from stopped to
starting
DEBUG [main] Waiting to start test/foo/1/car?name=PropertiesLoginModuleUse
because no targets are running for reference Next matching the patterns
test/foo/1/car?name=AuditLoginModuleUse
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=UPCredLoginModule
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=UPCredLoginModule
State changed from starting to running
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=UPCredLoginModuleUse
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=UPCredLoginModuleUse
State changed from starting to running
DEBUG [main] Checking if parent is running:
parent=test/foo/1/car?name=AuditLoginModule
DEBUG [main] Parent is running: parent=test/foo/1/car?name=AuditLoginModule
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=AuditLoginModuleUse
State changed from starting to running
DEBUG [main] Checking if parent is running:
parent=test/foo/1/car?name=PropertiesLoginModule
DEBUG [main] Parent is running:
[jira] Closed: (GERONIMO-2211) Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
[ http://issues.apache.org/jira/browse/GERONIMO-2211?page=all ]
Jason Dillon closed GERONIMO-2211.
--
Resolution: Fixed
Thanks Anita for pointing out that it works with basedir, the reference to the
login-audit.log was not being rooted with BASEDIR.
Looks okay now, so I'm enabling this test again.
Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
--
Key: GERONIMO-2211
URL: http://issues.apache.org/jira/browse/GERONIMO-2211
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: Jason Dillon
Fix For: 1.2
A few tests failed in non-obvious ways when run under the m2 build. Need
someone who knows these tests better to inspect, resolve and enable the test
(remove the test exclusions in the pom).
The test fails with (on the console):
{noformat}
DEBUG [main] Starting boot
DEBUG [main] GBeanInstanceState for: geronimo/boot/none/car?role=kernel State
changed from stopped to starting
DEBUG [main] GBeanInstanceState for: geronimo/boot/none/car?role=kernel State
changed from starting to running
DEBUG [main] Booted
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=ServerInfo State
changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=ServerInfo State
changed from starting to running
DEBUG [main] GBeanInstanceState for: test/foo/1/car?new=LoginConfiguration
State changed from stopped to starting
DEBUG [main] Installed Geronimo login configuration
DEBUG [main] GBeanInstanceState for: test/foo/1/car?new=LoginConfiguration
State changed from starting to running
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=TestLoginService
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=TestLoginService
State changed from starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed from stopped
to starting
DEBUG [main] Remote login service started on: tcp://0.0.0.0:4242 clients can
connect to: tcp://0.0.0.0:4242
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed from
starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from starting to
running
DEBUG [main] Added Application Configuration Entry properties-client
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesSecurityRealm State changed from stopped to
starting
DEBUG [main] Waiting to start test/foo/1/car?name=PropertiesSecurityRealm
because no targets are running for reference LoginModuleConfiguration
matching the patterns test/foo/1/car?name=PropertiesLoginModuleUse
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=AuditLoginModule
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=AuditLoginModule
State changed from starting to running
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=AuditLoginModuleUse
State changed from stopped to starting
DEBUG [main] Waiting to start test/foo/1/car?name=AuditLoginModuleUse because
no targets are running for reference Next matching the patterns
test/foo/1/car?name=UPCredLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModuleUse State changed from stopped to
starting
DEBUG [main] Waiting to start test/foo/1/car?name=PropertiesLoginModuleUse
because no targets are running for reference Next matching the patterns
test/foo/1/car?name=AuditLoginModuleUse
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=UPCredLoginModule
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=UPCredLoginModule
State changed from starting to running
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=UPCredLoginModuleUse
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=UPCredLoginModuleUse
State changed from starting to running
DEBUG [main] Checking if parent is running:
parent=test/foo/1/car?name=AuditLoginModule
DEBUG [main] Parent is running: parent=test/foo/1/car?name=AuditLoginModule
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=AuditLoginModuleUse
State
Re: windows build hell
If using 1.4.5-SNAPSHOT fixes things... then lets just use it.
Can someone with openejb2 commit privs add a getName() to get past
that other error too?
--jason
On Aug 30, 2006, at 8:46 AM, Jeff Genender wrote:
Joe Bohn wrote:
2) JSP compilation errors
Problem:
Embedded error: Unable to compile class for JSP
Strange error message about JAVA_HOME, etc...
Possible Solution/Work-around:
Update the pom.xml in the root directory to use version 1.4.5-
SNAPSHOT
(from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff Genender is
planning to make 1.4.5 an official release for this. We're not
sure why
it gets us around the problem so it may be a red herring.
Its not a red herring. It gets you around the problem because in
1.4.5
I actually hunt down the tools.jar file...in a similar fashion as done
in Ant when running the jspc complier from there. i.e.:
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath
pathelement location=${java.home}/../lib/tools.jar/
...
I have to duplicate that in code. That's why 1.4.5 works.
The release is under vote. So far no -1s. I think I will be able to
release it today as the 72 hours is up. I'll let this list know
when I
have released it.
Jeff
Re: [VOTE] Publish Genesis 1.0 to m2 central
I'm confused, how do we vote for 1.1 if 1.0 was never released? We need to keep the version number the same. Regards, Alan Jason Dillon wrote: Okay, I'm canceling this vote. I've removed the clover bits from Genesis, and added headers to scripts... will start a new vote for 1.1 soonish. Thanks for all of your input. Sorry I jumped the gun and created the release before the vote. --jason On Aug 29, 2006, at 9:10 AM, Kevan Miller wrote: On Aug 28, 2006, at 11:25 PM, Jason Dillon wrote: On Aug 28, 2006, at 7:59 PM, Kevan Miller wrote: I appreciate that, I applaud your efforts, and apologize if I'm being a PITA. However, we also have a responsibility as a community when releasing software. I'm trying to be sure we are addressing that responsibility. Mmmkay. I'm taking deep breaths... :-] For instance, I see that genesis-1.0 includes a software license for Clover? News to me, but I confess that genesis has been a bit of an unknown to me... from Product: Clover License: Open Source License, 0.x, 1.x Issued: Sun May 14 2006 21:59:13 CDT Expiry: Never Maintenance Expiry: Never Key: 965016739f4031c43d67e61b0 Name: Jason Dillon Org: Apache Geronimo Clause 5 of the Clover license says The Licensee may copy the Software for back-up purposes only. The Licensee may not assign or otherwise transfer the Software to any third party. IANAL ADNWTB, however, this gives me cause for concern. Can you explain what this is about? I have no idea what IANAL ADNWTB means. But Clover grants licenses for open source projects. I used the license they granted to me to be used to run the site builds. This is shared configuration, which was checked into genesis to simplify the configuration of modules which need it to run the plugin. Sorry.. I Am Not A Lawyer And Don't Want To Be I don't think we can put this license in on ibiblio. I also don't think it should be public in our source tree... I understand that this may make things more difficult, but it sure seems to me that we're violating the terms of the license agreement... Can you convince me otherwise? --kevan
Re: [VOTE] Publish Genesis 1.0 to m2 central
Well... it was actually released... and then pulled back... which is my fault. But, I don't see any reason why 1.0 needs to be re-released. I've already updated the tree to use 1.1-SNAPSHOT and have been making changes to it to fix the noted problems as well as a few other enhancements... IMO it is much more confusing to look at the SVN logs and see that 1.0 was made from a 1.1-SNAPSHOT. I think that the unfortunate practice of making a release then voting on it and then possibly re-cutting the same release is very poor. I'd much rather consider 1.0 dead and release 1.1 so that there is no confusion as to which is which. In almost every other software project I have worked on, a release is cut, if there are changes, then a new revision is made and then a new release is cut for the changes. If you wanted to keep the 1.0 bits in there then 1.0-1 and then 1.0-2 is common practice for minor fix iterations. While I can understand since the time to run the tck for the Geronimo server on the release binaries and then after that has run we vote... that the server release is a bit different. I don't think this needs to be or should be the case for other projects. I believe it is much, much better to test the latest SNAPSHOT, then vote to make the release and then make the release. Anyways, I don't think that the version matters very much here. This is an internal project used to support internal builds. I don't expect anyone outside of Geronimo to even care. So, I still recommend that 1.0 is dead and next to be released w/proper oversight and vote is 1.1. --jason On Aug 30, 2006, at 6:02 PM, Alan D. Cabrera wrote: I'm confused, how do we vote for 1.1 if 1.0 was never released? We need to keep the version number the same. Regards, Alan Jason Dillon wrote: Okay, I'm canceling this vote. I've removed the clover bits from Genesis, and added headers to scripts... will start a new vote for 1.1 soonish. Thanks for all of your input. Sorry I jumped the gun and created the release before the vote. --jason On Aug 29, 2006, at 9:10 AM, Kevan Miller wrote: On Aug 28, 2006, at 11:25 PM, Jason Dillon wrote: On Aug 28, 2006, at 7:59 PM, Kevan Miller wrote: I appreciate that, I applaud your efforts, and apologize if I'm being a PITA. However, we also have a responsibility as a community when releasing software. I'm trying to be sure we are addressing that responsibility. Mmmkay. I'm taking deep breaths... :-] For instance, I see that genesis-1.0 includes a software license for Clover? News to me, but I confess that genesis has been a bit of an unknown to me... from Product: Clover License: Open Source License, 0.x, 1.x Issued: Sun May 14 2006 21:59:13 CDT Expiry: Never Maintenance Expiry: Never Key: 965016739f4031c43d67e61b0 Name: Jason Dillon Org: Apache Geronimo Clause 5 of the Clover license says The Licensee may copy the Software for back-up purposes only. The Licensee may not assign or otherwise transfer the Software to any third party. IANAL ADNWTB, however, this gives me cause for concern. Can you explain what this is about? I have no idea what IANAL ADNWTB means. But Clover grants licenses for open source projects. I used the license they granted to me to be used to run the site builds. This is shared configuration, which was checked into genesis to simplify the configuration of modules which need it to run the plugin. Sorry.. I Am Not A Lawyer And Don't Want To Be I don't think we can put this license in on ibiblio. I also don't think it should be public in our source tree... I understand that this may make things more difficult, but it sure seems to me that we're violating the terms of the license agreement... Can you convince me otherwise? --kevan
Re: [VOTE] 1.1.1-rc1 for Release
I don't think that the JACC spec jar release needs to be tied w/ the Geronimo release. AAMOF, it should be released ASAP so that the Geronimo build automatically pulls it down. Regards, Alan Matt Hogstrom wrote: CTS is complete and here is the RC1 for your reviewing pleasure. Please send your comments to the dev@geronimo.apache.org list. If there are no negative comments after Monday, September 5th at 0900 ET. We'll move this to be the final and release it. If there are issues, they will be addressed and another e-mail will be issued resetting for an rc2 vote. Thanks. *Source* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-1.1.1-rc1-src.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-1.1.1-rc1-src.zip *Specifications* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-j2ee-jacc_1.0_spec-1.1.1.jar *Schemas* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-schema-j2ee_1.4-1.0-src.jar http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-schema-j2ee_1.4-1.0.jar *Distributions* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty-j2ee-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty-j2ee-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty-minimal-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty-minimal-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat-j2ee-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat-j2ee-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat-minimal-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat-minimal-1.1.1-rc1.zip If you want to build you will need these jars also (will be released simultaneously with Geronimo) and these need to be placed in your local Maven repository. *OpenEJB Jars* http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-builder-2.1.1.jar http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-core-2.1.1.jar http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-pkgen-builder-2.1.1.jar
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
Jason,
running the steps individually does not change the situation, it only
gives better chances to see what has gone wrong. I also don't want to
clean my local Maven repos each time, it might sound strange but I
have also other stuff there and not the G related components.
bootstrap anyhow cleans just the default location and not the place
specified in the Maven config. I don't want (even can't) use the
default under Windows. I synchronize my profile cross multiple
systems and I don't want to transfer all the jars.
I would prefer a boostrap process which just installs the requirements
and checks the correctness in a second step instead of mangling
installation with tests.
Heinz
On 8/30/06, Jason Dillon [EMAIL PROTECTED] wrote:
All of you guys who are seeing strange failures... I suggest you not
use bootstrap, but instead run the steps by hand.
--jason
On Aug 30, 2006, at 7:38 AM, Joe Bohn wrote:
Jason,
I'm not sure if this was intended or not ... but having these
thirdparty items under target results in the source being purged
when doing an mvn clean. This is unfortunate for those of us that
are hitting the failures on the openejb tests. My memory may not
be correct but I thought that prior to this change I could do the
following:
- bootstrap (with the change to use the jspc 1.4.5-SNAPSHOT to
avoid the jspc problem).
- watch it fail to build openejb due to the test failures.
- run mvn clean install -Dmaven.test.skip=true
However, now that openejb is under target the clean deletes the
source and before it attempts to build and the result is that I
still don't get the openejb jar created in my local repo. Now I
think I have to do the following:
- bootstrap (with the change to use the jspc 1.4.5-SNAPSHOT to
avoid the jspc problem).
- watch it fail to build openejb due to the test failures.
- cd to target\external\openejb2
- run mvn -Dmaven.test.skip=true
- run mvn clean install
Am I doing something wrong?
Thanks,
Joe
[EMAIL PROTECTED] wrote:
Author: jdillon
Date: Sat Aug 26 20:25:18 2006
New Revision: 437291
URL: http://svn.apache.org/viewvc?rev=437291view=rev
Log:
Changed bootstrap to put external stuff into target/external
instead of thirdparty
Reduced ant output using -emacs and logger
Modified:
geronimo/server/trunk/bootstrap
geronimo/server/trunk/bootstrap.bat
geronimo/server/trunk/bootstrap.xml
Modified: geronimo/server/trunk/bootstrap
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/bootstrap?
rev=437291r1=437290r2=437291view=diff
=
=
--- geronimo/server/trunk/bootstrap (original)
+++ geronimo/server/trunk/bootstrap Sat Aug 26 20:25:18 2006
@@ -19,5 +19,5 @@
PWD=`cygpath --windows $PWD`
fi
-ant $BUILD_OPTIONS -f bootstrap.xml $@
+ant $BUILD_OPTIONS -emacs -logger
org.apache.tools.ant.NoBannerLogger -f bootstrap.xml $@
Modified: geronimo/server/trunk/bootstrap.bat
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/
bootstrap.bat?rev=437291r1=437290r2=437291view=diff
=
=
--- geronimo/server/trunk/bootstrap.bat (original)
+++ geronimo/server/trunk/bootstrap.bat Sat Aug 26 20:25:18 2006
@@ -10,7 +10,7 @@
set PROGNAME=%~nx0%
set ARGS=%*
-ant %BUILD_OPTIONS% -f bootstrap.xml %ARGS%
+ant %BUILD_OPTIONS% -emacs -logger
org.apache.tools.ant.NoBannerLogger -f bootstrap.xml %ARGS%
:END
Modified: geronimo/server/trunk/bootstrap.xml
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/
bootstrap.xml?rev=437291r1=437290r2=437291view=diff
=
=
--- geronimo/server/trunk/bootstrap.xml (original)
+++ geronimo/server/trunk/bootstrap.xml Sat Aug 26 20:25:18 2006
@@ -14,19 +14,19 @@
/sequential
/macrodef
-macrodef name=build-thirdparty
+macrodef name=build-external
attribute name=url/
attribute name=name/
sequential
-mkdir dir=${basedir}/thirdparty/
+mkdir dir=${basedir}/target/external/
-exec executable=svn dir=${basedir}/
thirdparty
+exec executable=svn dir=${basedir}/target/external
arg value=co/
arg value=@{url}/
arg value=@{name}/
/exec
-mvn goal=install dir=${basedir}/
thirdparty/@{name}/
+mvn goal=install dir=${basedir}/target/external/@
{name}/
/sequential
/macrodef
@@ -42,6 +42,7 @@
target name=init depends=init:discover,
init:windows, init:defaults
record name=${basedir}/bootstrap.log/
+ echoStarting bootstrap build.../echo
/target
@@ -88,14 +89,12 @@
!-- --
target name=clean depends=clean:init, clean:minimal,
Re: Anyone know how to make the kernel tests be quiet?
Okay, I think I've found it... BootstrapLog4jLog and
BootstrapJdk1.4Log both have static blocks that install logging
configuration programatically.
I'm going to add a new method to GeronimoLogging, which will check if
this behavior is enabled or not:
/**
* Check if the Geronimo bootstrap logging initialization is
enabled.
*
* pChecks the system property
ttgeronimo.bootstrap.logging.enabled/tt
* if not set, or set to true then bootstrap logging
initialization is enabled.
*
* @return True of bootstrap logging initialization is enabled.
*/
public static boolean isBootstrapLoggingInitializationEnabled() {
String value = System.getProperty
(geronimo.bootstrap.logging.enabled);
if (value == null) {
return true;
}
else {
return Boolean.valueOf(value).booleanValue();
}
}
And then wrap the static blocks in the Log impls to only execute if
isBootstrapLoggingInitializationEnabled() returns true.
Then to hook up, I'm going to specify -
Dgeronimo.bootstrap.logging.enabled=false to the argLine in project-
config.
This should leave things as per normal for running the server, and
still allow the tests to be run from a single log4j logging
configuration. After this, target/test.log should contain DEBUG
level messages for the tests run, and only ERROR+ will get written to
console.
I'm going to double check... no triple check that this does not alter
the servers logging and then commit.
--jason
On Aug 30, 2006, at 4:50 PM, Dain Sundstrom wrote:
You should be able to turn on debugging, add a break point in the
logging code and see which test is causing the problem.
-dain
On Aug 30, 2006, at 4:31 PM, Jason Dillon wrote:
Looks like there is more going on which is causing tests to use
some additional configuration for tests...
Specifically, looks like something else is installing a
ConsoleAppender... as if I comment out the CONSOLE definition from
logging-config, then I still get console output.
I'm also seeing that something is setting the root logger's
level... as I've got the root configured to use DEBUG, but that
will not output DEBUG logs to the test.log as I would expect. I
have to explicitly configure org.apache.geronimo to use DEBUG, and
then I see the logs in test.log... but now with some rouge
ConsoleAppender it spits out a bunch of junk to the console.
Highly frustrating... :-(
--jason
On Aug 30, 2006, at 3:53 PM, Jason Dillon wrote:
This is fixed now... though it still spits out a few ERROR logs,
which I am hoping are expected from the test...
--jason
On Aug 30, 2006, at 3:49 PM, Jason Dillon wrote:
Um... looks like a few of these tests are explicitly enabling
DEBUG and installing a ConsoleAppender...
Logger.getRootLogger().addAppender(new ConsoleAppender(new
PatternLayout(%p [%t] %m %n)));
Logger.getRootLogger().setLevel(Level.DEBUG);
I'm not sure how they were quiet before m2 with code like above
in setUp().
--jason
On Aug 28, 2006, at 4:29 PM, Jason Dillon wrote:
Thats odd, because the default logging config is set to only
allow WARN and ERROR to go to console, not DEBUG.
Do these tests need to:
GeronimoLogging.initialize(GeronimoLogging.INFO);
Or something?
--jason
On Aug 28, 2006, at 10:14 AM, Dain Sundstrom wrote:
Not me. They were quiet before the m2 change but it looks
like logging got turned up.
-dain
On Aug 28, 2006, at 2:26 AM, Jason Dillon wrote:
These tests make way... way to much noise.
Anyone know how to make them shut up?
--jason
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
Running the steps by hand removes bootstrap, a convenience script, from the equation. You most certainly do not need to use it to build Geronimo. It is only an attempt to automate several steps together. As I have said before, and I will undoubtedly say again, bootstrap is temporary and will be removed as soon as we have all of the dependency artifacts published and have a few maven bugs resolved. I believe that the script as it is now is sufficient for use... and any problems which folks are seeing while using the script are issues that need to be fixed... not issues with bootstrap. The cleaning of the repository is a very needed step which helps to ensure that the build is able to resolve all required dependencies from the configured repositories. I am sorry if this is upsetting to some, but IMO it is essential to ensure that nothing creeps in due to an added dependency, which could have easily been installed into your repository by some other Maven project, but might not be accessible to others who are starting to build G from scratch. --jason On Aug 30, 2006, at 8:23 PM, Heinz Drews wrote: Jason, running the steps individually does not change the situation, it only gives better chances to see what has gone wrong. I also don't want to clean my local Maven repos each time, it might sound strange but I have also other stuff there and not the G related components. bootstrap anyhow cleans just the default location and not the place specified in the Maven config. I don't want (even can't) use the default under Windows. I synchronize my profile cross multiple systems and I don't want to transfer all the jars. I would prefer a boostrap process which just installs the requirements and checks the correctness in a second step instead of mangling installation with tests. Heinz On 8/30/06, Jason Dillon [EMAIL PROTECTED] wrote: All of you guys who are seeing strange failures... I suggest you not use bootstrap, but instead run the steps by hand. --jason On Aug 30, 2006, at 7:38 AM, Joe Bohn wrote: Jason, I'm not sure if this was intended or not ... but having these thirdparty items under target results in the source being purged when doing an mvn clean. This is unfortunate for those of us that are hitting the failures on the openejb tests. My memory may not be correct but I thought that prior to this change I could do the following: - bootstrap (with the change to use the jspc 1.4.5-SNAPSHOT to avoid the jspc problem). - watch it fail to build openejb due to the test failures. - run mvn clean install -Dmaven.test.skip=true However, now that openejb is under target the clean deletes the source and before it attempts to build and the result is that I still don't get the openejb jar created in my local repo. Now I think I have to do the following: - bootstrap (with the change to use the jspc 1.4.5-SNAPSHOT to avoid the jspc problem). - watch it fail to build openejb due to the test failures. - cd to target\external\openejb2 - run mvn -Dmaven.test.skip=true - run mvn clean install Am I doing something wrong? Thanks, Joe [EMAIL PROTECTED] wrote: Author: jdillon Date: Sat Aug 26 20:25:18 2006 New Revision: 437291 URL: http://svn.apache.org/viewvc?rev=437291view=rev Log: Changed bootstrap to put external stuff into target/external instead of thirdparty Reduced ant output using -emacs and logger Modified: geronimo/server/trunk/bootstrap geronimo/server/trunk/bootstrap.bat geronimo/server/trunk/bootstrap.xml Modified: geronimo/server/trunk/bootstrap URL: http://svn.apache.org/viewvc/geronimo/server/trunk/bootstrap? rev=437291r1=437290r2=437291view=diff = = --- geronimo/server/trunk/bootstrap (original) +++ geronimo/server/trunk/bootstrap Sat Aug 26 20:25:18 2006 @@ -19,5 +19,5 @@ PWD=`cygpath --windows $PWD` fi -ant $BUILD_OPTIONS -f bootstrap.xml $@ +ant $BUILD_OPTIONS -emacs -logger org.apache.tools.ant.NoBannerLogger -f bootstrap.xml $@ Modified: geronimo/server/trunk/bootstrap.bat URL: http://svn.apache.org/viewvc/geronimo/server/trunk/ bootstrap.bat?rev=437291r1=437290r2=437291view=diff = = --- geronimo/server/trunk/bootstrap.bat (original) +++ geronimo/server/trunk/bootstrap.bat Sat Aug 26 20:25:18 2006 @@ -10,7 +10,7 @@ set PROGNAME=%~nx0% set ARGS=%* -ant %BUILD_OPTIONS% -f bootstrap.xml %ARGS% +ant %BUILD_OPTIONS% -emacs -logger org.apache.tools.ant.NoBannerLogger -f bootstrap.xml %ARGS% :END Modified: geronimo/server/trunk/bootstrap.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/ bootstrap.xml?rev=437291r1=437290r2=437291view=diff = = --- geronimo/server/trunk/bootstrap.xml (original) +++
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
To clarify... the move of the downloaded sources to target/external
was intended, as I did want to make sure that mvn clean removed
them. These sources are not intended to be modified by hand.
Anything that you end up having problems with need to make it back to
those repositories as changes, so that bootstrap by itself
functions. This is not a problem with bootstrap, but a problem with
those dependent projects in addition to your local environment/os.
While I would very much like to get these build problems fixed for
you, changing bootstrap is not the right answer IMO.
--jason
On Aug 30, 2006, at 7:38 AM, Joe Bohn wrote:
Jason,
I'm not sure if this was intended or not ... but having these
thirdparty items under target results in the source being purged
when doing an mvn clean. This is unfortunate for those of us that
are hitting the failures on the openejb tests. My memory may not
be correct but I thought that prior to this change I could do the
following:
- bootstrap (with the change to use the jspc 1.4.5-SNAPSHOT to
avoid the jspc problem).
- watch it fail to build openejb due to the test failures.
- run mvn clean install -Dmaven.test.skip=true
However, now that openejb is under target the clean deletes the
source and before it attempts to build and the result is that I
still don't get the openejb jar created in my local repo. Now I
think I have to do the following:
- bootstrap (with the change to use the jspc 1.4.5-SNAPSHOT to
avoid the jspc problem).
- watch it fail to build openejb due to the test failures.
- cd to target\external\openejb2
- run mvn -Dmaven.test.skip=true
- run mvn clean install
Am I doing something wrong?
Thanks,
Joe
[EMAIL PROTECTED] wrote:
Author: jdillon
Date: Sat Aug 26 20:25:18 2006
New Revision: 437291
URL: http://svn.apache.org/viewvc?rev=437291view=rev
Log:
Changed bootstrap to put external stuff into target/external
instead of thirdparty
Reduced ant output using -emacs and logger
Modified:
geronimo/server/trunk/bootstrap
geronimo/server/trunk/bootstrap.bat
geronimo/server/trunk/bootstrap.xml
Modified: geronimo/server/trunk/bootstrap
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/bootstrap?
rev=437291r1=437290r2=437291view=diff
=
=
--- geronimo/server/trunk/bootstrap (original)
+++ geronimo/server/trunk/bootstrap Sat Aug 26 20:25:18 2006
@@ -19,5 +19,5 @@
PWD=`cygpath --windows $PWD`
fi
-ant $BUILD_OPTIONS -f bootstrap.xml $@
+ant $BUILD_OPTIONS -emacs -logger
org.apache.tools.ant.NoBannerLogger -f bootstrap.xml $@
Modified: geronimo/server/trunk/bootstrap.bat
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/
bootstrap.bat?rev=437291r1=437290r2=437291view=diff
=
=
--- geronimo/server/trunk/bootstrap.bat (original)
+++ geronimo/server/trunk/bootstrap.bat Sat Aug 26 20:25:18 2006
@@ -10,7 +10,7 @@
set PROGNAME=%~nx0%
set ARGS=%*
-ant %BUILD_OPTIONS% -f bootstrap.xml %ARGS%
+ant %BUILD_OPTIONS% -emacs -logger
org.apache.tools.ant.NoBannerLogger -f bootstrap.xml %ARGS%
:END
Modified: geronimo/server/trunk/bootstrap.xml
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/
bootstrap.xml?rev=437291r1=437290r2=437291view=diff
=
=
--- geronimo/server/trunk/bootstrap.xml (original)
+++ geronimo/server/trunk/bootstrap.xml Sat Aug 26 20:25:18 2006
@@ -14,19 +14,19 @@
/sequential
/macrodef
-macrodef name=build-thirdparty
+macrodef name=build-external
attribute name=url/
attribute name=name/
sequential
-mkdir dir=${basedir}/thirdparty/
+mkdir dir=${basedir}/target/external/
-exec executable=svn dir=${basedir}/
thirdparty
+exec executable=svn dir=${basedir}/target/external
arg value=co/
arg value=@{url}/
arg value=@{name}/
/exec
-mvn goal=install dir=${basedir}/
thirdparty/@{name}/
+mvn goal=install dir=${basedir}/target/external/@
{name}/
/sequential
/macrodef
@@ -42,6 +42,7 @@
target name=init depends=init:discover,
init:windows, init:defaults
record name=${basedir}/bootstrap.log/
+ echoStarting bootstrap build.../echo
/target
@@ -88,14 +89,12 @@
!-- --
target name=clean depends=clean:init, clean:minimal,
clean:full
-delete dir=${basedir}/thirdparty/
+delete dir=${basedir}/target/
mvn goal=clean/
/target
target name=clean:init depends=init
-echoCleaning.../echo
- mkdir dir=${user.home}/.m2/repository/
/target
@@ -120,18 +119,18 @@
/target
Re: Eclipse as development tool for Geronimo components
Generally I was successful using Eclipse to debug server components. As Paul mentioned for each of the modules different steps are required to deploy the changes. I build the jar using maven inside the module directory. With this approach I have experienced a litte problem. Because Eclipse is running immediate compiles the *.class files are uptodate and maven skips the compilation. This causes the failures because we have a number of serializable classes without serialVersionUID. The embedded compiler in Eclipse generates differently to javac. Therefore ist required to delete all *.class before running maven. Best would be to have serialVersionUID set in all cases. Heinz I'm looking for a solution to set .classpath properly for the modules referring xmlbeans On 8/28/06, Paul McMahan [EMAIL PROTECTED] wrote: Heinz, what you're describing has been my experience with Eclipse as well. Depending on which part of Geronimo you change there are different ways to get your changes loaded into the debug env. In some cases you can rebuild and then redeploy the code using the command line interface, perhaps from a script you invoke from an eclipse button. In other cases you might need to rebuild a jar, shut down the server, replace the jar in the repository directory, and then restart the server. In any case I haven't figured out a way to use hot replace from the IDE, which would be nice. As you know, debugging applications in Eclipse is easier than debugging the server because the Eclipse plugin handles the redeployment for you. Best wishes, Paul On 8/28/06, Heinz Drews [EMAIL PROTECTED] wrote: Hi Sachin, The mvn eclipse:eclipse generates the .project files with the proper reference. This solves the problem you mentioned. Generally it would be a nice start but naturally is the manual import a long and tedious exercise. I guess an exported workspace might help. With debugging there is currently the problem that o.g...Daemon requires the server.jar which then refers the modules via the manifest as jars. This forces then to build with maven instead of directly using the generated classes. Just building the changed component is sufficient with exception of the ones referring xmlbeans. I was hoing that somebody had already made more progress but I will not give up. Heinz On 8/28/06, Sachin Patel [EMAIL PROTECTED] wrote: One of the big problems is that you can not use pure Eclipse to develop Geronimo. (just make code changes and compile) The maven eclipse plugin generates the .classpath in which all the projects reference only the built jars in the maven repository rather then the projects set up to reference each other. This causes a huge annoyance in that every time you make a change that affects another module, you will not see any compilation errors since the modified module has to be rebuilt and redeployed with maven so that the affected jar picks up the change. Also using the maven plugin for eclipse doesn't help, and enabling the maven build to occur using it helps the issue but makes the build process extremlely long. I haven't tried the m2 eclipse goal to see if it addresses some of these issues or not. On Aug 28, 2006, at 12:01 PM, Heinz Drews wrote: Hello, I want to use Eclipse for development and debugging of Geronimo components. The Eclipse plugin I have already used for application development. I have run mvn eclipse:eclipse, imported manually the projects but I'm hoping for a faster approach. And I'm facing several problems. First I could not found the xmlbeans in the source tree, modules referring them don't compile. Then I have not found a way to run G directly from the compilation produced by Eclipse. Only approach now is to build a module with Maven and copy the jar to the Geronimo tree. Help would be very much appreciated. Regards, Heinz -sachin
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
Please don't see my comments as offense.
They are born from frustration. It seemed that build has been
promoted from being the way to being the destination.
For me it seems that setting MaxPermSize is helping a lot.
The situation that the total process stopped because of a failing test
has not happened again.
Just finished a successful build using bootstrap under WinXP.
--Heinz
On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote:
To clarify... the move of the downloaded sources to target/external
was intended, as I did want to make sure that mvn clean removed
them. These sources are not intended to be modified by hand.
Anything that you end up having problems with need to make it back to
those repositories as changes, so that bootstrap by itself
functions. This is not a problem with bootstrap, but a problem with
those dependent projects in addition to your local environment/os.
While I would very much like to get these build problems fixed for
you, changing bootstrap is not the right answer IMO.
--jason
On Aug 30, 2006, at 7:38 AM, Joe Bohn wrote:
Jason,
I'm not sure if this was intended or not ... but having these
thirdparty items under target results in the source being purged
when doing an mvn clean. This is unfortunate for those of us that
are hitting the failures on the openejb tests. My memory may not
be correct but I thought that prior to this change I could do the
following:
- bootstrap (with the change to use the jspc 1.4.5-SNAPSHOT to
avoid the jspc problem).
- watch it fail to build openejb due to the test failures.
- run mvn clean install -Dmaven.test.skip=true
However, now that openejb is under target the clean deletes the
source and before it attempts to build and the result is that I
still don't get the openejb jar created in my local repo. Now I
think I have to do the following:
- bootstrap (with the change to use the jspc 1.4.5-SNAPSHOT to
avoid the jspc problem).
- watch it fail to build openejb due to the test failures.
- cd to target\external\openejb2
- run mvn -Dmaven.test.skip=true
- run mvn clean install
Am I doing something wrong?
Thanks,
Joe
[EMAIL PROTECTED] wrote:
Author: jdillon
Date: Sat Aug 26 20:25:18 2006
New Revision: 437291
URL: http://svn.apache.org/viewvc?rev=437291view=rev
Log:
Changed bootstrap to put external stuff into target/external
instead of thirdparty
Reduced ant output using -emacs and logger
Modified:
geronimo/server/trunk/bootstrap
geronimo/server/trunk/bootstrap.bat
geronimo/server/trunk/bootstrap.xml
Modified: geronimo/server/trunk/bootstrap
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/bootstrap?
rev=437291r1=437290r2=437291view=diff
=
=
--- geronimo/server/trunk/bootstrap (original)
+++ geronimo/server/trunk/bootstrap Sat Aug 26 20:25:18 2006
@@ -19,5 +19,5 @@
PWD=`cygpath --windows $PWD`
fi
-ant $BUILD_OPTIONS -f bootstrap.xml $@
+ant $BUILD_OPTIONS -emacs -logger
org.apache.tools.ant.NoBannerLogger -f bootstrap.xml $@
Modified: geronimo/server/trunk/bootstrap.bat
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/
bootstrap.bat?rev=437291r1=437290r2=437291view=diff
=
=
--- geronimo/server/trunk/bootstrap.bat (original)
+++ geronimo/server/trunk/bootstrap.bat Sat Aug 26 20:25:18 2006
@@ -10,7 +10,7 @@
set PROGNAME=%~nx0%
set ARGS=%*
-ant %BUILD_OPTIONS% -f bootstrap.xml %ARGS%
+ant %BUILD_OPTIONS% -emacs -logger
org.apache.tools.ant.NoBannerLogger -f bootstrap.xml %ARGS%
:END
Modified: geronimo/server/trunk/bootstrap.xml
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/
bootstrap.xml?rev=437291r1=437290r2=437291view=diff
=
=
--- geronimo/server/trunk/bootstrap.xml (original)
+++ geronimo/server/trunk/bootstrap.xml Sat Aug 26 20:25:18 2006
@@ -14,19 +14,19 @@
/sequential
/macrodef
-macrodef name=build-thirdparty
+macrodef name=build-external
attribute name=url/
attribute name=name/
sequential
-mkdir dir=${basedir}/thirdparty/
+mkdir dir=${basedir}/target/external/
-exec executable=svn dir=${basedir}/
thirdparty
+exec executable=svn dir=${basedir}/target/external
arg value=co/
arg value=@{url}/
arg value=@{name}/
/exec
-mvn goal=install dir=${basedir}/
thirdparty/@{name}/
+mvn goal=install dir=${basedir}/target/external/@
{name}/
/sequential
/macrodef
@@ -42,6 +42,7 @@
target name=init depends=init:discover,
init:windows, init:defaults
record name=${basedir}/bootstrap.log/
+ echoStarting bootstrap
[jira] Commented: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2352?page=comments#action_12431784 ] Jason Dillon commented on GERONIMO-2352: So far looks good. A few issues... * indent of xml files was not consistent * new test-deployables module did not inherit from its parent, which added some additional unneeded config to children * some file shave openejb license and not ASL v2 * groupid/artifactid might not be optimal I've fixed the formatting and setup the pom to inherit and dropped the unneeded bits. I think we should change the artifactId's and directory names for the war/ear/ejb/rar bits... still pending what those will be, but I don't this we want to have files like war-1.2.war and ear-1.2.ear. And, I think we don't need to drop each group (1.3 1.4) deployables into a separate groupId. You also do not need to nor, should, specify the version of the dependency plugin in child usage, that will get picked up from the parent's pom. Anyways, all of this is minor... and I only point it out to you for future reference. I'm going to massage this patch slightly as mentioned above and then commit. Can fix up the licenses afterwards, not sure exactly what to do about this. j2ee-builder test deployment modules won't actually deploy -- Key: GERONIMO-2352 URL: http://issues.apache.org/jira/browse/GERONIMO-2352 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Bill Dudney Attachments: GERONIMO-2352.bdudney.patch The ear/war/ejb-jar/rar files wont actually deploy to the server. I have a partial patch avalible but I'd like to get some discussion going on how to fix some of the problems, that is happening in the dev list. I will post the complete patch here when that discussion is wrapped up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2352?page=all ] Jason Dillon reassigned GERONIMO-2352: -- Assignee: Jason Dillon j2ee-builder test deployment modules won't actually deploy -- Key: GERONIMO-2352 URL: http://issues.apache.org/jira/browse/GERONIMO-2352 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Bill Dudney Assigned To: Jason Dillon Attachments: GERONIMO-2352.bdudney.patch The ear/war/ejb-jar/rar files wont actually deploy to the server. I have a partial patch avalible but I'd like to get some discussion going on how to fix some of the problems, that is happening in the dev list. I will post the complete patch here when that discussion is wrapped up. -- 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
Build failure on branches/1.1.1 due to geronimo-j2ee-jacc_1.0_spec-1.1.1.jar
Build is failing due to geronimo-j2ee-jacc_1.0_spec-1.1.1.jar unavailable in the repository. Has anyone else hit this error? Console output given below. Thanks, Vamsi + | geronimo and geronimo-plugins Geronimo :: Security | Memory: 17M/29M + DEPRECATED: the default goal should be specified in the build section of proje ct.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of proje ct.xml instead of maven.xml build:end: Attempting to download geronimo-j2ee-jacc_1.0_spec-1.1.1.jar. WARNING: Failed to download geronimo-j2ee-jacc_1.0_spec-1.1.1.jar. BUILD FAILED File.. C:\g111\maven.xml Element... maven:reactor Line.. 43 Column -1 The build cannot continue because of the following unsatisfied dependency: geronimo-j2ee-jacc_1.0_spec-1.1.1.jar
Re: Build failure on branches/1.1.1 due to geronimo-j2ee-jacc_1.0_spec-1.1.1.jar
One more jar missing geronimo-schema-j2ee_1.4-1.0.jar May be there are more missing. Vamsi + | geronimo and geronimo-plugins Geronimo :: J2EE Schema | Memory: 14M/26M + DEPRECATED: the default goal should be specified in the build section of proje ct.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of proje ct.xml instead of maven.xml build:end: Attempting to download geronimo-schema-j2ee_1.4-1.0.jar. WARNING: Failed to download geronimo-schema-j2ee_1.4-1.0.jar. BUILD FAILED File.. C:\g111\maven.xml Element... maven:reactor Line.. 43 Column -1 The build cannot continue because of the following unsatisfied dependency: geronimo-schema-j2ee_1.4-1.0.jar On 8/31/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Build is failing due to geronimo-j2ee-jacc_1.0_spec-1.1.1.jar unavailable in the repository. Has anyone else hit this error? Console output given below. Thanks, Vamsi + | geronimo and geronimo-plugins Geronimo :: Security | Memory: 17M/29M + DEPRECATED: the default goal should be specified in the build section of proje ct.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of proje ct.xml instead of maven.xml build:end: Attempting to download geronimo-j2ee-jacc_1.0_spec-1.1.1.jar. WARNING: Failed to download geronimo-j2ee-jacc_1.0_spec-1.1.1.jar. BUILD FAILED File.. C:\g111\maven.xml Element... maven:reactor Line.. 43 Column -1 The build cannot continue because of the following unsatisfied dependency: geronimo-j2ee-jacc_1.0_spec-1.1.1.jar
Re: Build failure on branches/1.1.1 due to geronimo-j2ee-jacc_1.0_spec-1.1.1.jar
One more jar missing geronimo-schema-j2ee_1.4-1.0.jar May be there are more missing. Vamsi + | geronimo and geronimo-plugins Geronimo :: J2EE Schema | Memory: 14M/26M + DEPRECATED: the default goal should be specified in the build section of proje ct.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of proje ct.xml instead of maven.xml build:end: Attempting to download geronimo-schema-j2ee_1.4-1.0.jar. WARNING: Failed to download geronimo-schema-j2ee_1.4-1.0.jar. BUILD FAILED File.. C:\g111\maven.xml Element... maven:reactor Line.. 43 Column -1 The build cannot continue because of the following unsatisfied dependency: geronimo-schema-j2ee_1.4-1.0.jar On 8/31/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Build is failing due to geronimo-j2ee-jacc_1.0_spec-1.1.1.jar unavailable in the repository. Has anyone else hit this error? Console output given below. Thanks, Vamsi + | geronimo and geronimo-plugins Geronimo :: Security | Memory: 17M/29M + DEPRECATED: the default goal should be specified in the build section of proje ct.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of proje ct.xml instead of maven.xml build:end: Attempting to download geronimo-j2ee-jacc_1.0_spec-1.1.1.jar. WARNING: Failed to download geronimo-j2ee-jacc_1.0_spec-1.1.1.jar. BUILD FAILED File.. C:\g111\maven.xml Element... maven:reactor Line.. 43 Column -1 The build cannot continue because of the following unsatisfied dependency: geronimo-j2ee-jacc_1.0_spec-1.1.1.jar
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
I'm not offended... well, not by your email at least... your os...
well that is another story :-P
Hopefully we will have the magic recipe for building on windows soon.
--jason
On Aug 30, 2006, at 10:01 PM, Heinz Drews wrote:
Please don't see my comments as offense.
They are born from frustration. It seemed that build has been
promoted from being the way to being the destination.
For me it seems that setting MaxPermSize is helping a lot.
The situation that the total process stopped because of a failing test
has not happened again.
Just finished a successful build using bootstrap under WinXP.
--Heinz
On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote:
To clarify... the move of the downloaded sources to target/external
was intended, as I did want to make sure that mvn clean removed
them. These sources are not intended to be modified by hand.
Anything that you end up having problems with need to make it back to
those repositories as changes, so that bootstrap by itself
functions. This is not a problem with bootstrap, but a problem with
those dependent projects in addition to your local environment/os.
While I would very much like to get these build problems fixed for
you, changing bootstrap is not the right answer IMO.
--jason
On Aug 30, 2006, at 7:38 AM, Joe Bohn wrote:
Jason,
I'm not sure if this was intended or not ... but having these
thirdparty items under target results in the source being purged
when doing an mvn clean. This is unfortunate for those of us that
are hitting the failures on the openejb tests. My memory may not
be correct but I thought that prior to this change I could do the
following:
- bootstrap (with the change to use the jspc 1.4.5-SNAPSHOT to
avoid the jspc problem).
- watch it fail to build openejb due to the test failures.
- run mvn clean install -Dmaven.test.skip=true
However, now that openejb is under target the clean deletes the
source and before it attempts to build and the result is that I
still don't get the openejb jar created in my local repo. Now I
think I have to do the following:
- bootstrap (with the change to use the jspc 1.4.5-SNAPSHOT to
avoid the jspc problem).
- watch it fail to build openejb due to the test failures.
- cd to target\external\openejb2
- run mvn -Dmaven.test.skip=true
- run mvn clean install
Am I doing something wrong?
Thanks,
Joe
[EMAIL PROTECTED] wrote:
Author: jdillon
Date: Sat Aug 26 20:25:18 2006
New Revision: 437291
URL: http://svn.apache.org/viewvc?rev=437291view=rev
Log:
Changed bootstrap to put external stuff into target/external
instead of thirdparty
Reduced ant output using -emacs and logger
Modified:
geronimo/server/trunk/bootstrap
geronimo/server/trunk/bootstrap.bat
geronimo/server/trunk/bootstrap.xml
Modified: geronimo/server/trunk/bootstrap
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/bootstrap?
rev=437291r1=437290r2=437291view=diff
=
=
--- geronimo/server/trunk/bootstrap (original)
+++ geronimo/server/trunk/bootstrap Sat Aug 26 20:25:18 2006
@@ -19,5 +19,5 @@
PWD=`cygpath --windows $PWD`
fi
-ant $BUILD_OPTIONS -f bootstrap.xml $@
+ant $BUILD_OPTIONS -emacs -logger
org.apache.tools.ant.NoBannerLogger -f bootstrap.xml $@
Modified: geronimo/server/trunk/bootstrap.bat
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/
bootstrap.bat?rev=437291r1=437290r2=437291view=diff
=
=
--- geronimo/server/trunk/bootstrap.bat (original)
+++ geronimo/server/trunk/bootstrap.bat Sat Aug 26 20:25:18 2006
@@ -10,7 +10,7 @@
set PROGNAME=%~nx0%
set ARGS=%*
-ant %BUILD_OPTIONS% -f bootstrap.xml %ARGS%
+ant %BUILD_OPTIONS% -emacs -logger
org.apache.tools.ant.NoBannerLogger -f bootstrap.xml %ARGS%
:END
Modified: geronimo/server/trunk/bootstrap.xml
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/
bootstrap.xml?rev=437291r1=437290r2=437291view=diff
=
=
--- geronimo/server/trunk/bootstrap.xml (original)
+++ geronimo/server/trunk/bootstrap.xml Sat Aug 26 20:25:18 2006
@@ -14,19 +14,19 @@
/sequential
/macrodef
-macrodef name=build-thirdparty
+macrodef name=build-external
attribute name=url/
attribute name=name/
sequential
-mkdir dir=${basedir}/thirdparty/
+mkdir dir=${basedir}/target/external/
-exec executable=svn dir=${basedir}/
thirdparty
+exec executable=svn dir=${basedir}/target/
external
arg value=co/
arg value=@{url}/
arg value=@{name}/
/exec
-mvn goal=install dir=${basedir}/
thirdparty/@{name}/
+mvn goal=install
Re: Restructuring trunk, then next steps
I had thought about calling that module 'extentions' though seemed odd, since out extention mechanism is called plugins. I had also though about a 'components' tree, for optional stuff that can plugin, but not core to the server. --jason On Aug 28, 2006, at 8:02 AM, Paul McMahan wrote: Jason, the distinction between framework and system might be unclear to a novice. Something like bootstrap and system might be clearer. Also, I think of plugin as a packaging/distribution mechanism instead of a statement of functionality so I would call that directory something like ext and put modules in there that are optional extensions to the server (probably implemented as plugins, but not necessarily). Best wishes, Paul On 8/28/06, Jason Dillon [EMAIL PROTECTED] wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chunks. I took a few minutes and took a crude stab at what that might look like. This is just an example of how it might work... I did not do any extensive research into dependencies... Basically, I split things up into 5 main trees: * framework - common stuff, not really the server, but supports the server, modules here should have minimal deps * system - the major components which make up the server's system (should be the bits to start up a server shell) * tools - bits that support the system * plugins - components which plugin to the system * testsuite - placeholder for modules which will be aded soon that use the itest plugin to perform integration tests I'm not sure if this is the best split, but it kinda comes closer to what I hope we can get to. Below is how the modules that exists fit into these sections. framework/ geronimo-testsupport (may need to be in other tree? so can include in all modules by default) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel system/ geronimo-management geronimo-security geronimo-security-builder geronimo-service-builder geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-connector-builder geronimo-jmx-remoting geronimo-naming geronimo-naming-builder geronimo-test-ddbean (wtf is this for?) geronimo-deployment/ geronimo-deployment (rename to -core) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-hot-deploy geronimo-client geronimo-client-builder geronimo-j2ee/ geronimo-j2ee geronimo-j2ee-builder geronimo-j2ee-schema geronimo-web-builder plugins/ geronimo-activemq/ ge-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-axis-builder geronimo-derby geronimo-directory geronimo-tomcat geronimo-tomcat-builder geronimo-jetty geronimo-jetty-builder geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter testsuite/ TODO, home for itest usage Anyways, I wanted to post what I am thinking. I think that we are really close to the point where we will want to implement this sort of split up. Comments? --jason
Standard for serialVersionUID
As I have mentioned in another message I have accidently used class files in modules created by Eclipse embeded compiler. This calculates serialVersionUID different way then javac. I think that adding serialVersionUID to all serializable class would address the situation best. There are quite a number of class without the uid. I would volunteer to add them but which standard should be used? Eclipse provides the option set it to 1 or to calculate the uid. But the calculation is different to the one doen by javac. In other projects I have found the convention to use version number to support detection of incompatible modifications. The version number a much nicer to read in the message reporting mismatches than the generated ones. Least impact would be to calculate the value with the serialver tool. This avoids the need for redeploying. Which standard should be chosen? --Heinz
XBean and Genesis
It seems there are problems releasing Genesis, which XBean depends on. Should we remove this dependency and switch back to our old pom ? -- Cheers, Guillaume Nodet
