How many ADF library versions on one WLS installation?
Chris Muir
Has anybody come to the same following conclusion I have regards the
number of WebLogic Servers required to support ADF 11g? Your thoughts
appreciated.
Please note I'm aware of the difference between a WebLogic Server and
separate managed servers in WLS.
If we want to support 2 or more ADF applications written in different
ADF library versions (say JDev 11g v11.1.1.1.0 and JDev v11.1.1.2.0),
and porting the first application to the later ADF libraries version
is not possible (thanks to say, the resource requirements of
regression testing being to prohibitive), then in terms of WLS servers
we will need to have two or more separate WLS servers to support the
two different ADF Library versions?
I've come to this conclusion because:
a) the ADF Runtime Libraries installer (aka. applyJRF script) doesn't
distinguish between managed servers it installs to within a WLS
server, so you can't target specific ADF library versions to a managed
server (even though you can target them via the console later, but
read on)
b) besides WLS doesn't support two versions of the ADF Libraries
installed simultaneously anyhow, as WLS when installing the second
version of a library enforces the library/application name must be is
unique, which they aren't when you install the same ADF Libraries
twice (even though they're different versions)
.....and the documentation says you can't install multiple versions to
the same WLS anyhow. I was kinda hoping this was wrong and we could
install different ADF Library versions to different managed servers
within WLS, but the constraints a and b override this.
This implies that either:
1) The ability to regression test is a must for pushing our
applications up to the latest JDev version if we want to avoid a large
array of WebLogic Servers
2) We'll need multiple WLS servers for different ADF Library versions
otherwise.
Your thoughts?
Regards,
CM.
Simon Haslam
(even though the deployments are to managed servers), so that would
mean you'd need a new *domain* for every different version of ADF!
That sounds very unlikely and would make side-by-side deployments
impossible too.
One option is to bundle the ADF files with the app and use the
filtering classloader (http://download.oracle.com/docs/cd/E12839_01/
web.1111/e13706/classloading.htm#WLPRG313) but that's not very elegant
either.
I haven't tried it yet but I would have thought you could just load
multiple versions of the ADF libraries (i.e. with the same name) into
a domain and then specify required versions on the application. This
should even allow you to deploy two versions of the ADF libraries to
the same managed server. Of course there's lots of OFM stuff
(depending on your installation e.g. EM, SOA) in the admin server that
now needs ADF so I expect applying the JRFdomain template will have to
stay.
There's a section on library versioning here:
http://download.oracle.com/docs/cd/E12839_01/web.1111/e13706/libraries.htm#i1064656
...and how you specify the dependencies in weblogic-application.xml
here:
http://download.oracle.com/docs/cd/E12839_01/web.1111/e13706/libraries.htm#i1064660
Sounds to me like a packaging/scripting technique is required.
Simon
Chris Muir
2009/12/14 Simon Haslam <Sim...@veriton.co.uk>:
> (even though the deployments are to managed servers), so that would
> mean you'd need a new *domain* for every different version of ADF!
> That sounds very unlikely and would make side-by-side deployments
> impossible too.
WLST script to find out if it can be "hacked" with no success (I now
believe it in the ADF Runtime Installer - will have a look tomorrow).
What I'm a little concerned about in pursuing the multi managed server
deployment option is their's method in Oracle's madness in deploying
to a domain only. Could it be there something they change at the
domain level when running the WLST script that makes a domain only
deployment necessary?
> One option is to bundle the ADF files with the app and use the
> filtering classloader (http://download.oracle.com/docs/cd/E12839_01/
> web.1111/e13706/classloading.htm#WLPRG313) but that's not very elegant
> either.
> I haven't tried it yet but I would have thought you could just load
> multiple versions of the ADF libraries (i.e. with the same name) into
> a domain and then specify required versions on the application. This
> should even allow you to deploy two versions of the ADF libraries to
> the same managed server. Of course there's lots of OFM stuff
> (depending on your installation e.g. EM, SOA) in the admin server that
> now needs ADF so I expect applying the JRFdomain template will have to
> stay.
>
> There's a section on library versioning here:
> http://download.oracle.com/docs/cd/E12839_01/web.1111/e13706/libraries.htm#i1064656
> ...and how you specify the dependencies in weblogic-application.xml
> here:
> http://download.oracle.com/docs/cd/E12839_01/web.1111/e13706/libraries.htm#i1064660
backed up by the second. The thing is if you take the JARs from 2
different JDev vesions and deploy them to WLS, regardless that the
JARs have different specification-version/implementation-version
entries in their weblogic-application.xml file, WLS still rejects the
second library as it has the same name as the first library. I
thought about changing the library names to include the version, but
then there are inter library dependency issues that makes it all a big
hack and highly unmaintainable for the next joe who enherits my work.
> Sounds to me like a packaging/scripting technique is required.
evil campaign to make us buy numerous WLS licenses (only joking). I'm
hoping that the 1-domain-per-ADF-library limitation is just a
limitation in the initial JDev 11g offerings and the scripts they've
crated; maybe Oracle didn't think we'd be writing so many applications
so quickly, and there's an improved deployment mechanism on the way?
Any JDev PMs care to comment please?
Cheers,
CM.
Simon Haslam
from the WL console you must tick the library name and then do an
"Update" (not a new "Install"). I've just done that to get these
concurrent library deployments:
adf.oracle.domain(1.0,11.1.1.1.0)
adf.oracle.domain(1.0,11.1.1.2.0)
In my config.xml that gives me:
<library>
<name>adf.oracle.domain#1...@11.1.1.2.0</name>
<target>AdminServer</target>
<module-type>ear</module-type>
<source-path>/opt/oracle/middleware/oracle_common/modules/
oracle.adf.model_11.1.1/adf.oracle.domain.ear</source-path>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode>nostage</staging-mode>
</library>
and:
<library>
<name>adf.oracle.domain#1...@11.1.1.1.0</name>
<target>ManagedServer1</target>
<module-type>ear</module-type>
<source-path>{blah}/jdev111110_modules/adf.oracle.domain.ear</
source-path>
<security-dd-model>DDOnly</security-dd-model>
</library>
...you'll see the version is built into the library name. What I don't
see yet is how you stop it being deployed to the Admin Server too -
you really want to choose the servers to deploy to during the update
(i.e. you may want, say, 11.1.1.2 on the Admin Server and MS2, and
11.1.1.1 only on MS1). In my case I removed AdminServer as a target
for 11.1.1.1 after updating.
The second of my earlier URLs was just to show how you'd have to
specify it in your weblogic-application.xml in your ADF's ear file,
e.g. to make sure you only picked up 11.1.1.1.0. The default has:
<library-ref>
<library-name>adf.oracle.domain</library-name>
</library-ref>
so I expect you'd need to make that:
<library-ref>
<library-name>adf.oracle.domain</library-name>
<specification-version>1.0</specification-version>
<implementation-version>11.1.1.1.0</implementation-version>
<exact-match>true</exact-match>
</library-ref>
(I haven't tested this yet)
I agree this is quite hard work though, especially as there are quite
a few ADF-related libraries to worry about. It would benefit from
scripting or including in the JRF utilities, therefore it would be
useful to know if we're missing something, otherwise if there's
something automated in the pipeline. If not, I think there needs to be
an enhancement request since running multiple versions of ADF in one
domain is a strong requirement (as you suggest earlier - you can't
just regression test production apps at will).
Simon
> > here:
Chris Muir
button, I totally missed that, who would have thought greyed out
buttons actually do something), I discovered:
1) I located the oracle.adf.domain.webapp.war file in the JDev 11gR1
build 5537. The EAR file needs a fix in it's MANIFEST.MF file to
correctly deploy as a new version, otherwise WLS rejects it. The
MANIFEST.MF by default is:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0RC1
Created-By: 14.0-b16 (Sun Microsystems Inc.)
Built-By: ADF
Extension-Name: adf.oracle.domain.webapp
Implementation-Vendor: Oracle USA, Inc.
Implementation-Title: ADF Webapp Libraries
...and needs to read as the following for it to be correctly deployed
as an updated library:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0RC1
Created-By: 14.0-b16 (Sun Microsystems Inc.)
Built-By: ADF
Extension-Name: adf.oracle.domain.webapp
Specification-Version: 1.0
Implementation-Version: 11.1.1.2.0
Implementation-Vendor: Oracle USA, Inc.
Implementation-Title: ADF Webapp Libraries
...ensuring the specification-version and implementation-version
options come straight after the extension-name entry.
I'm unsure how the JDev installer gets away without doing this,
possibly via a WSLT script enforcing the versions.
As a result I managed to configure the different versions (ie.
v11.1.1.1.0 from 11g build 5407 vs v11.1.1.2.0 from 11g build 5537) of
the ADF libraries oracle.adf.domain and oracle.adf.domain.webapp
against separate managed servers, and the rest of the ADF libraries
which haven't been upgraded targeted to both managed servers. Next I
built 2 ADF applications against the different JDev builds. In each I
changed the weblogic-application.xml file to specifically reference
the correct managed library version. Then I deployed the first
application against the first managed server built with 11.1.1.1.0
build 5407 and it successfully ran the application. On deploying the
later app against the second managed server built on 11.1.1.2.0 build
5537 it refuses to deploy with a NoClassDefFound exception for various
classes.
I managed to resolve a few but then broke my installation and now I'm
a couple hours away from getting this going again. I've lost my
enthusiasm for working on this today. Unfortunately this still leaves
us at a point where we're unsure can 1 domain support multiple ADF
library versions + associated applications.
2) I also discovered approximately where the applyJRF scripts are.
Under:
build 5407: <jdev_home>\jdeveloper\common\templates\jdeveloper
\jrf_template_11.1.1.jar
build 5537: <jdev_home>\oracle_common\common\templates\applications
\jrf_template_11.1.1.jar
I'm not overly familiar with the WLST scripts contained within. You
can see in the scripts the managed libraries it configures, but I'm
not sure where the JAR files are sourced from. In turn I think some
of the files do point to configuration changes at the domain-level
which may derail the whole multi-ADF-library requirement.
I'm hoping the above information will spark others to pursue the multi-
ADF-library-version deployment option. From the ADF EMG group's point
of view it does seem reasonable to pursue this goal as it relates to
best practice of WLS configuration and installations for multi-
versioned-applications.
In turn I'll try emailing a few of the JDev PMs today to see if they
have any comments. Like Simon I don't think it an unreasonable
requirement and am looking for some expert advice why it's not
possible, or in turn if there is already an ER in the works.
Cheers,
CM.
ugb
I understand your problem. Cause of this problem is quick release
management in conjunction with development-, test-, integration- and
production environment.
In our projects we are pursuing the following approach:
1) Virtualization of development-,test- and integration environment
2) There is only one project within one Oracle ADF - Version
3) No mix of versions within one container
Advantage:
- There is only one version in production
- Operation and installation are carried out, perhaps
- No manipulation of deployment files, which understands only one
developer
- Running of test- and integration enviroment with version X only if
it is needed (Green IT)
- Cloning of development environments
Disadvantage
- Rebuilding the development environment and test environment on
virtual servers
- Strict own Release Management
- Sometimes you have to wait for patchset X on production: (
On of the most skeptical point every admin is speaking about inside
Java platform is: Version - "Everyday a new java libraries" etc.
Perhaps it is better not to put your feet into the JAR hell. (Remind
in the past, a lot of people speak about Microsoft DLL Hell) :)
uli
Chris Muir
Truthfully my current client is VMing their dev/test boxes as well,
but not production. I note you didn't say your VMing your production
box? Does this imply you've separate WLS installs on separate
production boxes, or possibly multiple WLS installs on the same
production box?
If you're not VMing your production box any specific reason why not?
Considering your VMed option for dev/test/and maybe prod it does seem
the best alternative for the multi-ADF-library-version issue if a
solution can't be found. One disadvantage I see is as we build more
applications (which we're doing faster and faster) and as Oracle
releases new versions of JDev (I count 2-3 in the last year I think)
we're going to end up with a h3ll of a lot of WLS installs. As you
say, we're already starting to suffer from the frequency of
patching/upgrading our WLS boxes which we'd like to sort out before
things get much worse.
Cheers,
CM.
2009/12/15 ugb <ulrich.gerk...@googlemail.com>:
> You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
--
Chris Muir
Oracle Systems Consultant & Trainer
SAGE Computing Services Pty Ltd
http://www.sagecomputing.com.au
Oracle ACE Director
http://www.oracle.com/technology/community/oracle_ace/index.html
Email: chris...@sagecomputing.com.au
Blog: http://one-size-doesnt-fit-all.blogspot.com/
Mobile/Cell: 043-828-6421
International: +61-43-828-6421
Gmail chat: chris...@gmail.com
Twitter: twitter.com/chriscmuir
LinkedIn: http://www.linkedin.com/in/chriscmuir
ugb
Our customers use VMware ESX - Server for the production. There was a
very good white paper regarding BEA and deployment on a VMWare ESX
server. Unfortunately, I discovered that the link does not work
anymore. If you have interest, I send you like the PDF.
The establishment of our development and our methodology, you can look
in my presentation, I gave at DOAG 2009th Unfortunately, the
presentation in German. But I think the essentials are clearly also by
the graphics.
Presentation: http://www.box.net/shared/m508ons8h9
uli
On 15 Dez., 22:24, Chris Muir <chriscm...@gmail.com> wrote:
> Thanks for the follow up Uli and sharing your setup.
>
> Truthfully my current client is VMing their dev/test boxes as well,
> but not production. I note you didn't say your VMing your production
> box? Does this imply you've separate WLS installs on separate
> production boxes, or possibly multiple WLS installs on the same
> production box?
>
> If you're not VMing your production box any specific reason why not?
>
> Considering your VMed option for dev/test/and maybe prod it does seem
> the best alternative for the multi-ADF-library-version issue if a
> solution can't be found. One disadvantage I see is as we build more
> applications (which we're doing faster and faster) and as Oracle
> releases new versions of JDev (I count 2-3 in the last year I think)
> we're going to end up with a h3ll of a lot of WLS installs. As you
> say, we're already starting to suffer from the frequency of
> patching/upgrading our WLS boxes which we'd like to sort out before
> things get much worse.
>
> Cheers,
>
> CM.
>
> 2009/12/15 ugb <ulrich.gerkmannbart...@googlemail.com>:
> Email: chris.m...@sagecomputing.com.au
> Blog:http://one-size-doesnt-fit-all.blogspot.com/
> Mobile/Cell: 043-828-6421
> International: +61-43-828-6421
> Gmail chat: chriscm...@gmail.com
Jean-Marc
Network Storage and it works well.
I can't see much risks of doing so and I see lots of advantages like
cloning, deduplication, recovery etc...
Though it helps, it does not solved the problem of dealing with new
releases.
Last 11.1.1.1 installation and integration with OID 10.1.4 and SSO
(required to work in conjunction with ADF 10g OC4J production Apps)
took me 2 full weeks due to a small but crucial instruction/note that
was omitted in Oracle installation docs... Sometimes my Oracle
relation is really looking like a sado-maso one...
Chris's point is a major one and in fact could be extended to a much
larger scope of development investments protection when building with
ADF.
One of the most important part of ADF Oracle should work on is making
any new ADF runtime version backward compatible with previous ones
both at WLS and JDev levels. E.g one Jdev, one WLS server with updates
at each new ADF runtime libraries.
Otherwise we will have to support multiple WLS installs and multiple
JDev installs and that won't be sustainable as the application base
grows.
Jean-Marc
Chris Muir
Oracle Support to remove the restriction of installing multiple ADF
Runtime Libraries on the same WLS server. If other Oracle customers
would like to see this problem solved too, I suggest raising your own
ER with similar concerns. Obviously the more requests Oracle gets the
hope would be they push this up their priority list, or alternatively
give us some guidance.
The details of the Service Request 3-1363418101 containing the
Enhancement Request for reference:
Q) Describe how the current product functionality is insufficient.
A) We have 1 production ADF applications written in an earlier version
of JDev 11.1.1.0.0 based on the same versioned ADF Runtime Libraries,
and a new application just about to go production written in a later
version of JDev 11.1.1.2.0 dependent on the newer ADF Runtime Library
version 11.1.1.2.0.
For our existing WebLogic Server infrastructure we have development,
test and production servers at version 10.3.1. For the original
production ADF application the ADF Runtime Libraries v11.1.1.0.0 have
been installed on all WLS servers.
We now want to deploy our new ADF 11.1.1.2.0 application but have
immediately hit the limitation that 2 versions of the ADF Runtime
Libraries cannot be installed on the same WLS server at once. This is
a particularly annoying limitation as WLS actually supports running
multiple versions of deployed libraries, but the ADF Runtime Libraries
have been configured in such a way that different versions cant exist
on the same WLS server.
The only solution is to have separate WLS servers with separate ADF
Runtime Libraries installed. This creates a maintenance and
administration nightmare as we have to configure and maintain far more
WLS environments than we care to. In addition it raises concerns
about licensing as customers are pushed into creating more WLS
installs, all because the ADF Runtime Libraries dont support the multi-
versioned library capability of WLS.
Q) If possible, identify how the product can be changed to achieve the
desired result.
A) The ADF Runtime Libraries, and the ADF Runtime Library Installers
need to be changed such that multiple different versions of the
libraries can be supported from the same WLS server.
Q) Explain why Oracle Development should consider your Enhancement
Request.
A) From Oracle's point of view it's causing ADF customersto create
some very messy solutions to get around the problem, making ADF
applications must harder to maintain, and could be seen as a reason
for customers to *not* use ADF. Follow the following ADF EMG thread
to see what some customers are doing to get around the problem:
http://groups.google.com/group/adf-methodology/browse_thread/thread/0590f5db6226a7e9?hl=en#
Q) Describe the business impact if the Enhancement is not considered.
A) At the moment we're regression testing the original application to
upgrade it to the latest ADF Runtime Libraries so we only require WLS
servers with one version of the ADF Runtime Library. We would have
liked to avoid this regression testing but the other alternative is to
create multiple WLS servers, which we strongly want to avoid.
However our second application is much larger, and presumably in the
future we'll have a third application on an even newer version of the
ADF Runtime Libraries. This faces us with dread, either regression
test two applications, or create a huge array of WLS servers with
different ADF Runtime Libraries.
Q) Is this Enhancement affecting an implementation milestone?
A) Yes, as we're being forced to regression test an earlier
application to support the building of a newer application. The older
application must be completed ready to deploy to an "upgraded" WLS
environment as soon as the new application is ready, otherwise we
effectively have down time of one of our applications.
Regards,
CM.
Jan Vervecken
That sounds like very fair enhancement request, so +1 from me.
I wish Oracle had some easy means for people to indicate their
preference for certain enhancement requests, so that one could "vote
for" something like e.g. "allowing multiple ADF Runtime Libraries
versions". And because those things are all about making choices,
maybe people should be able to say where Oracle should spend less
effort like e.g. "creating ADF Business Components on a diagram".
Success with the enhancement request.
regards
Jan Vervecken
Chris Muir
the customer's experience beyond a Flashy front end.
For other readers' reference, ER 9322213 raised "REQUEST FOR
SUPPORTING MULTIPLE VERSIONS OF ADF RUNTIME LIBRARIES ON WLS". You
could take the opportunity to raise your own SR/ER and refer this one
to put some wait behind it.
Cheers,
CM.
Jan Vervecken
Got to love the pun ... "put some wait/weight behind it". :)
regards
Jan Vervecken